From Dieter.Bratko@iaik.tugraz.at Mon Oct 1 07:34:53 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F00A1F0D02 for ; Mon, 1 Oct 2012 07:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.17 X-Spam-Level: X-Spam-Status: No, score=0.17 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZmLUif+3g1f for ; Mon, 1 Oct 2012 07:34:52 -0700 (PDT) Received: from mailrelay.tugraz.at (mailrelay.tu-graz.ac.at [129.27.2.202]) by ietfa.amsl.com (Postfix) with ESMTP id 665081F0C7E for ; Mon, 1 Oct 2012 07:34:51 -0700 (PDT) Received: from thor.iaik.tugraz.at (mail1.iaik.tugraz.at [129.27.152.30]) (authenticated bits=0) by mailrelay2.tugraz.at (8.14.4/8.14.4) with ESMTP id q91EYbgQ012195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Oct 2012 16:34:37 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 mailrelay2.tugraz.at q91EYbgQ012195 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tugraz.at; s=mailrelay; t=1349102078; i=@iaik.tugraz.at; bh=i75xRl6CmWMH+WHvTVF8ElkR/kQHtuvyXB4n2hjM4Ik=; h=Message-ID:From:To:Cc:References:In-Reply-To:Subject:Date: MIME-Version:Content-Type:Content-Transfer-Encoding; b=G6HT0N19QlEwWa4NqhJ9ar3c+aAVvXSEM/qrfM2V46BJYd+msUXSe6dOmDPeqQv8S dCAqVQ8NpThBHyHNLnr0yq18Y6ZDboWcHpIPPyLoSDbt5jcsCrQ5tD9xmThSPJvomF 9s82JWfWRNZnn8WF1mtF+tbPgTjA9VTpNigZ//vs= Received: from camulos (unknown [10.27.152.149]) by thor.iaik.tugraz.at (Postfix) with SMTP id C0A381067B3A2; Mon, 1 Oct 2012 16:34:36 +0200 (CEST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.3 at mail1 Message-ID: <61FF8D803A75497B8EF2FDD14C1A36BC@iaik.tugraz.at> From: "Dieter Bratko" To: "Stephen Kent" References: <50579666.3040705@bbn.com> <5061BD72.6090202@bbn.com> In-Reply-To: <5061BD72.6090202@bbn.com> Date: Mon, 1 Oct 2012 16:34:36 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 X-TUG-Backscatter-control: biYb0C0m31NH2O/F2I9vDw X-Spam-Scanner: SpamAssassin 3.003000 X-Spam-Score-relay: -0.5 X-Scanned-By: MIMEDefang 2.70 on 129.27.10.19 Cc: pkix Subject: Re: [pkix] 5280bis X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 14:34:53 -0000 2- "better to avoid unintended revocation" Dieter -----Ursprüngliche Nachricht----- From: Stephen Kent Sent: Tuesday, September 25, 2012 4:19 PM To: Santosh Chokhani Cc: pkix Subject: Re: [pkix] 5280bis Santosh, I'm comfortable with "undetermined" as the outcome of a CRL check, if the WG would rather be on the side of avoiding unintended revocation (and thus, DoS), vs. a "better safe than sorry" strategy. What I have not seen is a clear indication of preferences in this regard, by other than 3 WG members. Only when we have a clear direction re the policy, can we work out the fine print for 5380bis. So, let's begin a straw poll today. 1- "better safe than sorry" 2- "better to avoid unintended revocation" 3- don't care This poll will close on October 1. Please, just send a reply with a number between 1 and 3. No rationale, no tirades, ... Thanks, Steve _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From peter.lipp@iaik.tugraz.at Mon Oct 1 11:39:52 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA2021F8A11 for ; Mon, 1 Oct 2012 11:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.43 X-Spam-Level: X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeZAwx+ZD41G for ; Mon, 1 Oct 2012 11:39:51 -0700 (PDT) Received: from mailrelay.tugraz.at (mailrelay.tu-graz.ac.at [129.27.2.202]) by ietfa.amsl.com (Postfix) with ESMTP id 3A44E21F8A10 for ; Mon, 1 Oct 2012 11:39:50 -0700 (PDT) Received: from thor.iaik.tugraz.at (mail1.iaik.tugraz.at [129.27.152.30]) (authenticated bits=0) by mailrelay1.tugraz.at (8.14.4/8.14.4) with ESMTP id q91Idljf007349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 1 Oct 2012 20:39:47 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 mailrelay1.tugraz.at q91Idljf007349 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tugraz.at; s=mailrelay; t=1349116789; i=@iaik.tugraz.at; bh=g81/mU9h4p7ruDJARWzHBfEorF0ejVjPaJkYKaTXhqw=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type; b=QZlym4BmsX1njJTO7ZbRMFF3n2ZkSzInXzYHeQI1pWGNZhCaghs/m/h61ToL9VY/u V2UMpgXb1iJeuuEr/+mmJqbwXvcWuz+echoiBcKCpHStygQIIbwd5ACvtBO4Yrf3lV dfKvI1RbNlCDUvihwWfpKxDTY0uE6nWtwgbkYGX8= Received: from [172.16.168.62] (openvpn2.iaik.tugraz.at [129.27.152.210]) by thor.iaik.tugraz.at (Postfix) with ESMTP id 725E01067B3A2 for ; Mon, 1 Oct 2012 20:39:47 +0200 (CEST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.3 at mail1 Message-ID: <5069E373.9090804@iaik.tugraz.at> Date: Mon, 01 Oct 2012 20:39:47 +0200 From: Peter Lipp User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: pkix@ietf.org References: <50579666.3040705@bbn.com> <5061BD72.6090202@bbn.com> <61FF8D803A75497B8EF2FDD14C1A36BC@iaik.tugraz.at> In-Reply-To: <61FF8D803A75497B8EF2FDD14C1A36BC@iaik.tugraz.at> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010408030507020407010502" X-TUG-Backscatter-control: vGe401nmNWfDyC8KKwXTHA X-Spam-Scanner: SpamAssassin 3.003000 X-Spam-Score-relay: -0.5 X-Scanned-By: MIMEDefang 2.70 on 129.27.10.18 Subject: Re: [pkix] 5280bis X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 18:39:52 -0000 This is a cryptographically signed message in MIME format. --------------ms010408030507020407010502 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2- "better to avoid unintended revocation" Peter --------------ms010408030507020407010502 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWSzCC BTcwggQfoAMCAQICBwJC3837YVMwDQYJKoZIhvcNAQEFBQAwUjELMAkGA1UEBhMCQVQxEDAO BgNVBAoTB0V1cm9QS0kxMTAvBgNVBAMTKEV1cm9QS0kgQXVzdHJpYW4gQ2VydGlmaWNhdGlv biBBdXRob3JpdHkwHhcNMDgwMjI4MTUxODA1WhcNMTMwMjI4MTUxODA1WjCBvTEtMCsGA1UE AxMkRXVyb1BLSSBJQUlLIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSYwJAYDVQQKEx1HcmF6 IFVuaXZlcnNpdHkgb2YgVGVjaG5vbG9neTFIMEYGA1UECxM/SW5zdGl0dXRlIGZvciBBcHBs aWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMQ0wCwYDVQQH EwRHcmF6MQswCQYDVQQGEwJBVDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJVq 1UDVNzO89IbYhmgg+0QFc2BlJ1THnyzK44Shmz0c5zQyhwHaSjeMgN8H1gg/tssRqDXKOuU7 wbF+QEKJNC+d80MQgy9627AmYdKBpPEnc9GU5YMkyL8hs15fXKraw5jKzOlsrn+ObokCX9dt g2Y26I/HHY9HeJVkEvi/fywXujTH9qV7k/tGZbgperfoylz8poBbhwysNQAY2pxz0QjCRMDH Waga3y7u/8JOBYiKVduEHUEEGOn4LL26QFf4efCKZaUBwoUNOqbAWaAkD5CUIRBgezSjbKVY X7jU3wyK8uViq+pCWk4WpZK0GkqvyXGRyOkVHMWvLY5FaUrXr5sCAwEAAaOCAaQwggGgMA4G A1UdDwEB/wQEAwIBxjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBQ5dMfdyPH7CnA9Dsp9 RQKsoZvXnjBWBgNVHSAETzBNMEsGDCsGAQQBlRIBAgEBATA7MDkGCCsGAQUFBwIBFi1odHRw Oi8vZXVyb3BraS5pYWlrLmF0L2NhL2V1cm9wa2ktYXQvY3BzLzEuMS8wSAYDVR0fBEEwPzA9 oDugOYY3aHR0cDovL2NhLmlhaWsudHVncmF6LmF0L2NhcHNvL2NybHMvRXVyb1BLSUF1c3Ry aWFuLmNybDCBmgYIKwYBBQUHAQEEgY0wgYowQgYIKwYBBQUHMAGGNmh0dHA6Ly9jYS5pYWlr LnR1Z3Jhei5hdC9jYXBzby9PQ1NQP2NhPUV1cm9QS0lBdXN0cmlhbjBEBggrBgEFBQcwAoY4 aHR0cDovL2NhLmlhaWsudHVncmF6LmF0L2NhcHNvL2NlcnRzL0V1cm9QS0lBdXN0cmlhbi5j ZXIwHwYDVR0jBBgwFoAUdCnYUa/CPJin1/8xj0D3UOgHAegwDQYJKoZIhvcNAQEFBQADggEB AKaxhz5F2t93exXyOoOKlGR38EYTAYWJbJ1OYQxGKbKvZKao1VfiSGMATItxWPJgr4Vz5dET A621hwpAcUppFlENvLRG+eLA/ctfUO7fFecQeKP2gHoDZoRODWi4CcKKRdBDgLd4F8z29or1 VHST9qRqorNNM8GXxqjtOY59NN0gGtVKg9iN5dH+qbUDfic9vSBHmwEwRkRxmAM3agpIOysr ZsensAbfpH8C2cbJbiPWEjmFHflUKYBOjPh1tQqFmMMUlT4WCYA0BaHT4B61KFDuqlLojIdf F0MZhb/tIdvBayLimZGdGb/FpgtUKjfNEkPBpercmUo6HZWJ/ggXMCAwggWAMIIEaKADAgEC AgcDQOsnGTZ8MA0GCSqGSIb3DQEBBQUAMIG9MS0wKwYDVQQDEyRFdXJvUEtJIElBSUsgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkxJjAkBgNVBAoTHUdyYXogVW5pdmVyc2l0eSBvZiBUZWNo bm9sb2d5MUgwRgYDVQQLEz9JbnN0aXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJv Y2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxDTALBgNVBAcTBEdyYXoxCzAJBgNVBAYTAkFU MB4XDTA4MDIyODE1NDQxN1oXDTEzMDIyODE1NDQxN1owgawxHDAaBgNVBAMTE0V1cm9QS0kg SUFJSyBTaWcgQ0ExJjAkBgNVBAoTHUdyYXogVW5pdmVyc2l0eSBvZiBUZWNobm9sb2d5MUgw RgYDVQQLEz9JbnN0aXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJvY2Vzc2luZyBh bmQgQ29tbXVuaWNhdGlvbnMxDTALBgNVBAcTBEdyYXoxCzAJBgNVBAYTAkFUMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsGzZTb+VNeeiZeGA1QtaQBdLnTsDpS2axusAhdcr tchaDKNsqJgBKt16PQs8oa4W3Ftn4D97VxJXzKsJawH7izyNnAv7FtZ5cgZxopqu/Sel5dKp fRRmXsMzmZUgP4XAbVPveqOYga8TqLmoOc0S/SyIZ6K3ubQAfd0Xa5ySrp4q6jMC9yGUk5CT bs+po9EUJLkA+II0GsH0BRKGNcweyjXALWtrGWwYNz/Kd4LZng44FkuSzA8gy7SpTBV8ZVHu 7dYUsQ/dw9fDyVZvUprwbMYsGK+3g9HP7DKJsN9bH+L9KeFPN8S4HjLU8WO+wVDejdqbbMem q/LVY99SzFEtDQIDAQABo4IBkjCCAY4wDgYDVR0PAQH/BAQDAgHGMA8GA1UdEwEB/wQFMAMB Af8wHQYDVR0OBBYEFK7uVQYXelMRExirpM4ccQkagxTzMFAGA1UdIARJMEcwRQYMKwYBBAGV EgECAwEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6Ly9ldXJvcGtpLmlhaWsuYXQvY2EvaWFpay9j cHMvMS4zLzBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY2EuaWFpay50dWdyYXouYXQvY2Fw c28vY3Jscy9FdXJvUEtJSUFJSy5jcmwwgZIGCCsGAQUFBwEBBIGFMIGCMD4GCCsGAQUFBzAB hjJodHRwOi8vY2EuaWFpay50dWdyYXouYXQvY2Fwc28vT0NTUD9jYT1FdXJvUEtJSUFJSzBA BggrBgEFBQcwAoY0aHR0cDovL2NhLmlhaWsudHVncmF6LmF0L2NhcHNvL2NlcnRzL0V1cm9Q S0lJQUlLLmNlcjAfBgNVHSMEGDAWgBQ5dMfdyPH7CnA9Dsp9RQKsoZvXnjANBgkqhkiG9w0B AQUFAAOCAQEACDKzfAnYKLFwLwq647dr2Ty7SdPT49p8tH3AxAxazPvENMs3GJMkqcu90XDz oP4If6dfFHB6j8oNVhPnqrmt8qzjkjqZkNX7P/B5w1feh1Yy5jlrqPSD9FHhDP/CiR95TN9/ liLoeHU/1x7S7f8QcAdqdwkjcXGhmktTmo1Zk2j58jqeW44GZ0kJZmAJH2KO5yYW5ue7gRta XKGIfZ7Qfa1pTrNa9b/zfKpsQ7QGEMpVZZW1a+UX+m0FlAQnMAPWrlcmhs81D8gA1+zllx+4 LX4+boUQbRwxWcMIaVGgDnuhMgVo4NZA+viDEzLXX8xh71W58GKHkBTXPpXgjAnlJjCCBcIw ggSqoAMCAQICBwFhZm8b+RYwDQYJKoZIhvcNAQEFBQAwgawxHDAaBgNVBAMTE0V1cm9QS0kg SUFJSyBFbmMgQ0ExJjAkBgNVBAoTHUdyYXogVW5pdmVyc2l0eSBvZiBUZWNobm9sb2d5MUgw RgYDVQQLEz9JbnN0aXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJvY2Vzc2luZyBh bmQgQ29tbXVuaWNhdGlvbnMxDTALBgNVBAcTBEdyYXoxCzAJBgNVBAYTAkFUMB4XDTA5MTEx OTExNDYxOVoXDTEyMTExOTExNDYxOVowgdAxDjAMBgNVBCoTBVBldGVyMQ0wCwYDVQQEEwRM aXBwMRMwEQYDVQQDEwpQZXRlciBMaXBwMQwwCgYDVQQMEwNEci4xJjAkBgNVBAoTHUdyYXog VW5pdmVyc2l0eSBvZiBUZWNobm9sb2d5MUgwRgYDVQQLEz9JbnN0aXR1dGUgZm9yIEFwcGxp ZWQgSW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxDTALBgNVBAcT BEdyYXoxCzAJBgNVBAYTAkFUMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvF8g TgGsneIWz4ByBdZUpqY7pQYARL4fQqx7aoshsn8Ic6miT/pwaIUizu/EoGiMKLNveda+1z1i vX1211UJ6aZ0Z2NtpVqs+rbGPrjgCGk8aKdhDdlP9a+ztdmZkVdUqR2hY+gSAZOXCXwP3Mdg z55/CHVVnDxdRpPBmFQBiwWIeTYBX+zxHClBTpO7eaTzmyySyFCmubINa6D6JW8hWzjM9paa MUjqaRH0n3XajPgS6xM5LQVCnGWXJiddehXcRhctcsPghiGyiHd0iiK6MWxcK07m5NZ2feoT cYPX925S/u93E8mRd1u90GSWmb6+sGPJoPm5DJgbSmW1CvcWqwIDAQABo4IBwTCCAb0wDgYD VR0PAQH/BAQDAgQwMAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFJRS55U4eV+6ExWuuhfeT8NJ CODKMFAGA1UdIARJMEcwRQYMKwYBBAGVEgECAwEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6Ly9l dXJvcGtpLmlhaWsuYXQvY2EvaWFpay9jcHMvMS4zLzBIBgNVHR8EQTA/MD2gO6A5hjdodHRw Oi8vY2EuaWFpay50dWdyYXouYXQvY2Fwc28vY3Jscy9FdXJvUEtJSUFJS19FbmMuY3JsMIGa BggrBgEFBQcBAQSBjTCBijBCBggrBgEFBQcwAYY2aHR0cDovL2NhLmlhaWsudHVncmF6LmF0 L2NhcHNvL09DU1A/Y2E9RXVyb1BLSUlBSUtfRW5jMEQGCCsGAQUFBzAChjhodHRwOi8vY2Eu aWFpay50dWdyYXouYXQvY2Fwc28vY2VydHMvRXVyb1BLSUlBSUtfRW5jLmNlcjAkBgNVHREE HTAbgRlwZXRlci5saXBwQGlhaWsudHVncmF6LmF0MB8GA1UdIwQYMBaAFN1D9vfJDRGWYE0E pVZCGBIkptrqMA0GCSqGSIb3DQEBBQUAA4IBAQANcXhJ5ho+Mvyx9LH7uAFelQvdqRxAOMIA b8WBeQlW8/dIQB6rII216cHTEordXvC3RmbiACd016FDISGhUm4O70onH0MW0Uw2a4Gonnjp wFTsXwIvtIcmUMmgUPqge1irGkD82VxMNHJ1YKcSqaCHzqoPE+Yh766Rse7nuzSbEd5qjpPk RBdVLdkIS46FBr7/rTIG2gfPtM1ggy5aTEvRKB0TV49PuJkvL7IaeaIsgq2ic9dgM5gKux8S 08gIVd5u2xn7zJl9xIvpgLY4Ctk0dECRSr8y9lznFcwhxuIlenCwocNqoEg46Lfb+HFyj9N8 RK1JqunwO+bT9HOxOLfDMIIFwjCCBKqgAwIBAgIHAdFk/RDIFzANBgkqhkiG9w0BAQUFADCB rDEcMBoGA1UEAxMTRXVyb1BLSSBJQUlLIFNpZyBDQTEmMCQGA1UEChMdR3JheiBVbml2ZXJz aXR5IG9mIFRlY2hub2xvZ3kxSDBGBgNVBAsTP0luc3RpdHV0ZSBmb3IgQXBwbGllZCBJbmZv cm1hdGlvbiBQcm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczENMAsGA1UEBxMER3JhejEL MAkGA1UEBhMCQVQwHhcNMDkxMTE5MTE0NjMxWhcNMTIxMTE5MTE0NjMxWjCB0DEOMAwGA1UE KhMFUGV0ZXIxDTALBgNVBAQTBExpcHAxEzARBgNVBAMTClBldGVyIExpcHAxDDAKBgNVBAwT A0RyLjEmMCQGA1UEChMdR3JheiBVbml2ZXJzaXR5IG9mIFRlY2hub2xvZ3kxSDBGBgNVBAsT P0luc3RpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFuZCBDb21t dW5pY2F0aW9uczENMAsGA1UEBxMER3JhejELMAkGA1UEBhMCQVQwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDL6sQFpL2CwqJdGzkLY5tC+wCbMhIqtWdG/5mj4YNqmJMU+Mef co3pTN/z33FV/l1gO6wKkuIE4VGsWGcgUjQ5ZjX6osWKRL1ItE4UtMOEM2tdQUe+Uz6tQadJ osE7Vnio6gMVVlVT7oN+Vd/y1gGrHHyErcJQnKHv+iTDabtbeIXpJUO7Eotw406japqFpkSh cZlJFmyDVGff/QgnhNF094W9qH996D3bdMbB0mY4Yqvnw08mjwCJevgFEE6xyvdY6thaaYLv VTaAyQeE0GFwHssoLTz26SHperXO/pf+bJRHgD3Shu1tkZQ18aYm7nkguB0n/i+u8dioit5M CEaVAgMBAAGjggHBMIIBvTAOBgNVHQ8BAf8EBAMCBsAwDAYDVR0TAQH/BAIwADAdBgNVHQ4E FgQUpm0feVvkApmWWcxOYnS4VgdARjEwUAYDVR0gBEkwRzBFBgwrBgEEAZUSAQIDAQEwNTAz BggrBgEFBQcCARYnaHR0cDovL2V1cm9wa2kuaWFpay5hdC9jYS9pYWlrL2Nwcy8xLjMvMEgG A1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jYS5pYWlrLnR1Z3Jhei5hdC9jYXBzby9jcmxzL0V1 cm9QS0lJQUlLX1NpZy5jcmwwgZoGCCsGAQUFBwEBBIGNMIGKMEIGCCsGAQUFBzABhjZodHRw Oi8vY2EuaWFpay50dWdyYXouYXQvY2Fwc28vT0NTUD9jYT1FdXJvUEtJSUFJS19TaWcwRAYI KwYBBQUHMAKGOGh0dHA6Ly9jYS5pYWlrLnR1Z3Jhei5hdC9jYXBzby9jZXJ0cy9FdXJvUEtJ SUFJS19TaWcuY2VyMCQGA1UdEQQdMBuBGXBldGVyLmxpcHBAaWFpay50dWdyYXouYXQwHwYD VR0jBBgwFoAUru5VBhd6UxETGKukzhxxCRqDFPMwDQYJKoZIhvcNAQEFBQADggEBAC0dV7R6 4nwjR6kz8sVxsD6rG7lnBVInRFfWTw4Lyl54+UFF9AkmLRUtNU8hsXZT/86x1p1dQVCMcWxe e9edSXvhKyEte4/agOWXHFlCVXkC+LdyIl56jlfVMqqGg+9dTlojAyOnQcYltQf40ptMxpc+ KqJzIa+MONvJ58fahysJMM9YPm39TXOWE/nVOtyKL7wqKnMDYfY3Xa3p+heQ5rIvvCXHwLeM 4pajlkF+OktWQoHs2kNnK60F3OXEFln4N1gLsdVEvSFMgjFjjSHSzQcNgewdXHZ+mXbCeZl5 7L1cfRClykMEcTmWeNdEpNcXNsR2iTDhmzPNHXV9UQ2a4McxggRJMIIERQIBATCBuDCBrDEc MBoGA1UEAxMTRXVyb1BLSSBJQUlLIFNpZyBDQTEmMCQGA1UEChMdR3JheiBVbml2ZXJzaXR5 IG9mIFRlY2hub2xvZ3kxSDBGBgNVBAsTP0luc3RpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1h dGlvbiBQcm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczENMAsGA1UEBxMER3JhejELMAkG A1UEBhMCQVQCBwHRZP0QyBcwCQYFKw4DAhoFAKCCAmUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMDAxMTgzOTQ3WjAjBgkqhkiG9w0BCQQxFgQUKBuv 2Ot+ADvB3zsJbMd1t1u2f/4wbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDCByQYJKwYBBAGCNxAEMYG7MIG4MIGsMRwwGgYDVQQDExNF dXJvUEtJIElBSUsgRW5jIENBMSYwJAYDVQQKEx1HcmF6IFVuaXZlcnNpdHkgb2YgVGVjaG5v bG9neTFIMEYGA1UECxM/SW5zdGl0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9uIFByb2Nl c3NpbmcgYW5kIENvbW11bmljYXRpb25zMQ0wCwYDVQQHEwRHcmF6MQswCQYDVQQGEwJBVAIH AWFmbxv5FjCBywYLKoZIhvcNAQkQAgsxgbuggbgwgawxHDAaBgNVBAMTE0V1cm9QS0kgSUFJ SyBFbmMgQ0ExJjAkBgNVBAoTHUdyYXogVW5pdmVyc2l0eSBvZiBUZWNobm9sb2d5MUgwRgYD VQQLEz9JbnN0aXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQg Q29tbXVuaWNhdGlvbnMxDTALBgNVBAcTBEdyYXoxCzAJBgNVBAYTAkFUAgcBYWZvG/kWMA0G CSqGSIb3DQEBAQUABIIBAAU3uZWcwEXJtxHD5YhQJqwPFR9bdYG+X8GEG4ws+rjScxvzz5MX UlTzTZucFJ3h3Snr2sLZ9jylNp5nL7WqjeYbdBLQs3pjFqYKODsldKKpkDvFJwpvHBnhaw2W tboM4F4PQAMfWtD0vGx10EuWQw29jsOF566FdBwtNl/vE2qQg31zTn132OCPPf4Z0v266QA0 Z2RNpwSDhkg9j1QIBGHyFOxqDDrp4ZL+4LB2f58qaWswU1mzMmxQGejnxPfv5HklenNxh8yf 9d8jv6RN+Em1P7Yb70FB3hQ97yKnAE3cONgMAwskB0ewNu+w51aZk0J4QEOHx2Y3mXZ837Z2 NM4AAAAAAAA= --------------ms010408030507020407010502-- From kent@bbn.com Tue Oct 2 09:24:56 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC7721F84DC for ; Tue, 2 Oct 2012 09:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.602 X-Spam-Level: X-Spam-Status: No, score=-105.602 tagged_above=-999 required=5 tests=[AWL=-0.863, BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYMijCrGrV1z for ; Tue, 2 Oct 2012 09:24:52 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3263121F84D8 for ; Tue, 2 Oct 2012 09:24:52 -0700 (PDT) Received: from dhcp89-089-176.bbn.com ([128.89.89.176]:51733) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TJ5H5-000DYP-Ka for pkix@ietf.org; Tue, 02 Oct 2012 12:24:47 -0400 Message-ID: <506B154F.3080501@bbn.com> Date: Tue, 02 Oct 2012 12:24:47 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: pkix Content-Type: multipart/alternative; boundary="------------080405050605000008050904" Subject: [pkix] 5280bis CRL problem poll results X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 16:24:56 -0000 This is a multi-part message in MIME format. --------------080405050605000008050904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Folks, It is apparent from the straw poll that there is no WG consensus on this topic. I propose the following text, in lieu of the current "new second paragraph" that appears in Section 4 of draft-ietf-pkix-rfc5280-clarifications-09.txt: A critical extension in the crlEntryExtensions field of an entrySHALL affect only the certificate specified in that entry, unless there is a related critical extension in the crlExtensions field that advertises a special treatment for it. If a relying party is unable to process both a critical crlEntryExtension and a related critical crlExtension, the relying party is faced with a difficult choice. 1-The relying party may assume that the the CRLEntry is associated with the CA that issued the CRL, and thus treat that certificate as revoked. If the CRLEntry refers to a certificate issued by a different CA, the relying party will treat a valid certificate as being revoked. 2-The relying party, realizing that it cannot accurately determine if the CRLEntry is associated with the CA that issued the CRL, may choose to treat that certificate as having an undetermined revocation status. If the relying party is able to consult other sources of certificate revocation status (e.g., OCSP) it may use those sources instead. If not, the relying party may accept or reject the certificate as a matter of local policy. 3-The relying party may view the CRLEntry as being associated with an undetermined CA, and treat all certificates with that serialNumber as being revoked. This behavior runs the risk of treating a number of valid certificates as revoked. Because each of these options has associated risks, this document does not specify relying party behavior under the circumstances noted above. A relying party may accept or reject certificates with the indicated serialNumber as a matter of local policy. How does the WG feel about this alternate text? Steve --------------080405050605000008050904 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Folks,

 

It is apparent from the straw poll that there is no WG consensus on this topic.

 

I propose the following text, in lieu of the current “new second paragraph” that appears in Section 4 of draft-ietf-pkix-rfc5280-clarifications-09.txt:

 

A critical extension in the crlEntryExtensions field of an entry SHALL affect only the certificate specified in that entry, unless there is a related critical extension in the crlExtensions field that advertises a special treatment for it. If a relying party is unable to process both a critical crlEntryExtension and a related critical crlExtension, the relying party is faced with a difficult choice.

 

1-  The relying party may assume that the the CRLEntry is associated with the CA that issued the CRL, and thus treat that certificate as revoked. If the CRLEntry refers to a certificate issued by a different CA, the relying party will treat a valid certificate as being revoked.


2-  The relying party, realizing that it cannot accurately determine if the CRLEntry is associated with the CA that issued the CRL, may choose to treat that certificate as having an undetermined revocation status. If the relying party is able to consult other sources of certificate revocation status (e.g., OCSP) it may use those sources instead. If not, the relying party may accept or reject the certificate as a matter of local policy.


3-  The relying party may view the CRLEntry as being associated with an undetermined CA, and treat all certificates with that serialNumber as being revoked. This behavior runs the risk of treating a number of valid certificates as revoked.

 

Because each of these options has associated risks, this document does not specify relying party behavior under the circumstances noted above. A relying party may accept or reject certificates with the indicated serialNumber as a matter of local policy.

How does the WG feel about this alternate text?

Steve

--------------080405050605000008050904-- From denis.pinkas@bull.net Tue Oct 2 10:20:03 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D431121F84F9; Tue, 2 Oct 2012 10:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4ar3IMNs4yz; Tue, 2 Oct 2012 10:20:03 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 15AF121F84F6; Tue, 2 Oct 2012 10:20:01 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id BBB1B1C5F4; Tue, 2 Oct 2012 19:20:00 +0200 (CEST) In-Reply-To: <506B154F.3080501@bbn.com> References: <506B154F.3080501@bbn.com> To: Stephen Kent MIME-Version: 1.0 X-KeepSent: 5A506F3F:313DE22B-C1257A8B:005E4E82; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Tue, 2 Oct 2012 19:20:06 +0200 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 02/10/2012 19:20:00, Serialize complete at 02/10/2012 19:20:00 Content-Type: multipart/alternative; boundary="=_alternative 005F26E4C1257A8B_=" Cc: pkix , pkix-bounces@ietf.org Subject: Re: [pkix] 5280bis CRL problem poll results X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 17:20:04 -0000 Message en plusieurs parties au format MIME --=_alternative 005F26E4C1257A8B_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 U3RldmUsDQoNCkZpcnN0IG9mIGFsbCwgaXQgaXMgbmljZSBmcm9tIHlvdSB0byBwcm92aWRlIGEg c3RyYXdtYW4gdGV4dCBwcm9wb3NhbC4NCg0KSSBkb24ndCB1bmRlcnN0YW5kIHdoeSB0aGUgZm9s bG93aW5nIHNlbnRlbmNlIGhhcyBiZWVuIGRlbGV0ZWQgaW4gdGhlIG5ldyANCnRleHQgcHJvcG9z YWw6DQoNCiIgSW4gb3JkZXIgdG8gdXNlIHN1Y2ggYSBDUkwsIHRoZSByZWx5aW5nIHBhcnR5IE1V U1QgYmUgYWJsZSB0byBwcm9jZXNzIA0KYm90aCANCnRoZSBjcmxFbnRyeUV4dGVuc2lvbiBhbmQg dGhlIHJlbGF0ZWQgY3JsRXh0ZW5zaW9uIi4NCg0KSSBiZWxpZXZlIGl0IHNob3VsZCBzdGF5LiBU aGVuLCB0aGUgcHJvcG9zZWQgdGV4dCBzdGF0ZXM6DQpJZiBhIHJlbHlpbmcgcGFydHkgaXMgdW5h YmxlIHRvIHByb2Nlc3MgYm90aCBhIGNyaXRpY2FsIGNybEVudHJ5RXh0ZW5zaW9uIA0KYW5kIA0K YSByZWxhdGVkIGNyaXRpY2FsIGNybEV4dGVuc2lvbiwgdGhlIHJlbHlpbmcgcGFydHkgaXMgZmFj ZWQgd2l0aCBhIA0KZGlmZmljdWx0IGNob2ljZQ0KDQpNeSBxdWVzdGlvbiBpcyB0aGUgZm9sbG93 aW5nOiBpZiBhIHJlbHlpbmcgcGFydHkgaXMgdW5hYmxlIHRvIHByb2Nlc3MgYm90aCANCmEgY3Jp dGljYWwgY3JsRW50cnlFeHRlbnNpb24gYW5kIA0KYSBjcml0aWNhbCBjcmxFeHRlbnNpb24sIGhv dyBjYW4gaGUga25vdyB0aGF0IHRoZXkgYXJlIHJlbGF0ZWQgPw0KDQpEZW5pcw0KDQoNCg0KDQpE ZSA6ICAgIFN0ZXBoZW4gS2VudCA8a2VudEBiYm4uY29tPg0KQSA6ICAgICBwa2l4IDxwa2l4QGll dGYub3JnPg0KRGF0ZSA6ICAwMi8xMC8yMDEyIDE4OjI1DQpPYmpldCA6IFtwa2l4XSA1MjgwYmlz IENSTCBwcm9ibGVtIHBvbGwgcmVzdWx0cw0KRW52b3nDqSBwYXIgOiAgICBwa2l4LWJvdW5jZXNA aWV0Zi5vcmcNCg0KDQoNCkZvbGtzLA0KIA0KSXQgaXMgYXBwYXJlbnQgZnJvbSB0aGUgc3RyYXcg cG9sbCB0aGF0IHRoZXJlIGlzIG5vIFdHIGNvbnNlbnN1cyBvbiB0aGlzIA0KdG9waWMuDQogDQpJ IHByb3Bvc2UgdGhlIGZvbGxvd2luZyB0ZXh0LCBpbiBsaWV1IG9mIHRoZSBjdXJyZW50IOKAnG5l dyBzZWNvbmQgDQpwYXJhZ3JhcGjigJ0gdGhhdCBhcHBlYXJzIGluIFNlY3Rpb24gNCBvZiANCmRy YWZ0LWlldGYtcGtpeC1yZmM1MjgwLWNsYXJpZmljYXRpb25zLTA5LnR4dDoNCiANCkEgY3JpdGlj YWwgZXh0ZW5zaW9uIGluIHRoZSBjcmxFbnRyeUV4dGVuc2lvbnMgZmllbGQgb2YgYW4gZW50cnkg U0hBTEwgDQphZmZlY3Qgb25seSB0aGUgY2VydGlmaWNhdGUgc3BlY2lmaWVkIGluIHRoYXQgZW50 cnksIHVubGVzcyB0aGVyZSBpcyBhIA0KcmVsYXRlZCBjcml0aWNhbCBleHRlbnNpb24gaW4gdGhl IGNybEV4dGVuc2lvbnMgZmllbGQgdGhhdCBhZHZlcnRpc2VzIGEgDQpzcGVjaWFsIHRyZWF0bWVu dCBmb3IgaXQuIElmIGEgcmVseWluZyBwYXJ0eSBpcyB1bmFibGUgdG8gcHJvY2VzcyBib3RoIGEg DQpjcml0aWNhbCBjcmxFbnRyeUV4dGVuc2lvbiBhbmQgYSByZWxhdGVkIGNyaXRpY2FsIGNybEV4 dGVuc2lvbiwgdGhlIA0KcmVseWluZyBwYXJ0eSBpcyBmYWNlZCB3aXRoIGEgZGlmZmljdWx0IGNo b2ljZS4NCiANCjEtICBUaGUgcmVseWluZyBwYXJ0eSBtYXkgYXNzdW1lIHRoYXQgdGhlIHRoZSBD UkxFbnRyeSBpcyBhc3NvY2lhdGVkIHdpdGggDQp0aGUgQ0EgdGhhdCBpc3N1ZWQgdGhlIENSTCwg YW5kIHRodXMgdHJlYXQgdGhhdCBjZXJ0aWZpY2F0ZSBhcyByZXZva2VkLiBJZiANCnRoZSBDUkxF bnRyeSByZWZlcnMgdG8gYSBjZXJ0aWZpY2F0ZSBpc3N1ZWQgYnkgYSBkaWZmZXJlbnQgQ0EsIHRo ZSByZWx5aW5nIA0KcGFydHkgd2lsbCB0cmVhdCBhIHZhbGlkIGNlcnRpZmljYXRlIGFzIGJlaW5n IHJldm9rZWQuDQoNCjItICBUaGUgcmVseWluZyBwYXJ0eSwgcmVhbGl6aW5nIHRoYXQgaXQgY2Fu bm90IGFjY3VyYXRlbHkgZGV0ZXJtaW5lIGlmIA0KdGhlIENSTEVudHJ5IGlzIGFzc29jaWF0ZWQg d2l0aCB0aGUgQ0EgdGhhdCBpc3N1ZWQgdGhlIENSTCwgbWF5IGNob29zZSB0byANCnRyZWF0IHRo YXQgY2VydGlmaWNhdGUgYXMgaGF2aW5nIGFuIHVuZGV0ZXJtaW5lZCByZXZvY2F0aW9uIHN0YXR1 cy4gSWYgdGhlIA0KcmVseWluZyBwYXJ0eSBpcyBhYmxlIHRvIGNvbnN1bHQgb3RoZXIgc291cmNl cyBvZiBjZXJ0aWZpY2F0ZSByZXZvY2F0aW9uIA0Kc3RhdHVzIChlLmcuLCBPQ1NQKSBpdCBtYXkg dXNlIHRob3NlIHNvdXJjZXMgaW5zdGVhZC4gSWYgbm90LCB0aGUgcmVseWluZyANCnBhcnR5IG1h eSBhY2NlcHQgb3IgcmVqZWN0IHRoZSBjZXJ0aWZpY2F0ZSBhcyBhIG1hdHRlciBvZiBsb2NhbCBw b2xpY3kuDQoNCjMtICBUaGUgcmVseWluZyBwYXJ0eSBtYXkgdmlldyB0aGUgQ1JMRW50cnkgYXMg YmVpbmcgYXNzb2NpYXRlZCB3aXRoIGFuIA0KdW5kZXRlcm1pbmVkIENBLCBhbmQgdHJlYXQgYWxs IGNlcnRpZmljYXRlcyB3aXRoIHRoYXQgc2VyaWFsTnVtYmVyIGFzIA0KYmVpbmcgcmV2b2tlZC4g VGhpcyBiZWhhdmlvciBydW5zIHRoZSByaXNrIG9mIHRyZWF0aW5nIGEgbnVtYmVyIG9mIHZhbGlk IA0KY2VydGlmaWNhdGVzIGFzIHJldm9rZWQuDQogDQpCZWNhdXNlIGVhY2ggb2YgdGhlc2Ugb3B0 aW9ucyBoYXMgYXNzb2NpYXRlZCByaXNrcywgdGhpcyBkb2N1bWVudCBkb2VzIG5vdCANCnNwZWNp ZnkgcmVseWluZyBwYXJ0eSBiZWhhdmlvciB1bmRlciB0aGUgY2lyY3Vtc3RhbmNlcyBub3RlZCBh Ym92ZS4gQSANCnJlbHlpbmcgcGFydHkgbWF5IGFjY2VwdCBvciByZWplY3QgY2VydGlmaWNhdGVz IHdpdGggdGhlIGluZGljYXRlZCANCnNlcmlhbE51bWJlciBhcyBhIG1hdHRlciBvZiBsb2NhbCBw b2xpY3kuDQoNCkhvdyBkb2VzIHRoZSBXRyBmZWVsIGFib3V0IHRoaXMgYWx0ZXJuYXRlIHRleHQ/ DQoNClN0ZXZlX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CnBraXggbWFpbGluZyBsaXN0DQpwa2l4QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3BraXgNCg0KDQo= --=_alternative 005F26E4C1257A8B_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5TdGV2ZSw8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9IkFyaWFsIj5GaXJzdCBvZiBhbGwsIGl0IGlzIG5pY2UgZnJvbSB5b3UgdG8g cHJvdmlkZQ0KYSBzdHJhd21hbiB0ZXh0IHByb3Bvc2FsLjwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0iQXJpYWwiPkkgZG9uJ3QgdW5kZXJzdGFuZCB3aHkgdGhlIGZvbGxvd2lu ZyBzZW50ZW5jZQ0KaGFzIGJlZW4gZGVsZXRlZCBpbiB0aGUgbmV3IHRleHQgcHJvcG9zYWw6PC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+JnF1b3Q7IElu IG9yZGVyIHRvIHVzZSBzdWNoIGEgQ1JMLA0KdGhlIHJlbHlpbmcgcGFydHkgTVVTVCBiZSBhYmxl IHRvIHByb2Nlc3MgYm90aCA8YnI+DQp0aGUgY3JsRW50cnlFeHRlbnNpb24gYW5kIHRoZSByZWxh dGVkIGNybEV4dGVuc2lvbiZxdW90Oy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9IkFyaWFsIj5JIGJlbGlldmUgaXQgc2hvdWxkIHN0YXkuIFRoZW4sIHRoZSBwcm9wb3NlZA0K dGV4dCBzdGF0ZXM6PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5J ZiBhIHJlbHlpbmcgcGFydHkgaXMgdW5hYmxlIHRvIHByb2Nlc3MNCmJvdGggYSBjcml0aWNhbCBj cmxFbnRyeUV4dGVuc2lvbiBhbmQgPGJyPg0KYSA8Yj5yZWxhdGVkIDwvYj5jcml0aWNhbCBjcmxF eHRlbnNpb24sIHRoZSByZWx5aW5nIHBhcnR5IGlzIGZhY2VkIHdpdGgNCmEgZGlmZmljdWx0IGNo b2ljZTwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPk15IHF1ZXN0 aW9uIGlzIHRoZSBmb2xsb3dpbmc6IGlmIGEgcmVseWluZw0KcGFydHkgaXMgdW5hYmxlIHRvIHBy b2Nlc3MgYm90aCBhIGNyaXRpY2FsIGNybEVudHJ5RXh0ZW5zaW9uIGFuZCA8YnI+DQphIGNyaXRp Y2FsIGNybEV4dGVuc2lvbiwgaG93IGNhbiBoZSBrbm93IHRoYXQgdGhleSBhcmUgcmVsYXRlZCA/ PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+RGVuaXM8L2ZvbnQ+ DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYg ZmFjZT0ic2Fucy1zZXJpZiI+RGUgOiAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7PC9mb250 Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5TdGVwaGVuIEtlbnQgJmx0O2tlbnRAYmJu LmNvbSZndDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fu cy1zZXJpZiI+QSA6ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDs8L2ZvbnQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPnBraXggJmx0O3BraXhAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0K PGJyPjxmb250IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9InNhbnMtc2VyaWYiPkRhdGUgOiAm bmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj4wMi8xMC8yMDEyIDE4OjI1PC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBjb2xvcj0j NWY1ZjVmIGZhY2U9InNhbnMtc2VyaWYiPk9iamV0IDogJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZu YnNwOzwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+W3BraXhdIDUyODBiaXMN CkNSTCBwcm9ibGVtIHBvbGwgcmVzdWx0czwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgY29sb3I9 IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5FbnZvecOpIHBhciA6ICZuYnNwOyAmbmJzcDsNCiZu YnNwOyAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPnBraXgtYm91 bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxicj4NCjxociBub3NoYWRlPg0KPGJyPg0KPGJyPg0KPGJy Pjxmb250IHNpemU9Mj5Gb2xrcyw8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTI+Jm5ic3A7PC9mb250 Pg0KPHA+PGZvbnQgc2l6ZT0yPkl0IGlzIGFwcGFyZW50IGZyb20gdGhlIHN0cmF3IHBvbGwgdGhh dCB0aGVyZSBpcyBubyBXRw0KY29uc2Vuc3VzIG9uIHRoaXMgdG9waWMuPC9mb250Pg0KPHA+PGZv bnQgc2l6ZT0yPiZuYnNwOzwvZm9udD4NCjxwPjxmb250IHNpemU9Mj5JIHByb3Bvc2UgdGhlIGZv bGxvd2luZyB0ZXh0LCBpbiBsaWV1IG9mIHRoZSBjdXJyZW50IOKAnG5ldw0Kc2Vjb25kIHBhcmFn cmFwaOKAnSB0aGF0IGFwcGVhcnMgaW4gU2VjdGlvbiA0IG9mIGRyYWZ0LWlldGYtcGtpeC1yZmM1 MjgwLWNsYXJpZmljYXRpb25zLTA5LnR4dDo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTI+Jm5ic3A7 PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0yPkEgY3JpdGljYWwgZXh0ZW5zaW9uIGluIHRoZSBjcmxF bnRyeUV4dGVuc2lvbnMgZmllbGQgb2YNCmFuIGVudHJ5IFNIQUxMIGFmZmVjdCBvbmx5IHRoZSBj ZXJ0aWZpY2F0ZSBzcGVjaWZpZWQgaW4gdGhhdCBlbnRyeSwgdW5sZXNzDQp0aGVyZSBpcyBhIHJl bGF0ZWQgY3JpdGljYWwgZXh0ZW5zaW9uIGluIHRoZSBjcmxFeHRlbnNpb25zIGZpZWxkIHRoYXQg YWR2ZXJ0aXNlcw0KYSBzcGVjaWFsIHRyZWF0bWVudCBmb3IgaXQuIElmIGEgcmVseWluZyBwYXJ0 eSBpcyB1bmFibGUgdG8gcHJvY2VzcyBib3RoDQphIGNyaXRpY2FsIGNybEVudHJ5RXh0ZW5zaW9u IGFuZCBhIHJlbGF0ZWQgY3JpdGljYWwgY3JsRXh0ZW5zaW9uLCB0aGUgcmVseWluZw0KcGFydHkg aXMgZmFjZWQgd2l0aCBhIGRpZmZpY3VsdCBjaG9pY2UuPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0y PiZuYnNwOzwvZm9udD4NCjxwPjxmb250IHNpemU9Mj4xLSAmbmJzcDtUaGUgcmVseWluZyBwYXJ0 eSBtYXkgYXNzdW1lIHRoYXQgdGhlIHRoZSBDUkxFbnRyeQ0KaXMgYXNzb2NpYXRlZCB3aXRoIHRo ZSBDQSB0aGF0IGlzc3VlZCB0aGUgQ1JMLCBhbmQgdGh1cyB0cmVhdCB0aGF0IGNlcnRpZmljYXRl DQphcyByZXZva2VkLiBJZiB0aGUgQ1JMRW50cnkgcmVmZXJzIHRvIGEgY2VydGlmaWNhdGUgaXNz dWVkIGJ5IGEgZGlmZmVyZW50DQpDQSwgdGhlIHJlbHlpbmcgcGFydHkgd2lsbCB0cmVhdCBhIHZh bGlkIGNlcnRpZmljYXRlIGFzIGJlaW5nIHJldm9rZWQuPC9mb250Pg0KPHA+DQo8cD48Zm9udCBz aXplPTI+Mi0gJm5ic3A7VGhlIHJlbHlpbmcgcGFydHksIHJlYWxpemluZyB0aGF0IGl0IGNhbm5v dCBhY2N1cmF0ZWx5DQpkZXRlcm1pbmUgaWYgdGhlIENSTEVudHJ5IGlzIGFzc29jaWF0ZWQgd2l0 aCB0aGUgQ0EgdGhhdCBpc3N1ZWQgdGhlIENSTCwNCm1heSBjaG9vc2UgdG8gdHJlYXQgdGhhdCBj ZXJ0aWZpY2F0ZSBhcyBoYXZpbmcgYW4gdW5kZXRlcm1pbmVkIHJldm9jYXRpb24NCnN0YXR1cy4g SWYgdGhlIHJlbHlpbmcgcGFydHkgaXMgYWJsZSB0byBjb25zdWx0IG90aGVyIHNvdXJjZXMgb2Yg Y2VydGlmaWNhdGUNCnJldm9jYXRpb24gc3RhdHVzIChlLmcuLCBPQ1NQKSBpdCBtYXkgdXNlIHRo b3NlIHNvdXJjZXMgaW5zdGVhZC4gSWYgbm90LA0KdGhlIHJlbHlpbmcgcGFydHkgbWF5IGFjY2Vw dCBvciByZWplY3QgdGhlIGNlcnRpZmljYXRlIGFzIGEgbWF0dGVyIG9mIGxvY2FsDQpwb2xpY3ku PC9mb250Pg0KPHA+DQo8cD48Zm9udCBzaXplPTI+My0gJm5ic3A7VGhlIHJlbHlpbmcgcGFydHkg bWF5IHZpZXcgdGhlIENSTEVudHJ5IGFzIGJlaW5nDQphc3NvY2lhdGVkIHdpdGggYW4gdW5kZXRl cm1pbmVkIENBLCBhbmQgdHJlYXQgYWxsIGNlcnRpZmljYXRlcyB3aXRoIHRoYXQNCnNlcmlhbE51 bWJlciBhcyBiZWluZyByZXZva2VkLiBUaGlzIGJlaGF2aW9yIHJ1bnMgdGhlIHJpc2sgb2YgdHJl YXRpbmcNCmEgbnVtYmVyIG9mIHZhbGlkIGNlcnRpZmljYXRlcyBhcyByZXZva2VkLjwvZm9udD4N CjxwPjxmb250IHNpemU9Mj4mbmJzcDs8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTI+QmVjYXVzZSBl YWNoIG9mIHRoZXNlIG9wdGlvbnMgaGFzIGFzc29jaWF0ZWQgcmlza3MsIHRoaXMNCmRvY3VtZW50 IGRvZXMgbm90IHNwZWNpZnkgcmVseWluZyBwYXJ0eSBiZWhhdmlvciB1bmRlciB0aGUgY2lyY3Vt c3RhbmNlcw0Kbm90ZWQgYWJvdmUuIEEgcmVseWluZyBwYXJ0eSBtYXkgYWNjZXB0IG9yIHJlamVj dCBjZXJ0aWZpY2F0ZXMgd2l0aCB0aGUNCmluZGljYXRlZCBzZXJpYWxOdW1iZXIgYXMgYSBtYXR0 ZXIgb2YgbG9jYWwgcG9saWN5Ljxicj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9Mj5Ib3cgZG9l cyB0aGUgV0cgZmVlbCBhYm91dCB0aGlzIGFsdGVybmF0ZSB0ZXh0Pzxicj4NCjwvZm9udD4NCjxw Pjxmb250IHNpemU9Mj5TdGV2ZTwvZm9udD48dHQ+PGZvbnQgc2l6ZT0yPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KcGtpeCBtYWlsaW5nIGxpc3Q8 YnI+DQpwa2l4QGlldGYub3JnPGJyPg0KPC9mb250PjwvdHQ+PGEgaHJlZj1odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BraXg+PHR0Pjxmb250IHNpemU9Mj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BraXg8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250 IHNpemU9Mj48YnI+DQo8L2ZvbnQ+PC90dD4NCjxwPg0K --=_alternative 005F26E4C1257A8B_=-- From paul.hoffman@vpnc.org Tue Oct 2 10:23:20 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A49521F84F9 for ; Tue, 2 Oct 2012 10:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEYKXUhBso6E for ; Tue, 2 Oct 2012 10:23:19 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id B99F021F849A for ; Tue, 2 Oct 2012 10:23:19 -0700 (PDT) Received: from [10.20.30.108] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q92HN38T085902 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 2 Oct 2012 10:23:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Paul Hoffman In-Reply-To: <506B154F.3080501@bbn.com> Date: Tue, 2 Oct 2012 10:23:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <368B1CF8-5563-4912-B37D-CD1FC30FDD70@vpnc.org> References: <506B154F.3080501@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.1498) Cc: pkix Subject: Re: [pkix] 5280bis CRL problem poll results X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 17:23:20 -0000 On Oct 2, 2012, at 9:24 AM, Stephen Kent wrote: > Folks, > =20 > It is apparent from the straw poll that there is no WG consensus on = this topic. > =20 > I propose the following text, in lieu of the current =93new second = paragraph=94 that appears in Section 4 of = draft-ietf-pkix-rfc5280-clarifications-09.txt: > =20 > A critical extension in the crlEntryExtensions field of an entry SHALL = affect only the certificate specified in that entry, unless there is a = related critical extension in the crlExtensions field that advertises a = special treatment for it. If a relying party is unable to process both a = critical crlEntryExtension and a related critical crlExtension, the = relying party is faced with a difficult choice. > =20 > 1- The relying party may assume that the the CRLEntry is associated = with the CA that issued the CRL, and thus treat that certificate as = revoked. If the CRLEntry refers to a certificate issued by a different = CA, the relying party will treat a valid certificate as being revoked. >=20 > 2- The relying party, realizing that it cannot accurately determine = if the CRLEntry is associated with the CA that issued the CRL, may = choose to treat that certificate as having an undetermined revocation = status. If the relying party is able to consult other sources of = certificate revocation status (e.g., OCSP) it may use those sources = instead. If not, the relying party may accept or reject the certificate = as a matter of local policy. >=20 > 3- The relying party may view the CRLEntry as being associated with = an undetermined CA, and treat all certificates with that serialNumber as = being revoked. This behavior runs the risk of treating a number of valid = certificates as revoked. > =20 > Because each of these options has associated risks, this document does = not specify relying party behavior under the circumstances noted above. = A relying party may accept or reject certificates with the indicated = serialNumber as a matter of local policy. >=20 > How does the WG feel about this alternate text? That seems like a good approach, given the lack of consensus. One = editorial suggestion for the last sentence of item 2: change "the = relying party may accept or reject" to "the relying party then accepts = or rejects". The active tense is important here to indicate that the = local policy is already in place. --Paul Hoffman= From SChokhani@cygnacom.com Tue Oct 2 11:26:31 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D455C21F854E for ; Tue, 2 Oct 2012 11:26:31 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNN7VO0bMXmy for ; Tue, 2 Oct 2012 11:26:31 -0700 (PDT) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7CA21F8549 for ; Tue, 2 Oct 2012 11:26:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,524,1344225600"; d="scan'208";a="2091670" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 02 Oct 2012 14:26:15 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Tue, 2 Oct 2012 14:26:15 -0400 From: Santosh Chokhani To: Paul Hoffman , Stephen Kent Date: Tue, 2 Oct 2012 14:26:14 -0400 Thread-Topic: [pkix] 5280bis CRL problem poll results Thread-Index: Ac2gwqDcqIhwO6OkRqibFh/duxviZgACDQOQ Message-ID: References: <506B154F.3080501@bbn.com> <368B1CF8-5563-4912-B37D-CD1FC30FDD70@vpnc.org> In-Reply-To: <368B1CF8-5563-4912-B37D-CD1FC30FDD70@vpnc.org> 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: pkix Subject: Re: [pkix] 5280bis CRL problem poll results X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 18:26:31 -0000 Steve, I am confused by your proposal. I thought there is an agreement that if the CRL extension cannot be process= ed, the CRL MUST be rejected. I thought we are debating what to do when there is only a critical CRL entr= y extension and no related CRL extension, we know that the CRL entry extens= ion only affects the entry. And the question is whether to use the entry o= r not. That is what we need to decide. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Pau= l Hoffman Sent: Tuesday, October 02, 2012 1:23 PM To: Stephen Kent Cc: pkix Subject: Re: [pkix] 5280bis CRL problem poll results On Oct 2, 2012, at 9:24 AM, Stephen Kent wrote: > Folks, > =20 > It is apparent from the straw poll that there is no WG consensus on this = topic. > =20 > I propose the following text, in lieu of the current "new second paragrap= h" that appears in Section 4 of draft-ietf-pkix-rfc5280-clarifications-09.t= xt: > =20 > A critical extension in the crlEntryExtensions field of an entry SHALL af= fect only the certificate specified in that entry, unless there is a relate= d critical extension in the crlExtensions field that advertises a special t= reatment for it. If a relying party is unable to process both a critical cr= lEntryExtension and a related critical crlExtension, the relying party is f= aced with a difficult choice. > =20 > 1- The relying party may assume that the the CRLEntry is associated with= the CA that issued the CRL, and thus treat that certificate as revoked. If= the CRLEntry refers to a certificate issued by a different CA, the relying= party will treat a valid certificate as being revoked. >=20 > 2- The relying party, realizing that it cannot accurately determine if t= he CRLEntry is associated with the CA that issued the CRL, may choose to tr= eat that certificate as having an undetermined revocation status. If the re= lying party is able to consult other sources of certificate revocation stat= us (e.g., OCSP) it may use those sources instead. If not, the relying party= may accept or reject the certificate as a matter of local policy. >=20 > 3- The relying party may view the CRLEntry as being associated with an u= ndetermined CA, and treat all certificates with that serialNumber as being = revoked. This behavior runs the risk of treating a number of valid certific= ates as revoked. > =20 > Because each of these options has associated risks, this document does no= t specify relying party behavior under the circumstances noted above. A rel= ying party may accept or reject certificates with the indicated serialNumbe= r as a matter of local policy. >=20 > How does the WG feel about this alternate text? That seems like a good approach, given the lack of consensus. One editorial= suggestion for the last sentence of item 2: change "the relying party may = accept or reject" to "the relying party then accepts or rejects". The activ= e tense is important here to indicate that the local policy is already in p= lace. --Paul Hoffman _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From piyush@identicate.com Tue Oct 2 13:14:39 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 079E021F8599 for ; Tue, 2 Oct 2012 13:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.548 X-Spam-Level: X-Spam-Status: No, score=-5.548 tagged_above=-999 required=5 tests=[AWL=1.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qAU8meKTCyLN for ; Tue, 2 Oct 2012 13:14:36 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id 3415321F8595 for ; Tue, 2 Oct 2012 13:14:35 -0700 (PDT) Received: from mail176-va3-R.bigfish.com (10.7.14.242) by VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id 14.1.225.23; Tue, 2 Oct 2012 20:14:34 +0000 Received: from mail176-va3 (localhost [127.0.0.1]) by mail176-va3-R.bigfish.com (Postfix) with ESMTP id C5C734A00C8; Tue, 2 Oct 2012 20:14:34 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.229; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0610HT004.namprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: PS-21(zz9371Id6eahc85fhzz1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah1288h12a5h12bdh137ah1441h1155h) Received-SPF: pass (mail176-va3: domain of identicate.com designates 157.56.244.229 as permitted sender) client-ip=157.56.244.229; envelope-from=piyush@identicate.com; helo=CH1PRD0610HT004.namprd06.prod.outlook.com ; .outlook.com ; Received: from mail176-va3 (localhost.localdomain [127.0.0.1]) by mail176-va3 (MessageSwitch) id 1349208872392446_28689; Tue, 2 Oct 2012 20:14:32 +0000 (UTC) Received: from VA3EHSMHS008.bigfish.com (unknown [10.7.14.254]) by mail176-va3.bigfish.com (Postfix) with ESMTP id 535B080057; Tue, 2 Oct 2012 20:14:32 +0000 (UTC) Received: from CH1PRD0610HT004.namprd06.prod.outlook.com (157.56.244.229) by VA3EHSMHS008.bigfish.com (10.7.99.18) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 2 Oct 2012 20:14:30 +0000 Received: from CH1PRD0610MB393.namprd06.prod.outlook.com ([169.254.11.151]) by CH1PRD0610HT004.namprd06.prod.outlook.com ([10.255.151.39]) with mapi id 14.16.0207.009; Tue, 2 Oct 2012 20:14:29 +0000 From: Piyush Jain To: Stephen Kent , pkix Thread-Topic: [pkix] 5280bis CRL problem poll results Thread-Index: AQHNoLqAhz5yay+Hs0O+gjXV1eJ865ema4lQ Date: Tue, 2 Oct 2012 20:14:28 +0000 Message-ID: References: <506B154F.3080501@bbn.com> In-Reply-To: <506B154F.3080501@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [75.25.128.241] Content-Type: multipart/alternative; boundary="_000_AA6BA445CBFDB84785CC1C45DAAE4C7931EB1949CH1PRD0610MB393_" MIME-Version: 1.0 X-OriginatorOrg: identicate.com Subject: Re: [pkix] 5280bis CRL problem poll results X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 20:14:39 -0000 --_000_AA6BA445CBFDB84785CC1C45DAAE4C7931EB1949CH1PRD0610MB393_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Steve, The only thing that we need to convey in the text is that if a the certific= ate referred to by a unknown critical CRL entry extension should be treated= as 'revoked' or 'unknown'. I like your idea of letting local policy dictate this. So here are my changes to your proposed text. A critical extension in the crlEntryExtensions field of an entry SHALL affe= ct only the certificate specified in that entry, unless there is a related = critical extension in the crlExtensions field that advertises a special tre= atment for it. If the relying party cannot process a critical CRL Entry extension, it may = consider the status of the certificate referred to by this CRL entry as eit= her revoked or unknown as a matter of local policy. Please note the following changes to your proposed text DELETED - "If a relying party is unable to process both a critical crlEntry= Extension and a related critical crlExtension, the relying party is faced w= ith a difficult choice". This is incorrect. If a critical CRL extension cannot be processed, the CRL= MUST be rejected DELETED the choices. - RPs won't get to making those choices. If the RP = processes the CRL extension, it should also process the related CRL entry e= xtension. ADDED - "If the relying party cannot process a critical CRL Entry extensi= on, it may consider the status of the certificate referred to by this CRL e= ntry as either revoked or unknown as a matter of local policy." This deals with the scenario where there are no unrecognized CRL extensions= but unrecognized CRL entry extensions. From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Ste= phen Kent Sent: Tuesday, October 02, 2012 9:25 AM To: pkix Subject: [pkix] 5280bis CRL problem poll results Folks, It is apparent from the straw poll that there is no WG consensus on this to= pic. I propose the following text, in lieu of the current "new second paragraph"= that appears in Section 4 of draft-ietf-pkix-rfc5280-clarifications-09.txt= : A critical extension in the crlEntryExtensions field of an entry SHALL affe= ct only the certificate specified in that entry, unless there is a related = critical extension in the crlExtensions field that advertises a special tre= atment for it. If a relying party is unable to process both a critical crlE= ntryExtension and a related critical crlExtension, the relying party is fac= ed with a difficult choice. 1- The relying party may assume that the the CRLEntry is associated with t= he CA that issued the CRL, and thus treat that certificate as revoked. If t= he CRLEntry refers to a certificate issued by a different CA, the relying p= arty will treat a valid certificate as being revoked. 2- The relying party, realizing that it cannot accurately determine if the= CRLEntry is associated with the CA that issued the CRL, may choose to trea= t that certificate as having an undetermined revocation status. If the rely= ing party is able to consult other sources of certificate revocation status= (e.g., OCSP) it may use those sources instead. If not, the relying party m= ay accept or reject the certificate as a matter of local policy. 3- The relying party may view the CRLEntry as being associated with an und= etermined CA, and treat all certificates with that serialNumber as being re= voked. This behavior runs the risk of treating a number of valid certificat= es as revoked. Because each of these options has associated risks, this document does not = specify relying party behavior under the circumstances noted above. A relyi= ng party may accept or reject certificates with the indicated serialNumber = as a matter of local policy. How does the WG feel about this alternate text? Steve --_000_AA6BA445CBFDB84785CC1C45DAAE4C7931EB1949CH1PRD0610MB393_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Steve= ,

=  

The o= nly thing that we need to convey in the text is that if a the certificate r= eferred to by a unknown critical CRL entry extension should be treated as &= #8216;revoked’ or ‘unknown’.

I lik= e your idea of letting local policy dictate this.

=  

So he= re are my changes to your proposed text.

 

A critical extension in the crlEntryExtension= s field of an entry SHALL affect only the certificate specified in that ent= ry, unless there is a related critical extension in the crlExtensions field that advertises a special treatment for it.=

If the relying party cannot process a critica= l CRL Entry extension, it may consider the status of the certificate referr= ed to by this CRL entry as either revoked or unknown as a matter of local policy.

=  

Pleas= e note the following changes to your proposed text

DELETED - “If a relying= party is unable to process both a critical crlEntryExtension and a related= critical crlExtension, the relying party is faced with a difficult choice”.

This is incorrect. If a critical CRL extension cannot be proces= sed, the CRL MUST be rejected

 

   DELE= TED the choices. – RPs won’t get to making those choices. If th= e RP processes the CRL extension, it should also process the related CRL en= try extension.

 

ADDED  -  “If the relyi= ng party cannot process a critical CRL Entry extension, it may consider the status of the certificate referred to by this CRL entry as either revoked = or unknown as a matter of local policy.”

This deals with the scenario where there are no unrecognized CRL extensio= ns but unrecognized CRL entry extensions.

=  

From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of S= tephen Kent
Sent: Tuesday, October 02, 2012 9:25 AM
To: pkix
Subject: [pkix] 5280bis CRL problem poll results

 

Folks,

 

It is apparent from the straw poll that there is no WG cons= ensus on this topic.

 

I propose the following text, in lieu of the current “= ;new second paragraph” that appears in Section 4 of draft-ietf-pkix-r= fc5280-clarifications-09.txt:

 

A critical extension in the crlEntryExtensions field of an = entry SHALL affect only the certificate specified in that entry, unless there is a related critical extension in the crlExtensions f= ield that advertises a special treatment for it. If a relying party is unab= le to process both a critical crlEntryExtension and a related critical crlE= xtension, the relying party is faced with a difficult choice.

 

1-  The relying party may assume that the the CRLEntry is associa= ted with the CA that issued the CRL, and thus treat that certificate as rev= oked. If the CRLEntry refers to a certificate issued by a different CA, the relying party will treat a valid certificate as being = revoked.



2-  The relying party, realizing that it cannot accurately determ= ine if the CRLEntry is associated with the CA that issued the CRL, may choo= se to treat that certificate as having an undetermined revocation status. If the relying party is able to consult other sources o= f certificate revocation status (e.g., OCSP) it may use those sources inste= ad. If not, the relying party may accept or reject the certificate as a mat= ter of local policy.



3-  The relying party may view the CRLEntry as being associated w= ith an undetermined CA, and treat all certificates with that serialNumber a= s being revoked. This behavior runs the risk of treating a number of valid certificates as revoked.

 

Because each of these options has associated risks, this document= does not specify relying party behavior under the circumstances noted above. A relying party may accept or reject certificates with the in= dicated serialNumber as a matter of local policy.

How does the WG feel about this alternate text?=

Steve

--_000_AA6BA445CBFDB84785CC1C45DAAE4C7931EB1949CH1PRD0610MB393_-- From housley@vigilsec.com Tue Oct 2 14:43:11 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F23FB21F860D for ; Tue, 2 Oct 2012 14:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZAlxIdBqtLw for ; Tue, 2 Oct 2012 14:43:10 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 79C2F21F860B for ; Tue, 2 Oct 2012 14:43:09 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id E9EA59A4002; Tue, 2 Oct 2012 17:43:16 -0400 (EDT) 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 dlB9z53-lJlW; Tue, 2 Oct 2012 17:42:54 -0400 (EDT) Received: from [192.168.2.100] (pool-96-255-37-162.washdc.fios.verizon.net [96.255.37.162]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id E4BA09A4003; Tue, 2 Oct 2012 17:43:13 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-43--607690181 From: Russ Housley In-Reply-To: <506B154F.3080501@bbn.com> Date: Tue, 2 Oct 2012 17:43:00 -0400 Message-Id: References: <506B154F.3080501@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.1084) Cc: pkix Subject: Re: [pkix] 5280bis CRL problem poll results X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 21:43:11 -0000 --Apple-Mail-43--607690181 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 The lack of consensus is troubling, but I have two concerns with the = proposed text. First, if a critical CRL Entry Extension is unrecognized, then the = relying party cannot know that it is associated with particular CRL = Extension. Your text assumes that the only thing that such an extension = might convey is the issuing CA. This is true for the extensions that = PKIX has discussed to date, but I am not convinced that will be true for = all time. Second, I do not think there is a lack of consensus on this statement: A = relying party MUST reject a CRL that contains an unrecognized critical = extension, regardless of the extension being a CRL Extension or a CRL = Entry Extension. Russ On Oct 2, 2012, at 12:24 PM, Stephen Kent wrote: > Folks, > =20 > It is apparent from the straw poll that there is no WG consensus on = this topic. > =20 > I propose the following text, in lieu of the current =93new second = paragraph=94 that appears in Section 4 of = draft-ietf-pkix-rfc5280-clarifications-09.txt: > =20 > A critical extension in the crlEntryExtensions field of an entry SHALL = affect only the certificate specified in that entry, unless there is a = related critical extension in the crlExtensions field that advertises a = special treatment for it. If a relying party is unable to process both a = critical crlEntryExtension and a related critical crlExtension, the = relying party is faced with a difficult choice. > =20 > 1- The relying party may assume that the the CRLEntry is associated = with the CA that issued the CRL, and thus treat that certificate as = revoked. If the CRLEntry refers to a certificate issued by a different = CA, the relying party will treat a valid certificate as being revoked. >=20 > 2- The relying party, realizing that it cannot accurately determine = if the CRLEntry is associated with the CA that issued the CRL, may = choose to treat that certificate as having an undetermined revocation = status. If the relying party is able to consult other sources of = certificate revocation status (e.g., OCSP) it may use those sources = instead. If not, the relying party may accept or reject the certificate = as a matter of local policy. >=20 > 3- The relying party may view the CRLEntry as being associated with = an undetermined CA, and treat all certificates with that serialNumber as = being revoked. This behavior runs the risk of treating a number of valid = certificates as revoked. > =20 > Because each of these options has associated risks, this document does = not specify relying party behavior under the circumstances noted above. = A relying party may accept or reject certificates with the indicated = serialNumber as a matter of local policy. >=20 > How does the WG feel about this alternate text? >=20 > Steve > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --Apple-Mail-43--607690181 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 The = lack of consensus is troubling, but I have two concerns with the = proposed text.

First, if a critical CRL Entry = Extension is unrecognized, then the relying party cannot know that it is = associated with particular CRL Extension.  Your text assumes that = the only thing that such an extension might convey is the issuing CA. =  This is true for the extensions that PKIX has discussed to date, = but I am not convinced that will be true for all = time.

Second, I do not think there is a lack of = consensus on this statement: A relying party MUST reject a CRL that = contains an unrecognized critical extension, regardless of the extension = being a CRL Extension or a CRL Entry = Extension.

Russ


On Oct 2, 2012, at 12:24 PM, Stephen Kent wrote:

=20 =20

Folks,

 

It is apparent from the straw poll that there is no WG consensus on this = topic.

 

I propose the following text, in lieu of the current =93new second paragraph=94 that appears in Section 4 of = draft-ietf-pkix-rfc5280-clarifications-09.txt:

 

A critical extension in the crlEntryExtensions field of an entry SHALL affect only the certificate specified in that entry, unless there is a related critical extension in the crlExtensions field that advertises a special treatment for it. If a relying party is unable to process both a critical crlEntryExtension and a related critical crlExtension, the relying party is faced with a difficult choice.

 

1-  The relying party may assume that the the CRLEntry is associated with the CA that issued the CRL, and thus treat that certificate as revoked. If the CRLEntry refers to a certificate issued by a different CA, the relying party will treat a valid certificate as being revoked.


2-  The relying party, realizing that it cannot accurately determine if the CRLEntry is associated with the CA that issued the CRL, may choose to treat that certificate as having an undetermined revocation status. If the relying party is able to consult other sources of certificate revocation status (e.g., OCSP) it may use those sources instead. If not, the relying party may accept or reject the certificate as a matter of local policy.


3-  The relying party may view the CRLEntry as being associated with an undetermined CA, and treat all certificates with that serialNumber as being revoked. This behavior runs the risk of treating a number of valid certificates as revoked.

 

Because each of these options has associated risks, this document does not specify relying party behavior under the circumstances noted above. A relying party may accept or reject certificates with the indicated serialNumber as a matter of local = policy.

How does the WG feel about this alternate text?

Steve

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

= --Apple-Mail-43--607690181-- From denis.pinkas@bull.net Wed Oct 3 00:56:55 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFA2821F8694 for ; Wed, 3 Oct 2012 00:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.152 X-Spam-Level: X-Spam-Status: No, score=-2.152 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrFp6RB6I6bY for ; Wed, 3 Oct 2012 00:56:55 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED0A21F8690 for ; Wed, 3 Oct 2012 00:56:54 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id A3FE41C994; Wed, 3 Oct 2012 09:56:53 +0200 (CEST) In-Reply-To: References: <506B154F.3080501@bbn.com> To: Russ Housley MIME-Version: 1.0 X-KeepSent: B0B571A6:53848E3C-C1257A8C:002ACED1; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Wed, 3 Oct 2012 09:56:52 +0200 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 03/10/2012 09:56:53, Serialize complete at 03/10/2012 09:56:53 Content-Type: multipart/alternative; boundary="=_alternative 002B7D95C1257A8C_=" Cc: pkix Subject: Re: [pkix] 5280bis CRL problem poll results X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 07:56:56 -0000 Message en plusieurs parties au format MIME --=_alternative 002B7D95C1257A8C_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 UnVzcywNCg0KV2hpbGUgSSBhZ3JlZSB3aXRoIHlvdXIgZmlyc3Qgc3RhdGVtZW50LCBpLmUuIDsg ImlmIGEgY3JpdGljYWwgQ1JMIEVudHJ5IA0KRXh0ZW5zaW9uIGlzIHVucmVjb2duaXplZCwgDQp0 aGVuIHRoZSByZWx5aW5nIHBhcnR5IGNhbm5vdCBrbm93IHRoYXQgaXQgaXMgYXNzb2NpYXRlZCB3 aXRoIHBhcnRpY3VsYXIgDQpDUkwgRXh0ZW5zaW9uIiwgc2luY2UgDQppdCBkaXJlY3RseSByZWxh dGVzIHRvIHRoZSBxdWVzdGlvbiBJIGFza2VkIHRvIFN0ZXZlLg0KDQpIb3dldmVyLCBJIGRpc2Fn cmVlIHdpdGggeW91ciBsYXN0IHN0YXRlbWVudCwgaS5lLiAiQSByZWx5aW5nIHBhcnR5IE1VU1Qg DQpyZWplY3QgYSBDUkwgdGhhdCBjb250YWlucyANCmFuIHVucmVjb2duaXplZCBjcml0aWNhbCBl eHRlbnNpb24sIHJlZ2FyZGxlc3Mgb2YgdGhlIGV4dGVuc2lvbiBiZWluZyBhIA0KQ1JMIEV4dGVu c2lvbiBvciBhIENSTCBFbnRyeSBFeHRlbnNpb24uDQoNClRoZSBzZW50ZW5jZSBzaG91bGQgYmUg Y2hhbmdlZCBpbnRvOiAiQSByZWx5aW5nIHBhcnR5IE1VU1QgcmVqZWN0IGEgQ1JMIA0KdGhhdCBj b250YWlucyANCmFuIHVucmVjb2duaXplZCBjcml0aWNhbCBleHRlbnNpb24gaW4gYSBDUkwgRXh0 ZW5zaW9uIi4NCg0KRGVuaXMNCg0KDQoNCkRlIDogICAgUnVzcyBIb3VzbGV5IDxob3VzbGV5QHZp Z2lsc2VjLmNvbT4NCkEgOiAgICAgU3RlcGhlbiBLZW50IDxrZW50QGJibi5jb20+DQpDYyA6ICAg IHBraXggPHBraXhAaWV0Zi5vcmc+DQpEYXRlIDogIDAyLzEwLzIwMTIgMjM6NDMNCk9iamV0IDog UmU6IFtwa2l4XSA1MjgwYmlzIENSTCBwcm9ibGVtIHBvbGwgcmVzdWx0cw0KRW52b3nDqSBwYXIg OiAgICBwa2l4LWJvdW5jZXNAaWV0Zi5vcmcNCg0KDQoNClRoZSBsYWNrIG9mIGNvbnNlbnN1cyBp cyB0cm91YmxpbmcsIGJ1dCBJIGhhdmUgdHdvIGNvbmNlcm5zIHdpdGggdGhlIA0KcHJvcG9zZWQg dGV4dC4NCg0KRmlyc3QsIGlmIGEgY3JpdGljYWwgQ1JMIEVudHJ5IEV4dGVuc2lvbiBpcyB1bnJl Y29nbml6ZWQsIHRoZW4gdGhlIHJlbHlpbmcgDQpwYXJ0eSBjYW5ub3Qga25vdyB0aGF0IGl0IGlz IGFzc29jaWF0ZWQgd2l0aCBwYXJ0aWN1bGFyIENSTCBFeHRlbnNpb24uIA0KWW91ciB0ZXh0IGFz c3VtZXMgdGhhdCB0aGUgb25seSB0aGluZyB0aGF0IHN1Y2ggYW4gZXh0ZW5zaW9uIG1pZ2h0IGNv bnZleSANCmlzIHRoZSBpc3N1aW5nIENBLiAgVGhpcyBpcyB0cnVlIGZvciB0aGUgZXh0ZW5zaW9u cyB0aGF0IFBLSVggaGFzIA0KZGlzY3Vzc2VkIHRvIGRhdGUsIGJ1dCBJIGFtIG5vdCBjb252aW5j ZWQgdGhhdCB3aWxsIGJlIHRydWUgZm9yIGFsbCB0aW1lLg0KDQpTZWNvbmQsIEkgZG8gbm90IHRo aW5rIHRoZXJlIGlzIGEgbGFjayBvZiBjb25zZW5zdXMgb24gdGhpcyBzdGF0ZW1lbnQ6IEEgDQpy ZWx5aW5nIHBhcnR5IE1VU1QgcmVqZWN0IGEgQ1JMIHRoYXQgY29udGFpbnMgYW4gdW5yZWNvZ25p emVkIGNyaXRpY2FsIA0KZXh0ZW5zaW9uLCByZWdhcmRsZXNzIG9mIHRoZSBleHRlbnNpb24gYmVp bmcgYSBDUkwgRXh0ZW5zaW9uIG9yIGEgQ1JMIA0KRW50cnkgRXh0ZW5zaW9uLg0KDQpSdXNzDQoN Cg0KT24gT2N0IDIsIDIwMTIsIGF0IDEyOjI0IFBNLCBTdGVwaGVuIEtlbnQgd3JvdGU6DQoNCkZv bGtzLA0KIA0KSXQgaXMgYXBwYXJlbnQgZnJvbSB0aGUgc3RyYXcgcG9sbCB0aGF0IHRoZXJlIGlz IG5vIFdHIGNvbnNlbnN1cyBvbiB0aGlzIA0KdG9waWMuDQogDQpJIHByb3Bvc2UgdGhlIGZvbGxv d2luZyB0ZXh0LCBpbiBsaWV1IG9mIHRoZSBjdXJyZW50IOKAnG5ldyBzZWNvbmQgDQpwYXJhZ3Jh cGjigJ0gdGhhdCBhcHBlYXJzIGluIFNlY3Rpb24gNCBvZiANCmRyYWZ0LWlldGYtcGtpeC1yZmM1 MjgwLWNsYXJpZmljYXRpb25zLTA5LnR4dDoNCiANCkEgY3JpdGljYWwgZXh0ZW5zaW9uIGluIHRo ZSBjcmxFbnRyeUV4dGVuc2lvbnMgZmllbGQgb2YgYW4gZW50cnkgU0hBTEwgDQphZmZlY3Qgb25s eSB0aGUgY2VydGlmaWNhdGUgc3BlY2lmaWVkIGluIHRoYXQgZW50cnksIHVubGVzcyB0aGVyZSBp cyBhIA0KcmVsYXRlZCBjcml0aWNhbCBleHRlbnNpb24gaW4gdGhlIGNybEV4dGVuc2lvbnMgZmll bGQgdGhhdCBhZHZlcnRpc2VzIGEgDQpzcGVjaWFsIHRyZWF0bWVudCBmb3IgaXQuIElmIGEgcmVs eWluZyBwYXJ0eSBpcyB1bmFibGUgdG8gcHJvY2VzcyBib3RoIGEgDQpjcml0aWNhbCBjcmxFbnRy eUV4dGVuc2lvbiBhbmQgYSByZWxhdGVkIGNyaXRpY2FsIGNybEV4dGVuc2lvbiwgdGhlIA0KcmVs eWluZyBwYXJ0eSBpcyBmYWNlZCB3aXRoIGEgZGlmZmljdWx0IGNob2ljZS4NCiANCjEtICBUaGUg cmVseWluZyBwYXJ0eSBtYXkgYXNzdW1lIHRoYXQgdGhlIHRoZSBDUkxFbnRyeSBpcyBhc3NvY2lh dGVkIHdpdGggDQp0aGUgQ0EgdGhhdCBpc3N1ZWQgdGhlIENSTCwgYW5kIHRodXMgdHJlYXQgdGhh dCBjZXJ0aWZpY2F0ZSBhcyByZXZva2VkLiBJZiANCnRoZSBDUkxFbnRyeSByZWZlcnMgdG8gYSBj ZXJ0aWZpY2F0ZSBpc3N1ZWQgYnkgYSBkaWZmZXJlbnQgQ0EsIHRoZSByZWx5aW5nIA0KcGFydHkg d2lsbCB0cmVhdCBhIHZhbGlkIGNlcnRpZmljYXRlIGFzIGJlaW5nIHJldm9rZWQuDQoNCjItICBU aGUgcmVseWluZyBwYXJ0eSwgcmVhbGl6aW5nIHRoYXQgaXQgY2Fubm90IGFjY3VyYXRlbHkgZGV0 ZXJtaW5lIGlmIA0KdGhlIENSTEVudHJ5IGlzIGFzc29jaWF0ZWQgd2l0aCB0aGUgQ0EgdGhhdCBp c3N1ZWQgdGhlIENSTCwgbWF5IGNob29zZSB0byANCnRyZWF0IHRoYXQgY2VydGlmaWNhdGUgYXMg aGF2aW5nIGFuIHVuZGV0ZXJtaW5lZCByZXZvY2F0aW9uIHN0YXR1cy4gSWYgdGhlIA0KcmVseWlu ZyBwYXJ0eSBpcyBhYmxlIHRvIGNvbnN1bHQgb3RoZXIgc291cmNlcyBvZiBjZXJ0aWZpY2F0ZSBy ZXZvY2F0aW9uIA0Kc3RhdHVzIChlLmcuLCBPQ1NQKSBpdCBtYXkgdXNlIHRob3NlIHNvdXJjZXMg aW5zdGVhZC4gSWYgbm90LCB0aGUgcmVseWluZyANCnBhcnR5IG1heSBhY2NlcHQgb3IgcmVqZWN0 IHRoZSBjZXJ0aWZpY2F0ZSBhcyBhIG1hdHRlciBvZiBsb2NhbCBwb2xpY3kuDQoNCjMtICBUaGUg cmVseWluZyBwYXJ0eSBtYXkgdmlldyB0aGUgQ1JMRW50cnkgYXMgYmVpbmcgYXNzb2NpYXRlZCB3 aXRoIGFuIA0KdW5kZXRlcm1pbmVkIENBLCBhbmQgdHJlYXQgYWxsIGNlcnRpZmljYXRlcyB3aXRo IHRoYXQgc2VyaWFsTnVtYmVyIGFzIA0KYmVpbmcgcmV2b2tlZC4gVGhpcyBiZWhhdmlvciBydW5z IHRoZSByaXNrIG9mIHRyZWF0aW5nIGEgbnVtYmVyIG9mIHZhbGlkIA0KY2VydGlmaWNhdGVzIGFz IHJldm9rZWQuDQogDQpCZWNhdXNlIGVhY2ggb2YgdGhlc2Ugb3B0aW9ucyBoYXMgYXNzb2NpYXRl ZCByaXNrcywgdGhpcyBkb2N1bWVudCBkb2VzIG5vdCANCnNwZWNpZnkgcmVseWluZyBwYXJ0eSBi ZWhhdmlvciB1bmRlciB0aGUgY2lyY3Vtc3RhbmNlcyBub3RlZCBhYm92ZS4gQSANCnJlbHlpbmcg cGFydHkgbWF5IGFjY2VwdCBvciByZWplY3QgY2VydGlmaWNhdGVzIHdpdGggdGhlIGluZGljYXRl ZCANCnNlcmlhbE51bWJlciBhcyBhIG1hdHRlciBvZiBsb2NhbCBwb2xpY3kuDQoNCkhvdyBkb2Vz IHRoZSBXRyBmZWVsIGFib3V0IHRoaXMgYWx0ZXJuYXRlIHRleHQ/DQoNClN0ZXZlDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcGtpeCBtYWlsaW5nIGxp c3QNCnBraXhAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cGtpeA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnBr aXggbWFpbGluZyBsaXN0DQpwa2l4QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3BraXgNCg0KDQo= --=_alternative 002B7D95C1257A8C_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5SdXNzLDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0iQXJpYWwiPldoaWxlIEkgYWdyZWUgd2l0aCB5b3VyIGZpcnN0IHN0YXRlbWVu dCwNCmkuZS4gOyAmcXVvdDtpZiBhIGNyaXRpY2FsIENSTCBFbnRyeSBFeHRlbnNpb24gaXMgdW5y ZWNvZ25pemVkLCA8YnI+DQp0aGVuIHRoZSByZWx5aW5nIHBhcnR5IGNhbm5vdCBrbm93IHRoYXQg aXQgaXMgYXNzb2NpYXRlZCB3aXRoIHBhcnRpY3VsYXINCkNSTCBFeHRlbnNpb24mcXVvdDssIHNp bmNlIDxicj4NCml0IGRpcmVjdGx5IHJlbGF0ZXMgdG8gdGhlIHF1ZXN0aW9uIEkgYXNrZWQgdG8g U3RldmUuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+SG93ZXZl ciwgSSBkaXNhZ3JlZSB3aXRoIHlvdXIgbGFzdCBzdGF0ZW1lbnQsDQppLmUuICZxdW90O0EgcmVs eWluZyBwYXJ0eSBNVVNUIHJlamVjdCBhIENSTCB0aGF0IGNvbnRhaW5zIDxicj4NCmFuIHVucmVj b2duaXplZCBjcml0aWNhbCBleHRlbnNpb24sIHJlZ2FyZGxlc3Mgb2YgdGhlIGV4dGVuc2lvbiBi ZWluZyBhDQpDUkwgRXh0ZW5zaW9uIG9yIGEgQ1JMIEVudHJ5IEV4dGVuc2lvbi48L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5UaGUgc2VudGVuY2Ugc2hvdWxkIGJl IGNoYW5nZWQgaW50bzogJnF1b3Q7QQ0KcmVseWluZyBwYXJ0eSBNVVNUIHJlamVjdCBhIENSTCB0 aGF0IGNvbnRhaW5zIDxicj4NCmFuIHVucmVjb2duaXplZCBjcml0aWNhbCBleHRlbnNpb24gaW4g YSBDUkwgRXh0ZW5zaW9uJnF1b3Q7LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0iQXJpYWwiPkRlbmlzPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MSBjb2xvcj0jNWY1ZjVmIGZhY2U9InNhbnMtc2VyaWYiPkRlIDogJm5ic3A7ICZuYnNwOyAmbmJz cDsNCiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UnVzcyBIb3Vz bGV5ICZsdDtob3VzbGV5QHZpZ2lsc2VjLmNvbSZndDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0x IGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+QSA6ICZuYnNwOyAmbmJzcDsgJm5ic3A7 DQombmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlN0ZXBoZW4gS2Vu dCAmbHQ7a2VudEBiYm4uY29tJmd0OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgY29sb3I9IzVm NWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5DYyZuYnNwOzogJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZu YnNwOzwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+cGtpeCAmbHQ7cGtpeEBp ZXRmLm9yZyZndDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0i c2Fucy1zZXJpZiI+RGF0ZSA6ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDs8L2ZvbnQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjAyLzEwLzIwMTIgMjM6NDM8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+T2JqZXQgOiAmbmJz cDsgJm5ic3A7DQombmJzcDsgJm5ic3A7PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj5SZTogW3BraXhdIDUyODBiaXMNCkNSTCBwcm9ibGVtIHBvbGwgcmVzdWx0czwvZm9udD4N Cjxicj48Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5FbnZvecOp IHBhciA6ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPnBraXgtYm91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxicj4NCjxociBu b3NoYWRlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mz5UaGUgbGFjayBvZiBjb25zZW5z dXMgaXMgdHJvdWJsaW5nLCBidXQgSSBoYXZlIHR3byBjb25jZXJucw0Kd2l0aCB0aGUgcHJvcG9z ZWQgdGV4dC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPkZpcnN0LCBpZiBhIGNyaXRp Y2FsIENSTCBFbnRyeSBFeHRlbnNpb24gaXMgdW5yZWNvZ25pemVkLA0KdGhlbiB0aGUgcmVseWlu ZyBwYXJ0eSBjYW5ub3Qga25vdyB0aGF0IGl0IGlzIGFzc29jaWF0ZWQgd2l0aCBwYXJ0aWN1bGFy DQpDUkwgRXh0ZW5zaW9uLiAmbmJzcDtZb3VyIHRleHQgYXNzdW1lcyB0aGF0IHRoZSBvbmx5IHRo aW5nIHRoYXQgc3VjaCBhbg0KZXh0ZW5zaW9uIG1pZ2h0IGNvbnZleSBpcyB0aGUgaXNzdWluZyBD QS4gJm5ic3A7VGhpcyBpcyB0cnVlIGZvciB0aGUgZXh0ZW5zaW9ucw0KdGhhdCBQS0lYIGhhcyBk aXNjdXNzZWQgdG8gZGF0ZSwgYnV0IEkgYW0gbm90IGNvbnZpbmNlZCB0aGF0IHdpbGwgYmUgdHJ1 ZQ0KZm9yIGFsbCB0aW1lLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+U2Vjb25kLCBJ IGRvIG5vdCB0aGluayB0aGVyZSBpcyBhIGxhY2sgb2YgY29uc2Vuc3VzIG9uDQp0aGlzIHN0YXRl bWVudDogQSByZWx5aW5nIHBhcnR5IE1VU1QgcmVqZWN0IGEgQ1JMIHRoYXQgY29udGFpbnMgYW4g dW5yZWNvZ25pemVkDQpjcml0aWNhbCBleHRlbnNpb24sIHJlZ2FyZGxlc3Mgb2YgdGhlIGV4dGVu c2lvbiBiZWluZyBhIENSTCBFeHRlbnNpb24gb3INCmEgQ1JMIEVudHJ5IEV4dGVuc2lvbi48L2Zv bnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPlJ1c3M8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0zPk9uIE9jdCAyLCAyMDEyLCBhdCAxMjoyNCBQTSwgU3RlcGhlbiBLZW50IHdy b3RlOjwvZm9udD4NCjxicj4NCjxwPjxmb250IHNpemU9Mj5Gb2xrcyw8L2ZvbnQ+DQo8cD48Zm9u dCBzaXplPTI+Jm5ic3A7PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0yPkl0IGlzIGFwcGFyZW50IGZy b20gdGhlIHN0cmF3IHBvbGwgdGhhdCB0aGVyZSBpcyBubyBXRw0KY29uc2Vuc3VzIG9uIHRoaXMg dG9waWMuPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0yPiZuYnNwOzwvZm9udD4NCjxwPjxmb250IHNp emU9Mj5JIHByb3Bvc2UgdGhlIGZvbGxvd2luZyB0ZXh0LCBpbiBsaWV1IG9mIHRoZSBjdXJyZW50 IOKAnG5ldw0Kc2Vjb25kIHBhcmFncmFwaOKAnSB0aGF0IGFwcGVhcnMgaW4gU2VjdGlvbiA0IG9m IGRyYWZ0LWlldGYtcGtpeC1yZmM1MjgwLWNsYXJpZmljYXRpb25zLTA5LnR4dDo8L2ZvbnQ+DQo8 cD48Zm9udCBzaXplPTI+Jm5ic3A7PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0yPkEgY3JpdGljYWwg ZXh0ZW5zaW9uIGluIHRoZSBjcmxFbnRyeUV4dGVuc2lvbnMgZmllbGQgb2YNCmFuIGVudHJ5IFNI QUxMIGFmZmVjdCBvbmx5IHRoZSBjZXJ0aWZpY2F0ZSBzcGVjaWZpZWQgaW4gdGhhdCBlbnRyeSwg dW5sZXNzDQp0aGVyZSBpcyBhIHJlbGF0ZWQgY3JpdGljYWwgZXh0ZW5zaW9uIGluIHRoZSBjcmxF eHRlbnNpb25zIGZpZWxkIHRoYXQgYWR2ZXJ0aXNlcw0KYSBzcGVjaWFsIHRyZWF0bWVudCBmb3Ig aXQuIElmIGEgcmVseWluZyBwYXJ0eSBpcyB1bmFibGUgdG8gcHJvY2VzcyBib3RoDQphIGNyaXRp Y2FsIGNybEVudHJ5RXh0ZW5zaW9uIGFuZCBhIHJlbGF0ZWQgY3JpdGljYWwgY3JsRXh0ZW5zaW9u LCB0aGUgcmVseWluZw0KcGFydHkgaXMgZmFjZWQgd2l0aCBhIGRpZmZpY3VsdCBjaG9pY2UuPC9m b250Pg0KPHA+PGZvbnQgc2l6ZT0yPiZuYnNwOzwvZm9udD4NCjxwPjxmb250IHNpemU9Mj4xLSAm bmJzcDtUaGUgcmVseWluZyBwYXJ0eSBtYXkgYXNzdW1lIHRoYXQgdGhlIHRoZSBDUkxFbnRyeQ0K aXMgYXNzb2NpYXRlZCB3aXRoIHRoZSBDQSB0aGF0IGlzc3VlZCB0aGUgQ1JMLCBhbmQgdGh1cyB0 cmVhdCB0aGF0IGNlcnRpZmljYXRlDQphcyByZXZva2VkLiBJZiB0aGUgQ1JMRW50cnkgcmVmZXJz IHRvIGEgY2VydGlmaWNhdGUgaXNzdWVkIGJ5IGEgZGlmZmVyZW50DQpDQSwgdGhlIHJlbHlpbmcg cGFydHkgd2lsbCB0cmVhdCBhIHZhbGlkIGNlcnRpZmljYXRlIGFzIGJlaW5nIHJldm9rZWQuPC9m b250Pg0KPHA+DQo8cD48Zm9udCBzaXplPTI+Mi0gJm5ic3A7VGhlIHJlbHlpbmcgcGFydHksIHJl YWxpemluZyB0aGF0IGl0IGNhbm5vdCBhY2N1cmF0ZWx5DQpkZXRlcm1pbmUgaWYgdGhlIENSTEVu dHJ5IGlzIGFzc29jaWF0ZWQgd2l0aCB0aGUgQ0EgdGhhdCBpc3N1ZWQgdGhlIENSTCwNCm1heSBj aG9vc2UgdG8gdHJlYXQgdGhhdCBjZXJ0aWZpY2F0ZSBhcyBoYXZpbmcgYW4gdW5kZXRlcm1pbmVk IHJldm9jYXRpb24NCnN0YXR1cy4gSWYgdGhlIHJlbHlpbmcgcGFydHkgaXMgYWJsZSB0byBjb25z dWx0IG90aGVyIHNvdXJjZXMgb2YgY2VydGlmaWNhdGUNCnJldm9jYXRpb24gc3RhdHVzIChlLmcu LCBPQ1NQKSBpdCBtYXkgdXNlIHRob3NlIHNvdXJjZXMgaW5zdGVhZC4gSWYgbm90LA0KdGhlIHJl bHlpbmcgcGFydHkgbWF5IGFjY2VwdCBvciByZWplY3QgdGhlIGNlcnRpZmljYXRlIGFzIGEgbWF0 dGVyIG9mIGxvY2FsDQpwb2xpY3kuPC9mb250Pg0KPHA+DQo8cD48Zm9udCBzaXplPTI+My0gJm5i c3A7VGhlIHJlbHlpbmcgcGFydHkgbWF5IHZpZXcgdGhlIENSTEVudHJ5IGFzIGJlaW5nDQphc3Nv Y2lhdGVkIHdpdGggYW4gdW5kZXRlcm1pbmVkIENBLCBhbmQgdHJlYXQgYWxsIGNlcnRpZmljYXRl cyB3aXRoIHRoYXQNCnNlcmlhbE51bWJlciBhcyBiZWluZyByZXZva2VkLiBUaGlzIGJlaGF2aW9y IHJ1bnMgdGhlIHJpc2sgb2YgdHJlYXRpbmcNCmEgbnVtYmVyIG9mIHZhbGlkIGNlcnRpZmljYXRl cyBhcyByZXZva2VkLjwvZm9udD4NCjxwPjxmb250IHNpemU9Mj4mbmJzcDs8L2ZvbnQ+DQo8cD48 Zm9udCBzaXplPTI+QmVjYXVzZSBlYWNoIG9mIHRoZXNlIG9wdGlvbnMgaGFzIGFzc29jaWF0ZWQg cmlza3MsIHRoaXMNCmRvY3VtZW50IGRvZXMgbm90IHNwZWNpZnkgcmVseWluZyBwYXJ0eSBiZWhh dmlvciB1bmRlciB0aGUgY2lyY3Vtc3RhbmNlcw0Kbm90ZWQgYWJvdmUuIEEgcmVseWluZyBwYXJ0 eSBtYXkgYWNjZXB0IG9yIHJlamVjdCBjZXJ0aWZpY2F0ZXMgd2l0aCB0aGUNCmluZGljYXRlZCBz ZXJpYWxOdW1iZXIgYXMgYSBtYXR0ZXIgb2YgbG9jYWwgcG9saWN5Ljxicj4NCjwvZm9udD4NCjxw Pjxmb250IHNpemU9Mj5Ib3cgZG9lcyB0aGUgV0cgZmVlbCBhYm91dCB0aGlzIGFsdGVybmF0ZSB0 ZXh0Pzxicj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9Mj5TdGV2ZTwvZm9udD4NCjxwPjxmb250 IHNpemU9Mz5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCnBraXggbWFpbGluZyBsaXN0PC9mb250Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx1Pjxi cj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj1tYWlsdG86cGtpeEBpZXRmLm9yZz48Zm9udCBzaXplPTMg Y29sb3I9Ymx1ZT48dT5wa2l4QGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGNv bG9yPWJsdWU+PHU+PGJyPg0KPC91PjwvZm9udD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vcGtpeD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dT5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BraXg8L3U+PC9mb250PjwvYT4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KcGtpeCBtYWlsaW5nIGxpc3Q8YnI+DQpwa2l4QGlldGYub3JnPGJyPg0KPC9m b250PjwvdHQ+PGEgaHJlZj1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Br aXg+PHR0Pjxmb250IHNpemU9Mj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3BraXg8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+DQo8L2ZvbnQ+PC90dD4N Cjxicj4NCg== --=_alternative 002B7D95C1257A8C_=-- From kent@bbn.com Wed Oct 3 07:43:11 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F37A821F868A for ; Wed, 3 Oct 2012 07:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLjxSryQBRFn for ; Wed, 3 Oct 2012 07:43:09 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id C8A0721F8688 for ; Wed, 3 Oct 2012 07:43:08 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:51511 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TJQAA-00079q-4n for pkix@ietf.org; Wed, 03 Oct 2012 10:43:02 -0400 Message-ID: <506C4EF5.9030103@bbn.com> Date: Wed, 03 Oct 2012 10:43:01 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: pkix Content-Type: multipart/alternative; boundary="------------080805090408090700040409" Subject: [pkix] once again, with feeling ... X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 14:43:11 -0000 This is a multi-part message in MIME format. --------------080805090408090700040409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thank for the feedback. Obviously my text was incorrect in that an RP that can't process a CRL extension has no way of determining if that extension is related to a CRL entry extension that it also cannot process. Also, there was no intent to change the requirements re dealing with an unknown CRL (vs. CRL entry) extension. Note that this text augments Section 5.3 of 5280, which deals only with processing of CRL _entry_ extensions. Based on feedback from several messages, I have revised the text slightly. Here is my next pass. Steve ------ I propose the following text, in lieu of the current "new second paragraph" that appears in Section 4 of draft-ietf-pkix-rfc5280-clarifications-09.txt: A critical extension in the crlEntryExtensions field of an entrySHALL affect only the certificate specified in that entry, unless there is a related critical extension in the crlExtensions field that advertises a special treatment for it. If a relying party is unable to process a critical crlEntryExtension, the relying party is faced with a difficult choice. 1-The relying party may assume that the the CRLEntry is associated with the CA that issued the CRL, and thus treat that certificate as revoked. If the CRLEntry refers to a certificate issued by a different CA, the relying party will treat a valid certificate as being revoked. 2-The relying party, realizing that it cannot accurately determine if the CRLEntry is associated with the CA that issued the CRL, may choose to treat that certificate as having an undetermined revocation status. If the relying party is able to consult other sources of certificate revocation status (e.g., OCSP) it may use those sources instead. If not, the relying party then accepts or rejects the certificate as a matter of local policy. 3-The relying party may view the CRLEntry as being associated with an undetermined CA, and treat all certificates with that serialNumber as being revoked. This behavior runs the risk of treating a number of valid certificates as revoked. Because options one and three have associated risks, this document does not specify relying party behavior under the circumstances noted above. A relying party SHOULD accept or reject certificates with the indicated serialNumber as a matter of local policy. --------------080805090408090700040409 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thank for the feedback. Obviously my text was incorrect in that an RP that can't process
a CRL extension has no way of determining if that extension is related to a CRL entry extension
that it also cannot process.  Also, there was no intent to change the requirements re dealing
with an unknown CRL (vs. CRL entry) extension. Note that this text augments Section 5.3 of 5280,
which deals only with processing of CRL entry extensions.

Based on feedback from several messages, I have revised the text slightly.  Here is my next pass.

Steve
------

I propose the following text, in lieu of the current “new second paragraph” that appears in Section 4 of draft-ietf-pkix-rfc5280-clarifications-09.txt:

 

A critical extension in the crlEntryExtensions field of an entry SHALL affect only the certificate specified in that entry, unless there is a related critical extension in the crlExtensions field that advertises a special treatment for it. If a relying party is unable to process a critical crlEntryExtension, the relying party is faced with a difficult choice.

 

1-  The relying party may assume that the the CRLEntry is associated with the CA that issued the CRL, and thus treat that certificate as revoked. If the CRLEntry refers to a certificate issued by a different CA, the relying party will treat a valid certificate as being revoked.

2-  The relying party, realizing that it cannot accurately determine if the CRLEntry is associated with the CA that issued the CRL, may choose to treat that certificate as having an undetermined revocation status. If the relying party is able to consult other sources of certificate revocation status (e.g., OCSP) it may use those sources instead. If not, the relying party then accepts or rejects the certificate as a matter of local policy.

3-  The relying party may view the CRLEntry as being associated with an undetermined CA, and treat all certificates with that serialNumber as being revoked. This behavior runs the risk of treating a number of valid certificates as revoked.

 

Because options one and three have associated risks, this document does not specify relying party behavior under the circumstances noted above. A relying party SHOULD accept or reject certificates with the indicated serialNumber as a matter of local policy.


--------------080805090408090700040409-- From piyush@identicate.com Wed Oct 3 08:30:22 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF4021F84FC for ; Wed, 3 Oct 2012 08:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.144 X-Spam-Level: X-Spam-Status: No, score=-4.144 tagged_above=-999 required=5 tests=[AWL=-0.546, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSKFkd5ec3Z6 for ; Wed, 3 Oct 2012 08:30:19 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id 4348221F84E2 for ; Wed, 3 Oct 2012 08:30:19 -0700 (PDT) Received: from mail55-am1-R.bigfish.com (10.3.201.228) by AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id 14.1.225.23; Wed, 3 Oct 2012 15:30:18 +0000 Received: from mail55-am1 (localhost [127.0.0.1]) by mail55-am1-R.bigfish.com (Postfix) with ESMTP id 1B6264401A5; Wed, 3 Oct 2012 15:30:18 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.229; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0610HT002.namprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: PS-22(zz98dI9371Id6eahc85fhzz1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah1288h12a5h12bdh137ah1441h1155h) Received-SPF: pass (mail55-am1: domain of identicate.com designates 157.56.244.229 as permitted sender) client-ip=157.56.244.229; envelope-from=piyush@identicate.com; helo=CH1PRD0610HT002.namprd06.prod.outlook.com ; .outlook.com ; Received: from mail55-am1 (localhost.localdomain [127.0.0.1]) by mail55-am1 (MessageSwitch) id 1349278215636539_23834; Wed, 3 Oct 2012 15:30:15 +0000 (UTC) Received: from AM1EHSMHS001.bigfish.com (unknown [10.3.201.252]) by mail55-am1.bigfish.com (Postfix) with ESMTP id 985DA180063; Wed, 3 Oct 2012 15:30:15 +0000 (UTC) Received: from CH1PRD0610HT002.namprd06.prod.outlook.com (157.56.244.229) by AM1EHSMHS001.bigfish.com (10.3.207.101) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 3 Oct 2012 15:30:09 +0000 Received: from CH1PRD0610MB393.namprd06.prod.outlook.com ([169.254.11.151]) by CH1PRD0610HT002.namprd06.prod.outlook.com ([10.255.151.37]) with mapi id 14.16.0207.009; Wed, 3 Oct 2012 15:30:08 +0000 From: Piyush Jain To: Russ Housley , Stephen Kent Thread-Topic: [pkix] 5280bis CRL problem poll results Thread-Index: AQHNoLqAhz5yay+Hs0O+gjXV1eJ865emjFMAgAEmrOA= Date: Wed, 3 Oct 2012 15:30:08 +0000 Message-ID: References: <506B154F.3080501@bbn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [75.25.128.241] Content-Type: multipart/alternative; boundary="_000_AA6BA445CBFDB84785CC1C45DAAE4C7931EB1EC2CH1PRD0610MB393_" MIME-Version: 1.0 X-OriginatorOrg: identicate.com Cc: pkix Subject: Re: [pkix] 5280bis CRL problem poll results X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 15:30:22 -0000 --_000_AA6BA445CBFDB84785CC1C45DAAE4C7931EB1EC2CH1PRD0610MB393_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Russ, There is consensus on the statement that the relying party must reject the = CRL if it encounters an unknown critical CRL extension. And I think (based on discussion over past few weeks) that most folks here = believe that the whole CRL should NOT be rejected because of an unknown cri= tical CRL entry extension. The only point of contention is that if the certificate referred to by such= a CRL entry should be treated as 'revoked' or 'unknown'. -Piyush From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Rus= s Housley Sent: Tuesday, October 02, 2012 2:43 PM To: Stephen Kent Cc: pkix Subject: Re: [pkix] 5280bis CRL problem poll results The lack of consensus is troubling, but I have two concerns with the propos= ed text. First, if a critical CRL Entry Extension is unrecognized, then the relying = party cannot know that it is associated with particular CRL Extension. You= r text assumes that the only thing that such an extension might convey is t= he issuing CA. This is true for the extensions that PKIX has discussed to = date, but I am not convinced that will be true for all time. Second, I do not think there is a lack of consensus on this statement: A re= lying party MUST reject a CRL that contains an unrecognized critical extens= ion, regardless of the extension being a CRL Extension or a CRL Entry Exten= sion. Russ On Oct 2, 2012, at 12:24 PM, Stephen Kent wrote: Folks, It is apparent from the straw poll that there is no WG consensus on this to= pic. I propose the following text, in lieu of the current "new second paragraph"= that appears in Section 4 of draft-ietf-pkix-rfc5280-clarifications-09.txt= : A critical extension in the crlEntryExtensions field of an entry SHALL affe= ct only the certificate specified in that entry, unless there is a related = critical extension in the crlExtensions field that advertises a special tre= atment for it. If a relying party is unable to process both a critical crlE= ntryExtension and a related critical crlExtension, the relying party is fac= ed with a difficult choice. 1- The relying party may assume that the the CRLEntry is associated with t= he CA that issued the CRL, and thus treat that certificate as revoked. If t= he CRLEntry refers to a certificate issued by a different CA, the relying p= arty will treat a valid certificate as being revoked. 2- The relying party, realizing that it cannot accurately determine if the= CRLEntry is associated with the CA that issued the CRL, may choose to trea= t that certificate as having an undetermined revocation status. If the rely= ing party is able to consult other sources of certificate revocation status= (e.g., OCSP) it may use those sources instead. If not, the relying party m= ay accept or reject the certificate as a matter of local policy. 3- The relying party may view the CRLEntry as being associated with an und= etermined CA, and treat all certificates with that serialNumber as being re= voked. This behavior runs the risk of treating a number of valid certificat= es as revoked. Because each of these options has associated risks, this document does not = specify relying party behavior under the circumstances noted above. A relyi= ng party may accept or reject certificates with the indicated serialNumber = as a matter of local policy. How does the WG feel about this alternate text? Steve _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --_000_AA6BA445CBFDB84785CC1C45DAAE4C7931EB1EC2CH1PRD0610MB393_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Russ,=

=  

=  

There= is consensus on the statement that the relying party must reject the CRL i= f it encounters an unknown critical CRL extension.

And I= think (based on discussion over past few weeks) that most folks here belie= ve that the whole CRL should NOT be rejected because of an unknown critical= CRL entry extension.

=  

The o= nly point of contention is that if the certificate referred to by such a CR= L entry should be treated as ‘revoked’ or ‘unknown’= .

=  

-Piyu= sh

=  

From: pkix-bounces@ietf.org [mailto= :pkix-bounces@ietf.org] On Behalf Of Russ Housley
Sent: Tuesday, October 02, 2012 2:43 PM
To: Stephen Kent
Cc: pkix
Subject: Re: [pkix] 5280bis CRL problem poll results

 

The lack of consensus is troubling, but I have two c= oncerns with the proposed text.

 

First, if a critical CRL Entry Extension is unrecogn= ized, then the relying party cannot know that it is associated with particu= lar CRL Extension.  Your text assumes that the only thing that such an= extension might convey is the issuing CA.  This is true for the extensions that PKIX has discussed to date,= but I am not convinced that will be true for all time.

 

Second, I do not think there is a lack of consensus = on this statement: A relying party MUST reject a CRL that contains an unrec= ognized critical extension, regardless of the extension being a CRL Extensi= on or a CRL Entry Extension.

 

Russ

 

 

On Oct 2, 2012, at 12:24 PM, Stephen Kent wrote:



Folks,

 

It is apparent from the straw poll that there is no WG cons= ensus on this topic.

 

I propose the following text, in lieu of the current “= ;new second paragraph” that appears in Section 4 of draft-ietf-pkix-r= fc5280-clarifications-09.txt:

 

A critical extension in the crlEntryExtensions field of an = entry SHALL affect only the certificate specified in that entry, unless there is a related critical extension in the crlExtensions f= ield that advertises a special treatment for it. If a relying party is unab= le to process both a critical crlEntryExtension and a related critical crlE= xtension, the relying party is faced with a difficult choice.

 

1-  The relying party may assume that the the CRLEntry is associa= ted with the CA that issued the CRL, and thus treat that certificate as rev= oked. If the CRLEntry refers to a certificate issued by a different CA, the relying party will treat a valid certificate as being = revoked.



2-  The relying party, realizing that it cannot accurately determ= ine if the CRLEntry is associated with the CA that issued the CRL, may choo= se to treat that certificate as having an undetermined revocation status. If the relying party is able to consult other sources o= f certificate revocation status (e.g., OCSP) it may use those sources inste= ad. If not, the relying party may accept or reject the certificate as a mat= ter of local policy.



3-  The relying party may view the CRLEntry as being associated w= ith an undetermined CA, and treat all certificates with that serialNumber a= s being revoked. This behavior runs the risk of treating a number of valid certificates as revoked.

 

Because each of these options has associated risks, this document= does not specify relying party behavior under the circumstances noted above. A relying party may accept or reject certificates with the in= dicated serialNumber as a matter of local policy.

How does the WG feel about this alternate text?=

Steve

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

 

--_000_AA6BA445CBFDB84785CC1C45DAAE4C7931EB1EC2CH1PRD0610MB393_-- From piyush@identicate.com Wed Oct 3 09:02:27 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8CB121F8624 for ; Wed, 3 Oct 2012 09:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIoQjLneXdxi for ; Wed, 3 Oct 2012 09:02:25 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 5D63921F8668 for ; Wed, 3 Oct 2012 09:02:25 -0700 (PDT) Received: from mail17-ch1-R.bigfish.com (10.43.68.232) by CH1EHSOBE015.bigfish.com (10.43.70.65) with Microsoft SMTP Server id 14.1.225.23; Wed, 3 Oct 2012 16:02:24 +0000 Received: from mail17-ch1 (localhost [127.0.0.1]) by mail17-ch1-R.bigfish.com (Postfix) with ESMTP id 84B6E160329; Wed, 3 Oct 2012 16:02:24 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.229; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0610HT002.namprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: PS-21(zz9371Id6eahc85fhzz1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah1288h12a5h12bdh137ah1441h1155h) Received-SPF: pass (mail17-ch1: domain of identicate.com designates 157.56.244.229 as permitted sender) client-ip=157.56.244.229; envelope-from=piyush@identicate.com; helo=CH1PRD0610HT002.namprd06.prod.outlook.com ; .outlook.com ; Received: from mail17-ch1 (localhost.localdomain [127.0.0.1]) by mail17-ch1 (MessageSwitch) id 1349280143219502_6113; Wed, 3 Oct 2012 16:02:23 +0000 (UTC) Received: from CH1EHSMHS011.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.247]) by mail17-ch1.bigfish.com (Postfix) with ESMTP id 33EA64C0074; Wed, 3 Oct 2012 16:02:23 +0000 (UTC) Received: from CH1PRD0610HT002.namprd06.prod.outlook.com (157.56.244.229) by CH1EHSMHS011.bigfish.com (10.43.70.11) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 3 Oct 2012 16:02:22 +0000 Received: from CH1PRD0610MB393.namprd06.prod.outlook.com ([169.254.11.151]) by CH1PRD0610HT002.namprd06.prod.outlook.com ([10.255.151.37]) with mapi id 14.16.0207.009; Wed, 3 Oct 2012 16:02:20 +0000 From: Piyush Jain To: Stephen Kent , pkix Thread-Topic: [pkix] once again, with feeling ... Thread-Index: AQHNoXV01iRhzFg5dEOSp6DxkhN2IZentc5A Date: Wed, 3 Oct 2012 16:02:15 +0000 Message-ID: References: <506C4EF5.9030103@bbn.com> In-Reply-To: <506C4EF5.9030103@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [75.25.128.241] Content-Type: multipart/alternative; boundary="_000_AA6BA445CBFDB84785CC1C45DAAE4C7931EB1F08CH1PRD0610MB393_" MIME-Version: 1.0 X-OriginatorOrg: identicate.com Subject: Re: [pkix] once again, with feeling ... X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 16:02:28 -0000 --_000_AA6BA445CBFDB84785CC1C45DAAE4C7931EB1F08CH1PRD0610MB393_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Steve, I'm a little confused about the original issues that this proposed change i= s attempting to address. I don't think that tying a CRL entry to the cert issuer is the problem here= . That is addressed clearly by "Issuing Distribution Point" and "Certificat= e Issuer" extensions. Your proposal below assumes that a critical CRL entry extension (without an= associated CRL extension) can indicate that the CRL entry refers to a cert= ificate not issued by the CRL issuer. One can argue that this provides mor= e flexibility to future CRL entry extension designers, but IMHO it would be= bad design and just complicate the processing of CRLs unnecessarily. As I understood the original problem: Should the RP use a CRL entry with un= known critical extension for revocation status check or not? -Piyush From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Ste= phen Kent Sent: Wednesday, October 03, 2012 7:43 AM To: pkix Subject: [pkix] once again, with feeling ... Thank for the feedback. Obviously my text was incorrect in that an RP that = can't process a CRL extension has no way of determining if that extension is related to a= CRL entry extension that it also cannot process. Also, there was no intent to change the requi= rements re dealing with an unknown CRL (vs. CRL entry) extension. Note that this text augments= Section 5.3 of 5280, which deals only with processing of CRL entry extensions. Based on feedback from several messages, I have revised the text slightly. = Here is my next pass. Steve ------ I propose the following text, in lieu of the current "new second paragraph"= that appears in Section 4 of draft-ietf-pkix-rfc5280-clarifications-09.txt= : A critical extension in the crlEntryExtensions field of an entry SHALL affe= ct only the certificate specified in that entry, unless there is a related = critical extension in the crlExtensions field that advertises a special tre= atment for it. If a relying party is unable to process a critical crlEntryE= xtension, the relying party is faced with a difficult choice. 1- The relying party may assume that the the CRLEntry is associated with t= he CA that issued the CRL, and thus treat that certificate as revoked. If t= he CRLEntry refers to a certificate issued by a different CA, the relying p= arty will treat a valid certificate as being revoked. 2- The relying party, realizing that it cannot accurately determine if the= CRLEntry is associated with the CA that issued the CRL, may choose to trea= t that certificate as having an undetermined revocation status. If the rely= ing party is able to consult other sources of certificate revocation status= (e.g., OCSP) it may use those sources instead. If not, the relying party t= hen accepts or rejects the certificate as a matter of local policy. 3- The relying party may view the CRLEntry as being associated with an und= etermined CA, and treat all certificates with that serialNumber as being re= voked. This behavior runs the risk of treating a number of valid certificat= es as revoked. Because options one and three have associated risks, this document does not= specify relying party behavior under the circumstances noted above. A rely= ing party SHOULD accept or reject certificates with the indicated serialNum= ber as a matter of local policy. --_000_AA6BA445CBFDB84785CC1C45DAAE4C7931EB1F08CH1PRD0610MB393_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Steve= ,

=  

IR= 17;m a little confused about the original issues that this proposed change = is attempting to address.

=  

I don= ’t think that tying a CRL entry to the cert issuer is the problem her= e. That is addressed clearly by “Issuing Distribution Point” an= d “Certificate Issuer” extensions.

=  

Your = proposal below assumes that a critical CRL entry extension (without an asso= ciated CRL extension) can indicate that the CRL entry refers to a certifica= te not issued by the CRL issuer.  One can argue that this provides more flexibility to future CRL entry extensio= n designers, but IMHO it would be bad design and just complicate the proces= sing of CRLs unnecessarily.

=  

As I = understood the original problem: Should the RP use a CRL entry with unknown= critical extension for revocation status check or not?

=  

-Piyu= sh

=  

=  

=  

=  

=  

From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of S= tephen Kent
Sent: Wednesday, October 03, 2012 7:43 AM
To: pkix
Subject: [pkix] once again, with feeling ...

 

Thank for the feedback. Obviously my text was incorr= ect in that an RP that can't process
a CRL extension has no way of determining if that extension is related to a= CRL entry extension
that it also cannot process.  Also, there was no intent to change the = requirements re dealing
with an unknown CRL (vs. CRL entry) extension. Note that this text augments= Section 5.3 of 5280,
which deals only with processing of CRL entry extensions.

Based on feedback from several messages, I have revised the text slightly.&= nbsp; Here is my next pass.

Steve
------


I propose the following text, in lieu of the current “= ;new second paragraph” that appears in Section 4 of draft-ietf-pkix-r= fc5280-clarifications-09.txt:

 

A critical extension in the crlEntryExtensions field of an = entry SHALL affect only the certificate specified in that entry, unless there is a related critical extension in the crlExtensions f= ield that advertises a special treatment for it. If a relying party is unab= le to process a critical crlEntryExtension, the relying party is faced with= a difficult choice.

 

1-  The relying party may assume that the the CRLEntry is associa= ted with the CA that issued the CRL, and thus treat that certificate as rev= oked. If the CRLEntry refers to a certificate issued by a different CA, the relying party will treat a valid certificate as being = revoked.

2-  The relying party, realizing that it cannot accurately determ= ine if the CRLEntry is associated with the CA that issued the CRL, may choo= se to treat that certificate as having an undetermined revocation status. If the relying party is able to consult other sources o= f certificate revocation status (e.g., OCSP) it may use those sources inste= ad. If not, the relying party then accepts or rejects the certificate as a = matter of local policy.

3-  The relying party may view the CRLEntry as being associated w= ith an undetermined CA, and treat all certificates with that serialNumber a= s being revoked. This behavior runs the risk of treating a number of valid certificates as revoked.

 

Because options one and three have associated risks, this d= ocument does not specify relying party behavior under the circumstances noted above. A relying party SHOULD accept or reject certifi= cates with the indicated serialNumber as a matter of local policy.

 

--_000_AA6BA445CBFDB84785CC1C45DAAE4C7931EB1F08CH1PRD0610MB393_-- From denis.pinkas@bull.net Wed Oct 3 09:27:10 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BDE721F8555 for ; Wed, 3 Oct 2012 09:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.156 X-Spam-Level: X-Spam-Status: No, score=-2.156 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n06KLDVhiMNj for ; Wed, 3 Oct 2012 09:27:09 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA3821F8554 for ; Wed, 3 Oct 2012 09:27:09 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id 6889A1C6CC; Wed, 3 Oct 2012 18:27:08 +0200 (CEST) In-Reply-To: <506C4EF5.9030103@bbn.com> References: <506C4EF5.9030103@bbn.com> To: Stephen Kent MIME-Version: 1.0 X-KeepSent: 9D2BA3D8:02EF65FE-C1257A8C:0055FBF5; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010 From: denis.pinkas@bull.net Message-ID: Date: Wed, 3 Oct 2012 18:27:07 +0200 X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 03/10/2012 18:27:08, Serialize complete at 03/10/2012 18:27:08 Content-Type: multipart/alternative; boundary="=_alternative 005A59F5C1257A8C_=" Cc: pkix Subject: Re: [pkix] once again, with feeling ... X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 16:27:10 -0000 Message en plusieurs parties au format MIME --=_alternative 005A59F5C1257A8C_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 U3RldmUsDQoNClRoYW5rIHlvdSBmb3IgdGhlIG5ldyBwcm9wb3NhbC4gSXQgaXMgY2VydGFpbmx5 IGJldHRlciB0aGFuIHRoZSBwcmV2aW91cyANCm9uZS4NCg0KSSBoYXZlIHJldXNlZCB5b3VyIHRl eHQgYW5kIHJlYXJyYW5nZWQgaXQuIA0KDQpIZXJlIGlzIGEgbmV3IHN0cmF3bWFuIHByb3Bvc2Fs Og0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KQSBjcml0aWNhbCBleHRlbnNpb24gaW4g dGhlIGNybEVudHJ5RXh0ZW5zaW9ucyBmaWVsZCBvZiBhbiBlbnRyeSBTSEFMTCANCmFmZmVjdCBv bmx5IHRoZSBjZXJ0aWZpY2F0ZSBzcGVjaWZpZWQgaW4gdGhhdCBlbnRyeSwgDQp1bmxlc3MgdGhl cmUgaXMgYSByZWxhdGVkIGNyaXRpY2FsIGV4dGVuc2lvbiBpbiB0aGUgY3JsRXh0ZW5zaW9ucyBm aWVsZCANCnRoYXQgYWR2ZXJ0aXNlcyBhIHNwZWNpYWwgdHJlYXRtZW50IGZvciBpdC4gDQpJZiBh IHJlbHlpbmcgcGFydHkgaXMgdW5hYmxlIHRvIHByb2Nlc3MgYSBjcml0aWNhbCBjcmxFbnRyeUV4 dGVuc2lvbiwgdGhlIA0KcmVseWluZyBwYXJ0eSBjYW5ub3QgYWNjdXJhdGVseSBkZXRlcm1pbmUg DQp0aGUgcmV2b2NhdGlvbiBzdGF0dXMgb2YgdGhlIGNlcnRpZmljYXRlIGlkZW50aWZpZWQgaW4g dGhhdCBDUkxFbnRyeSwgDQp1bmxlc3MgdGhlIHJlbHlpbmcgcGFydHkgaXMgYWJsZSB0byBjb25z dWx0IA0Kb3RoZXIgc291cmNlcyBvZiBjZXJ0aWZpY2F0ZSByZXZvY2F0aW9uIHN0YXR1cyAoZS5n LiwgT0NTUCkgZm9yIHRoZSANCmNlcnRpZmljYXRlIGJlaW5nIGNoZWNrZWQuIEluIHN1Y2ggYSBj YXNlLCBpdCANCm1heSBvYnRhaW4gYSByZWxpYWJsZSByZXZvY2F0aW9uIHN0YXR1cy4gT3RoZXJ3 aXNlOg0KSWYgdGhlIHJlbHlpbmcgcGFydHkgaXMgYWJsZSB0byBrbm93ICh1c2luZyBvdXQgb2Yg YmFuZHMgbWVhbnMpIHRoYXQgdGhlIA0KQ1JMRW50cnkgaXMgYXNzb2NpYXRlZCB3aXRoIHRoZSBD QSB0aGF0IGlzc3VlZCANCnRoZSBDUkwsIHRoZW4gdGhlIHJlbHlpbmcgcGFydHkgU0hBTEwgY29u c2lkZXIgdGhhdCB0aGUgcmV2b2NhdGlvbiBzdGF0dXMgDQpvZiB0aGUgY2VydGlmaWNhdGUgaXMg cmV2b2tlZC4NCklmIHRoZSByZWx5aW5nIHBhcnR5IGlzIHVuYWJsZSB0byBrbm93IChldmVuIHVz aW5nIG91dCBvZiBiYW5kcyBtZWFucykgDQp3aGV0aGVyIHRoZSBDUkxFbnRyeSBpcyBhc3NvY2lh dGVkIHdpdGggdGhlIENBIA0KdGhhdCBpc3N1ZWQgdGhlIENSTCwgdGhlbiB0aGUgcmVseWluZyBw YXJ0eSBpcyBmYWNlZCB3aXRoIGEgZGlmZmljdWx0IA0KY2hvaWNlLiBIb3dldmVyLCBzaW5jZSBt b3N0IENBcyBhcmUgdXNpbmcgbGFyZ2UgDQpjZXJ0aWZpY2F0ZSBzZXJpYWwgbnVtYmVycyBhIGNv bGxpc2lvbiBiZXR3ZWVuIHN1Y2ggbnVtYmVycyBpcyByYXRoZXIgDQp1bmxpa2VseS4gU28gaXQg aXMgbW9yZSBsaWtlbHkgdGhhdCB0aGUgY2VydGlmaWNhdGUgDQpzZXJpYWwgbnVtYmVyIHJlbGF0 ZXMgdG8gdGhlIHJpZ2h0IENBIGFuZCBmb3IgdGhhdCByZWFzb24gdGhpcyBkb2N1bWVudCANClJF Q09NTUVORFMgdG8gY29uc2lkZXIgdGhhdCBjZXJ0aWZpY2F0ZSBhcyBoYXZpbmcgDQphIHJldm9r ZWQgcmV2b2NhdGlvbiBzdGF0dXMuICBIb3dldmVyLCBhIGxvY2FsIHBvbGljeSBtYXkgZGljdGF0 ZSANCm90aGVyd2lzZS4NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0NCkRlbmlzDQoNCg0KDQpEZSA6ICAgIFN0ZXBoZW4gS2VudCA8a2VudEBiYm4uY29tPg0K QSA6ICAgICBwa2l4IDxwa2l4QGlldGYub3JnPg0KRGF0ZSA6ICAwMy8xMC8yMDEyIDE2OjQzDQpP YmpldCA6IFtwa2l4XSBvbmNlIGFnYWluLCB3aXRoIGZlZWxpbmcgLi4uDQpFbnZvecOpIHBhciA6 ICAgIHBraXgtYm91bmNlc0BpZXRmLm9yZw0KDQoNCg0KVGhhbmsgZm9yIHRoZSBmZWVkYmFjay4g T2J2aW91c2x5IG15IHRleHQgd2FzIGluY29ycmVjdCBpbiB0aGF0IGFuIFJQIHRoYXQgDQpjYW4n dCBwcm9jZXNzDQphIENSTCBleHRlbnNpb24gaGFzIG5vIHdheSBvZiBkZXRlcm1pbmluZyBpZiB0 aGF0IGV4dGVuc2lvbiBpcyByZWxhdGVkIHRvIA0KYSBDUkwgZW50cnkgZXh0ZW5zaW9uDQp0aGF0 IGl0IGFsc28gY2Fubm90IHByb2Nlc3MuICBBbHNvLCB0aGVyZSB3YXMgbm8gaW50ZW50IHRvIGNo YW5nZSB0aGUgDQpyZXF1aXJlbWVudHMgcmUgZGVhbGluZw0Kd2l0aCBhbiB1bmtub3duIENSTCAo dnMuIENSTCBlbnRyeSkgZXh0ZW5zaW9uLiBOb3RlIHRoYXQgdGhpcyB0ZXh0IA0KYXVnbWVudHMg U2VjdGlvbiA1LjMgb2YgNTI4MCwNCndoaWNoIGRlYWxzIG9ubHkgd2l0aCBwcm9jZXNzaW5nIG9m IENSTCBlbnRyeSBleHRlbnNpb25zLiANCg0KQmFzZWQgb24gZmVlZGJhY2sgZnJvbSBzZXZlcmFs IG1lc3NhZ2VzLCBJIGhhdmUgcmV2aXNlZCB0aGUgdGV4dCBzbGlnaHRseS4gDQogSGVyZSBpcyBt eSBuZXh0IHBhc3MuDQoNClN0ZXZlDQotLS0tLS0NCg0KSSBwcm9wb3NlIHRoZSBmb2xsb3dpbmcg dGV4dCwgaW4gbGlldSBvZiB0aGUgY3VycmVudCDigJxuZXcgc2Vjb25kIA0KcGFyYWdyYXBo4oCd IHRoYXQgYXBwZWFycyBpbiBTZWN0aW9uIDQgb2YgDQpkcmFmdC1pZXRmLXBraXgtcmZjNTI4MC1j bGFyaWZpY2F0aW9ucy0wOS50eHQ6DQogDQpBIGNyaXRpY2FsIGV4dGVuc2lvbiBpbiB0aGUgY3Js RW50cnlFeHRlbnNpb25zIGZpZWxkIG9mIGFuIGVudHJ5IFNIQUxMIA0KYWZmZWN0IG9ubHkgdGhl IGNlcnRpZmljYXRlIHNwZWNpZmllZCBpbiB0aGF0IGVudHJ5LCB1bmxlc3MgdGhlcmUgaXMgYSAN CnJlbGF0ZWQgY3JpdGljYWwgZXh0ZW5zaW9uIGluIHRoZSBjcmxFeHRlbnNpb25zIGZpZWxkIHRo YXQgYWR2ZXJ0aXNlcyBhIA0Kc3BlY2lhbCB0cmVhdG1lbnQgZm9yIGl0LiBJZiBhIHJlbHlpbmcg cGFydHkgaXMgdW5hYmxlIHRvIHByb2Nlc3MgYSANCmNyaXRpY2FsIGNybEVudHJ5RXh0ZW5zaW9u LCB0aGUgcmVseWluZyBwYXJ0eSBpcyBmYWNlZCB3aXRoIGEgZGlmZmljdWx0IA0KY2hvaWNlLiAN CiANCjEtICBUaGUgcmVseWluZyBwYXJ0eSBtYXkgYXNzdW1lIHRoYXQgdGhlIHRoZSBDUkxFbnRy eSBpcyBhc3NvY2lhdGVkIHdpdGggDQp0aGUgQ0EgdGhhdCBpc3N1ZWQgdGhlIENSTCwgYW5kIHRo dXMgdHJlYXQgdGhhdCBjZXJ0aWZpY2F0ZSBhcyByZXZva2VkLiBJZiANCnRoZSBDUkxFbnRyeSBy ZWZlcnMgdG8gYSBjZXJ0aWZpY2F0ZSBpc3N1ZWQgYnkgYSBkaWZmZXJlbnQgQ0EsIHRoZSByZWx5 aW5nIA0KcGFydHkgd2lsbCB0cmVhdCBhIHZhbGlkIGNlcnRpZmljYXRlIGFzIGJlaW5nIHJldm9r ZWQuDQoyLSAgVGhlIHJlbHlpbmcgcGFydHksIHJlYWxpemluZyB0aGF0IGl0IGNhbm5vdCBhY2N1 cmF0ZWx5IGRldGVybWluZSBpZiANCnRoZSBDUkxFbnRyeSBpcyBhc3NvY2lhdGVkIHdpdGggdGhl IENBIHRoYXQgaXNzdWVkIHRoZSBDUkwsIG1heSBjaG9vc2UgdG8gDQp0cmVhdCB0aGF0IGNlcnRp ZmljYXRlIGFzIGhhdmluZyBhbiB1bmRldGVybWluZWQgcmV2b2NhdGlvbiBzdGF0dXMuIElmIHRo ZSANCnJlbHlpbmcgcGFydHkgaXMgYWJsZSB0byBjb25zdWx0IG90aGVyIHNvdXJjZXMgb2YgY2Vy dGlmaWNhdGUgcmV2b2NhdGlvbiANCnN0YXR1cyAoZS5nLiwgT0NTUCkgaXQgbWF5IHVzZSB0aG9z ZSBzb3VyY2VzIGluc3RlYWQuIElmIG5vdCwgdGhlIHJlbHlpbmcgDQpwYXJ0eSB0aGVuIGFjY2Vw dHMgb3IgcmVqZWN0cyB0aGUgY2VydGlmaWNhdGUgYXMgYSBtYXR0ZXIgb2YgbG9jYWwgcG9saWN5 Lg0KMy0gIFRoZSByZWx5aW5nIHBhcnR5IG1heSB2aWV3IHRoZSBDUkxFbnRyeSBhcyBiZWluZyBh c3NvY2lhdGVkIHdpdGggYW4gDQp1bmRldGVybWluZWQgQ0EsIGFuZCB0cmVhdCBhbGwgY2VydGlm aWNhdGVzIHdpdGggdGhhdCBzZXJpYWxOdW1iZXIgYXMgDQpiZWluZyByZXZva2VkLiBUaGlzIGJl aGF2aW9yIHJ1bnMgdGhlIHJpc2sgb2YgdHJlYXRpbmcgYSBudW1iZXIgb2YgdmFsaWQgDQpjZXJ0 aWZpY2F0ZXMgYXMgcmV2b2tlZC4NCiANCkJlY2F1c2Ugb3B0aW9ucyBvbmUgYW5kIHRocmVlIGhh dmUgYXNzb2NpYXRlZCByaXNrcywgdGhpcyBkb2N1bWVudCBkb2VzIA0Kbm90IHNwZWNpZnkgcmVs eWluZyBwYXJ0eSBiZWhhdmlvciB1bmRlciB0aGUgY2lyY3Vtc3RhbmNlcyBub3RlZCBhYm92ZS4g QSANCnJlbHlpbmcgcGFydHkgU0hPVUxEIGFjY2VwdCBvciByZWplY3QgY2VydGlmaWNhdGVzIHdp dGggdGhlIGluZGljYXRlZCANCnNlcmlhbE51bWJlciBhcyBhIG1hdHRlciBvZiBsb2NhbCBwb2xp Y3kuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcGtp eCBtYWlsaW5nIGxpc3QNCnBraXhAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcGtpeA0KDQoNCg== --=_alternative 005A59F5C1257A8C_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5TdGV2ZSw8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9IkFyaWFsIj5UaGFuayB5b3UgZm9yIHRoZSBuZXcgcHJvcG9zYWwuIEl0IGlz IGNlcnRhaW5seQ0KYmV0dGVyIHRoYW4gdGhlIHByZXZpb3VzIG9uZS48L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5JIGhhdmUgcmV1c2VkIHlvdXIgdGV4dCBhbmQg cmVhcnJhbmdlZCBpdC4NCjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJp YWwiPkhlcmUgaXMgYSBuZXcgc3RyYXdtYW4gcHJvcG9zYWw6PC9mb250Pg0KPGJyPg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJBcmlhbCI+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08L2ZvbnQ+ DQo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPkEgY3JpdGljYWwgZXh0ZW5zaW9u IGluIHRoZSBjcmxFbnRyeUV4dGVuc2lvbnMNCmZpZWxkIG9mIGFuIGVudHJ5IFNIQUxMIGFmZmVj dCBvbmx5IHRoZSBjZXJ0aWZpY2F0ZSBzcGVjaWZpZWQgaW4gdGhhdCBlbnRyeSwNCjxicj4NCnVu bGVzcyB0aGVyZSBpcyBhIHJlbGF0ZWQgY3JpdGljYWwgZXh0ZW5zaW9uIGluIHRoZSBjcmxFeHRl bnNpb25zIGZpZWxkDQp0aGF0IGFkdmVydGlzZXMgYSBzcGVjaWFsIHRyZWF0bWVudCBmb3IgaXQu IDwvZm9udD4NCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+SWYgYSByZWx5aW5n IHBhcnR5IGlzIHVuYWJsZSB0byBwcm9jZXNzDQphIGNyaXRpY2FsIGNybEVudHJ5RXh0ZW5zaW9u LCB0aGUgcmVseWluZyBwYXJ0eSBjYW5ub3QgYWNjdXJhdGVseSBkZXRlcm1pbmUNCjxicj4NCnRo ZSByZXZvY2F0aW9uIHN0YXR1cyBvZiB0aGUgY2VydGlmaWNhdGUgaWRlbnRpZmllZCBpbiB0aGF0 IENSTEVudHJ5LCB1bmxlc3MNCnRoZSByZWx5aW5nIHBhcnR5IGlzIGFibGUgdG8gY29uc3VsdCA8 YnI+DQpvdGhlciBzb3VyY2VzIG9mIGNlcnRpZmljYXRlIHJldm9jYXRpb24gc3RhdHVzIChlLmcu LCBPQ1NQKSBmb3IgdGhlIGNlcnRpZmljYXRlDQpiZWluZyBjaGVja2VkLiBJbiBzdWNoIGEgY2Fz ZSwgaXQgPGJyPg0KbWF5IG9idGFpbiBhIHJlbGlhYmxlIHJldm9jYXRpb24gc3RhdHVzLiBPdGhl cndpc2U6PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5JZiB0aGUg cmVseWluZyBwYXJ0eSBpcyBhYmxlIHRvIGtub3cNCih1c2luZyBvdXQgb2YgYmFuZHMgbWVhbnMp IHRoYXQgdGhlIENSTEVudHJ5IGlzIGFzc29jaWF0ZWQgd2l0aCB0aGUgQ0ENCnRoYXQgaXNzdWVk IDxicj4NCnRoZSBDUkwsIHRoZW4gdGhlIHJlbHlpbmcgcGFydHkgU0hBTEwgY29uc2lkZXIgdGhh dCB0aGUgcmV2b2NhdGlvbiBzdGF0dXMNCm9mIHRoZSBjZXJ0aWZpY2F0ZSBpcyByZXZva2VkLjwv Zm9udD4NCjxwPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+SWYgdGhlIHJlbHlpbmcg cGFydHkgaXMgdW5hYmxlIHRvIGtub3cNCihldmVuIHVzaW5nIG91dCBvZiBiYW5kcyBtZWFucykg d2hldGhlciB0aGUgQ1JMRW50cnkgaXMgYXNzb2NpYXRlZCB3aXRoDQp0aGUgQ0EgPGJyPg0KdGhh dCBpc3N1ZWQgdGhlIENSTCwgdGhlbiB0aGUgcmVseWluZyBwYXJ0eSBpcyBmYWNlZCB3aXRoIGEg ZGlmZmljdWx0IGNob2ljZS4NCkhvd2V2ZXIsIHNpbmNlIG1vc3QgQ0FzIGFyZSB1c2luZyBsYXJn ZSA8YnI+DQpjZXJ0aWZpY2F0ZSBzZXJpYWwgbnVtYmVycyBhIGNvbGxpc2lvbiBiZXR3ZWVuIHN1 Y2ggbnVtYmVycyBpcyByYXRoZXIgdW5saWtlbHkuDQpTbyBpdCBpcyBtb3JlIGxpa2VseSB0aGF0 IHRoZSBjZXJ0aWZpY2F0ZSA8YnI+DQpzZXJpYWwgbnVtYmVyIHJlbGF0ZXMgdG8gdGhlIHJpZ2h0 IENBIGFuZCBmb3IgdGhhdCByZWFzb24gdGhpcyBkb2N1bWVudA0KUkVDT01NRU5EUyB0byBjb25z aWRlciB0aGF0IGNlcnRpZmljYXRlIGFzIGhhdmluZyA8YnI+DQphIHJldm9rZWQgcmV2b2NhdGlv biBzdGF0dXMuICZuYnNwO0hvd2V2ZXIsIGEgbG9jYWwgcG9saWN5IG1heSBkaWN0YXRlDQpvdGhl cndpc2UuPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj49PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0y IGZhY2U9IkFyaWFsIj5EZW5pczwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj48Zm9udCBz aXplPTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5EZSA6ICZuYnNwOyAmbmJzcDsg Jm5ic3A7DQombmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlN0ZXBo ZW4gS2VudCAmbHQ7a2VudEBiYm4uY29tJmd0OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgY29s b3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5BIDogJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZu YnNwOzwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+cGtpeCAmbHQ7cGtpeEBp ZXRmLm9yZyZndDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0i c2Fucy1zZXJpZiI+RGF0ZSA6ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDs8L2ZvbnQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjAzLzEwLzIwMTIgMTY6NDM8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+T2JqZXQgOiAmbmJz cDsgJm5ic3A7DQombmJzcDsgJm5ic3A7PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj5bcGtpeF0gb25jZQ0KYWdhaW4sIHdpdGggZmVlbGluZyAuLi48L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+RW52b3nDqSBwYXIgOiAm bmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj5wa2l4LWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8YnI+DQo8aHIgbm9zaGFkZT4N Cjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+VGhhbmsgZm9yIHRoZSBmZWVkYmFjay4gT2J2 aW91c2x5IG15IHRleHQgd2FzIGluY29ycmVjdA0KaW4gdGhhdCBhbiBSUCB0aGF0IGNhbid0IHBy b2Nlc3M8YnI+DQphIENSTCBleHRlbnNpb24gaGFzIG5vIHdheSBvZiBkZXRlcm1pbmluZyBpZiB0 aGF0IGV4dGVuc2lvbiBpcyByZWxhdGVkDQp0byBhIENSTCBlbnRyeSBleHRlbnNpb248YnI+DQp0 aGF0IGl0IGFsc28gY2Fubm90IHByb2Nlc3MuICZuYnNwO0Fsc28sIHRoZXJlIHdhcyBubyBpbnRl bnQgdG8gY2hhbmdlDQp0aGUgcmVxdWlyZW1lbnRzIHJlIGRlYWxpbmc8YnI+DQp3aXRoIGFuIHVu a25vd24gQ1JMICh2cy4gQ1JMIGVudHJ5KSBleHRlbnNpb24uIE5vdGUgdGhhdCB0aGlzIHRleHQg YXVnbWVudHMNClNlY3Rpb24gNS4zIG9mIDUyODAsPGJyPg0Kd2hpY2ggZGVhbHMgb25seSB3aXRo IHByb2Nlc3Npbmcgb2YgQ1JMIDx1PmVudHJ5PC91PiBleHRlbnNpb25zLiA8YnI+DQo8YnI+DQpC YXNlZCBvbiBmZWVkYmFjayBmcm9tIHNldmVyYWwgbWVzc2FnZXMsIEkgaGF2ZSByZXZpc2VkIHRo ZSB0ZXh0IHNsaWdodGx5Lg0KJm5ic3A7SGVyZSBpcyBteSBuZXh0IHBhc3MuPGJyPg0KPGJyPg0K U3RldmU8YnI+DQotLS0tLS08YnI+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTI+SSBwcm9wb3Nl IHRoZSBmb2xsb3dpbmcgdGV4dCwgaW4gbGlldSBvZiB0aGUgY3VycmVudCDigJxuZXcNCnNlY29u ZCBwYXJhZ3JhcGjigJ0gdGhhdCBhcHBlYXJzIGluIFNlY3Rpb24gNCBvZiBkcmFmdC1pZXRmLXBr aXgtcmZjNTI4MC1jbGFyaWZpY2F0aW9ucy0wOS50eHQ6PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0y PiZuYnNwOzwvZm9udD4NCjxwPjxmb250IHNpemU9Mj5BIGNyaXRpY2FsIGV4dGVuc2lvbiBpbiB0 aGUgY3JsRW50cnlFeHRlbnNpb25zIGZpZWxkIG9mDQphbiBlbnRyeSBTSEFMTCBhZmZlY3Qgb25s eSB0aGUgY2VydGlmaWNhdGUgc3BlY2lmaWVkIGluIHRoYXQgZW50cnksIHVubGVzcw0KdGhlcmUg aXMgYSByZWxhdGVkIGNyaXRpY2FsIGV4dGVuc2lvbiBpbiB0aGUgY3JsRXh0ZW5zaW9ucyBmaWVs ZCB0aGF0IGFkdmVydGlzZXMNCmEgc3BlY2lhbCB0cmVhdG1lbnQgZm9yIGl0LiBJZiBhIHJlbHlp bmcgcGFydHkgaXMgdW5hYmxlIHRvIHByb2Nlc3MgYSBjcml0aWNhbA0KY3JsRW50cnlFeHRlbnNp b24sIHRoZSByZWx5aW5nIHBhcnR5IGlzIGZhY2VkIHdpdGggYSBkaWZmaWN1bHQgY2hvaWNlLg0K PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0yPiZuYnNwOzwvZm9udD4NCjxwPjxmb250IHNpemU9Mj4x LSAmbmJzcDtUaGUgcmVseWluZyBwYXJ0eSBtYXkgYXNzdW1lIHRoYXQgdGhlIHRoZSBDUkxFbnRy eQ0KaXMgYXNzb2NpYXRlZCB3aXRoIHRoZSBDQSB0aGF0IGlzc3VlZCB0aGUgQ1JMLCBhbmQgdGh1 cyB0cmVhdCB0aGF0IGNlcnRpZmljYXRlDQphcyByZXZva2VkLiBJZiB0aGUgQ1JMRW50cnkgcmVm ZXJzIHRvIGEgY2VydGlmaWNhdGUgaXNzdWVkIGJ5IGEgZGlmZmVyZW50DQpDQSwgdGhlIHJlbHlp bmcgcGFydHkgd2lsbCB0cmVhdCBhIHZhbGlkIGNlcnRpZmljYXRlIGFzIGJlaW5nIHJldm9rZWQu PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0yPjItICZuYnNwO1RoZSByZWx5aW5nIHBhcnR5LCByZWFs aXppbmcgdGhhdCBpdCBjYW5ub3QgYWNjdXJhdGVseQ0KZGV0ZXJtaW5lIGlmIHRoZSBDUkxFbnRy eSBpcyBhc3NvY2lhdGVkIHdpdGggdGhlIENBIHRoYXQgaXNzdWVkIHRoZSBDUkwsDQptYXkgY2hv b3NlIHRvIHRyZWF0IHRoYXQgY2VydGlmaWNhdGUgYXMgaGF2aW5nIGFuIHVuZGV0ZXJtaW5lZCBy ZXZvY2F0aW9uDQpzdGF0dXMuIElmIHRoZSByZWx5aW5nIHBhcnR5IGlzIGFibGUgdG8gY29uc3Vs dCBvdGhlciBzb3VyY2VzIG9mIGNlcnRpZmljYXRlDQpyZXZvY2F0aW9uIHN0YXR1cyAoZS5nLiwg T0NTUCkgaXQgbWF5IHVzZSB0aG9zZSBzb3VyY2VzIGluc3RlYWQuIElmIG5vdCwNCnRoZSByZWx5 aW5nIHBhcnR5IHRoZW4gYWNjZXB0cyBvciByZWplY3RzIHRoZSBjZXJ0aWZpY2F0ZSBhcyBhIG1h dHRlciBvZg0KbG9jYWwgcG9saWN5LjwvZm9udD4NCjxwPjxmb250IHNpemU9Mj4zLSAmbmJzcDtU aGUgcmVseWluZyBwYXJ0eSBtYXkgdmlldyB0aGUgQ1JMRW50cnkgYXMgYmVpbmcNCmFzc29jaWF0 ZWQgd2l0aCBhbiB1bmRldGVybWluZWQgQ0EsIGFuZCB0cmVhdCBhbGwgY2VydGlmaWNhdGVzIHdp dGggdGhhdA0Kc2VyaWFsTnVtYmVyIGFzIGJlaW5nIHJldm9rZWQuIFRoaXMgYmVoYXZpb3IgcnVu cyB0aGUgcmlzayBvZiB0cmVhdGluZw0KYSBudW1iZXIgb2YgdmFsaWQgY2VydGlmaWNhdGVzIGFz IHJldm9rZWQuPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0yPiZuYnNwOzwvZm9udD4NCjxwPjxmb250 IHNpemU9Mj5CZWNhdXNlIG9wdGlvbnMgb25lIGFuZCB0aHJlZSBoYXZlIGFzc29jaWF0ZWQgcmlz a3MsIHRoaXMNCmRvY3VtZW50IGRvZXMgbm90IHNwZWNpZnkgcmVseWluZyBwYXJ0eSBiZWhhdmlv ciB1bmRlciB0aGUgY2lyY3Vtc3RhbmNlcw0Kbm90ZWQgYWJvdmUuIEEgcmVseWluZyBwYXJ0eSBT SE9VTEQgYWNjZXB0IG9yIHJlamVjdCBjZXJ0aWZpY2F0ZXMgd2l0aA0KdGhlIGluZGljYXRlZCBz ZXJpYWxOdW1iZXIgYXMgYSBtYXR0ZXIgb2YgbG9jYWwgcG9saWN5LjwvZm9udD4NCjxwPjx0dD48 Zm9udCBzaXplPTI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpwa2l4IG1haWxpbmcgbGlzdDxicj4NCnBraXhAaWV0Zi5vcmc8YnI+DQo8L2ZvbnQ+ PC90dD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGtpeD48 dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGtp eDwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCjwvZm9udD48L3R0Pg0KPHA+ DQo= --=_alternative 005A59F5C1257A8C_=-- From housley@vigilsec.com Wed Oct 3 10:08:02 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C99C21F8688 for ; Wed, 3 Oct 2012 10:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qmFo9SEw7EYD for ; Wed, 3 Oct 2012 10:08:01 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 0754921F8673 for ; Wed, 3 Oct 2012 10:08:01 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 7A7339A4002; Wed, 3 Oct 2012 13:08:20 -0400 (EDT) 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 AomaO32yNo+q; Wed, 3 Oct 2012 13:07:49 -0400 (EDT) Received: from [192.168.2.100] (pool-96-255-37-162.washdc.fios.verizon.net [96.255.37.162]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id F2D9E9A4001; Wed, 3 Oct 2012 13:08:18 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-53--537792542 From: Russ Housley In-Reply-To: Date: Wed, 3 Oct 2012 13:07:58 -0400 Message-Id: <3BA097D9-B4ED-44EF-B3A5-3B7BBC60EE15@vigilsec.com> References: <506B154F.3080501@bbn.com> To: Piyush Jain X-Mailer: Apple Mail (2.1084) Cc: IETF PKIX Subject: Re: [pkix] 5280bis CRL problem poll results X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 17:08:02 -0000 --Apple-Mail-53--537792542 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I recognize that people want the critical CRL entry extension to only = mean that that entry cannot be used. But RFC 5280 already says = otherwise. Section 5.3 says: ... If a CRL contains a critical CRL entry extension that the application cannot process, then the application MUST NOT use that CRL to determine the status of any certificates. ... The clarifications document cannot reverse this MUST statement. Russ On Oct 3, 2012, at 11:30 AM, Piyush Jain wrote: > Russ, > =20 > =20 > There is consensus on the statement that the relying party must reject = the CRL if it encounters an unknown critical CRL extension. > And I think (based on discussion over past few weeks) that most folks = here believe that the whole CRL should NOT be rejected because of an = unknown critical CRL entry extension. > =20 > The only point of contention is that if the certificate referred to by = such a CRL entry should be treated as =91revoked=92 or =91unknown=92. > =20 > -Piyush > =20 > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf = Of Russ Housley > Sent: Tuesday, October 02, 2012 2:43 PM > To: Stephen Kent > Cc: pkix > Subject: Re: [pkix] 5280bis CRL problem poll results > =20 > The lack of consensus is troubling, but I have two concerns with the = proposed text. > =20 > First, if a critical CRL Entry Extension is unrecognized, then the = relying party cannot know that it is associated with particular CRL = Extension. Your text assumes that the only thing that such an extension = might convey is the issuing CA. This is true for the extensions that = PKIX has discussed to date, but I am not convinced that will be true for = all time. > =20 > Second, I do not think there is a lack of consensus on this statement: = A relying party MUST reject a CRL that contains an unrecognized critical = extension, regardless of the extension being a CRL Extension or a CRL = Entry Extension. > =20 > Russ > =20 > =20 > On Oct 2, 2012, at 12:24 PM, Stephen Kent wrote: >=20 >=20 > Folks, > =20 > It is apparent from the straw poll that there is no WG consensus on = this topic. > =20 > I propose the following text, in lieu of the current =93new second = paragraph=94 that appears in Section 4 of = draft-ietf-pkix-rfc5280-clarifications-09.txt: > =20 > A critical extension in the crlEntryExtensions field of an entry SHALL = affect only the certificate specified in that entry, unless there is a = related critical extension in the crlExtensions field that advertises a = special treatment for it. If a relying party is unable to process both a = critical crlEntryExtension and a related critical crlExtension, the = relying party is faced with a difficult choice. > =20 > 1- The relying party may assume that the the CRLEntry is associated = with the CA that issued the CRL, and thus treat that certificate as = revoked. If the CRLEntry refers to a certificate issued by a different = CA, the relying party will treat a valid certificate as being revoked. >=20 >=20 > 2- The relying party, realizing that it cannot accurately determine = if the CRLEntry is associated with the CA that issued the CRL, may = choose to treat that certificate as having an undetermined revocation = status. If the relying party is able to consult other sources of = certificate revocation status (e.g., OCSP) it may use those sources = instead. If not, the relying party may accept or reject the certificate = as a matter of local policy. >=20 >=20 > 3- The relying party may view the CRLEntry as being associated with = an undetermined CA, and treat all certificates with that serialNumber as = being revoked. This behavior runs the risk of treating a number of valid = certificates as revoked. > =20 > Because each of these options has associated risks, this document does = not specify relying party behavior under the circumstances noted above. = A relying party may accept or reject certificates with the indicated = serialNumber as a matter of local policy. >=20 > How does the WG feel about this alternate text? >=20 > Steve > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > =20 --Apple-Mail-53--537792542 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
I = recognize that people want the critical CRL entry extension to only mean = that that entry cannot be used.  But RFC 5280 already says = otherwise.  Section 5.3 says:

  ... If a = CRL
  contains a critical CRL entry extension that the = application cannot
  process, then the application MUST NOT = use that CRL to determine the
  status of any certificates. = ...

The clarifications document cannot reverse this MUST = statement.

Russ



On = Oct 3, 2012, at 11:30 AM, Piyush Jain wrote:

Russ,
 
And I think (based on discussion over = past few weeks) that most folks here believe that the whole CRL should = NOT be rejected because of an unknown critical CRL entry = extension.
 
 
 
From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org= ] On Behalf Of Russ = Housley
Sent: Tuesday, October 02, 2012 = 2:43 PM
To: Stephen = Kent
Cc: pkix
Subject: Re: [pkix] 5280bis CRL = problem poll results
 
The lack of consensus is = troubling, but I have two concerns with the proposed = text.
First, if a critical CRL Entry = Extension is unrecognized, then the relying party cannot know that it is = associated with particular CRL Extension.  Your text assumes that = the only thing that such an extension might convey is the issuing CA. =  This is true for the extensions that PKIX has discussed to date, = but I am not convinced that will be true for all = time.
Second, I do not think there = is a lack of consensus on this statement: A relying party MUST reject a = CRL that contains an unrecognized critical extension, regardless of the = extension being a CRL Extension or a CRL Entry = Extension.
On Oct 2, 2012, at 12:24 PM, = Stephen Kent wrote:
Folks,
 
It is apparent from the straw poll = that there is no WG consensus on this topic.
 
I propose the following text, in = lieu of the current =93new second paragraph=94 that appears in Section 4 = of = draft-ietf-pkix-rfc5280-clarifications-09.txt:
 
A critical extension in the = crlEntryExtensions field of an entry SHALL affect only the certificate = specified in that entry, unless there is a related critical extension in = the crlExtensions field that advertises a special treatment for it. If a = relying party is unable to process both a critical crlEntryExtension and = a related critical crlExtension, the relying party is faced with a = difficult choice.
 
1- The relying = party may assume that the the CRLEntry is associated with the CA that = issued the CRL, and thus treat that certificate as revoked. If the = CRLEntry refers to a certificate issued by a different CA, the relying = party will treat a valid certificate as being = revoked.
2-  The relying = party, realizing that it cannot accurately determine if the CRLEntry is = associated with the CA that issued the CRL, may choose to treat that = certificate as having an undetermined revocation status. If the relying = party is able to consult other sources of certificate revocation status = (e.g., OCSP) it may use those sources instead. If not, the relying party = may accept or reject the certificate as a matter of local = policy.
3-  The relying = party may view the CRLEntry as being associated with an undetermined CA, = and treat all certificates with that serialNumber as being revoked. This = behavior runs the risk of treating a number of valid certificates as = revoked.
 

Because each of these options has associated risks, = this document does not specify relying party behavior under the = circumstances noted above. A relying party may accept or reject = certificates with the indicated serialNumber as a matter of local = policy.

How does the WG = feel about this alternate text?

Steve
pkix@ietf.org
then the relying party cannot know that it is associated with = particular CRL Extension", since=20 > it directly relates to the question I asked to Steve.=20 >=20 > However, I disagree with your last statement, i.e. "A relying party = MUST reject a CRL that contains=20 > an unrecognized critical extension, regardless of the extension being = a CRL Extension or a CRL Entry Extension.=20 >=20 > The sentence should be changed into: "A relying party MUST reject a = CRL that contains=20 > an unrecognized critical extension in a CRL Extension".=20 >=20 > Denis=20 >=20 >=20 >=20 > De : Russ Housley =20 > A : Stephen Kent =20 > Cc : pkix =20 > Date : 02/10/2012 23:43=20 > Objet : Re: [pkix] 5280bis CRL problem poll results=20 > Envoy=E9 par : pkix-bounces@ietf.org=20 >=20 >=20 >=20 > The lack of consensus is troubling, but I have two concerns with the = proposed text.=20 >=20 > First, if a critical CRL Entry Extension is unrecognized, then the = relying party cannot know that it is associated with particular CRL = Extension. Your text assumes that the only thing that such an extension = might convey is the issuing CA. This is true for the extensions that = PKIX has discussed to date, but I am not convinced that will be true for = all time.=20 >=20 > Second, I do not think there is a lack of consensus on this statement: = A relying party MUST reject a CRL that contains an unrecognized critical = extension, regardless of the extension being a CRL Extension or a CRL = Entry Extension.=20 >=20 > Russ=20 >=20 >=20 > On Oct 2, 2012, at 12:24 PM, Stephen Kent wrote:=20 > Folks, >=20 > =20 > It is apparent from the straw poll that there is no WG consensus on = this topic. >=20 > =20 > I propose the following text, in lieu of the current =93new second = paragraph=94 that appears in Section 4 of = draft-ietf-pkix-rfc5280-clarifications-09.txt: >=20 > =20 > A critical extension in the crlEntryExtensions field of an entry SHALL = affect only the certificate specified in that entry, unless there is a = related critical extension in the crlExtensions field that advertises a = special treatment for it. If a relying party is unable to process both a = critical crlEntryExtension and a related critical crlExtension, the = relying party is faced with a difficult choice. >=20 > =20 > 1- The relying party may assume that the the CRLEntry is associated = with the CA that issued the CRL, and thus treat that certificate as = revoked. If the CRLEntry refers to a certificate issued by a different = CA, the relying party will treat a valid certificate as being revoked. >=20 >=20 > 2- The relying party, realizing that it cannot accurately determine = if the CRLEntry is associated with the CA that issued the CRL, may = choose to treat that certificate as having an undetermined revocation = status. If the relying party is able to consult other sources of = certificate revocation status (e.g., OCSP) it may use those sources = instead. If not, the relying party may accept or reject the certificate = as a matter of local policy. >=20 >=20 > 3- The relying party may view the CRLEntry as being associated with = an undetermined CA, and treat all certificates with that serialNumber as = being revoked. This behavior runs the risk of treating a number of valid = certificates as revoked. >=20 > =20 > Because each of these options has associated risks, this document does = not specify relying party behavior under the circumstances noted above. = A relying party may accept or reject certificates with the indicated = serialNumber as a matter of local policy. >=20 > How does the WG feel about this alternate text? >=20 > Steve >=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-55--536195861 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Denis.Pinkas@bull.net = wrote:

Russ,

While I agree with your first = statement, i.e. ; "if a critical CRL Entry Extension is unrecognized,
then the relying party cannot know that it is associated with particular CRL Extension", since
it directly relates to the question I asked to Steve.

However, I disagree with your last = statement, i.e. "A relying party MUST reject a CRL that contains
an unrecognized critical extension, regardless of the extension being a CRL Extension or a CRL Entry Extension.

The sentence should be changed into: = "A relying party MUST reject a CRL that contains
an unrecognized critical extension in a CRL Extension".

Denis



De :   =      Russ Housley <housley@vigilsec.com>
A :   =      Stephen Kent <kent@bbn.com>
Cc : =        pkix <pkix@ietf.org>
Date :   =      02/10/2012 = 23:43
Objet : =        Re: [pkix] = 5280bis CRL problem poll results
Envoy=E9 par = :        pkix-bounces@ietf.org



The lack of consensus is troubling, but I have two = concerns with the proposed text.

First, if a critical CRL Entry Extension is = unrecognized, then the relying party cannot know that it is associated with particular CRL Extension.  Your text assumes that the only thing that such an extension might convey is the issuing CA.  This is true for the = extensions that PKIX has discussed to date, but I am not convinced that will be = true for all time.

Second, I do not think there is a lack of consensus = on this statement: A relying party MUST reject a CRL that contains an = unrecognized critical extension, regardless of the extension being a CRL Extension or a CRL Entry Extension.

Russ


On Oct 2, 2012, at 12:24 PM, Stephen Kent = wrote:

Folks,

 

It is = apparent from the straw poll that there is no WG consensus on this topic.

 

I = propose the following text, in lieu of the current =93new second paragraph=94 that appears in Section 4 of = draft-ietf-pkix-rfc5280-clarifications-09.txt:

 

A = critical extension in the crlEntryExtensions field of an entry SHALL affect only the certificate specified in that entry, = unless there is a related critical extension in the crlExtensions field that = advertises a special treatment for it. If a relying party is unable to process both a critical crlEntryExtension and a related critical crlExtension, the = relying party is faced with a difficult choice.

 

1- =  The relying party may assume that the the CRLEntry is associated with the CA that issued the CRL, and thus treat that = certificate as revoked. If the CRLEntry refers to a certificate issued by a = different CA, the relying party will treat a valid certificate as being = revoked.


2- =  The relying party, realizing that it cannot accurately determine if the CRLEntry is associated with the CA that issued the CRL, may choose to treat that certificate as having an undetermined = revocation status. If the relying party is able to consult other sources of = certificate revocation status (e.g., OCSP) it may use those sources instead. If not, the relying party may accept or reject the certificate as a matter of = local policy.


3- =  The relying party may view the CRLEntry as being associated with an undetermined CA, and treat all certificates with that serialNumber as being revoked. This behavior runs the risk of treating a number of valid certificates as revoked.

 

Because = each of these options has associated risks, this document does not specify relying party behavior under the circumstances noted above. A relying party may accept or reject certificates with the indicated serialNumber as a matter of local policy.

How does the WG feel about this alternate = text?

Steve

_______________________________________________
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<= font size=3D"2">


= --Apple-Mail-55--536195861-- From kent@bbn.com Wed Oct 3 10:51:03 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8C7621F852B for ; Wed, 3 Oct 2012 10:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.445 X-Spam-Level: X-Spam-Status: No, score=-106.445 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pw3iJikUIYpO for ; Wed, 3 Oct 2012 10:51:02 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id F31D721F84D9 for ; Wed, 3 Oct 2012 10:51:01 -0700 (PDT) Received: from dhcp89-089-176.bbn.com ([128.89.89.176]:50031) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TJT62-0004as-Ue; Wed, 03 Oct 2012 13:50:58 -0400 Message-ID: <506C7B02.9020009@bbn.com> Date: Wed, 03 Oct 2012 13:50:58 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Piyush Jain References: <506C4EF5.9030103@bbn.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070000060709000502050907" Cc: pkix Subject: Re: [pkix] once again, with feeling ... X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 17:51:03 -0000 This is a multi-part message in MIME format. --------------070000060709000502050907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Piyush, Note that there is already aCertificate Issuer CRL entry extension, whic is critical, contrary to what you stated in your message. So, yes, tying the cert to the issuer via a CRL entry extension is a legitimate focus of this text. Steve --------------070000060709000502050907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Piyush,

Note that there is already a Certificate Issuer CRL entry extension, whic is critical,
contrary to what you stated in your message. So, yes, tying the cert to the issuer via a CRL entry extension is a legitimate focus of this text.

Steve
--------------070000060709000502050907-- From kent@bbn.com Wed Oct 3 11:11:25 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1043921F8528 for ; Wed, 3 Oct 2012 11:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.46 X-Spam-Level: X-Spam-Status: No, score=-106.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zT0zaK9v90WK for ; Wed, 3 Oct 2012 11:11:24 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 3010121F84EB for ; Wed, 3 Oct 2012 11:11:24 -0700 (PDT) Received: from dhcp89-089-176.bbn.com ([128.89.89.176]:50042) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TJTPn-0004uI-HR; Wed, 03 Oct 2012 14:11:23 -0400 Message-ID: <506C7FCB.40706@bbn.com> Date: Wed, 03 Oct 2012 14:11:23 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: russ housley References: <506B154F.3080501@bbn.com> <76BF385F-CF20-4A7A-96D9-803BCD17EE20@vigilsec.com> In-Reply-To: <76BF385F-CF20-4A7A-96D9-803BCD17EE20@vigilsec.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] 5280bis CRL problem poll results X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 18:11:25 -0000 Russ, This is a standards track doc, and has been marked as such since at least the -01 version. So it is legitimate to rescind the MUST with this doc. Steve From piyush@identicate.com Wed Oct 3 11:15:56 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF53721F864D for ; Wed, 3 Oct 2012 11:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.76 X-Spam-Level: X-Spam-Status: No, score=-3.76 tagged_above=-999 required=5 tests=[AWL=-0.762, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lXOw6l9AU7z for ; Wed, 3 Oct 2012 11:15:54 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 0818F21F8620 for ; Wed, 3 Oct 2012 11:15:53 -0700 (PDT) Received: from mail236-ch1-R.bigfish.com (10.43.68.227) by CH1EHSOBE012.bigfish.com (10.43.70.62) with Microsoft SMTP Server id 14.1.225.23; Wed, 3 Oct 2012 18:15:53 +0000 Received: from mail236-ch1 (localhost [127.0.0.1]) by mail236-ch1-R.bigfish.com (Postfix) with ESMTP id 2AADDF80124; Wed, 3 Oct 2012 18:15:53 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.229; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0610HT002.namprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: PS-1(zz9371Id6eahc85fhzz1202h1d1ah1d2ahzz17326ah8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah1288h12a5h12bdh137ah1441h1155h) Received-SPF: pass (mail236-ch1: domain of identicate.com designates 157.56.244.229 as permitted sender) client-ip=157.56.244.229; envelope-from=piyush@identicate.com; helo=CH1PRD0610HT002.namprd06.prod.outlook.com ; .outlook.com ; Received: from mail236-ch1 (localhost.localdomain [127.0.0.1]) by mail236-ch1 (MessageSwitch) id 1349288150887199_21591; Wed, 3 Oct 2012 18:15:50 +0000 (UTC) Received: from CH1EHSMHS038.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.240]) by mail236-ch1.bigfish.com (Postfix) with ESMTP id CFAF71900049; Wed, 3 Oct 2012 18:15:50 +0000 (UTC) Received: from CH1PRD0610HT002.namprd06.prod.outlook.com (157.56.244.229) by CH1EHSMHS038.bigfish.com (10.43.69.247) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 3 Oct 2012 18:15:48 +0000 Received: from CH1PRD0610MB393.namprd06.prod.outlook.com ([169.254.11.151]) by CH1PRD0610HT002.namprd06.prod.outlook.com ([10.255.151.37]) with mapi id 14.16.0207.009; Wed, 3 Oct 2012 18:15:47 +0000 From: Piyush Jain To: Stephen Kent Thread-Topic: [pkix] once again, with feeling ... Thread-Index: AQHNoXV01iRhzFg5dEOSp6DxkhN2IZentc5AgAAmkACAAAJjMA== Date: Wed, 3 Oct 2012 18:15:46 +0000 Message-ID: References: <506C4EF5.9030103@bbn.com> <506C7B02.9020009@bbn.com> In-Reply-To: <506C7B02.9020009@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [75.25.128.241] Content-Type: multipart/alternative; boundary="_000_AA6BA445CBFDB84785CC1C45DAAE4C7931EB1FF8CH1PRD0610MB393_" MIME-Version: 1.0 X-OriginatorOrg: identicate.com Cc: pkix Subject: Re: [pkix] once again, with feeling ... X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 18:15:57 -0000 --_000_AA6BA445CBFDB84785CC1C45DAAE4C7931EB1FF8CH1PRD0610MB393_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Steve, Certificate Issuer is related to Issuing Distribution point CRL extension. If the RP can process IDP(with indirectCRL flag), it should also be able to= process Certificate Issuer. Your text is dealing with the case where there is an unrecognized critical = CRL entry extension without any unrecognized critical CRL extension. So the question is - do we want to encourage creation of CRL entry extensio= ns (without any associated CRL extension) that affect the meaning of whole = CRL as opposed just the meaning of that entry. Please note that such a behavior would contradict the following text from s= ection 5.2.5 If the distributionPoint field is absent, the CRL MUST contain entries for = all revoked unexpired certificates issued by the CRL issuer, if any, within= the scope of the CRL. From: Stephen Kent [mailto:kent@bbn.com] Sent: Wednesday, October 03, 2012 10:51 AM To: Piyush Jain Cc: pkix Subject: Re: [pkix] once again, with feeling ... Piyush, Note that there is already a Certificate Issuer CRL entry extension, whic i= s critical, contrary to what you stated in your message. So, yes, tying the cert to the= issuer via a CRL entry extension is a legitimate focus of this text. Steve --_000_AA6BA445CBFDB84785CC1C45DAAE4C7931EB1FF8CH1PRD0610MB393_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Steve,<= /p>

 <= /p>

Certificate Issuer is rel= ated to Issuing Distribution point CRL extension.

If the RP can process IDP= (with indirectCRL flag), it should also be able to process Certificate Issu= er.

 <= /p>

Your text is dealing with= the case where there is an unrecognized critical CRL entry extension witho= ut any unrecognized critical CRL extension.

 <= /p>

So the question is –= ; do we want to encourage creation of CRL entry extensions (without any ass= ociated CRL extension) that affect the meaning of whole CRL as opposed just the meaning of that entry.

 <= /p>

Please note that such a b= ehavior would contradict the following text from section 5.2.5

 

If the distributionPoint field is absent, the CRL MUST con= tain entries for all revoked unexpired certificates issued by the CRL issue= r, if any, within the scope of the CRL.

 <= /p>

 <= /p>

 <= /p>

From: Stephen Kent [mailto:kent@bbn.com]
Sent: Wednesday, October 03, 2012 10:51 AM
To: Piyush Jain
Cc: pkix
Subject: Re: [pkix] once again, with feeling ...

 

Piyush,

Note that there is already a Certificate Issuer CRL entry extension, whic i= s critical,
contrary to what you stated in your message. So, yes, tying the cert to the= issuer via a CRL entry extension is a legitimate focus of this text.

Steve

--_000_AA6BA445CBFDB84785CC1C45DAAE4C7931EB1FF8CH1PRD0610MB393_-- From housley@vigilsec.com Wed Oct 3 11:19:25 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5721D21F8522 for ; Wed, 3 Oct 2012 11:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGRMHOPPxVcF for ; Wed, 3 Oct 2012 11:19:24 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id D004621F84B8 for ; Wed, 3 Oct 2012 11:19:23 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 128539A4002; Wed, 3 Oct 2012 14:19:27 -0400 (EDT) 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 UC9jAI-BSarf; Wed, 3 Oct 2012 14:19:19 -0400 (EDT) Received: from [192.168.2.100] (pool-96-255-37-162.washdc.fios.verizon.net [96.255.37.162]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 371D79A4001; Wed, 3 Oct 2012 14:19:24 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-57--533510845 From: Russ Housley In-Reply-To: <76BF385F-CF20-4A7A-96D9-803BCD17EE20@vigilsec.com> Date: Wed, 3 Oct 2012 14:19:20 -0400 Message-Id: <3EDDE74C-A1E1-454F-9563-A8EC02C1B037@vigilsec.com> References: <506B154F.3080501@bbn.com> <76BF385F-CF20-4A7A-96D9-803BCD17EE20@vigilsec.com> To: Denis Pinkas X-Mailer: Apple Mail (2.1084) Cc: IETF PKIX Subject: Re: [pkix] 5280bis CRL problem poll results X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 18:19:25 -0000 --Apple-Mail-57--533510845 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Ooops. I see that the most recent version = is aimed at standards = track. Sorry for the confusion, Russ On Oct 3, 2012, at 1:34 PM, Russ Housley wrote: > Denis: >=20 > While I think that we should move to a more granular handling of CRL = Entry Extensions, that cannot be done in an informational clarifications = document. That would require a standards-track update to RFC 5280. >=20 > RFC 5280 is pretty clear in Section 5.3: >=20 > ... If a CRL > contains a critical CRL entry extension that the application cannot > process, then the application MUST NOT use that CRL to determine the > status of any certificates. ... >=20 > Russ >=20 >=20 > On Oct 3, 2012, at 3:56 AM, Denis.Pinkas@bull.net wrote: >=20 >> Russ,=20 >>=20 >> While I agree with your first statement, i.e. ; "if a critical CRL = Entry Extension is unrecognized,=20 >> then the relying party cannot know that it is associated with = particular CRL Extension", since=20 >> it directly relates to the question I asked to Steve.=20 >>=20 >> However, I disagree with your last statement, i.e. "A relying party = MUST reject a CRL that contains=20 >> an unrecognized critical extension, regardless of the extension being = a CRL Extension or a CRL Entry Extension.=20 >>=20 >> The sentence should be changed into: "A relying party MUST reject a = CRL that contains=20 >> an unrecognized critical extension in a CRL Extension".=20 >>=20 >> Denis=20 >>=20 >>=20 >>=20 >> De : Russ Housley =20 >> A : Stephen Kent =20 >> Cc : pkix =20 >> Date : 02/10/2012 23:43=20 >> Objet : Re: [pkix] 5280bis CRL problem poll results=20 >> Envoy=E9 par : pkix-bounces@ietf.org=20 >>=20 >>=20 >>=20 >> The lack of consensus is troubling, but I have two concerns with the = proposed text.=20 >>=20 >> First, if a critical CRL Entry Extension is unrecognized, then the = relying party cannot know that it is associated with particular CRL = Extension. Your text assumes that the only thing that such an extension = might convey is the issuing CA. This is true for the extensions that = PKIX has discussed to date, but I am not convinced that will be true for = all time.=20 >>=20 >> Second, I do not think there is a lack of consensus on this = statement: A relying party MUST reject a CRL that contains an = unrecognized critical extension, regardless of the extension being a CRL = Extension or a CRL Entry Extension.=20 >>=20 >> Russ=20 >>=20 >>=20 >> On Oct 2, 2012, at 12:24 PM, Stephen Kent wrote:=20 >> Folks, >>=20 >> =20 >> It is apparent from the straw poll that there is no WG consensus on = this topic. >>=20 >> =20 >> I propose the following text, in lieu of the current =93new second = paragraph=94 that appears in Section 4 of = draft-ietf-pkix-rfc5280-clarifications-09.txt: >>=20 >> =20 >> A critical extension in the crlEntryExtensions field of an entry = SHALL affect only the certificate specified in that entry, unless there = is a related critical extension in the crlExtensions field that = advertises a special treatment for it. If a relying party is unable to = process both a critical crlEntryExtension and a related critical = crlExtension, the relying party is faced with a difficult choice. >>=20 >> =20 >> 1- The relying party may assume that the the CRLEntry is associated = with the CA that issued the CRL, and thus treat that certificate as = revoked. If the CRLEntry refers to a certificate issued by a different = CA, the relying party will treat a valid certificate as being revoked. >>=20 >>=20 >> 2- The relying party, realizing that it cannot accurately determine = if the CRLEntry is associated with the CA that issued the CRL, may = choose to treat that certificate as having an undetermined revocation = status. If the relying party is able to consult other sources of = certificate revocation status (e.g., OCSP) it may use those sources = instead. If not, the relying party may accept or reject the certificate = as a matter of local policy. >>=20 >>=20 >> 3- The relying party may view the CRLEntry as being associated with = an undetermined CA, and treat all certificates with that serialNumber as = being revoked. This behavior runs the risk of treating a number of valid = certificates as revoked. >>=20 >> =20 >> Because each of these options has associated risks, this document = does not specify relying party behavior under the circumstances noted = above. A relying party may accept or reject certificates with the = indicated serialNumber as a matter of local policy. >>=20 >> How does the WG feel about this alternate text? >>=20 >> Steve >>=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 >=20 --Apple-Mail-57--533510845 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Denis:

While = I think that we should move to a more granular handling of CRL Entry = Extensions, that cannot be done in an informational clarifications = document.  That would require a standards-track update to RFC = 5280.

RFC 5280 is pretty clear in Section = 5.3:

  ... If a CRL
  contains a critical = CRL entry extension that the application cannot
  process, = then the application MUST NOT use that CRL to determine = the
  status of any certificates. = ...

Russ


On Oct 3, 2012, at 3:56 AM, Denis.Pinkas@bull.net = wrote:

Russ,

While I agree with your first = statement, i.e. ; "if a critical CRL Entry Extension is unrecognized,
then the relying party cannot know that it is associated with particular CRL Extension", since
it directly relates to the question I asked to Steve.

However, I disagree with your last = statement, i.e. "A relying party MUST reject a CRL that contains
an unrecognized critical extension, regardless of the extension being a CRL Extension or a CRL Entry Extension.

The sentence should be changed into: = "A relying party MUST reject a CRL that contains
an unrecognized critical extension in a CRL Extension".

Denis



De :   =      Russ Housley <housley@vigilsec.com>
A :   =      Stephen Kent <kent@bbn.com>
Cc : =        pkix <pkix@ietf.org>
Date :   =      02/10/2012 = 23:43
Objet : =        Re: [pkix] = 5280bis CRL problem poll results
Envoy=E9 par = :        pkix-bounces@ietf.org



The lack of consensus is troubling, but I have two = concerns with the proposed text.

First, if a critical CRL Entry Extension is = unrecognized, then the relying party cannot know that it is associated with particular CRL Extension.  Your text assumes that the only thing that such an extension might convey is the issuing CA.  This is true for the = extensions that PKIX has discussed to date, but I am not convinced that will be = true for all time.

Second, I do not think there is a lack of consensus = on this statement: A relying party MUST reject a CRL that contains an = unrecognized critical extension, regardless of the extension being a CRL Extension or a CRL Entry Extension.

Russ


On Oct 2, 2012, at 12:24 PM, Stephen Kent = wrote:

Folks,

 

It is = apparent from the straw poll that there is no WG consensus on this topic.

 

I = propose the following text, in lieu of the current =93new second paragraph=94 that appears in Section 4 of = draft-ietf-pkix-rfc5280-clarifications-09.txt:

 

A = critical extension in the crlEntryExtensions field of an entry SHALL affect only the certificate specified in that entry, = unless there is a related critical extension in the crlExtensions field that = advertises a special treatment for it. If a relying party is unable to process both a critical crlEntryExtension and a related critical crlExtension, the = relying party is faced with a difficult choice.

 

1- =  The relying party may assume that the the CRLEntry is associated with the CA that issued the CRL, and thus treat that = certificate as revoked. If the CRLEntry refers to a certificate issued by a = different CA, the relying party will treat a valid certificate as being = revoked.


2- =  The relying party, realizing that it cannot accurately determine if the CRLEntry is associated with the CA that issued the CRL, may choose to treat that certificate as having an undetermined = revocation status. If the relying party is able to consult other sources of = certificate revocation status (e.g., OCSP) it may use those sources instead. If not, the relying party may accept or reject the certificate as a matter of = local policy.


3- =  The relying party may view the CRLEntry as being associated with an undetermined CA, and treat all certificates with that serialNumber as being revoked. This behavior runs the risk of treating a number of valid certificates as revoked.

 

Because = each of these options has associated risks, this document does not specify relying party behavior under the circumstances noted above. A relying party may accept or reject certificates with the indicated serialNumber as a matter of local policy.

How does the WG feel about this alternate = text?

Steve

_______________________________________________
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<= font size=3D"2">
=



= = --Apple-Mail-57--533510845-- From kent@bbn.com Wed Oct 3 11:21:20 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92E7D21F8522 for ; Wed, 3 Oct 2012 11:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.471 X-Spam-Level: X-Spam-Status: No, score=-106.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PA4EqnqwTzlv for ; Wed, 3 Oct 2012 11:21:20 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 04D4421F8620 for ; Wed, 3 Oct 2012 11:21:19 -0700 (PDT) Received: from dhcp89-089-176.bbn.com ([128.89.89.176]:50045) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TJTZO-000CLj-QC; Wed, 03 Oct 2012 14:21:18 -0400 Message-ID: <506C821E.9080701@bbn.com> Date: Wed, 03 Oct 2012 14:21:18 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: denis.pinkas@bull.net References: <506C4EF5.9030103@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pkix Subject: Re: [pkix] once again, with feeling ... X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 18:21:20 -0000 Denis, The new text in your proposed revision starts with a sentence that is 4 lines long! We're trying to make statements that are easier for readers to understand, so let's not go for long sentences. Your second proposed paragraph introduces a completely new topic, i.e., unspecified o-o-b identification of the issuer related to the CRL entry in question. I do not want to include new topics this late in the process. Also, if the RP has access to such o-o-b info, lI think we are in the realm of local policy anyway. The final paragraph is another whopping long sentence, and it also introduces new topics, i e., CA serial number conventions. This is not something I want to deal with at this stage, and the assumption of large (pseudo randomness is really the relevant property here, not mere size) serial numbers appears nowhere in 5280. I prefer my text. Steve From kent@bbn.com Wed Oct 3 11:29:45 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9084721F85A1 for ; Wed, 3 Oct 2012 11:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.181 X-Spam-Level: X-Spam-Status: No, score=-106.181 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AuUVlYsTupwS for ; Wed, 3 Oct 2012 11:29:44 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8070B21F8555 for ; Wed, 3 Oct 2012 11:29:44 -0700 (PDT) Received: from dhcp89-089-176.bbn.com ([128.89.89.176]:50048) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TJThX-000CUb-HR; Wed, 03 Oct 2012 14:29:43 -0400 Message-ID: <506C8417.6030305@bbn.com> Date: Wed, 03 Oct 2012 14:29:43 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Piyush Jain References: <506C4EF5.9030103@bbn.com> <506C7B02.9020009@bbn.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090608080706060305010707" Cc: pkix Subject: Re: [pkix] once again, with feeling ... X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 18:29:45 -0000 This is a multi-part message in MIME format. --------------090608080706060305010707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/3/12 2:15 PM, Piyush Jain wrote: > > Steve, > > Certificate Issuer is related to Issuing Distribution point CRL extension. > > If the RP can process IDP(with indirectCRL flag), it should also be > able to process Certificate Issuer > it is related to IDP, but it's presence is optional in an indirect CRL. > > .Your text is dealing with the case where there is an unrecognized > critical CRL entry extension without any unrecognized critical CRL > extension. > yes, so? > > So the question is -- do we want to encourage creation of CRL entry > extensions (without any associated CRL extension) that affect the > meaning of whole CRL as opposed just the meaning of that entry. > that is not the question. Without creating a new CRL entry extension we already face the problem that an RP might recognize the IDP extension, but not the Cert issuer entry xtension, hence the need for the text. Steve --------------090608080706060305010707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 10/3/12 2:15 PM, Piyush Jain wrote:

Steve,

 

Certificate Issuer is related to Issuing Distribution point CRL extension.

If the RP can process IDP(with indirectCRL flag), it should also be able to process Certificate Issuer

it is related to IDP, but it's presence is optional in an indirect CRL.

.Your text is dealing with the case where there is an unrecognized critical CRL entry extension without any unrecognized critical CRL extension.

yes, so?

 

So the question is – do we want to encourage creation of CRL entry extensions (without any associated CRL extension) that affect the meaning of whole CRL as opposed just the meaning of that entry.

that is not the question. Without creating a new CRL entry extension we already face the problem
that an RP might recognize the IDP extension, but not the Cert issuer entry xtension, hence the
need for the text.

Steve
--------------090608080706060305010707-- From piyush@identicate.com Wed Oct 3 12:54:50 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D04CB11E80A3 for ; Wed, 3 Oct 2012 12:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.705 X-Spam-Level: X-Spam-Status: No, score=-3.705 tagged_above=-999 required=5 tests=[AWL=-0.707, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLlz1AMhdKsR for ; Wed, 3 Oct 2012 12:54:49 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe003.messaging.microsoft.com [216.32.180.186]) by ietfa.amsl.com (Postfix) with ESMTP id 51CBA11E8091 for ; Wed, 3 Oct 2012 12:54:49 -0700 (PDT) Received: from mail200-co1-R.bigfish.com (10.243.78.225) by CO1EHSOBE009.bigfish.com (10.243.66.72) with Microsoft SMTP Server id 14.1.225.23; Wed, 3 Oct 2012 19:54:47 +0000 Received: from mail200-co1 (localhost [127.0.0.1]) by mail200-co1-R.bigfish.com (Postfix) with ESMTP id 0C4D41200C4; Wed, 3 Oct 2012 19:54:48 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.229; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0610HT002.namprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -3 X-BigFish: PS-3(zzbb2dI98dI9371Id6eahc85fhzz1202h1d1ah1d2ahzz17326ah8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah1288h12a5h12bdh137ah1441h1155h) Received-SPF: pass (mail200-co1: domain of identicate.com designates 157.56.244.229 as permitted sender) client-ip=157.56.244.229; envelope-from=piyush@identicate.com; helo=CH1PRD0610HT002.namprd06.prod.outlook.com ; .outlook.com ; Received: from mail200-co1 (localhost.localdomain [127.0.0.1]) by mail200-co1 (MessageSwitch) id 1349294085950541_25048; Wed, 3 Oct 2012 19:54:45 +0000 (UTC) Received: from CO1EHSMHS026.bigfish.com (unknown [10.243.78.227]) by mail200-co1.bigfish.com (Postfix) with ESMTP id E204830004F; Wed, 3 Oct 2012 19:54:45 +0000 (UTC) Received: from CH1PRD0610HT002.namprd06.prod.outlook.com (157.56.244.229) by CO1EHSMHS026.bigfish.com (10.243.66.36) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 3 Oct 2012 19:54:44 +0000 Received: from CH1PRD0610MB393.namprd06.prod.outlook.com ([169.254.11.151]) by CH1PRD0610HT002.namprd06.prod.outlook.com ([10.255.151.37]) with mapi id 14.16.0207.009; Wed, 3 Oct 2012 19:54:44 +0000 From: Piyush Jain To: Stephen Kent Thread-Topic: [pkix] once again, with feeling ... Thread-Index: AQHNoXV01iRhzFg5dEOSp6DxkhN2IZentc5AgAAmkACAAAJjMIAACHGAgAAVtWA= Date: Wed, 3 Oct 2012 19:54:42 +0000 Message-ID: References: <506C4EF5.9030103@bbn.com> <506C7B02.9020009@bbn.com> <506C8417.6030305@bbn.com> In-Reply-To: <506C8417.6030305@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [75.25.128.241] Content-Type: multipart/alternative; boundary="_000_AA6BA445CBFDB84785CC1C45DAAE4C7931EB20ABCH1PRD0610MB393_" MIME-Version: 1.0 X-OriginatorOrg: identicate.com Cc: pkix Subject: Re: [pkix] once again, with feeling ... X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 19:54:50 -0000 --_000_AA6BA445CBFDB84785CC1C45DAAE4C7931EB20ABCH1PRD0610MB393_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Are you saying that a compliant RP can process IDP with indirectCRL Boolean= on and choose not to process "CRL Issuer" extension? This is what 5280 says: If the scope of the CRL only includes certificates issued by the CRL issuer= , then the indirectCRL boolean MUST be set to FALSE. Otherwise, if the scop= e of the CRL includes certificates issued by one or more authorities other = than the CRL issuer, the indirectCRL boolean MUST be set to TRUE. The auth= ority responsible for each entry is indicated by the certificate issuer CRL= entry extension(Section 5.3.3). While it is not explicit in the above text, my interpretation is that if an= RP claims to process IDP, it should also process "Certificate Issuers". From: Stephen Kent [mailto:kent@bbn.com] Sent: Wednesday, October 03, 2012 11:30 AM To: Piyush Jain Cc: pkix Subject: Re: [pkix] once again, with feeling ... On 10/3/12 2:15 PM, Piyush Jain wrote: Steve, Certificate Issuer is related to Issuing Distribution point CRL extension. If the RP can process IDP(with indirectCRL flag), it should also be able to= process Certificate Issuer it is related to IDP, but it's presence is optional in an indirect CRL. .Your text is dealing with the case where there is an unrecognized critical= CRL entry extension without any unrecognized critical CRL extension. yes, so? So the question is - do we want to encourage creation of CRL entry extensio= ns (without any associated CRL extension) that affect the meaning of whole = CRL as opposed just the meaning of that entry. that is not the question. Without creating a new CRL entry extension we alr= eady face the problem that an RP might recognize the IDP extension, but not the Cert issuer entry= xtension, hence the need for the text. Steve --_000_AA6BA445CBFDB84785CC1C45DAAE4C7931EB20ABCH1PRD0610MB393_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Are you saying that a com= pliant RP can process IDP with indirectCRL Boolean on and choose not to pro= cess “CRL Issuer” extension?

 <= /p>

This is what 5280 says:

 <= /p>

If the scope of the CRL only includes certificates issued = by the CRL issuer, then the indirectCRL boolean MUST be set to FALSE. Other= wise, if the scope of the CRL includes certificates issued by one or more authorities other than the CRL issuer, the indirectC= RL boolean MUST be set to TRUE.  The authority responsible for each en= try is indicated by the certificate issuer CRL entry extension(Section 5.3.= 3).

 <= /p>

While it is not explicit = in the above text, my interpretation is that if an RP claims to process IDP= , it should also process “Certificate Issuers”.  

From: Stephen Kent [mailto:kent@bbn.com]
Sent: Wednesday, October 03, 2012 11:30 AM
To: Piyush Jain
Cc: pkix
Subject: Re: [pkix] once again, with feeling ...

 

 

On 10/3/12 2:15 PM, Piyush Jain wrote:

Steve,<= /p>

 <= /p>

Certificate Issuer is rel= ated to Issuing Distribution point CRL extension.

If the RP can process IDP= (with indirectCRL flag), it should also be able to process Certificate Issu= er

it is related to IDP, but it's presence is optional = in an indirect CRL.

.Your text is dealing wit= h the case where there is an unrecognized critical CRL entry extension with= out any unrecognized critical CRL extension.

yes, so?

 <= /p>

So the question is –= ; do we want to encourage creation of CRL entry extensions (without any ass= ociated CRL extension) that affect the meaning of whole CRL as opposed just the meaning of that entry.

that is not the question. Without creating a new CRL= entry extension we already face the problem
that an RP might recognize the IDP extension, but not the Cert issuer entry= xtension, hence the
need for the text.

Steve

--_000_AA6BA445CBFDB84785CC1C45DAAE4C7931EB20ABCH1PRD0610MB393_-- From kent@bbn.com Wed Oct 3 13:14:41 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6613421F854F for ; Wed, 3 Oct 2012 13:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.468 X-Spam-Level: X-Spam-Status: No, score=-106.468 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pl6bnc8b7RAv for ; Wed, 3 Oct 2012 13:14:40 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id C468521F853E for ; Wed, 3 Oct 2012 13:14:39 -0700 (PDT) Received: from dhcp89-089-176.bbn.com ([128.89.89.176]:50228) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TJVL0-000Ee4-1v; Wed, 03 Oct 2012 16:14:34 -0400 Message-ID: <506C9CA9.2040501@bbn.com> Date: Wed, 03 Oct 2012 16:14:33 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Piyush Jain References: <506C4EF5.9030103@bbn.com> <506C7B02.9020009@bbn.com> <506C8417.6030305@bbn.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020408080309070302060402" Cc: pkix Subject: Re: [pkix] once again, with feeling ... X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 20:14:41 -0000 This is a multi-part message in MIME format. --------------020408080309070302060402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/3/12 3:54 PM, Piyush Jain wrote: > > Are you saying that a compliant RP can process IDP with indirectCRL > Boolean on and choose not to process "CRL Issuer" extension? > No. I am saying that a sloppy RP might be programmed to understand the IDP extension and indirectCRL Boolean, but might not understand the CRL Issuer entry extension. > > This is what 5280 says: > > If the scope of the CRL only includes certificates issued by the CRL > issuer, then the indirectCRL boolean MUST be set to FALSE. Otherwise, > if the scope of the CRL includes certificates issued by one or more > authorities other than the CRL issuer, the indirectCRL boolean MUST be > set to TRUE. The authority responsible for each entry is indicated by > the certificate issuer CRL entry extension(Section 5.3.3). > > While it is not explicit in the above text, my interpretation is that > if an RP claims to process IDP, it should also process "Certificate > Issuers". > We live in an era when a major vendor still does not support the name constraints extension, and thus will reject certs with that extension marked critical, despite the fact that this cert extension has been around for well over a decade. Given this real world example, we ought not assume much re 5280 (or 3280, or 2459) compliance, especially when it involves multiple extensions and flags, as is the case here. Steve --------------020408080309070302060402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 10/3/12 3:54 PM, Piyush Jain wrote:

Are you saying that a compliant RP can process IDP with indirectCRL Boolean on and choose not to process “CRL Issuer” extension?

No. I am saying that a sloppy RP might be programmed to understand the IDP extension and indirectCRL Boolean, but might not understand the CRL Issuer entry extension.

 

This is what 5280 says:

 

If the scope of the CRL only includes certificates issued by the CRL issuer, then the indirectCRL boolean MUST be set to FALSE. Otherwise, if the scope of the CRL includes certificates issued by one or more authorities other than the CRL issuer, the indirectCRL boolean MUST be set to TRUE.  The authority responsible for each entry is indicated by the certificate issuer CRL entry extension(Section 5.3.3).

 

While it is not explicit in the above text, my interpretation is that if an RP claims to process IDP, it should also process “Certificate Issuers”. 

We live in an era when a major vendor still does not support the name constraints extension,
and thus will reject certs with that extension marked critical, despite the fact that this
cert extension has been around for well over a decade. Given this real world example, we ought
not assume much re 5280 (or 3280, or 2459) compliance, especially when it involves multiple extensions
and flags, as is the case here.

Steve
--------------020408080309070302060402-- From housley@vigilsec.com Wed Oct 3 14:33:24 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAEF021F84C8 for ; Wed, 3 Oct 2012 14:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id em5uuQb4otMU for ; Wed, 3 Oct 2012 14:33:24 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 349BA21F85A7 for ; Wed, 3 Oct 2012 14:33:24 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 342669A4004 for ; Wed, 3 Oct 2012 17:33:31 -0400 (EDT) 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 OqwARQB4sWQq for ; Wed, 3 Oct 2012 17:33:20 -0400 (EDT) Received: from [192.168.2.100] (pool-96-255-37-162.washdc.fios.verizon.net [96.255.37.162]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 5953F9A4001 for ; Wed, 3 Oct 2012 17:33:29 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Russ Housley In-Reply-To: <9FF53209-599C-4F33-AA2B-36AEFD8007AF@vigilsec.com> Date: Wed, 3 Oct 2012 17:33:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <506B154F.3080501@bbn.com> <506C4D25.6090601@bbn.com> <655F8F68-F5EA-42EA-9CCA-5AFD1627A48D@vigilsec.com> <506C7787.4090900@bbn.com> <9FF53209-599C-4F33-AA2B-36AEFD8007AF@vigilsec.com> To: IETF PKIX X-Mailer: Apple Mail (2.1084) Subject: Re: [pkix] 5280bis CRL problem poll results X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 21:33:24 -0000 It seems that the PKIX WG is faced with a difficult choice. I see three = ways we could go regarding the update to Section 5.3 of RFC 5280. (1) Stick with the text in RFC 5280. At one point in time, there was = consensus for it. Ignoring a CRL with an unrecognized CRL Entry = Extension is not aligned with the most recent version of X.509, but it = is a safe thing to do. (2) Build consensus for the text in the current I-D. We have been = working toward that for several weeks, and we are not making progress. (3) Build consensus around some alternate text. Steve put forward some = alternate text, but it does not seem to have any more consensus than the = text in the current I-D. Can Steve's text be changed in a way that gets = us to consensus? So far, I have seen two major concerns raised that = need to be resolved if this is the way forward. Russ From stephen.farrell@cs.tcd.ie Wed Oct 3 14:47:44 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0932511E8097 for ; Wed, 3 Oct 2012 14:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3dcdnSd4bDM for ; Wed, 3 Oct 2012 14:47:43 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 0269C11E8091 for ; Wed, 3 Oct 2012 14:47:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 93F67104243; Wed, 3 Oct 2012 22:47:40 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h=date :subject:from:x-mailer:message-id:content-type :content-transfer-encoding:mime-version:in-reply-to:references :received:received:x-virus-scanned; s=cs; t=1349300860; bh=MCvOw ZOgGxNLokM2c3jlC374NGeK5IpYRxVEdwTrYKU=; b=zHnkBSGkegI94wLcMPXev sTOdOmV3+DQBsRQv24Jf0EWcMRVuUJXomPwVpBGsbOrbLFrIbpgXTwyLE/fUAg3M fK00iky5xk+PuFeDrpG9wIkyDkDz4oc5hpLwDuCHnMGRhBHumwJZEO4gvGrY53nu SssWSCMaKZv8z7sElebraFhchdJpNtdY/GOxlgkROX1jqXHkjXT7c4pH/OQZASr6 2WG2AJACBrN2XWva5V37krV40FbadNxATQVWGHn4nGTtN5tPD4SEm6sdiHWcE3CQ mvnR6sgQNiuOujvHtEEcW2XSRpT/kOH5qo5j/4hNCAmwfBns9Fv40VOqJtk+Od4o g== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id Ez07aIyHfuDN; Wed, 3 Oct 2012 22:47:40 +0100 (IST) Received: from [10.87.48.4] (unknown [86.42.186.173]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 658BE104242; Wed, 3 Oct 2012 22:47:39 +0100 (IST) References: <506B154F.3080501@bbn.com> <506C4D25.6090601@bbn.com> <655F8F68-F5EA-42EA-9CCA-5AFD1627A48D@vigilsec.com> <506C7787.4090900@bbn.com> <9FF53209-599C-4F33-AA2B-36AEFD8007AF@vigilsec.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <0FD98C24-41C1-48F1-B9D7-E212D6BF474D@cs.tcd.ie> X-Mailer: iPhone Mail (9B206) From: Stephen Farrell Date: Wed, 3 Oct 2012 22:46:21 +0100 To: Russ Housley Cc: IETF PKIX Subject: Re: [pkix] 5280bis CRL problem poll results X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 21:47:44 -0000 On 3 Oct 2012, at 22:33, Russ Housley wrote: > It seems that the PKIX WG is faced with a difficult choice. I see three w= ays we could go regarding the update to Section 5.3 of RFC 5280. >=20 I'd say #1 is fine. The world has survived with 5280 and I'm not sure how ma= ny of those suggesting changes have significant running code. (And nor do I s= o I'm happy to defer to anyone who does and who cares.) S > (1) Stick with the text in RFC 5280. At one point in time, there was cons= ensus for it. Ignoring a CRL with an unrecognized CRL Entry Extension is no= t aligned with the most recent version of X.509, but it is a safe thing to d= o. >=20 > (2) Build consensus for the text in the current I-D. We have been working= toward that for several weeks, and we are not making progress. >=20 > (3) Build consensus around some alternate text. Steve put forward some al= ternate text, but it does not seem to have any more consensus than the text i= n the current I-D. Can Steve's text be changed in a way that gets us to con= sensus? So far, I have seen two major concerns raised that need to be resol= ved if this is the way forward. >=20 > Russ >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From denis.pinkas@bull.net Thu Oct 4 07:11:34 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 781F421F86DE for ; Thu, 4 Oct 2012 07:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.16 X-Spam-Level: X-Spam-Status: No, score=-2.16 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmTAenQQSlu4 for ; Thu, 4 Oct 2012 07:11:33 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 3541E21F86DD for ; Thu, 4 Oct 2012 07:11:33 -0700 (PDT) Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id 317951C9BD; Thu, 4 Oct 2012 16:11:32 +0200 (CEST) Received: from [127.0.0.1] ([129.184.39.15]) by MSGC-007.bull.fr (Lotus Domino Release 8.5.3FP1) with ESMTP id 2012100416113181-13 ; Thu, 4 Oct 2012 16:11:31 +0200 Message-ID: <506D9910.3000004@bull.net> Date: Thu, 04 Oct 2012 16:11:28 +0200 From: Denis Pinkas Bull User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Stephen Kent References: <506C4EF5.9030103@bbn.com> <506C821E.9080701@bbn.com> In-Reply-To: <506C821E.9080701@bbn.com> X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 04/10/2012 16:11:31, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 04/10/2012 16:11:32, Serialize complete at 04/10/2012 16:11:32 X-TNEFEvaluated: 1 Content-Type: multipart/alternative; boundary="------------020605040308020506080902" Cc: pkix@ietf.org Subject: Re: [pkix] once again, with feeling ... X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 14:11:34 -0000 This is a multi-part message in MIME format. --------------020605040308020506080902 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed Steve, Please reconsider your position in the light of the following explanations: In my proposal, there is a graduation with serial processing rules rather than a choice between three parallel alternatives. If the RP is unable to process a critical crlEntryExtension then: 1) Check if there is another source of information available, like OCSP 2) Check if there is a local policy states which that the CRL issuer is only taking care of the certificates from one CA. 3) and finally, if none of the two previous cases provided an answer, consider the probability of serial number collisions and make the decision according to probability rules. I have reconsidered my text proposal in the light of your comments. I================================================================================== A critical extension in the crlEntryExtensions field of an entry SHALL affect only the certificate specified in that entry, unless there is a related critical extension in the crlExtensions field that advertises a special treatment for it. If a relying party is unable to process a critical crlEntryExtension, then the relying party cannot accurately determine the revocation status of the certificate identified in that CRLEntry, unless it is able to consult other sources of certificate revocation status (e.g., OCSP). If the relying party is able to know (using a local policy) that the CRLEntry is associated with the CA that issued the CRL, then the relying party SHALL consider that the revocation status of the certificate is revoked. If the relying party is unable to know whether the CRLEntry is associated with the CA that issued the CRL, then the relying party is faced with a difficult choice. However, most CAs are using large random certificate serial numbers and thus a collision between such numbers is rather unlikely. So it is more likely that the certificate serial number relates to the right CA and for that reason this document RECOMMENDS to consider that certificate as having a revoked revocation status.In such case the relying party will treat a valid certificate as being revoked. > Denis, > > The new text in your proposed revision starts with a sentence that is > 4 lines long! > We're trying to make statements that are easier for readers to > understand, so let's > not go for long sentences. > > Your second proposed paragraph introduces a completely new topic, > i.e., unspecified > o-o-b identification of the issuer related to the CRL entry in > question. I do not want > to include new topics this late in the process. Also, if the RP has > access to such o-o-b info, > lI think we are in the realm of local policy anyway. > > The final paragraph is another whopping long sentence, and it also > introduces new topics, > i e., CA serial number conventions. This is not something I want to > deal with at this stage, > and the assumption of large (pseudo randomness is really the relevant > property here, not > mere size) serial numbers appears nowhere in 5280. > > I prefer my text. --------------020605040308020506080902 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=ISO-8859-1
Steve,
 
Please reconsider your position in the light of the following explanations:
 
In my proposal, there is a graduation with serial processing rules rather than a choice between three parallel alternatives.

If the RP is unable to process a critical crlEntryExtension then:

   1) Check if there is another source of information available, like OCSP
   2) Check if there is a local policy states which that the CRL issuer is only taking care
       of the certificates from one CA.
   3) and finally, if none of the two previous cases provided an answer, consider the probability
       of serial number collisions and make the decision according to probability rules.

I have reconsidered my text proposal in the light of your comments.
 
I==================================================================================
 
A critical extension in the crlEntryExtensions field of an entry SHALL affect
only the certificate specified in that entry, unless there is a related critical
extension in the crlExtensions field that advertises a special treatment for it.

If a relying party is unable to process a critical crlEntryExtension, then the
relying party cannot accurately determine the revocation status of the certificate
identified in that CRLEntry, unless it is able to consult other sources of
certificate revocation status (e.g., OCSP).

If the relying party is able to know (using a local policy) that the CRLEntry
is associated with the CA that issued the CRL, then the relying party SHALL
consider that the revocation status of the certificate is revoked.

If the relying party is unable to know whether the CRLEntry is associated with
the CA that issued the CRL, then the relying party is faced with a difficult choice.
 
However, most CAs are using large random certificate serial numbers and thus
a collision between such numbers is rather unlikely.  So it is more likely
that the certificate serial number relates to the right CA and for that reason
this document RECOMMENDS to consider that certificate as having a revoked
revocation status. In such case the relying party will treat a valid certificate
as being revoked.
Denis,

The new text in your proposed revision starts with a sentence that is 4 lines long!
We're trying to make statements that are easier for readers to understand, so let's
not go for long sentences.

Your second proposed paragraph introduces a completely new topic, i.e., unspecified
o-o-b identification of the issuer related to the CRL entry in question.  I do not want
to include new topics this late in the process. Also, if the RP has access to such o-o-b info,
lI think we are in the realm of local policy anyway.

The final paragraph is another whopping long sentence, and it also introduces new topics,
i e., CA serial number conventions. This is not something I want to deal with at this stage,
and the assumption of large (pseudo randomness is really the relevant property here, not
mere size) serial numbers appears nowhere in 5280.

I prefer my text.


--------------020605040308020506080902-- From kent@bbn.com Thu Oct 4 09:01:48 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E06F1F0C96 for ; Thu, 4 Oct 2012 09:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.476 X-Spam-Level: X-Spam-Status: No, score=-106.476 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtjRRgF43xXq for ; Thu, 4 Oct 2012 09:01:48 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id D491E1F0C94 for ; Thu, 4 Oct 2012 09:01:47 -0700 (PDT) Received: from dhcp89-089-176.bbn.com ([128.89.89.176]:49610) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TJnrp-00017t-OV; Thu, 04 Oct 2012 12:01:41 -0400 Message-ID: <506DB2E5.7000907@bbn.com> Date: Thu, 04 Oct 2012 12:01:41 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Denis Pinkas Bull References: <506C4EF5.9030103@bbn.com> <506C821E.9080701@bbn.com> <506D9910.3000004@bull.net> In-Reply-To: <506D9910.3000004@bull.net> Content-Type: multipart/alternative; boundary="------------050505030007010809080506" Cc: pkix@ietf.org Subject: Re: [pkix] once again, with feeling ... X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 16:01:48 -0000 This is a multi-part message in MIME format. --------------050505030007010809080506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Denis, The 3 alternatives I provided were intended only to motivate the decision to allow RPs to use local policy to decide how to handle this messy situation. They were not intended to be an algorithmic processing list for RP reference. Nonetheless, unless there is a show of WG consensus for this approach, this is moot, as per Russ's message yesterday. Steve On 10/4/12 10:11 AM, Denis Pinkas Bull wrote: > Steve, > > Please reconsider your position in the light of the following > explanations: > > In my proposal, there is a graduation with serial processing rules > rather than a choice between three parallel alternatives. > > If the RP is unable to process a critical crlEntryExtension then: > > 1) Check if there is another source of information available, like OCSP > 2) Check if there is a local policy states which that the CRL > issuer is only taking care > of the certificates from one CA. > 3) and finally, if none of the two previous cases provided an > answer, consider the probability > of serial number collisions and make the decision according to > probability rules. > > I have reconsidered my text proposal in the light of your comments. > > I================================================================================== > --------------050505030007010809080506 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Denis,

The 3 alternatives I provided were intended only to motivate the decision to allow RPs to
use local policy to decide how to handle this messy situation. They were not intended to
be an algorithmic processing list for RP reference.

Nonetheless, unless there is a show of WG consensus for this approach, this is moot,
as per Russ's message yesterday.

Steve

On 10/4/12 10:11 AM, Denis Pinkas Bull wrote:
Steve,
 
Please reconsider your position in the light of the following explanations:
 
In my proposal, there is a graduation with serial processing rules rather than a choice between three parallel alternatives.

If the RP is unable to process a critical crlEntryExtension then:

   1) Check if there is another source of information available, like OCSP
   2) Check if there is a local policy states which that the CRL issuer is only taking care
       of the certificates from one CA.
   3) and finally, if none of the two previous cases provided an answer, consider the probability
       of serial number collisions and make the decision according to probability rules.

I have reconsidered my text proposal in the light of your comments.
 
I==================================================================================


--------------050505030007010809080506-- From denis.pinkas@bull.net Fri Oct 5 02:24:58 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C95A621F8607 for ; Fri, 5 Oct 2012 02:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAKFZLFajDIz for ; Fri, 5 Oct 2012 02:24:58 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id AAEF621F85F7 for ; Fri, 5 Oct 2012 02:24:57 -0700 (PDT) Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id 6EA6D1CA2C for ; Fri, 5 Oct 2012 11:24:56 +0200 (CEST) Received: from [127.0.0.1] ([129.184.39.15]) by MSGC-007.bull.fr (Lotus Domino Release 8.5.3FP1) with ESMTP id 2012100511245585-59 ; Fri, 5 Oct 2012 11:24:55 +0200 Message-ID: <506EA763.5060001@bull.net> Date: Fri, 05 Oct 2012 11:24:51 +0200 From: Denis Pinkas Bull User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: pkix@ietf.org References: <506B154F.3080501@bbn.com> <506C4D25.6090601@bbn.com> <655F8F68-F5EA-42EA-9CCA-5AFD1627A48D@vigilsec.com> <506C7787.4090900@bbn.com> <9FF53209-599C-4F33-AA2B-36AEFD8007AF@vigilsec.com> In-Reply-To: X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 05/10/2012 11:24:56, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 05/10/2012 11:24:56, Serialize complete at 05/10/2012 11:24:56 X-TNEFEvaluated: 1 Content-Type: multipart/alternative; boundary="------------030903080800070302020809" Subject: Re: [pkix] 5280bis CRL problem poll results X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 09:24:59 -0000 This is a multi-part message in MIME format. --------------030903080800070302020809 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed Russ, You said: " Steve put forward some alternate text, but it does not seem to have any more consensus than the text in the current I-D. Can Steve's text be changed in a way that gets us to consensus? " Here is a new proposal for changing Steve's text. =========================================================================== The CRL entry extensions defined by ISO/IEC, ITU-T, and ANSI X9 for X.509 v2 CRLs provide methods for associating additional attributes with CRL entries [X.509] [X9.55]. The X.509 v2 CRL format also allows communities to define private CRL entry extensions to carry information unique to those communities. Each extension in a CRLentry may be designated as critical or non-critical. A critical extension in the crlEntryExtensions field of an entry SHALL affect only the certificate identified in that entry, unless there is a related critical extension in the crlExtensions field that advertises a special treatment for it. If a CRL contains a critical CRL entry extension that the application cannot process, then the relying party SHOULD use, if possible, other sources of certificate revocation status (e.g. OCSP) to accurately the revocation status of the certificate identified in that CRLEntry. If the relying party is able to know (using a local policy) that the CRLEntry is associated with the CA that issued the CRL, then the relying party SHALL consider that the revocation status of the certificate is revoked. If the relying party is unable to know whether the CRLEntry is associated with the CA that issued the CRL, then the relying party SHOULD consider that the revocation status of the certificate is revoked. Note: In the last case, the relying party may treat a valid certificate as being revoked. However, since most CAs are currently using large random certificate serial numbers, a collision between such numbers is rather unlikely. So it is more likely that the certificate serial number identified in the CRLentry relates to the right CA. =========================================================================== The Note above could be transformed and placed in the security considerations section. It is taking care of a situation that is likely to happen one out of a zillion of zillion cases. It is one of the reasons why I have not kept the "dramatic" sentence from Steve's proposal: "the relying party is faced with a difficult choice". > It seems that the PKIX WG is faced with a difficult choice. I see three ways we could go regarding the update to Section 5.3 of RFC 5280. > > (1) Stick with the text in RFC 5280. At one point in time, there was consensus for it. Ignoring a CRL with an unrecognized CRL Entry Extension is not aligned with the most recent version of X.509, but it is a safe thing to do. > > (2) Build consensus for the text in the current I-D. We have been working toward that for several weeks, and we are not making progress. > > (3) Build consensus around some alternate text. Steve put forward some alternate text, but it does not seem to have any more consensus than the text in the current I-D. Can Steve's text be changed in a way that gets us to consensus? So far, I have seen two major concerns raised that need to be resolved if this is the way forward. > > Russ > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --------------030903080800070302020809 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=ISO-8859-1
Russ,

You said: " 
Steve put forward some alternate text, but it does not seem to have any more consensus 
than the text in the current I-D.  Can Steve's text be changed in a way that gets us to consensus? "

Here is a new proposal for changing Steve's text.

===========================================================================

   The CRL entry extensions defined by ISO/IEC, ITU-T, and ANSI X9
   for X.509 v2 CRLs provide methods for associating additional 
   attributes with CRL entries [X.509] [X9.55].  The X.509 v2 CRL 
   format also allows communities to define private CRL entry 
   extensions to carry information unique to those communities. 
   Each extension in a CRLentry may be designated as critical or 
   non-critical.  A critical extension in the crlEntryExtensions 
   field of an entry SHALL affect only the certificate identified 
   in that entry, unless there is a related critical extension in 
   the crlExtensions field that advertises a special treatment for 
   it. 

   If a CRL contains a critical CRL entry extension that the 
   application cannot process, then the relying party SHOULD use, 
   if possible, other sources of certificate revocation status 
   (e.g. OCSP) to accurately the revocation status of the 
   certificate identified in that CRLEntry. 
   
   If the relying party is able to know (using a local policy) 
   that the CRLEntry is associated with the CA that issued the CRL, 
   then the relying party SHALL consider that the revocation status 
   of the certificate is revoked. 

   If the relying party is unable to know whether the CRLEntry 
   is associated with the CA that issued the CRL, then the relying 
   party SHOULD consider that the revocation status of the 
   certificate is revoked.

   Note: In the last case, the relying party may treat a valid 
         certificate as being revoked.  However, since most CAs are 
         currently using large random certificate serial numbers, 
         a collision between such numbers is rather unlikely.
         So it is more likely that the certificate serial number 
         identified in the CRLentry relates to the right CA.

===========================================================================

The Note above could be transformed and placed in the security considerations section.
It is taking care of a situation that is likely to happen one out of a zillion of zillion cases.

It is one of the reasons why I have not kept the "dramatic" sentence from Steve's proposal: 
"the relying party is faced with a difficult choice".

  

It seems that the PKIX WG is faced with a difficult choice.  I see three ways we could go regarding the update to Section 5.3 of RFC 5280.

(1) Stick with the text in RFC 5280.  At one point in time, there was consensus for it.  Ignoring a CRL with an unrecognized CRL Entry Extension is not aligned with the most recent version of X.509, but it is a safe thing to do.

(2) Build consensus for the text in the current I-D.  We have been working toward that for several weeks, and we are not making progress.

(3) Build consensus around some alternate text.  Steve put forward some alternate text, but it does not seem to have any more consensus than the text in the current I-D.  Can Steve's text be changed in a way that gets us to consensus?  So far, I have seen two major concerns raised that need to be resolved if this is the way forward.

Russ

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


--------------030903080800070302020809-- From hallam@gmail.com Fri Oct 5 11:13:34 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBA2F21F8440 for ; Fri, 5 Oct 2012 11:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.893 X-Spam-Level: X-Spam-Status: No, score=-3.893 tagged_above=-999 required=5 tests=[AWL=-0.295, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvzlE5l1Xv9w for ; Fri, 5 Oct 2012 11:13:33 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id AACC621F8435 for ; Fri, 5 Oct 2012 11:13:33 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so2472570oag.31 for ; Fri, 05 Oct 2012 11:13:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/kzHxX2Jfek8EQvtyYoiHd9wtBJRbrgXfcQwp5cKGq0=; b=Vwa2xBwHfBQJ4goc8DhiNcwU7r6Gn2/mybeAyF7oXPhPJjGu4Tw/JWmYGQvlGqeX8c 1sAjP3+s50D1Tot88OpY0ubllcW8cyQej9y+9Vhl4ZT7QS5kGILuSB81nIWVJsL826Bv sP4AgrXBPLgX+0565Jm+v+WkhjTBRpMgPZ5QVm3vtx56CEPw2RPmKJi+4hMxLvNEkVf5 sOmkzFZHvcYJZUCbPaCleiL1HH5QbrPGdCKSKiUGbC6SKBhbmd/JPEBIrC6pqabkdHgF 2NAE6yf6HsWaFLsa/iT/4rLVHm03K4hivLJW37ZDph4r3YiF24X9+C+u37SghFQaOk3l 499A== MIME-Version: 1.0 Received: by 10.60.170.9 with SMTP id ai9mr7534404oec.36.1349460813291; Fri, 05 Oct 2012 11:13:33 -0700 (PDT) Received: by 10.76.27.103 with HTTP; Fri, 5 Oct 2012 11:13:33 -0700 (PDT) In-Reply-To: <5059CCA8.2040201@bbn.com> References: <20120828161824.12779.10639.idtracker@ietfa.amsl.com> <504731B1.7090201@ieca.com> <504777C6.9090200@bbn.com> <5059CCA8.2040201@bbn.com> Date: Fri, 5 Oct 2012 14:13:33 -0400 Message-ID: From: Phillip Hallam-Baker To: Stephen Kent Content-Type: multipart/alternative; boundary=bcaec54a3e026a1f6b04cb53d485 Cc: pkix@ietf.org Subject: Re: [pkix] I-D Action: draft-ietf-pkix-caa-13.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 18:13:34 -0000 --bcaec54a3e026a1f6b04cb53d485 Content-Type: text/plain; charset=ISO-8859-1 OK, I checked the spec and I am certain that the language there is correct, the search goes up to but not including the dot. However to make sure I propose adding the following: The search for a CAA record climbs the DNS name tree from the specified label up to but not including the DNS root '.'. I did think of adding in an explanation but this is normative text and that is a bad idea ('A well regulated PKI...') the reason it has to be this way is that even though a CAA record is unlikely to appear in .com it is very likely we will see them appear if the new ICANN TLDs actually happen the way they imagine. On Wed, Sep 19, 2012 at 9:46 AM, Stephen Kent wrote: > Phillip, > > I have confidence that you can add suitable language to address this > concern. > > The WGLC has completed and I will ask Sean to re-submit the doc for > IETF-wide LC. > > Steve > > > On 9/18/12 2:54 PM, Phillip Hallam-Baker wrote: > > OK, the only comment I saw was that maybe I should go back and make > absolutely sure that the language makes clear that we are scanning up to > and including the TLD but not looking in the root itself (which would > expose us to a whole new set of concerns such as the fact that there is > more than one of them and the root operators are not the same as ICANN). > > On Wed, Sep 5, 2012 at 12:03 PM, Stephen Kent wrote: > >> As per Sean's message, we are beginning a second WGLC for CAA (version >> 13), effective today. >> Since this is a second WGLC, it will be a bit shorter this time, >> terminating on 9/15. >> >> Steve >> >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >> > > > > -- > Website: http://hallambaker.com/ > > > -- Website: http://hallambaker.com/ --bcaec54a3e026a1f6b04cb53d485 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable OK, I checked the spec and I am certain that the language there is correct,= the search goes up to but not including the dot. However to make sure I pr= opose adding the following:

=A0 =A0 =A0 =A0 The sea= rch for a CAA record climbs the DNS name tree from the=A0
=A0 =A0 =A0 =A0 specified label up to but not including the DNS root &= #39;.'.=A0

I did think of adding in an explana= tion but this is normative text and that is a bad idea ('A well regulat= ed PKI...')

the reason it has to be this way is that even though a = CAA record is unlikely to appear in .com it is very likely we will see them= appear if the new ICANN TLDs actually happen the way they imagine.

On Wed, Sep 19, 2012 at 9:46 AM, Stephen Ken= t <k= ent@bbn.com> wrote:
=20 =20 =20
Phillip,

I have confidence that you can add suitable language to address this concern.

The WGLC has completed and I will ask Sean to re-submit the doc for IETF-wide LC.

Steve


On 9/18/12 2:54 PM, Phillip Hallam-Baker wrote:
OK, the only comment I saw was that maybe I s= hould go back and make absolutely sure that the language makes clear that we are scanning up to and including the TLD but not looking in the root itself (which would expose us to a whole new set of concerns such as the fact that there is more than one of them and the root operators are not the same as ICANN).

On Wed, Sep 5, 2012 at 12:03 PM, Stephen Kent <kent@bbn.com> wrote:
As per Sean's message, we are beginning a second WGLC for CAA (version 13), effective today.
Since this is a second WGLC, it will be a bit shorter this time, terminating on 9/15.

Steve


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



--
Website: http:/= /hallambaker.com/





--
Website: http://hallambaker.com/

--bcaec54a3e026a1f6b04cb53d485-- From mrex@sap.com Fri Oct 5 12:16:49 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C93F521F87B9 for ; Fri, 5 Oct 2012 12:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.202 X-Spam-Level: X-Spam-Status: No, score=-10.202 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ydoy4+D8nuHk for ; Fri, 5 Oct 2012 12:16:49 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id E538D21F87B8 for ; Fri, 5 Oct 2012 12:16:48 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q95JGhMZ027789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Oct 2012 21:16:46 +0200 (MEST) In-Reply-To: <0FD98C24-41C1-48F1-B9D7-E212D6BF474D@cs.tcd.ie> To: Stephen Farrell Date: Fri, 5 Oct 2012 21:16:43 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20121005191643.3574F1A2A0@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: IETF PKIX Subject: Re: [pkix] 5280bis CRL problem poll results X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 19:16:50 -0000 Stephen Farrell wrote: > > Russ Housley wrote: > >> It seems that the PKIX WG is faced with a difficult choice. >> I see three ways we could go regarding the update to Section 5.3 of RFC 5280. >> >> (1) Stick with the text in RFC 5280. At one point in time, there was >> consensus for it. Ignoring a CRL with an unrecognized CRL Entry Extension >> is not aligned with the most recent version of X.509, but it is a safe >> thing to do. > > I'd say #1 is fine. The world has survived with 5280 and I'm not sure > how many of those suggesting changes have significant running code. > (And nor do I so I'm happy to defer to anyone who does and who cares.) In principle, I would whole-heartedly agree, when just looking at this rfc5280 requirement: Russ Housley wrote: > RFC 5280 is pretty clear in Section 5.3: > > ... If a CRL > contains a critical CRL entry extension that the application cannot > process, then the application MUST NOT use that CRL to determine the > status of any certificates. ... but I see two issues (A,B) with this that deserve clarification, and I believe that the inconsitency (A) should be fixed and the defective CRL processing rules in the 08/2005 version of X.509 should be mentioned and its use discouraged. (A) there is this contradiction in rfc5280 with section 5.2.5, last (two) sentences of first paragraph: http://tools.ietf.org/html/rfc5280#section-5.2.5 Although the extension is critical, conforming implementations are not required to support this extension. However, implementations that do not support this extension MUST either treat the status of any certificate not listed on this CRL as unknown or locate another CRL that does not contain any unrecognized critical extensions. Where the wording of the last sentence suggests that it is OK for apps that do not support the critical crlExtension "IssuingDistributionPoint" to use this CRL anyhow to determine the status of certs that _are_ listed in the CRL. I like Piyush's suggested fix here: http://www.ietf.org/mail-archive/web/pkix/current/msg31734.html (B) the general guidance in rfc5280 section 6.1 "Basic Path Validation" (3rd paragraph): http://tools.ietf.org/html/rfc5280#section-6.1 While the certificate and CRL profiles specified in Sections 4 and 5 of this document specify values for certificate and CRL fields and extensions that are considered to be appropriate for the Internet PKI, the algorithm presented in this section is not limited to accepting certificates and CRLs that conform to these profiles. Therefore, the algorithm only includes checks to verify that the certification path is valid according to X.509 and does not include checks to verify that the certificates and CRLs conform to this profile. While the algorithm could be extended to include checks for conformance to the profiles in Sections 4 and 5, this profile RECOMMENDS against including such checks. This text in rfc5280 explicitly recommends to disregard (the more correct) processing rule in Section 5 (including the statement from section 5.3), and recommends using the processing rules specified by X.509 instead. Now the problem with this is, that rfc5280 refers to X.509 08/2005, a document where the CRL processing rules are significantly broken, rather than X.509 11/2008, which contains a corrected&reasonable set of CRL processing rules. -Martin From mrex@sap.com Fri Oct 5 19:48:43 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EABD321F8528 for ; Fri, 5 Oct 2012 19:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.903 X-Spam-Level: X-Spam-Status: No, score=-9.903 tagged_above=-999 required=5 tests=[AWL=-0.254, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pa6ic3PyrvIs for ; Fri, 5 Oct 2012 19:48:43 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3838421F84FD for ; Fri, 5 Oct 2012 19:48:43 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q962mTGC014821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 6 Oct 2012 04:48:34 +0200 (MEST) In-Reply-To: <506C9CA9.2040501@bbn.com> To: Stephen Kent Date: Sat, 6 Oct 2012 04:48:28 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20121006024829.0047A1A2A1@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: pkix Subject: Re: [pkix] once again, with feeling ... X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 02:48:44 -0000 Stephen Kent wrote: > > We live in an era when a major vendor still does not support the name > constraints extension, and thus will reject certs with that extension > marked critical, Perfectly PKIX-compliant behaviour. It's not only that one vendor which will reject certs with name constraints that are marked critical, there a number of other, perfectly compliant PKIX implementations that will reject such certs. openssl below version 1.0.0 will also reject certs with critical name constraints. And the installed base of openssl-0.9.X is **HUGE** (might actually be larger than the number of iPhones,iPods,iPads and Macs combined). > > despite the fact that this cert extension has been around for well > over a decade. Other than your message asserts, support for name constraints is PURELY optional, in X.509 and PKIX. While the wording of X.509 and PKIX suggests that support for name constraints on the "directory name" is required (and support for all subject alt names is explicitly optional), the specification for processing of name constraints for "directory name" is incomplete (underspecified), which defacto kills it status as a required feature. -Martin From mrex@sap.com Fri Oct 5 19:55:19 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8EB21F85C3 for ; Fri, 5 Oct 2012 19:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.194 X-Spam-Level: X-Spam-Status: No, score=-10.194 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id luuq4OK+cMh9 for ; Fri, 5 Oct 2012 19:55:07 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 790D421F8562 for ; Fri, 5 Oct 2012 19:55:07 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q962t0jQ015016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 6 Oct 2012 04:55:00 +0200 (MEST) In-Reply-To: <506C9CA9.2040501@bbn.com> To: Stephen Kent Date: Sat, 6 Oct 2012 04:55:00 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20121006025500.790DC1A2A1@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: pkix Subject: Re: [pkix] once again, with feeling ... X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 02:55:19 -0000 Stephen Kent wrote: > > Piyush Jain wrote: >> >> Are you saying that a compliant RP can process IDP with indirectCRL >> Boolean on and choose not to process "CRL Issuer" extension? > > No. I am saying that a sloppy RP might be programmed to understand the > IDP extension and indirectCRL Boolean, but might not understand the CRL > Issuer entry extension. That seems to be a perfectly valid&conforming implementation option. An RP that supports the IDP crlExtension, but not the CertificateIsser crlEntryExtension, would not be allowed to use a CRL with the indirectCRL Boolean asserted (=TRUE) to determine the status of any certs. -Martin From internet-drafts@ietf.org Sat Oct 6 19:32:28 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA4421F849B; Sat, 6 Oct 2012 19:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.503 X-Spam-Level: X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4fjX2YIvZZI; Sat, 6 Oct 2012 19:32:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75DB921F84B5; Sat, 6 Oct 2012 19:32:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121007023227.19777.9236.idtracker@ietfa.amsl.com> Date: Sat, 06 Oct 2012 19:32:27 -0700 Cc: pkix@ietf.org Subject: [pkix] I-D Action: draft-ietf-pkix-caa-14.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 02:32:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Public-Key Infrastructure (X.509) Working= Group of the IETF. Title : DNS Certification Authority Authorization (CAA) Resource= Record Author(s) : Phillip Hallam-Baker Rob Stradling Filename : draft-ietf-pkix-caa-14.txt Pages : 18 Date : 2012-10-06 Abstract: The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain. CAA resource records allow a public Certification Authority to implement additional controls to reduce the risk of unintended certificate mis-issue. This document defines the syntax of the CAA record and rules for processing CAA records by certificate issuers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pkix-caa There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pkix-caa-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pkix-caa-14 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From James.H.Manger@team.telstra.com Sun Oct 7 18:27:29 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F03721F874A for ; Sun, 7 Oct 2012 18:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.595 X-Spam-Level: X-Spam-Status: No, score=-0.595 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zbmc73gy4u3O for ; Sun, 7 Oct 2012 18:27:28 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id EF16921F8749 for ; Sun, 7 Oct 2012 18:27:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,549,1344175200"; d="scan'208";a="97637150" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipocvi.tcif.telstra.com.au with ESMTP; 08 Oct 2012 12:27:27 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6858"; a="91842348" Received: from wsmsg3703.srv.dir.telstra.com ([172.49.40.171]) by ipcdvi.tcif.telstra.com.au with ESMTP; 08 Oct 2012 12:27:25 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3703.srv.dir.telstra.com ([172.49.40.171]) with mapi; Mon, 8 Oct 2012 12:27:26 +1100 From: "Manger, James H" To: Phillip Hallam-Baker Date: Mon, 8 Oct 2012 12:27:25 +1100 Thread-Topic: [pkix] I-D Action: draft-ietf-pkix-caa-14.txt Thread-Index: Ac2kNBwsZxLUjn9cRTWnRGvdADezrwAsmlew Message-ID: <255B9BB34FB7D647A506DC292726F6E114FD99FC60@WSMSG3153V.srv.dir.telstra.com> References: <20121007023227.19777.9236.idtracker@ietfa.amsl.com> In-Reply-To: <20121007023227.19777.9236.idtracker@ietfa.amsl.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] I-D Action: draft-ietf-pkix-caa-14.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 01:27:29 -0000 Q29tbWVudHMgb24gZHJhZnQtaWV0Zi1wa2l4LWNhYS0xNA0KDQoNCjMuIFRoZSBDQUEgUlIgdHlw ZQ0KPGlzc3VlPiBhbmQgPGlvZGVmPiB0YWdzIGFyZSBsaXN0ZWQsIGJ1dCBub3QgPGlzc3Vld2ls ZD4uDQoNCg0KNS4yLiBDQUEgaXNzdWUgUHJvcGVydHk6IEFCTkYgdHlwb3MNCiAgPFByb3BlcnR5 PiBpcyBtaXNzaW5nIGEgJ10nOw0KICA8cGFyYW1ldGVyPiBoYXMgZXh0cmFuZW91cyAnLyc7DQog IDxzcGFjZT4gd291bGQgYmUgYmV0dGVyIGp1c3QgaW4gPFByb3BlcnR5Piwgbm90IGFsc28gaW4g PHBhcmFtZXRlcj47DQogIDxWQ0hBUj4gaW5jbHVkZXMgPERRVU9URT4gc28gPHZhbHVlPiBpcyBh bWJpZ3VvdXMuIA0KDQpXUk9ORzoNCiAgUHJvcGVydHkgPSBzcGFjZSBbZG9tYWluXSBzcGFjZSBb IjsiIHNwYWNlICogKHBhcmFtZXRlciBzcGFjZSkNCiAgcGFyYW1ldGVyID0gIC8gc3BhY2UgdGFn ICI9IiB2YWx1ZQ0KICB2YWx1ZSA9ICpWQ0hBUiB8IERRVU9URSAqKCV4MjAtMjEgLyAleDIzLTdF KSBEUVVPVEUNCg0KUklHSFQ6DQogIFByb3BlcnR5ID0gc3BhY2UgW2RvbWFpbl0gc3BhY2UgWyI7 IiAqKHNwYWNlIHBhcmFtZXRlcikgc3BhY2VdDQogIHBhcmFtZXRlciA9IHRhZyAiPSIgdmFsdWUN CiAgdmFsdWUgPSAqVkNIQVINCg0KQWRkaW5nIGEgcXVvdGluZyBtZWNoYW5pc20gZm9yIDx2YWx1 ZT4gYWxsb3dzIG9ubHkgb25lIGV4dHJhIGNoYXJhY3RlciBTUEFDRS4gSXQncyBub3Qgd29ydGgg aXQuIEEgcXVvdGluZyBtZWNoYW5pc20gd291bGQgYWxzbyBpbnRlcmFjdCBhd2t3YXJkbHkgd2l0 aCB0aGUgKHVuZGVyLXNwZWNpZmllZCkgcHJlc2VudGF0aW9uIGZvcm1hdC4NCg0KDQo1LjEuMS4g Q2Fub25pY2FsIFByZXNlbnRhdGlvbiBGb3JtYXQNClRoZSAnVmFsdWUnIHBhcnQgb2YgYSBDQUEg cmVjb3JkIGlzIHNwZWNpZmllZCBhcyBhICJzZXF1ZW5jZSBvZiBvY3RldHMiLiBUaGUgcHJlc2Vu dGF0aW9uIGZvcm1hdCBpcyBzcGVjaWZpZWQgYXMgInRoZSBVUy1BU0NJSSB0ZXh0IEVuY29kaW5n IG9mIHRoZSB2YWx1ZSBmaWVsZCIuIEnigJltIG5vdCBzdXJlIHdoZXJlIHRoYXQgInRleHQgRW5j b2RpbmciIGlzIGRlZmluZWQsIHBlcmhhcHMgUkZDMTAzNSAiRG9tYWluIEltcGxlbWVudGF0aW9u IGFuZCBTcGVjaWZpY2F0aW9uIiBzZWN0aW9uIDUuMS4gTWFzdGVyIEZpbGVzIEZvcm1hdC4gRG9l cyBpdCBzYXkgYWx3YXlzLXdyYXAtaW4tZG91YmxlLXF1b3Rlcz8NCg0KDQo4LjEuIE5vcm1hdGl2 ZSBSZWZlcmVuY2VzDQpSRkMxMDM0IGFuZCBSRkMxMDM1IGFwcGVhciB0d2ljZTogb25jZSBhcyB0 aGVtc2VsdmVzOyB0aGVuIGFnYWluIGFzIFNURDEzDQoNCi0tDQpKYW1lcyBNYW5nZXINCg== From Jeff.Hodges@KingsMountain.com Mon Oct 8 11:37:53 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2EE121F8828 for ; Mon, 8 Oct 2012 11:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.672 X-Spam-Level: X-Spam-Status: No, score=-99.672 tagged_above=-999 required=5 tests=[AWL=-0.666, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVh0yMXR9AdK for ; Mon, 8 Oct 2012 11:37:52 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7.bluehost.com [IPv6:2605:dc00:100:2::a7]) by ietfa.amsl.com (Postfix) with SMTP id C3F6421F8823 for ; Mon, 8 Oct 2012 11:37:52 -0700 (PDT) Received: (qmail 24752 invoked by uid 0); 8 Oct 2012 18:37:44 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy7.bluehost.com with SMTP; 8 Oct 2012 18:37:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=NDm6RIGFftscPn8/krZuSaGW79SplHRYcmjwJxT5XyI=; b=VyAXBCkyc+AwfWkmVrrtZOCH1TZs/2cja1SaDaVOmacdkMOBNPYkRow6YdJZOOr4rpvtPg1YqoW4aExLJuBgbZ7rVAeK8/IoR4Y0zG/YZc105QsEAFVJqvd0t5gG1kZ6; Received: from [216.113.168.128] (port=43504 helo=[10.244.137.180]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1TLID1-0006kM-Mh; Mon, 08 Oct 2012 12:37:43 -0600 Message-ID: <50731D75.9060108@KingsMountain.com> Date: Mon, 08 Oct 2012 11:37:41 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: IETF Security Area Advisory Group , IETF PKIX WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: [pkix] fyi: CA/Browser Forum (CABF) Organisational Reform vote results X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 18:37:53 -0000 Greetings again, As I'd pointed out earlier this year [1][2], the CA/Browser Forum (CABF) was entertaining organisational reform proposals. It recently completed its final voting exercise [3] and decided on a governance reform proposal [4]. Also, the CABF has created a publicly readable email distribution list [5]. One overall assessment of the reform voting results is here.. Certificate Authorities asked to step up for Internet security; CABF takes a step back instead. (5-Oct-2012) =JeffH [1] Re: [saag] fyi: CA/Browser Forum Announces Organizational Reform Working Group https://www.ietf.org/mail-archive/web/saag/current/msg03585.html [2] [saag] fyi: CA/Browser Forum (CABF) reform voting (corrected) https://www.ietf.org/mail-archive/web/saag/current/msg04015.html [3] [cabfpub] Tally Results on Ballot 90 https://cabforum.org/pipermail/public/2012-September/000544.html [4] https://www.cabforum.org/governance/Trend_Micro_Governance_Proposal.pdf [5] https://cabforum.org/mailman/listinfo/public Note: only CABF members may post to this list. Others may subscribe and receive list traffic. The archives are publicly readable. From housley@vigilsec.com Tue Oct 9 11:47:58 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59DA921F8710 for ; Tue, 9 Oct 2012 11:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cCyzoF4L92Q for ; Tue, 9 Oct 2012 11:47:57 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 22EB921F86FD for ; Tue, 9 Oct 2012 11:47:57 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id C5A6D9A4004; Tue, 9 Oct 2012 14:48:12 -0400 (EDT) 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 bwUOgy2FtldA; Tue, 9 Oct 2012 14:47:48 -0400 (EDT) Received: from [10.242.26.155] (mf10f36d0.tmodns.net [208.54.15.241]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 73B509A4006; Tue, 9 Oct 2012 14:48:10 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-125--22990511 From: Russ Housley In-Reply-To: <506EA763.5060001@bull.net> Date: Tue, 9 Oct 2012 12:08:00 -0400 Message-Id: References: <506B154F.3080501@bbn.com> <506C4D25.6090601@bbn.com> <655F8F68-F5EA-42EA-9CCA-5AFD1627A48D@vigilsec.com> <506C7787.4090900@bbn.com> <9FF53209-599C-4F33-AA2B-36AEFD8007AF@vigilsec.com> <506EA763.5060001@bull.net> To: Denis Pinkas Bull X-Mailer: Apple Mail (2.1085) Cc: pkix@ietf.org Subject: Re: [pkix] 5280bis CRL problem poll results X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 18:47:58 -0000 --Apple-Mail-125--22990511 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Denis: I do not support this alternate text. If there is an unrecognized CRL = Entry Extension, then the replying party cannot know whether the entry = applies to a particular certificate or not. Certificates are identified = by an issuer and serial number. An unrecognized CRL Entry Extension can = change the issuer portion of the tuple. The relying party can always try an alternate CRL or and alternate = protocol like OCSP to check out the certificate of interest. This would = be true for any type of CRL validation trouble. I am unclear how local policy can be helpful here. If there is an = unrecognized CRL Entry Extension, the relying party knows that it cannot = use the entry. If the relying party does not know the issuer associated with a = particular CRL entry, then it does not know whether that entry is = associated with the certificate of interest or not. Given this = situation, I think that the appropriate action is not to treat the = certificate as revoked; instead, the CRL is providing no useful = information to make such a decision. Russ On Oct 5, 2012, at 5:24 AM, Denis Pinkas Bull wrote: > Russ, >=20 > You said: "=20 > Steve put forward some alternate text, but it does not seem to have = any more consensus=20 > than the text in the current I-D. Can Steve's text be changed in a = way that gets us to consensus? " >=20 > Here is a new proposal for changing Steve's text. >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >=20 > The CRL entry extensions defined by ISO/IEC, ITU-T, and ANSI X9 > for X.509 v2 CRLs provide methods for associating additional=20 > attributes with CRL entries [X.509] [X9.55]. The X.509 v2 CRL=20 > format also allows communities to define private CRL entry=20 > extensions to carry information unique to those communities.=20 > Each extension in a CRLentry may be designated as critical or=20 > non-critical. A critical extension in the crlEntryExtensions=20 > field of an entry SHALL affect only the certificate identified=20 > in that entry, unless there is a related critical extension in=20 > the crlExtensions field that advertises a special treatment for=20 > it.=20 >=20 > If a CRL contains a critical CRL entry extension that the=20 > application cannot process, then the relying party SHOULD use,=20 > if possible, other sources of certificate revocation status=20 > (e.g. OCSP) to accurately the revocation status of the=20 > certificate identified in that CRLEntry.=20 > =20 > If the relying party is able to know (using a local policy)=20 > that the CRLEntry is associated with the CA that issued the CRL,=20 > then the relying party SHALL consider that the revocation status=20 > of the certificate is revoked.=20 >=20 > If the relying party is unable to know whether the CRLEntry=20 > is associated with the CA that issued the CRL, then the relying=20 > party SHOULD consider that the revocation status of the=20 > certificate is revoked. >=20 > Note: In the last case, the relying party may treat a valid=20 > certificate as being revoked. However, since most CAs are=20 > currently using large random certificate serial numbers,=20 > a collision between such numbers is rather unlikely. > So it is more likely that the certificate serial number=20 > identified in the CRLentry relates to the right CA. >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >=20 > The Note above could be transformed and placed in the security = considerations section. > It is taking care of a situation that is likely to happen one out of a = zillion of zillion cases. >=20 > It is one of the reasons why I have not kept the "dramatic" sentence = from Steve's proposal:=20 > "the relying party is faced with a difficult choice". >=20 > =20 >=20 >> It seems that the PKIX WG is faced with a difficult choice. I see = three ways we could go regarding the update to Section 5.3 of RFC 5280. >>=20 >> (1) Stick with the text in RFC 5280. At one point in time, there was = consensus for it. Ignoring a CRL with an unrecognized CRL Entry = Extension is not aligned with the most recent version of X.509, but it = is a safe thing to do. >>=20 >> (2) Build consensus for the text in the current I-D. We have been = working toward that for several weeks, and we are not making progress. >>=20 >> (3) Build consensus around some alternate text. Steve put forward = some alternate text, but it does not seem to have any more consensus = than the text in the current I-D. Can Steve's text be changed in a way = that gets us to consensus? So far, I have seen two major concerns = raised that need to be resolved if this is the way forward. >>=20 >> Russ >>=20 >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >=20 >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --Apple-Mail-125--22990511 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
=20 =20
Russ,

You said: " 
Steve put forward some alternate text, but it does =
not seem to have any more consensus=20
than the text in the current I-D.  Can Steve's text be changed in a way =
that gets us to consensus? "

Here is a new proposal for changing Steve's text.

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


   The CRL entry extensions defined by ISO/IEC, ITU-T, and ANSI X9
   for X.509 v2 CRLs provide methods for associating additional=20
   attributes with CRL entries [X.509] [X9.55].  The X.509 v2 CRL=20
   format also allows communities to define private CRL entry=20
   extensions to carry information unique to those communities.=20
   Each extension in a CRLentry may be designated as critical or=20
   non-critical.  A critical extension in the crlEntryExtensions=20
   field of an entry SHALL affect only the certificate identified=20
   in that entry, unless there is a related critical extension in=20
   the crlExtensions field that advertises a special treatment for=20
   it.=20

   If a CRL contains a critical CRL entry extension that the=20
   application cannot process, then the relying party SHOULD use,=20
   if possible, other sources of certificate revocation status=20
   (e.g. OCSP) to accurately the revocation status of the=20
   certificate identified in that CRLEntry.=20
  =20
   If the relying party is able to know (using a local policy)=20
   that the CRLEntry is associated with the CA that issued the CRL,=20
   then the relying party SHALL consider that the revocation status=20
   of the certificate is revoked.=20

   If the relying party is unable to know whether the CRLEntry=20
   is associated with the CA that issued the CRL, then the relying=20
   party SHOULD consider that the revocation status of the=20
   certificate is revoked.

   Note: In the last case, the relying party may treat a valid=20
         certificate as being revoked.  However, since most CAs are=20
         currently using large random certificate serial numbers,=20
         a collision between such numbers is rather unlikely.
         So it is more likely that the certificate serial number=20
         identified in the CRLentry relates to the right CA.

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


The Note above could be transformed and placed in the security =
considerations section.
It is taking care of a situation that is likely to happen one out of a =
zillion of zillion cases.

It is one of the reasons why I have not kept the "dramatic" sentence =
from Steve's proposal:=20
"the relying party is faced with a difficult choice".

  

It seems that the PKIX WG is faced with a difficult =
choice.  I see three ways we could go regarding the update to Section =
5.3 of RFC 5280.

(1) Stick with the text in RFC 5280.  At one point in time, there was =
consensus for it.  Ignoring a CRL with an unrecognized CRL Entry =
Extension is not aligned with the most recent version of X.509, but it =
is a safe thing to do.

(2) Build consensus for the text in the current I-D.  We have been =
working toward that for several weeks, and we are not making progress.

(3) Build consensus around some alternate text.  Steve put forward some =
alternate text, but it does not seem to have any more consensus than the =
text in the current I-D.  Can Steve's text be changed in a way that gets =
us to consensus?  So far, I have seen two major concerns raised that =
need to be resolved if this is the way forward.

Russ

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


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

= --Apple-Mail-125--22990511-- From piyush@ditenity.com Tue Oct 9 12:49:07 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4682F1F040A for ; Tue, 9 Oct 2012 12:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-y1ak9kYdxa for ; Tue, 9 Oct 2012 12:49:03 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 539BC11E80A4 for ; Tue, 9 Oct 2012 12:49:03 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id o25so1261906iad.31 for ; Tue, 09 Oct 2012 12:49:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language :x-gm-message-state; bh=io1fYfilXLIuEpPAvPwvEcYpwMF3U+NYAaR4QI197xY=; b=dlc6l/GTObqGZp0tFcQFOR5yj5qQ4AfQ788v+fvvgQdEgMfgiSXtZ3JP1xey3SVZ4s AdXPaiyQ1OFNTSaduzUP4pLEz3Im4ccrWBvl85oHwr2yKYELcPBYMTrrv2NHq9tGoiA8 yxmnfe8QhdSyuUGcPl2rrtETLfwBIYkoK1etRTsYdfETebedxiIU2B+dGeomQtIaXAwj 4eYkzak+qFlkIJyP15s2+HtwzK8uJRdjp+7MzpmKLPJe18cK6b2AD/bnQ4VwYCSw08p1 Qs/w72o1QZ0vKVAbM7E6cxG6kM+3d9cTXwGJxHsYWXBvSKqrgx+qHxc6cRYhaATy5Fh3 pYvg== Received: by 10.50.154.227 with SMTP id vr3mr2939576igb.43.1349812142654; Tue, 09 Oct 2012 12:49:02 -0700 (PDT) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id ce10sm10065420igb.1.2012.10.09.12.49.00 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 09 Oct 2012 12:49:01 -0700 (PDT) From: "Piyush Jain" To: "'Russ Housley'" , "'Denis Pinkas Bull'" References: <506B154F.3080501@bbn.com> <506C4D25.6090601@bbn.com> <655F8F68-F5EA-42EA-9CCA-5AFD1627A48D@vigilsec.com> <506C7787.4090900@bbn.com> <9FF53209-599C-4F33-AA2B-36AEFD8007AF@vigilsec.com> <506EA763.5060001@bull.net> In-Reply-To: Date: Tue, 9 Oct 2012 12:48:56 -0700 Message-ID: <00fe01cda657$2003fbf0$600bf3d0$@ditenity.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00FF_01CDA61C.73AD1330" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLQtn3Q5t/ZLWxOZhAOPk+cR/p25wHbOm0YAm6R/QMCtQeTcgGtycusAs8n59kBsLm+aQG7p68uAyuIz4qVGpQR0A== Content-Language: en-us X-Gm-Message-State: ALoCoQn5CL4NfhzicYpDmMPzz2+n0vIS6IMCwfRCMreBp274uO5ayf2xrSUnYLTzLUcr9bniv8fV X-Mailman-Approved-At: Tue, 09 Oct 2012 14:06:47 -0700 Cc: pkix@ietf.org Subject: Re: [pkix] 5280bis CRL problem poll results X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 19:50:06 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00FF_01CDA61C.73AD1330 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Not that I support Denis's proposal but I also disagree with this "If there is an unrecognized CRL Entry Extension, then the replying party cannot know whether the entry applies to a particular certificate or not. Certificates are identified by an issuer and serial number. An unrecognized CRL Entry Extension can change the issuer portion of the tuple" This is only true if there is a critical CRL extension which allows such behavior. If the RP can process the CRL extension, it should also process the CRL entry extension which implies that the CRL entry extension is NOT unrecognized. If the RP cannot process the critical CRL extension, it'll reject the CRL and the question of what to do with CRL entry with unrecognized extensions becomes moot. CRL extensions affect the whole CRLs. CRL entry extensions affect only the CRL entry unless indicated by a related CRL extension. The point of contention is that 5280 says that whole CRL should be rejected if an unrecognized critical CRL entry extension is encountered. This is what we need to do" - Make it explicit that that if RP processes IDP it should also process "Certificate Issuer" - Change the text to say that RP should treat the certificate referred to by a CRL entry with unknown critical extension as "revoked". (Same as X.509) All these proposals are assuming that a future CRL entry extension can affect the whole CRL on its own. I'm sure if someone comes up with such an extension he won't find any support in this WG or any other WG. From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Russ Housley Sent: Tuesday, October 09, 2012 9:08 AM To: Denis Pinkas Bull Cc: pkix@ietf.org Subject: Re: [pkix] 5280bis CRL problem poll results Denis: I do not support this alternate text. If there is an unrecognized CRL Entry Extension, then the replying party cannot know whether the entry applies to a particular certificate or not. Certificates are identified by an issuer and serial number. An unrecognized CRL Entry Extension can change the issuer portion of the tuple. The relying party can always try an alternate CRL or and alternate protocol like OCSP to check out the certificate of interest. This would be true for any type of CRL validation trouble. I am unclear how local policy can be helpful here. If there is an unrecognized CRL Entry Extension, the relying party knows that it cannot use the entry. If the relying party does not know the issuer associated with a particular CRL entry, then it does not know whether that entry is associated with the certificate of interest or not. Given this situation, I think that the appropriate action is not to treat the certificate as revoked; instead, the CRL is providing no useful information to make such a decision. Russ On Oct 5, 2012, at 5:24 AM, Denis Pinkas Bull wrote: Russ, You said: " Steve put forward some alternate text, but it does not seem to have any more consensus than the text in the current I-D. Can Steve's text be changed in a way that gets us to consensus? " Here is a new proposal for changing Steve's text. =========================================================================== The CRL entry extensions defined by ISO/IEC, ITU-T, and ANSI X9 for X.509 v2 CRLs provide methods for associating additional attributes with CRL entries [X.509] [X9.55]. The X.509 v2 CRL format also allows communities to define private CRL entry extensions to carry information unique to those communities. Each extension in a CRLentry may be designated as critical or non-critical. A critical extension in the crlEntryExtensions field of an entry SHALL affect only the certificate identified in that entry, unless there is a related critical extension in the crlExtensions field that advertises a special treatment for it. If a CRL contains a critical CRL entry extension that the application cannot process, then the relying party SHOULD use, if possible, other sources of certificate revocation status (e.g. OCSP) to accurately the revocation status of the certificate identified in that CRLEntry. If the relying party is able to know (using a local policy) that the CRLEntry is associated with the CA that issued the CRL, then the relying party SHALL consider that the revocation status of the certificate is revoked. If the relying party is unable to know whether the CRLEntry is associated with the CA that issued the CRL, then the relying party SHOULD consider that the revocation status of the certificate is revoked. Note: In the last case, the relying party may treat a valid certificate as being revoked. However, since most CAs are currently using large random certificate serial numbers, a collision between such numbers is rather unlikely. So it is more likely that the certificate serial number identified in the CRLentry relates to the right CA. =========================================================================== The Note above could be transformed and placed in the security considerations section. It is taking care of a situation that is likely to happen one out of a zillion of zillion cases. It is one of the reasons why I have not kept the "dramatic" sentence from Steve's proposal: "the relying party is faced with a difficult choice". It seems that the PKIX WG is faced with a difficult choice. I see three ways we could go regarding the update to Section 5.3 of RFC 5280. (1) Stick with the text in RFC 5280. At one point in time, there was consensus for it. Ignoring a CRL with an unrecognized CRL Entry Extension is not aligned with the most recent version of X.509, but it is a safe thing to do. (2) Build consensus for the text in the current I-D. We have been working toward that for several weeks, and we are not making progress. (3) Build consensus around some alternate text. Steve put forward some alternate text, but it does not seem to have any more consensus than the text in the current I-D. Can Steve's text be changed in a way that gets us to consensus? So far, I have seen two major concerns raised that need to be resolved if this is the way forward. Russ _______________________________________________ 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 ------=_NextPart_000_00FF_01CDA61C.73AD1330 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Not that I support Denis’s proposal but I also disagree with = this

“If there is an unrecognized CRL Entry = Extension, then the replying party cannot know whether the entry applies = to a particular certificate or not.  Certificates are identified by = an issuer and serial number.  An unrecognized CRL Entry Extension = can change the issuer portion of the = tuple”

 

This is only true if there is a critical CRL extension which allows = such behavior.

If the RP can process the CRL extension, it should also process the = CRL entry extension which implies that the CRL entry extension is NOT = unrecognized.

If the RP cannot process the critical CRL extension, it’ll = reject the CRL and the question of what to do with CRL entry with = unrecognized extensions becomes moot.

 

CRL extensions affect the whole CRLs.

CRL entry extensions affect only the CRL entry unless indicated by a = related CRL extension.

 

The point of contention is that 5280 says that whole CRL should be = rejected if an unrecognized critical CRL entry extension is = encountered.

This is what we need to do”

-         = Make it explicit that that if RP processes IDP it should also process = “Certificate Issuer”

-         = Change the text to say that RP should treat the certificate referred = to by a CRL entry with unknown critical extension as = “revoked”. (Same as X.509)

 

All these proposals are assuming that a future CRL entry extension = can affect the whole CRL on its own. I’m sure if someone comes up = with such an extension he won’t find any support in this WG or any = other WG.

 

From:= = pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of = Russ Housley
Sent: Tuesday, October 09, 2012 9:08 = AM
To: Denis Pinkas Bull
Cc: = pkix@ietf.org
Subject: Re: [pkix] 5280bis CRL problem poll = results

 

Denis:

 

I = do not support this alternate text.  If there is an unrecognized = CRL Entry Extension, then the replying party cannot know whether the = entry applies to a particular certificate or not.  Certificates are = identified by an issuer and serial number.  An unrecognized CRL = Entry Extension can change the issuer portion of the = tuple.

 

The relying party can always try an alternate CRL or = and alternate protocol like OCSP to check out the certificate of = interest.  This would be true for any type of CRL validation = trouble.

 

I = am unclear how local policy can be helpful here.  If there is an = unrecognized CRL Entry Extension, the relying party knows that it cannot = use the entry.

 

If the relying party does not know the issuer = associated with a particular CRL entry, then it does not know whether = that entry is associated with the certificate of interest or not. =  Given this situation, I think that the appropriate action is not = to treat the certificate as revoked; instead, the CRL is providing no = useful information to make such a decision.

 

Russ

 

 

On = Oct 5, 2012, at 5:24 AM, Denis Pinkas Bull wrote:



Russ,

You = said: " 

Steve put forward some =
alternate text, but it does not seem to have any more consensus =

than the text in the current I-D.  Can =
Steve's text be changed in a way that gets us to consensus? =
"
 
Here is a new =
proposal for changing Steve's =
text.
 
=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
   The CRL entry extensions =
defined by ISO/IEC, ITU-T, and ANSI X9
   =
for X.509 v2 CRLs provide methods for associating additional =

   attributes with CRL entries =
[X.509] [X9.55].  The X.509 v2 CRL =

   format also allows communities =
to define private CRL entry =

   extensions to carry information =
unique to those communities. =

   Each extension in a CRLentry may =
be designated as critical or =

   non-critical.  A critical =
extension in the crlEntryExtensions =

   field of an entry SHALL affect =
only the certificate identified =

   in that entry, unless there is a =
related critical extension in =

   the crlExtensions field that =
advertises a special treatment for =

   it. =

 
   If a CRL =
contains a critical CRL entry extension that the =

   application cannot process, then =
the relying party SHOULD use, 
   if =
possible, other sources of certificate revocation status =

   (e.g. OCSP) to accurately the =
revocation status of the =

   certificate identified in that =
CRLEntry. =

   
  =
; If the relying party is able to know (using a local policy) =

   that the CRLEntry is associated =
with the CA that issued the CRL, =

   then the relying party SHALL =
consider that the revocation status =

   of the certificate is revoked. =

 
   If the =
relying party is unable to know whether the CRLEntry =

   is associated with the CA that =
issued the CRL, then the relying =

   party SHOULD consider that the =
revocation status of the =

   certificate is =
revoked.
 
   =
Note: In the last case, the relying party may treat a valid =

        &nb=
sp;certificate as being revoked.  However, since most CAs are =

        &nb=
sp;currently using large random certificate serial numbers, =

        &nb=
sp;a collision between such numbers is rather =
unlikely.
       =
  So it is more likely that the certificate serial number =

        &nb=
sp;identified in the CRLentry relates to the right =
CA.
 
=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
The Note above could be transformed and =
placed in the security considerations section.
It =
is taking care of a situation that is likely to happen one out of a =
zillion of zillion =
cases.
 
It is one of the =
reasons why I have not kept the "dramatic" sentence from =
Steve's proposal: 
"the relying party is faced =
with a difficult =
choice".
 
  =

 

It seems that the =
PKIX WG is faced with a difficult choice.  I see three ways we =
could go regarding the update to Section 5.3 of RFC =
5280.
 
(1) Stick with =
the text in RFC 5280.  At one point in time, there was consensus =
for it.  Ignoring a CRL with an unrecognized CRL Entry Extension is =
not aligned with the most recent version of X.509, but it is a safe =
thing to do.
 
(2) Build =
consensus for the text in the current I-D.  We have been working =
toward that for several weeks, and we are not making =
progress.
 
(3) Build =
consensus around some alternate text.  Steve put forward some =
alternate text, but it does not seem to have any more consensus than the =
text in the current I-D.  Can Steve's text be changed in a way that =
gets us to consensus?  So far, I have seen two major concerns =
raised that need to be resolved if this is the way =
forward.
 
Russ=

 
__________________________________=
_____________
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

 

------=_NextPart_000_00FF_01CDA61C.73AD1330-- From stefan@aaa-sec.com Wed Oct 10 04:32:00 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39D3A21F876C for ; Wed, 10 Oct 2012 04:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.852 X-Spam-Level: X-Spam-Status: No, score=-100.852 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id seM1SLu5LBMN for ; Wed, 10 Oct 2012 04:31:59 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id E0AA621F8752 for ; Wed, 10 Oct 2012 04:31:57 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 5DF242249DCC for ; Wed, 10 Oct 2012 13:31:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Acmyb6sjSR-F for ; Wed, 10 Oct 2012 13:31:53 +0200 (CEST) Received: from s328.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 074B62249DFF for ; Wed, 10 Oct 2012 13:31:48 +0200 (CEST) Received: (qmail 20488 invoked from network); 10 Oct 2012 11:31:47 -0000 Received: from static-213-115-40-164.sme.bredbandsbolaget.se (HELO [172.16.50.125]) (stefan@fiddler.nu@[213.115.40.164]) (envelope-sender ) by s328.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 10 Oct 2012 11:31:47 -0000 User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Wed, 10 Oct 2012 13:31:45 +0200 From: Stefan Santesson To: Santosh Chokhani , "denis.pinkas@bull.net" , pkix Message-ID: Thread-Topic: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3432720708_1966522" Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 11:32:00 -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_3432720708_1966522 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Why do you need this at all? I don't see that this extension is required in order to split OCSP responding for chunks of certs. You can point the client to the correct responder using information in the cert today. The responder can determine if the requested vert is within it's handled portion of certs. Given that you trust the OCSP responder and the responder is honest, you will receive an appropriate response. So, why the extension? I can only imagine the extension being useful to detect if a responder responds outside of it's authority, but if the OCSP responder is dishonest, then you are screwed in any case. /Stefan From: Santosh Chokhani Date: Friday, September 28, 2012 4:17 PM To: "denis.pinkas@bull.net" , pkix Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt > Denis, > > I find the document in general acceptable. It definitely fills a hole. > > That said, it is effective both in general and against MITM attack if the CA > recognizes that the absence of the critical extension you designed in the OCSP > certificate means that the Responder is authoritative for all certificates as > long as the rest of the requirements in RFC 2560 are met. > > Note that absence of IDP means that the CRL is full and complete. We do not > have a similar statement in 2560 and this extension is fully effective only if > such is the case, i.e., by omitting this extension, the CA implies that the > Responder is authoritative for all certificates signed using that CA key. > > We either need to impose this requirement, which while new, most > implementations I know impose or discuss it in the Security Considerations > section. > > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > denis.pinkas@bull.net > Sent: Tuesday, September 25, 2012 11:12 AM > To: pkix > Subject: [pkix] New Version Notification for > draft-pinkas-2560bis-ocsp-locationcheck-00.txt > > To the list, > > The last comment from Santosh, triggered me to write a new draft proposal > directly related to 2560bis. > > This proposal allows to split the workload of an OCSP service from a CA > between several OCSP Responders. > This may be desirable for PKIs issuing a large number of certificates (e.g. > several hundred of thousands). > > Denis > > ============================================================================== > ================ > > A new version of I-D, draft-pinkas-2560bis-ocsp-locationcheck-00.txt > has been successfully submitted by Denis Pinkas and posted to the > IETF repository. > > Filename: draft-pinkas-2560bis-ocsp-locationcheck > Revision: 00 > Title: OCSP LocationCheck certificate extension Update to OCSP > < draft-pinkas-2560bis-ocsp-locationcheck-00.txt > > Creation date: 2012-09-25 > WG ID: Individual Submission > Number of pages: 6 > URL: > http://www.ietf.org/internet-drafts/draft-pinkas-2560bis-ocsp-locationcheck-00 > .txt > 0.txt> > Status: > http://datatracker.ietf.org/doc/draft-pinkas-2560bis-ocsp-locationcheck > > Htmlized: > http://tools.ietf.org/html/draft-pinkas-2560bis-ocsp-locationcheck-00 > > > > Abstract: > > RFC 2560 [RFC2560] allows CAs to designate one or more OCSP > Responders for being responsible to provide the revocation status > of the certificates they issue under a given CA key. > > This document introduces a new feature that allows allows CAs to > split the workload between different sets of OCSP Responders in a > way that is analogous to the way CRLs can be split between > different sets of CRL issuers (using the cRLDistributionPoints > extension). > > This new feature allows a CA to designate one or more OCSP > Responders for being responsible to provide the revocation status > for a subset of the certificates they issue under a given CA key. > > This document defines a critical extension that may only be placed > in an OCSP certificate and the way it shall be processed by OCSP > clients. > > The IETF Secretariat > _______________________________________________ pkix mailing list > pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --B_3432720708_1966522 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Why do you need this at all?=

I don't see that this extension is required in ord= er to split OCSP responding for chunks of certs.
You can point the= client to the correct responder using information in the cert today.
<= div>The responder can determine if the requested vert is within it's handled= portion of certs.

Given that you trust the OCSP re= sponder and the responder is honest, you will receive an appropriate respons= e.

So, why the extension?

= I can only imagine the extension being useful to detect if a responder respo= nds outside of it's authority, but if the OCSP responder is dishonest, then = you are screwed in any case.

/Stefan

=

From: Santosh Chokh= ani <SChokhani@cygnacom.com&g= t;
Date: Friday, September 28, 201= 2 4:17 PM
To: "denis.pinkas@bull.net" <denis.pinkas@bull.net>, pkix <pkix@ietf.org>
Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-loca= tioncheck-00.txt

Denis,

 

=

I find the document in general acceptable.&= nbsp; It definitely fills a hole.

=  

Tha= t said, it is effective both in general and against MITM attack if the CA re= cognizes that the absence of the critical extension you designed in the OCSP= certificate means that the Responder is authoritative for all certificates = as long as the rest of the requirements in RFC 2560 are met.

 

Note that absence of IDP means that the CRL is full = and complete.  We do not have a similar statement in 2560 and this exte= nsion is fully effective only if such is the case, i.e., by omitting this ex= tension, the CA implies that the Responder is authoritative for all certific= ates signed using that CA key.

 

We eit= her need to impose this requirement, which while new, most implementations I= know impose or discuss it in the Security Considerations section.

 

From: pkix-bounces@ietf.org= [mailto:pkix-bounces@ietf.org] On Behalf Of denis.pinkas@b= ull.net
Sent: Tuesday, September 25, 2012 11:12 AM
To: pkix
Subject: [pkix] New Version Notification for draft-pinkas-= 2560bis-ocsp-locationcheck-00.txt

=  

To the list,

The last comment from Santosh,= triggered me to write a new draft proposal directly related to 2560bis. &nb= sp;

This proposal allows to split the workload of an OCSP service from a = CA between several OCSP Responders.
This may be desirable for PKIs issuing a = large number of certificates (e.g. several hundred of thousands).
Denis <= /span>


A new version of I-D, draft-pinkas-2560bis-ocsp-loca= tioncheck-00.txt
has been successfully submitted by Denis Pinkas= and posted to the
IETF repository.

Filename: &n= bsp;               draft-pinkas-2560bis-o= csp-locationcheck
Revision:           &= nbsp;     00
Title:          =       OCSP LocationCheck certificate extension Update to OCS= P
                 = ; < draft-pinkas-2560bis-ocsp-locationcheck-00.txt >
Creat= ion date:                  2012= -09-25
WG ID:               &= nbsp;                   Individ= ual Submission
Number of pages: 6
URL:    =         http://www.ietf.org/internet-drafts/draft-pinkas-2560bis-oc= sp-locationcheck-00.txt
Status:          http://datatracker.ietf.or= g/doc/draft-pinkas-2560bis-ocsp-locationcheck
Htmlized:    =    http://tool= s.ietf.org/html/draft-pinkas-2560bis-ocsp-locationcheck-00


Ab= stract:

  RFC 2560 [RFC2560] allows CAs to designate one or mor= e OCSP
  Responders for being responsible to provide the re= vocation status
  of the certificates they issue under a gi= ven CA key.

  This document introduces a new feature th= at allows allows CAs to
  split the workload between differ= ent sets of OCSP Responders in a
  way that is analogous to= the way CRLs can be split between
  different sets of CRL = issuers (using the cRLDistributionPoints
  extension).=

  This new feature allows a CA to designate one or more OCS= P
  Responders for being responsible to provide the revocat= ion status
  for a subset of the certificates they issue un= der a given CA key.

  This document defines a critical = extension that may only be placed
  in an OCSP certificate = and the way it shall be processed by OCSP
  clients.
The IETF Secretariat

_= ______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/m= ailman/listinfo/pkix
--B_3432720708_1966522-- From stefan@aaa-sec.com Wed Oct 10 04:39:20 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 906F821F86B2 for ; Wed, 10 Oct 2012 04:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.852 X-Spam-Level: X-Spam-Status: No, score=-100.852 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WCwspO0Tj9l for ; Wed, 10 Oct 2012 04:39:05 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id A926B21F8625 for ; Wed, 10 Oct 2012 04:39:02 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 2DC76224A079 for ; Wed, 10 Oct 2012 13:39:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nskSn5KJr3cB for ; Wed, 10 Oct 2012 13:38:40 +0200 (CEST) Received: from s376.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id CA97A224A00E for ; Wed, 10 Oct 2012 13:38:10 +0200 (CEST) Received: (qmail 42626 invoked from network); 10 Oct 2012 11:38:10 -0000 Received: from static-213-115-40-164.sme.bredbandsbolaget.se (HELO [172.16.50.125]) (stefan@fiddler.nu@[213.115.40.164]) (envelope-sender ) by s376.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 10 Oct 2012 11:38:10 -0000 User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Wed, 10 Oct 2012 13:38:05 +0200 From: Stefan Santesson To: , Santosh Chokhani Message-ID: Thread-Topic: [pkix] draft-pinkas-rfc2560bis-03 In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3432721091_2028510" Cc: "pkix@ietf.org" Subject: Re: [pkix] draft-pinkas-rfc2560bis-03 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 11:39:20 -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_3432721091_2028510 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Denis, Posting my major comments on this draft: - This is a substantial rewrite of the original standard. There has been a WG decision to limit changes to RFC 2560 to what is necessary to resolve previous ambiguity. In many places, the text provided in your draft adds confusion and adds ambiguity instead of removing them. - This is a protocol specification. That is, it defines the data elements exchanged for the purpose of doing OCSP checks. It is NOT a system design specification. Processing rules are only relevant if they have a direct impact on the bits on the wire. - The distinction between OCSP responder, OCSP server and OCSP service is in this context confusing and adds nothing useful to an implementer on either side of the protocol. /Stefan From: Date: Tuesday, September 25, 2012 5:01 PM To: Santosh Chokhani Cc: "pkix@ietf.org" Subject: [pkix] draft-pinkas-rfc2560bis-03 > Santosh, >=20 > This text change has been included in draft -03 which is now available at= : >=20 > http://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-03.txt > >=20 > Denis >=20 >=20 >=20 > De : Santosh Chokhani > A : "denis.pinkas@bull.net" > Cc : "pkix@ietf.org" > Date : 24/09/2012 18:21 > Objet : RE: draft-pinkas-rfc2560bis-02 >=20 >=20 >=20 >=20 > Denis, > =20 > OK except a nit (replace =B3accessLocation field from=B2 to =B3accessLocation f= ield > of=B2) > =20 > From: denis.pinkas@bull.net [mailto:denis.pinkas@bull.net > ] > Sent: Monday, September 24, 2012 2:17 AM > To: Santosh Chokhani > Cc: pkix@ietf.org > Subject: RE: draft-pinkas-rfc2560bis-02 > =20 > Santosh, >=20 > Your point is valid. Here is a proposed change to solve the issue. >=20 > OLD TEXT:=20 >=20 > For a given URI value identifying the location of an OCSP Responder, > the OCSP Responder SHALL only use one OCSP key pair value for a > given period of time. For example, it is acceptable for an OCSP > Responder to rekey, stop using the old key, and continue to use the > same URI while using the new key. >=20 > NEW TEXT:=20 >=20 > An OCSP Responder key rollover does not affect the values of the > URIs that are placed in the accessLocation field from the target > certificates. One or more OCSP Responder MAY respond to an OCSP > request addressed at a given URI picked from the accessLocation > field from a target certificate. Each OCSP Responder MAY use a > different signing key, as long as it got an OCSP certificate > appropriate for that signing key and for the target certificate. >=20 > Denis=20 >=20 >=20 >=20 > De : Santosh Chokhani > > A : "denis.pinkas@bull.net " > > > Cc : "pkix@ietf.org " > > Date : 21/09/2012 17:42 > Objet : RE: draft-pinkas-rfc2560bis-02 >=20 >=20 >=20 >=20 >=20 >=20 > Denis,=20 > =20 > Thanks. I am ok with your changes. > =20 > One thing listed below is troubling me and I would like your and others=B9 > opinion on it.=20 > =20 > While you have revised the text in Section 3.3.3 as I requested, it is ov= erly > constraining and has been troublesome from the beginning. The text I ref= er to > is: =B3For a given URI value identifying the location of an OCSP Responder,= the > OCSP Responder SHALL only use one OCSP key pair value for a given period = of > time=B2.=20 > =20 > While I can see how this assertion simplifies the sausage-making of the > standard and the data structures you spell out, it is something these nee= d not > be applies in order for the OCSP to work. It is generally a bad ideas i= n a > standard to impose a constraint that is not necessary for feasibility, > security or interoperability reasons. > =20 > For example, one could have geographical load balancing and/or geographic= al > redundancy for the URL and rather than porting the same key, have differe= nt > keys for the Servers. In that case, the actual Server that got the reque= st > routed would sign the response. > =20 > Another example, is the URL and the server map to the same machine and it= has > multiple keys and can use any one of them. > =20 > I do agree that there needs to be some constraint that specifies that the > server must be able to provide response to all the queries it is authorit= ative > for and meet the cryptographic binding requirement. > I think we need to work the 3.3.3 language so that the constraint is spec= ified > such that it does not prohibit valid architectures. > =20 > From: denis.pinkas@bull.net > [mailto:denis.pinkas@bull.net ] > Sent: Friday, September 21, 2012 9:22 AM > To: Santosh Chokhani > Cc: pkix@ietf.org > Subject: draft-pinkas-rfc2560bis-02 > =20 > Santosh,=20 >=20 > Thank you for these new comments. I have one comment back and two nits. >=20 > You suggested to add text at the end of STEP 2, since the current draft d= oes > not cover when the response is signed by the OCSP Responder. > Your rational is quite true. However, your propose change does not fit we= ll. I > have changed the text differently >=20 > Please take a look at draft -02 which has been issued today. > http://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-02.txt > >=20 > First nit :=20 >=20 > PROPOSED TEXT:=20 >=20 > Note: The CA may need to continue issuing certificates to the OCSP Respon= der > using the old CA key until > all the certificates issued under the CA=B9 old key for which the OCSP Resp= onder > is authoritative for expire. >=20 > NEW TEXT:=20 >=20 > Note: The CA may need to continue issuing certificates to the OCSP Respon= der > using the old CA key until > all the certificates issued under the CA=B9 old key for which the OCSP Resp= onder > is authoritative have expired. >=20 > Second nit :=20 >=20 > PROPOSED TEXT:=20 >=20 > For example, it is acceptable for an OCSP Responder to rekey, stop using = the > old key, and continue to use > the old URI while using the new key=B2 >=20 > NEW TEXT:=20 >=20 > For example, it is acceptable for an OCSP Responder to rekey, stop using = the > old key, and continue to use > the same URI while using the new key. >=20 > Denis=20 >=20 >=20 >=20 > De : Santosh Chokhani > > A : "denis.pinkas@bull.net " > > > Cc : "pkix@ietf.org " > > Date : 18/09/2012 21:27 > Objet : RE: [pkix] draft-pinkas-rfc2560bis-00 >=20 > =20 >=20 >=20 >=20 >=20 >=20 >=20 > Denis,=20 > =20 > Thanks. Below are my updated recommended changes: > =20 > Section 3.2=20 > =20 > Add the following Note after the second dash: > =20 > Note: The change in accessLocation is necessary when the CA rekeys to mee= t the > following constraints imposed by this standard: 1) a BasicOCSPResponse ca= n > only be signed using a single private key; 2) the response must be signed > using the same CA key that was used to sign the certificate in question; = and > 3) the OCSP response needs to cover all the certificates queried in the O= CSP > request.=20 > =20 > Section 3.3.2:=20 > =20 > Add the following Note to the 3rd and the last paragraph: > =20 > Note: The CA may need to continue issuing certificates to the OCSP Respon= der > using the old CA key until all the certificates issued under the CA=B9 old = key > for which the OCSP Responder is authoritative for expire. > =20 > Section 3.3.3:=20 > =20 > OLD TEXT:=20 > =20 > =B3For a given URI value identifying the location of an OCSP Responder, the= OCSP > Responder SHALL only use one OCSP key pair value.=B2 > =20 > NEW TEXT:=20 > =20 > =B3For a given URI value identifying the location of an OCSP Responder, the= OCSP > Responder SHALL only use one OCSP key pair value for a given period of ti= me. > For example, it is acceptable for an OCSP Responder to rekey, stop using = the > old key, and continue to use the old URI while using the new key=B2 > =20 > Section 3.4:=20 > =20 > OLD TEXT:=20 > =20 > Note: For each candidate certificate, when performing the path > validation algorithm, the OCSP client will verify that the > current time is within the validity period of the target > certificate. Thus, certificates which are outside their > validity period will not be included in the request or will > be rejected later on by the OCSP responder. > =20 > =20 > NEW TEXT:=20 > =20 > Note: For each candidate certificate, when performing the path > validation algorithm, the OCSP client SHOULD verify that the > current time is within the validity period of the target > certificate. Thus, certificates which are outside their > validity period SHOULD not be included in the request. > =20 > Section 4.3.1.3:=20 > =20 > OLD TEXT:=20 > =20 > For each CA from which the locally trusted Responder has received a > delegation, the OCSP Responder SHALL maintain a list of entries. > =20 > =20 > NEW TEXT:=20 > =20 > For each CA for which the locally trusted Responder is authoritative, the= OCSP > Responder SHALL maintain a list of entries. > =20 > RATIONALE:=20 > =20 > The locally trusted responder need not have delegation from the CA > =20 > Section 4.3.2:=20 > =20 > Add the following at the end of STEP 2: > =20 > check whether the response is signed using the OCSP Responder key: > =20 > If it is the case, then the revocation status of that > certificate as indicated in the certStatus field is > accepted and proceed to step 3. > =20 > If it is not the case, then the revocation status of that > certificate is "unknown" and proceed to step 3. > =20 > Rationale: Current draft does not cover when the response is signed by th= e > OCSP Responder=20 > =20 > Change S. Shokhani to S. Chokhani > =20 > =20 > From: denis.pinkas@bull.net > [mailto:denis.pinkas@bull.net ] > Sent: Monday, September 17, 2012 3:59 AM > To: Santosh Chokhani > Cc: pkix@ietf.org > Subject: RE: [pkix] draft-pinkas-rfc2560bis-00 > =20 > Santosh,=20 >=20 > Thank you for your very valuable comments. It took me "some time" to proc= ess > them.=20 > It will take you "some time" to review them. :-) >=20 > Since the comments and the changes were numerous, I have issued a new dra= ft > which is available at: > http://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-01.txt > >=20 > For Santosh in particular, see my responses below in lines. >=20 > Denis,=20 >=20 > Thanks for this. My initial review indicates that this a very good first > draft. =20 > Note that I did not review ASN.1 carefully (I assume it was copied from t= he > existing RFC).=20 >=20 > It was copied from the draft prepared by Stefan, but the ASN. 1 module ne= eds > to be modified=20 > since the syntax of nonce has been omitted. >=20 > I have added:=20 >=20 > Nonce ::=3D OCTET STRING >=20 > Since the syntax of the nocheck extension was missing, I have also added: >=20 > NoCheck ::=3D NULL >=20 > In the introduction, I have also added: >=20 > o Section 4.3.2 now indicates that the value of the nocheck > extension SHALL be NULL. >=20 > The ASN.1 module that conforms to the 2002 version of ASN.1 which may be = found > in Section 4=20 > of RFC5912 has another problem, since the nocheck extension has been omit= ted. >=20 > I have added:=20 >=20 > -- Certificate Extension >=20 > ocsp-nocheck EXTENSION ::=3D { SYNTAX NULL > IDENTIFIED BY > id-pkix-ocsp-nocheck } >=20 > This means that we cannot keep the same OID for the two ASN. 1 modules an= d > thus we will need two new ones. >=20 > I have now included both syntaxes in draft -01. >=20 > In the introduction, I have also added: >=20 > o Annex B includes a new ASN.1 module using the 1988 syntax > since the syntax of nonce had been omitted. It also includes > a new ASN.1 module using the 2002 syntax since in the ASN.1 > module which may be found in Section 4 of RFC5912 the nocheck > extension had been omitted. >=20 > I do have the following comment though: >=20 > Section 2.2: When the CA is signing the response, should it not also use = the > same key to sign the response > as the certificate in question? The later part of the section indicates = this > as a requirement. > In that case, why not make this explicit like the OCSP Responder. >=20 > You are correct: I have added: >=20 > In the former case, the CA MUST use the same key as the one that was > used to issue the target certificate. >=20 > Section 3.1.3, First paragraph, the rational for CA certificates to have > digital signature bit set because > they sign OCSP certificates is incorrect. May be what you mean is that a= CA > that signs OCSP responses > needs to have digital signature bit set in its own certificate (i.e., the > certificate for which the CA is the subject). >=20 > Oups! The text was: >=20 > Therefore the digitalSignature bit in the keyUsage extension MUST > be set.=20 >=20 > Note 1: Since the CA issues certificates, the keyCertSign bit MUST also > be set. >=20 > Note 2: If the CA supports CRLs, in particular to revoke the > certificate of the OCSP Responders, then the cRLSign bit, the > digitalSignature bit and the keyCertSig bit MUST be set. >=20 > I have changed it into: >=20 > Therefore the keyCertSign bit in the keyUsage extension MUST be set. >=20 > If the CA supports CRLs, in particular to revoke the certificate of > the OCSP Responders, then both the cRLSign bit and the keyCertSig > bit MUST be set. >=20 > Section 3.1.3, Note 2, Again there is no requirement for digital signatur= e bit > to be set just because the CA signs > certificates and CRLs. >=20 > You are correct. See the correction proposed above. >=20 > Section 3.2: It not clear which accessLocation is being referred to here > (cAissuers or OCSP). If this is OCSP, > the RFC is overly implementation specific. A CA can use the same OCSP > location and sign the response with > appropriate key and include the appropriate CA certificate without having= to > change the OCSP pointer. >=20 > Section 3.2 addresses the case of CA that directly supports an OCSP servi= ce > and which performs a key rollover. > If the CA key changes, the OCSP location must change since it is only pos= sible > use a single key to sign the OCSP > responses. Nevertheless, I take your other point to be more specific abou= t the > accessLocation.=20 > The point is addressed later on in another comment from you. >=20 > General: The I-D does not address how the CA deals with the situation whe= n > status of multiple certificates issued by the CA, > but using different keys is requested. May be the restriction in 3.2 is = used > to ensure that such situation does not occur. > If so, a short discussion would be helpful. >=20 > Your comment is related to section 4.3.1.1. (=B3Processing by a CA acting a= s an > OCSP responder=B2). > The case is already addressed with the following text: >=20 > For each target certificate, the OCSP responder SHALL verify whether > both the hash of the issuer's DN and the hash of the issuer public > key which are present in the request match respectively with the DN > and the hash of the public key of contained in an entry from the > list of entries maintained by this OCSP responder. >=20 > When there is no match, then the OCSP responder SHALL indicate the > "unknown" status and proceed with the next target certificate from > the OCSP request. >=20 > General: It not clear which accessLocation is being referred to in most > places.=20 > It would be worth stating that it refers to OCSP in all cases unless othe= rwise > stated.=20 >=20 > I have added a note after the first occurrence of the word in section 3.1= .1. >=20 > Note: accessLocation is mentioned in several places of this document. > It refers in all cases to the accessLocation field that is present > in an AIA extension field to designate the location of the OCSP > responder. In that case, the accessMethod field contains the > id-ad-ocsp OID. >=20 > Section 3.3.2 does not fully and explicitly cover the most common > implementation I have seen and that is short life certificates. > In that scenario, the CA needs to continue to issue the OCSP Responder > certificate using the old CA key until all the certificates > issued by the CA using the old key and for which the OCSP Responder is > authoritative expire. > The text in 3.3.3 can form a model for this when CA rekeys and OCSP Respo= nder > has the old keys. >=20 > The text in section 3.3.2 does not say what you say. Please be more speci= fic > or since the text is short, provide an alternative >=20 > Section 3.3.3, the last sentence is not desirable and can cause problems = with > some implementations. > It is perfectly ok for a Responder to change its key independent of > certificate it is authoritative for. > Note that OCSP field in a issue certificate cannot be changed just becaus= e the > Responder rekyed, > be it routine or due to loss or compromise of Responder key. >=20 > The text in section 3.3.3 does not say what you say. Please be more speci= fic > or since the text is short, provide an alternative. >=20 > Section 3.4, last paragraph, I would think that expiration checking need = not > be part of OCSP client. > Expiration checking should come under 5280 certificate validation. >=20 > The text was:=20 >=20 > For each candidate certificate, the OCSP client SHALL verify that > the current time is within the validity period of the target > certificate. If this is not the case, the candidate certificate > SHALL be discarded. >=20 > I have changed it into; >=20 > Note: For each candidate certificate, when performing the path > validation algorithm, the OCSP client will verify that the > current time is within the validity period of the target > certificate. Thus, certificates which are outside their > validity period will not be included in the request or will > be rejected later on by the OCSP responder. >=20 > Section 4.1, We should dilute two CAs =B3never have the same issuerKeyHash=B2= to > something more akin > to statistically infeasible. >=20 > The text was:=20 >=20 > Two CAs will never, however, have the same public key unless the > CAs either explicitly decided to share their private key, or the > key of one of the CAs was compromised. >=20 > I have changed it into: >=20 > However, it is statistically infeasible that two CAs use the same > public key unless the CAs either explicitly decided to share > their private key, or the key of one of the CAs was compromised. >=20 > Titles of subsections under 4.3 could stand improvements. Responders pro= cess > request and produce response; > they do not process responses. Clients process responses. >=20 > The titles were:=20 >=20 > 4.3. Response processing > 4.3.1. Response processing by OCSP servers > 4.3.1.1. Processing by a CA acting as an OCSP responder > 4.3.1.2. Processing by an OCSP Responder > 4.3.2. Response processing by an OCSP client >=20 > I have changed them into: >=20 > 4.3. Processing of requests and responses > 4.3.1. Request processing by OCSP servers > 4.3.1.1. Processing by a CA acting as an OCSP responder > 4.3.1.2. Processing by an OCSP Responder > 4.3.2. Response processing by an OCSP client >=20 > Section 4.3.1.1, The entry should contain method used to gain access and = sign > just like the text in 4.3.1.2 > as opposed to the private key. In other words, align the two texts for > accessing and using private key > to sign OCSP responses. >=20 > Both sections have been aligned. >=20 > Section 4.3.1,1, page 18 =B3defined in entry=B2 could be misinterpreted as me= thod > define in request entry. >=20 > I don=B9t think that a change is necessary, since it uses the term =B3for eac= h > target certificate=B2 and the entry thus > refers to one of the entries from the tables of entries advertised at the > beginning of the section. > If you believe that a change is necessary, would you be able to make a > proposal ?=20 >=20 > Section 4.3.1.2, Again the same comment, for the delegated OCSP Responder= , > changing the URL=20 > when key is changed is not required and breaks many implementations and h= ence > is unacceptable.=20 >=20 > Would you be able to be more specific, since I don=B9t see that the text st= ates > what you mean ?=20 >=20 > Section 4.3.2, the check for thisUpdate is flawed since this value may be > derived from CRL even for responses > that are not pre-generated and hence can be hours or days off depending o= n CRL > issuance frequency, > It is better to replace it with producedAt field in the response whether = it is > related to current time or time in the past. >=20 > Good catch !=20 >=20 > The text has been changed into : >=20 > If the checking time is the current time, and if no nonce has been > used in the request, OCSP clients MUST check that the producedAt > field is within a time window that is "close enough" to the current > time.=20 >=20 > If the checking time is a time in the past, verifiers MUST check > that the producedAt field is in accordance with the verification > rules (e.g. close and/or after the date of a time-stamp token). >=20 > Section 4,3,2 is missing processing signature on the response and process= ing > response extension. >=20 > I don=B9t understand your request about =B3missing processing signature on th= e > response=B2, since this point is addressed > under STEP 2. If you believe that a change is necessary, would you be abl= e to > be more specific ? >=20 > Processing response extension is only covered for singleExtensions when t= he > criticality flag is set and > the extension is not understood. So you are correct to request additional= text > to handle the other cases. >=20 > The following text has been added for the processing of responseExtension= s: >=20 > OCSP clients or verifiers SHALL check if the response contains a > critical responseExtensions. If such an extension is found and is > recognized, it MUST be processed. If such an extension is found and > is not recognized, the whole OCSP response MUST be considered as > invalid.=20 >=20 > The following text has been added for the processing of singleExtensions: >=20 > If checks are successful, then OCSP clients MUST process the > singleExtensions field, if it is present. >=20 > If the criticality flag is set and the extension is not understood, > then the status of the certificate shall be "unknown" and proceed to > step 3. Otherwise, proceed to step 2. >=20 > If the extension is understood, then the extension MUST be > processed. According to its content proceed either to step 2 or to > step 3.=20 >=20 > Section 5.5: Replay attack is also possible when not using pre-computed > responses.=20 >=20 > I have added in new section with the following text: >=20 > 5.7. Other replay attacks >=20 > As already mentioned in section 5.5, replay attacks are possible > using precomputed responses. Replay attacks are also possible when > no nonce is being used in the OCSP request and the time window > mentioned in section 4.3.2 (STEP 1)is too large. >=20 > General: Removal of locally trusted Responder from the I-D is unacceptabl= e. >=20 > The intent was not to remove the =B3locally trusted Responder=B2. Nevertheles= s, > the current text has been improved > in several places. For example, in the introduction, I have added: >=20 > The term =B3locally trusted Responder=B2 is used to designate an OCSP > responder that is trusted using local rules. >=20 > In section 2.2, the text now states: >=20 > A response message MUST be signed either by a certificate's issuer, > by an authorized OCSP Responder or according to local rules. >=20 > In the first case, the CA MUST use the same key as the one that was > used to issue the target certificate. >=20 > In the second case, the CA MUST explicitly designate the OCSP > Responder by issuing an OCSP certificate to the OCSP Responder. > OCSP signing delegation SHALL be indicated by the inclusion of > id-kp-OCSPSigning in an extendedKeyUsage certificate extension > included in the OCSP response signer's certificate. This > certificate MUST be issued directly by the CA and under the same key > that was used to issue the target certificate. >=20 > For these two cases, systems or applications that rely on OCSP > responses MUST be capable of detecting and enforcing use of the > id-ad-ocspSigning value as described above. >=20 > In the third case, the OCSP client uses a locally trusted Responder. > The key used to sign OCSP responses may be directly trusted or be a > key contained in an OCSP certificate which is verified according to > local rules, instead of the rules detailed in this document. >=20 > In section I have changed the following text : >=20 > The OCSP certificate SHALL be signed by the CA issuing private key > which corresponds to the issuing CA public key that is in this > entry, unless some specific rules are agreed between the OCSP > Responder and OCSP clients. In that later case, the OCSP > certificate MAY be signed by a different entity. >=20 > into:=20 >=20 > The OCSP certificate SHALL be signed by the CA issuing private key > which corresponds to the issuing CA public key that is in this > entry, unless some specific rules are agreed between the OCSP > Responder and OCSP clients. In that later case, which corresponds > to the case of a locally trusted Responder, the OCSP certificate MAY > be signed by a different entity. >=20 > There is now also a completely new section: 4.3.1.3, called =B3Processing b= y a > locally trusted Responder=B2. >=20 > When reviewing the text, I found that, in section 4.3.1.2, the list only > mentioned:=20 >=20 > - the method(s) used to obtain the revocation status of the > certificates issued under that CA issuing public key, >=20 > In practice, an OCSP responder may not be responsible for all the certifi= cates > issued by a CA.=20 > So it also needs to know which subset of the certificates issued by each = CA it > is responsible for. >=20 > Thus I have changed the text into: >=20 > - the method(s) used to know for which subset of certificates > issued by the CA it is responsible for, >=20 > - the method(s) used to obtain the revocation status of that > subset of certificates issued under that CA issuing public key, >=20 >=20 > Denis=20 >=20 >> > A new Internet-Draft is available from the on-line Internet-Drafts >> > directories. >> >=20 >> > Title : X.509 Internet Public Key Infrastructure Online >> > Certificate Status Protocol - OCSP >> > Author(s) : D. Pinkas >> > Filename : draft-pinkas-rfc2560bis >> > Pages : 41 >> > Date : Aug. 27, 2012 >> > =20 >> > This document specifies a protocol useful in determining the current >> > status of a digital certificate without requiring CRLs. Additional >> > mechanisms addressing PKIX operational requirements are specified in >> > separate documents. This document obsoletes RFC 2560 and RFC 6277. >> >=20 >> > A URL for this Internet-Draft is: >> > http://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-00.txt >> >> >=20 >> > Internet-Drafts are also available by anonymous FTP at: >> > ftp://ftp.ietf.org/internet-drafts/ >> >=20 >> > Below is the data which will enable a MIME compliant mail reader >> > implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >=20 >> > > > >> >=20 >> > A few explanations about the content of draft-ietf-pinkas-rfc2560bis-0= 0. >> >=20 >> > 25 changes are indicated at the beginning of the document. >> > I will only mention a few of them: >> >=20 >> > A - Explanations were missing to describe: >> >=20 >> > - the building of a request by an OCSP client, >> > - the processing of a request by an OCSP server, >> > - the building of a response by an OCSP server, and >> > - the processing of a response by an OCSP client. >> >=20 >> > These explanations have been added. >> >=20 >> > B - Explanations were missing to address CA key rollover and OCSP >> > key rollover. These explanations have been added. >> >=20 >> > C - Backwards compatibility has been addressed in the following way: >> >=20 >> > 1) An OCSP response by be signed either by a CA or by an OCSP >> Responder. >> >=20 >> > 2) Besides local configuration settings which are optional, >> > only two cases SHALL be supported by OCSP clients (and thus O= CSP >> servers)=20 >> > as explained below. >> >=20 >> > The key to be used to verify a SingleResponse (within a >> > BasicOCSPResponse) MUST: >> >=20 >> > (1) either be the same key that the one used to sign the >> > target certificate, >> >=20 >> > (2) or be the public key from an OCSP responder that is >> > contained in an OCSP certificate that has been signed by= the >> same key=20 >> > that the one used to sign the target certificate. >> > .=20 >> > The text allows to use the same general processing for a few other >> > cases, since "escape" sentences are provided to allow for these other >> cases,=20 >> > but only using "local configuration settings". >> >=20 >> > This means in particular that the Identrust model may be supported >> > and that the "several many cases" that were detailed in the annexes f >> > from draft -04 from David Cooper and Stefan Santesson (but which were = not >> > interoperable with most current implementations) can take benefit of t= he >> description=20 >> > of the general processing. >> >=20 >> > Denis=20 > _______________________________________________ pkix mailing list > pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --B_3432721091_2028510 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Denis,
Posting my major comments on this draft:

- This is a substantial re= write of the original standard. There has been a
WG decision to limit changes to RFC 2560 to what is ne= cessary to resolve
previous= ambiguity. In many places, the text provided in your draft adds
confusion and adds ambiguity instead o= f removing them.

- This is a protocol specificati= on. That is, it defines the data elements
exchanged for the purpose of doing OCSP checks. It is NOT a s= ystem design
specification.= Processing rules are only relevant if they have a direct
<= font face=3D"Calibri,sans-serif">impact on the bits on the wire.
<= div>
- The distinction between OCSP responder, OCSP server and OCSP= service is
in this context= confusing and adds nothing useful to an implementer on
either side of the protocol.
=

/Stefan

From: <denis.pinkas@bull.net>
Date: Tuesday, September 25, 2012 5:01 PM
To:= Santosh Chokhani <SChokh= ani@cygnacom.com>
Cc: "pkix@ietf.org" <pkix@ietf.org>
Subject: [pkix] draft-pinkas-rfc2560bis-03

Santosh,

This text change has been includ= ed in draft -03 which is now available at :

htt= p://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-03.txt<= /a>

Denis



De :        Santosh Chokhani <SChokhani@cygnacom.com>
A :        "denis.pinkas@bull.net" <denis.pinkas@bull.net>
Cc :   &n= bsp;    "pkix@ietf.org" <pkix@ietf.org>
Date :        24/09/2012 18:21
Objet :        RE: draft-pinkas-rfc25= 60bis-02



Denis,
&= nbsp;
OK except a nit = (replace “accessLocation field from” to “accessLocation field of”)
 
From: denis.pinkas@bu= ll.net [mailto:denis.pinkas@bull.net]
Sent: Monday, September 24, 2012 2:17 AM
To: Santosh Chokhani
Cc: pkix@ietf.org
Subject: RE: draft-pinkas-rfc2560bis-02
 
Santosh,

Your point is valid. Here is a proposed change to solve the issue.

OLD TEXT:

  For a given URI value identifying the location of an OCSP Responder= ,
  the OCSP Responder SHALL only use one OCSP key pair value for a
  given period of time.  For example, it is acceptable for an OCSP
  Responder to rekey, stop using the old key, and continue to use the
  same URI while using the new key.

NEW TEXT:

  An OCSP Responder key rollover does not affect the values of the
  URIs that are placed in the accessLocation field from the target
  certificates.  One or more OCSP Responder MAY respond to an OCSP
  request addressed at a given URI picked from the accessLocation
  field from a target certificate.  Each OCSP Responder MAY use a
  different signing key, as long as it got an OCSP certificate
  appropriate for that signing key and for the target certificate.

Denis



De :        Santosh Chokhani <SChokhani@cygnacom.com>
A :        "<= a href=3D"mailto:denis.pinkas@bull.net">denis.pinkas@bull.net" <denis.pinkas@bull.net>
Cc :        "= p= kix@ietf.org" <pkix@ietf.org>
Date :        21/09/= 2012 17:42
Objet :        RE: draft-pinkas-rfc2560bis-02




Denis,
 
Thanks.  I am ok with your changes.
 
One thing listed below is troubling me and I would like your and othersR= 17; opinion on it.
 
While you have revised the text in Section 3.3.3 as I requested, it is overly constraining and has been troublesome from the beginning.  The text I refer to is: “For a given URI value identifying the location o= f an OCSP Responder, the OCSP Responder SHALL only use one OCSP key pair value for a given period of time”.
 
While I can see how this assertion simplifies the sausage-making of the standard and the data structures you spell out, it is something these need not be applies in order for the OCSP to work.   It is generally a bad ideas in a standard to impose a constraint that is not necessary for feasibility, security or interoperability reasons.
 
For example, one could have geographical load balancing and/or geographical= redundancy for the URL and rather than porting the same key, have different= keys for the Servers.  In that case, the actual Server that got the request routed would sign the response.
 
Another example, is the URL and the server map to the same machine and it has multiple keys and can use any one of them.
 
I do agree that there needs to be some constraint that specifies that the server must be able to provide response to all the queries it is authoritat= ive for and meet the cryptographic binding requirement.
I think we need to work the 3.3.3 language so that the constraint is specif= ied such that it does not prohibit valid architectures.
=  
From: denis.pinkas@bull.net [mailto:denis.pinkas@bull.net]
Sent: Friday, September 21, 2012 9:22 AM
To: Santosh Chokhani
Cc: pkix@ietf.org=
Subject: draft-pinkas-rfc2560bis-02
 
Santosh,

Thank you for these new comments. I have one comment back and two nits.=

You suggested to add text at the end of STEP 2, since the current draft does not cover when the response is signed by the OCSP Responder.
Your rational is quite true. However, your propose change does not fit well. I have changed the text differently

Please take a look at draft -02 which has been issued today.


First nit :

PROPOSED TEXT:

Note: The CA may need to continue issuing certificates to the OCSP Responde= r using the old CA key until
all the certificates issued under the CA’ old key for which the OCSP = Responder is authoritative for expire.

NEW TEXT:

Note: The CA may need to continue issuing certificates to the OCSP Responde= r using the old CA key until
all the certificates issued under the CA’ old key for which the OCSP = Responder is authoritative h= ave expired.

Second nit :

PROPOSED TEXT:

For example, it is acceptable for an OCSP Responder to rekey, stop using the old key, and continue to use
the old URI while using the new key”

NEW TEXT:

For example, it is acceptable for an OCSP Responder to rekey, stop using the old key, and continue to use
the same URI while using the new key.

Denis



De :        Santosh Chokhani <SChokhani@cygnacom.com>
A :        "<= a href=3D"mailto:denis.pinkas@bull.net">denis.pinkas@bull.net" <denis.pinkas@bull.net>
Cc :        "= p= kix@ietf.org" <pkix@ietf.org>
Date :        18/09/= 2012 21:27
Objet :        RE: [pkix] draft-pinkas-rfc2560bis-00

&nbs= p;

=



Denis,

Thanks.  Below are my updated recommended changes:

Section 3.2

Add the following Note after the second dash:

Note: The change in accessLocation is necessary when the CA rekeys to meet the following constraints imposed by this standard: 1) a BasicOCSPResponse can only be signed using a single private key; 2) the response must be signed using the same CA key that was used to sign the certificate in quest= ion; and 3) the OCSP response needs to cover all the certificates queried in the OCSP request.

Section 3.3.2:

Add the following Note to the 3rd and the last paragraph:

Note: The CA may need to continue issuing certificates to the OCSP Responde= r using the old CA key until all the certificates issued under the CA’ = old key for which the OCSP Responder is authoritative for expire.

Section 3.3.3:

OLD TEXT:

“For a given URI value ident= ifying the location of an OCSP Responder, the OCSP Responder SHALL only use one OCSP key pair value.”
NEW TEXT:

“For a given URI value ident= ifying the location of an OCSP Responder, the OCSP Responder SHALL only use one OCSP key pair value fo= r a given period of time.  For example, it is acceptable for an OCSP Responder to rekey, stop using the old key, and continue to use the old URI while using the new key”=

Section 3.4:

OLD TEXT:

Note:  For each candidate certificate, when performing the path
     validation algorithm, the OCSP client will verify that the
     current time is within the validity period of the target
     certificate.  Thus, certificates which are outsid= e their
     validity period will not be included in the request or will
     be rejected later on by the OCSP responder.


NEW TEXT:

Note:  For each candidate certificate, when performing the path
     validation algorithm, the OCSP client SHOULD verify that the
     current time is within the validity period of the target
     certificate.  Thus, certificates which are outsid= e their
     validity period SHOULD not be included in the request.

Section 4.3.1.3:

OLD TEXT:

 For each CA from which the locally trusted Responder has received a
 delegation, the OCSP Responder SHALL maintain a list of entries.


NEW TEXT:

For each CA for= which the locally trusted Responder is authoritative, the OCSP Responder SHALL maintain a list of entries.

RATIONALE:

The locally trusted responder need not have delegation from the CA

Section 4.3.2:

Add the following at the end of STEP 2:

check whether the response is signed using the OCSP Responder key:

           If it is the case, then the revoc= ation status of that
           certificate as indicated in the certStatus field is
           accepted and proceed to step 3.

           If it is not the case, then the revocation status of that
           certificate is "unknown" and proceed to step 3.

Rationale: Current draft does not cover when the response is signed by the OCSP Responder

Change S. Shokhani to S. Chokhani


From: denis.pinkas@bull.net [mailto:denis.pinkas@bull.net]
Sent: Monday, September 17, 2012 3:59 AM
To: Santosh Chokhani
Cc: pkix@ietf.org=
Subject: RE: [pkix] draft-pinkas-rfc2560bis-00

Santosh,

Thank you for your very valuable comments. It took me "some time" to process them.
It will take you "some time" to review them. :-)

Since the comments and the changes were numerous, I have issued a new draft= which is available at: =
http://www.ietf.org/internet-drafts/dr= aft-pinkas-rfc2560bis-01.txt

For Santosh in particular, see my responses below in lines.

Denis,

Thanks for this.  My initial review indicates that this a very good first draft.  
Note that I did not review ASN.1 carefully (I assume it was copied from the existing RFC).

It was copied from the draft prepared by Stefan, but the ASN. 1 module needs to be modified
since the syntax of nonce has been omitted.

I have added:

Nonce ::=3D OCTET STRING

Since the syntax of the nocheck extension was missing, I have also added:

NoCheck ::=3D NULL

In the introduction, I have also added:

   o  Section 4.3.2 now indicates that the value of the nocheck
      extension SHALL be NULL.

The ASN.1 module that conforms to the 2002 version of ASN.1 which may be found in Section 4
of RFC5912 has another problem, since the nocheck extension has been omitte= d.

I have added:

--  Certificate Extension=

ocsp-nocheck EXTENSION ::=3D { SYNTAX NULL
                                      IDENTIFIED BY
                                      id-pkix-ocsp= -nocheck }

This means that we cannot keep the same OID for the two ASN. 1 modules and thus we will need two new ones.

I have now included both syntaxes in draft -01.

In the introduction, I have also added:

   o  Annex B includes a new ASN.1 module using the 1988 syntax
      since the syntax of nonce had been omitted.  It also includes
      a new ASN.1 module using the 2002 syntax since in the ASN.1
      module which may be found in Section 4 of RFC5912 the nocheck
      extension had been omitted.
I do have the following comment though:

Section 2.2: When the CA is signing the response, should it not also use the same key to sign the response
as the certificate in question?  The later part of the section indicat= es this as a requirement.  
In that case, why not make this explicit like the OCSP Responder.
You are correct: I have added:
In the former case, the CA MUST use the same key as the one that was
used to issue the target certificate.

Section 3.1.3, First paragraph, the rational for CA certificates to have digital signature bit set because
they sign OCSP certificates is incorrect.  May be what you mean is that a CA that signs OCSP responses
needs to have digital signature bit set in its own certificate (i.e., the certificate for which the CA is the subject).

Oups! The text was:

Therefore the digitalSignature bit in the keyUsage extension MUST
be set.

Note 1: Since the CA issues certificates, the keyCertSign bit MUST also
     be set.

Note 2: If the CA supports CRLs, in particular to revoke the
     certificate of the OCSP Responders, then the cRLSign bit, the
     digitalSignature bit and the keyCertSig bit MUST be set.

I have changed it into:

Therefore the keyCertSign bit in the keyUsage extension MUST be set.
<= br> If the CA supports CRLs, in particular to revoke the certificate of
the OCSP Responders, then both the cRLSign bit and the keyCertSig
bit MUST be set.

Section 3.1.3, Note 2, Again there is no requirement for digital signature bit to be set just because the CA signs
certificates and CRLs. =

You are correct. See the correction proposed above.
=
Section 3.2: It not clear which accessLocation is being referred to here (cAissuers or OCSP).  If this is OCSP,
the RFC is overly implementation specific.  A CA can use the same OCSP location and sign the response with
appropriate key and include the appropriate CA certificate without having to change the OCSP pointer.

Section 3.2 addresses the case of CA that directly supports an OCSP service= and which performs a key rollover.  
If the CA key changes, the OCSP location must change since it is only possi= ble use a single key to sign the OCSP
responses. Nevertheless, I take your other point to be more specific about the accessLocation.
The point is addressed later on in another comment from you.

General: The I-D does not address how the CA deals with the situation when status of multiple certificates issued by the CA,
but using different keys is requested.  May be the restriction in 3.2 is used to ensure that such situation does not occur.  
If so, a short discussion would be helpful.

Your comment is related to section 4.3.1.1. (“Processing by a CA acti= ng as an OCSP responder”).
The case is already addressed with the following text:

For each target certificate, the OCSP responder SHALL verify whether
both the hash of the issuer's DN and the hash of the issuer public
key which are present in the request match respectively with the DN
and the hash of the public key of contained in an entry from the
list of entries maintained by this OCSP responder.

When there is no match, then the OCSP responder SHALL indicate the
"unknown" status and proceed with the next target certificate from
the OCSP request.

General: It not clear which accessLocation is being referred to in most places.
It would be worth stating that it refers to OCSP in all cases unless otherw= ise stated.

I have added a note after the first occurrence of the word in section 3.1.1= .

Note: accessLocation is mentioned in several places of this document.
   It refers in all cases to the accessLocation field that is present
   in an AIA extension field to designate the location of the OCSP
   responder.  In that case, the accessMethod field contain= s the
   id-ad-ocsp OID.<= /font>

Section 3.3.2 does not fully and explicitly cover the most common implement= ation I have seen and that is short life certificates.  
In that scenario, the CA needs to continue to issue the OCSP Responder certificate using the old CA key until all the certificates
issued by the CA using the old key and for which the OCSP Responder is authoritative expire.  
The text in 3.3.3 can form a model for this when CA rekeys and OCSP Respond= er has the old keys.

The text in section 3.3.2 does not say what you say. Please be more specifi= c or since the text is short, provide an alternative
<= br> Section 3.3.3, the last sentence is not desirable and can cause problems with some implementations.
It is perfectly ok for a Responder to change its key independent of certifi= cate it is authoritative for.  
Note that OCSP field in a issue certificate cannot be changed just because the Responder rekyed,
be it routine or due to loss or compromise of Responder key.

The text in section 3.3.3 does not say what you say. Please be more specifi= c or since the text is short, provide an alternative.
=
Section 3.4, last paragraph, I would think that expiration checking need not be part of OCSP client.  
Expiration checking should come under 5280 certificate validation.
<= br> The text was:

For each candidate certificate, the OCSP client SHALL verify that
the current time is within the validity period of the target
certificate.  If this is not the case, the candidate certificate
SHALL be discarded.

I have changed it into;

Note:  For each candidate certificate, when performing the path
    validation algorithm, the OCSP client will verify that the
    current time is within the validity period of the target
    certificate.  Thus, certificates which are outside their
    validity period will not be included in the request or will
    be rejected later on by the OCSP responder.

Section 4.1, We should dilute two CAs “never have the same issuerKeyH= ash” to something more akin
to statistically infeasible.

The text was:

   Two CAs will never, however, have the same public key unless the
   CAs either explicitly decided to share their private key, or the
   key of one of the CAs was compromised.

I have changed it into:

   However, it is statistically infeasible that two CAs use the same
   public key unless the CAs either explicitly decided to share
   their private key, or the key of one of the CAs was compromis= ed.

Titles of subsections under 4.3 could stand improvements.  Responders process request and produce response;
they do not process responses.  Clients process responses.

= The titles were:

  4.3. Response processing
    4.3.1. Response processing by OCSP servers
      4.3.1.1. Processing by a CA acting as an OCSP respond= er
      4.3.1.2. Processing by an OCSP Responder     4.3.2. Response processing by an OCSP client

I have changed them into:

  4.3. Processing of requests and responses
    4.3.1. Request processing by OCSP servers
      4.3.1.1. Processing by a CA acting as an OCSP respond= er
      4.3.1.2. Processing by an OCSP Responder
    4.3.2. Response processing by an OCSP client

Section 4.3.1.1, The entry should contain method used to gain access and sign just like the text in 4.3.1.2
as opposed to the private key.  In other words, align the two texts for accessing and using private key
to sign OCSP responses.

Both sections have been aligned.

Section 4.3.1,1, page 18 “defined in entry” could be misinterpr= eted as method define in request entry.

I don’t think that a change is necessary, since it uses the term R= 20;for each target certificate” and the entry thus
refers to one of the entries from the tables of entries advertised at the beginning of the section.
If you believe that a change is necessary, would you be able to make a proposal ?

Section 4.3.1.2, Again the same comment, for the delegated OCSP Responder, changing the URL
when key is changed is not required and breaks many implementations and hence is unacceptable. =

Would you be able to be more specific, since I don’t see that the tex= t states what you mean ? =

Section 4.3.2, the check for thisUpdate is flawed since this value may be derived from CRL even for responses
that are not pre-generated and hence can be hours or days off depending on CRL issuance frequency,
It is better to replace it with producedAt field in the response whether it is related to current time or time in the past.

Good catch !

The text has been changed into :

If the checking time is the current time, and if no nonce has been
used in the request, OCSP clients MUST check that the producedAt=
field is within a time window that is "close enough" to the current
time.

If the checking time is a time in the past, verifiers MUST check
that the producedAt field is in accordance with the verification
rules (e.g. close and/or after the date of a time-stamp token).

Section 4,3,2 is missing processing signature on the response and processin= g response extension.

I don’t understand your request about “missing processing signa= ture on the response”, since this point is addressed
under STEP 2. If you believe that a change is necessary, would you be able to be more specific ? <= font size=3D"3" face=3D"Arial">

Processing response extension is only covered for singleExtensions when the criticality flag is set and
the extension is not understood. So you are correct to request additional text to handle the other cases.

The following text has been added for the processing of responseExtensions:=

OCSP clients or verifiers SHALL check if the response contains a
critical responseExtensions. If such an extension is found and is
recognized, it MUST be processed.  If such an extension is found and
is not recognized, the whole OCSP response MUST be considered as
invalid.

The following text has been added for the processing of singleExtensions:

If checks are successful, then OCSP clients MUST process the
singleExtensions field, if it is present.

If the criticality flag is set and the extension is not understood,
then the status of the certificate shall be "unknown" and proceed to
step 3.  Otherwise, proceed to step 2.

If the extension is understood, then the extension MUST be
processed.  According to its content proceed either to step 2 or to
step 3.

Section 5.5: Replay attack is also possible when not using pre-computed responses.

I have added in new section with the following text:

5.7. Other replay attacks

As already mentioned in section 5.5, replay attacks are possible
using precomputed responses.  Replay attacks are also possible when
no nonce is being used in the OCSP request and the time window
mentioned in section 4.3.2 (STEP 1)is too large.
General: Removal of locally trusted Responder from the I-D is unacceptable.=

The intent was not to remove the “locally trusted Responder”. N= evertheless, the current text has been improved
in several places. For example, in the introduction, I have added:

   The term “locally trusted Responder” is used to d= esignate an OCSP
   responder that is trusted using local rules.

In section 2.2, the text now states:

A response message MUST be signed either by a certificate's issuer,
by an authorized OCSP Responder or according to local rules.

In the first case, the CA MUST use the same key as the one that was
used to issue the target certificate.

In the second case, the CA MUST explicitly designate the OCSP
Responder by issuing an OCSP certificate to the OCSP Responder.
OCSP signing delegation SHALL be indicated by the inclusion of
id-kp-OCSPSigning in an extendedKeyUsage certificate extension
included in the OCSP response signer's certificate.  This
certificate MUST be issued directly by the CA and under the same key
that was used to issue the target certificate.

For these two cases, systems or applications that rely on OCSP
responses MUST be capable of detecting and enforcing use of the
id-ad-ocspSigning value as described above.

In the third case, the OCSP client uses a locally trusted Responder.
The key used to sign OCSP responses may be directly trusted or be a
key contained in an OCSP certificate which is verified according to
local rules, instead of the rules detailed in this document.

In section I have changed the following text :

The OCSP certificate SHALL be signed by the CA issuing private key
which corresponds to the issuing CA public key that is in this
entry, unless some specific rules are agreed between the OCSP
Responder and OCSP clients.  In that later case, the OCSP
certificate MAY be signed by a different entity.

into:

The OCSP certificate SHALL be signed by the CA issuing private key
which corresponds to the issuing CA public key that is in this
entry, unless some specific rules are agreed between the OCSP
Responder and OCSP clients.  In that later case, which corresponds
to the case of a locally trusted Responder, the OCSP certificate MAY
be signed by a different entity.

There is now also a completely new section: 4.3.1.3, called “Processi= ng by a locally trusted Responder”.

When reviewing the text, I found that, in section 4.3.1.2, the list only mentioned:

  - the method(s) used to obtain the revocation status of the
    certificates issued under that CA issuing public key,=
In practice, an OCSP responder may not be responsible for all the certifica= tes issued by a CA.
So it also needs to know which subset of the certificates issued by each CA it is responsible for.

Thus I have changed the text into:

  - the method(s) used to know for which subset of certificates
    issued by the CA it is responsible for,

  - the method(s) used to obtain the revocation status of that
    subset of certificates issued under that CA issuing public key,


Denis

> A new Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>    Title         : X.509 Internet Public= Key Infrastructure Online
>                    C= ertificate Status Protocol - OCSP
>    Author(s)     : D. Pinkas
>    Filename      : draft-pinkas-rfc2560bis >    Pages         : 41
>    Date          : Aug. 27, 2012
>    
>   This document specifies a protocol useful in determining the current
>   status of a digital certificate without requiring CRLs.  A= dditional
>   mechanisms addressing PKIX operational requirements are specifi= ed in
>   separate documents. This document obsoletes RFC 2560 and RFC 6277.
>
> A URL for this Internet-Draft is:
> http://www.i= etf.org/internet-drafts/draft-pinkas-rfc2560bis-00.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.
>
> <ftp://ftp.ietf.o= rg/internet-drafts/draft-pinkas-rfc2560bis>
>
> A few explanations about the content of draft-ietf-pinkas-rfc2560bis-0= 0.
>
> 25 changes are indicated at the beginning of the document.
> I will only mention a few of them:
>
> A - Explanations were missing to describe:
>
>      - the building of a request by an OCSP client,
>      - the processing of a request by an OCSP server,
>      - the building of a response  by an OCSP server, and
>      - the processing of a response by an OCSP client.
>
> These explanations have been added.
>
> B - Explanations were missing to address CA key rollover and OCSP
>     key rollover. These explanations have been added.
>
> C - Backwards compatibility has been addressed in the following way:
>
>       1) An OCSP response by be signed either by a CA or by an OCSP Responder.
>
>       2) Besides local configuration settings which are optional,
>          only two cases SHALL be supported by OCSP clients (and thus OCSP servers)
>          as explained below.
>
>        The key to be used to verify a SingleRespon= se (within a
>        BasicOCSPResponse) MUST:
>
>           (1) either be the same key that the one used to sign the
>               target certificate, >
>           (2) or be the public key from an OCSP responder that is
>               contained in an OCSP certificate that has been signed by the same key
>               that the one used to sign the target certificate.
>    .
> The text allows to use the same general processing for a few other
> cases, since "escape"  sentences are provided to allow for these other cases,
> but only using "local configuration settings".
>
> This means in particular that the Identrust model may be supported
> and that the "several many cases" that were detailed in the annexes f
> from draft -04 from David Cooper and Stefan Santesson (but which were not
> interoperable with most current implementations) can take benefit of the description
> of the general processing.
>
> Denis
_______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/m= ailman/listinfo/pkix
--B_3432721091_2028510-- From hotz@jpl.nasa.gov Wed Oct 10 13:15:21 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBB121F859F for ; Wed, 10 Oct 2012 13:15:21 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tL2wBOSntpMS for ; Wed, 10 Oct 2012 13:15:20 -0700 (PDT) Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.109]) by ietfa.amsl.com (Postfix) with ESMTP id AECD021F8534 for ; Wed, 10 Oct 2012 13:15:20 -0700 (PDT) Received: from dhcp-128-149-183-211.jpl.nasa.gov (dhcp-128-149-183-211.jpl.nasa.gov [128.149.183.211]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q9AKFEul026411 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Wed, 10 Oct 2012 13:15:15 -0700 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: "Henry B. Hotz" In-Reply-To: <00fe01cda657$2003fbf0$600bf3d0$@ditenity.com> Date: Wed, 10 Oct 2012 13:15:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <506B154F.3080501@bbn.com> <506C4D25.6090601@bbn.com> <655F8F68-F5EA-42EA-9CCA-5AFD1627A48D@vigilsec.com> <506C7787.4090900@bbn.com> <9FF53209-599C-4F33-AA2B-36AEFD8007AF@vigilsec.com> <506EA763.5060001@bull.net> <00fe01cda657$2003fbf0$600bf3d0$@ditenity.com> To: Piyush Jain X-Mailer: Apple Mail (2.1085) X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: pkix@ietf.org Subject: Re: [pkix] 5280bis CRL problem poll results X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 20:15:21 -0000 It makes no sense to me that a single CRL *entry* extension could cause = the entire CRL to be rejected. On Oct 9, 2012, at 12:48 PM, Piyush Jain wrote: > Not that I support Denis=92s proposal but I also disagree with this > =93If there is an unrecognized CRL Entry Extension, then the replying = party cannot know whether the entry applies to a particular certificate = or not. Certificates are identified by an issuer and serial number. An = unrecognized CRL Entry Extension can change the issuer portion of the = tuple=94 > =20 > This is only true if there is a critical CRL extension which allows = such behavior. > If the RP can process the CRL extension, it should also process the = CRL entry extension which implies that the CRL entry extension is NOT = unrecognized. > If the RP cannot process the critical CRL extension, it=92ll reject = the CRL and the question of what to do with CRL entry with unrecognized = extensions becomes moot. > =20 > CRL extensions affect the whole CRLs. > CRL entry extensions affect only the CRL entry unless indicated by a = related CRL extension. > =20 > The point of contention is that 5280 says that whole CRL should be = rejected if an unrecognized critical CRL entry extension is encountered. > This is what we need to do=94 > - Make it explicit that that if RP processes IDP it should = also process =93Certificate Issuer=94 > - Change the text to say that RP should treat the certificate = referred to by a CRL entry with unknown critical extension as =93revoked=94= . (Same as X.509) > =20 > All these proposals are assuming that a future CRL entry extension can = affect the whole CRL on its own. I=92m sure if someone comes up with = such an extension he won=92t find any support in this WG or any other = WG. >=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 From stefan@aaa-sec.com Wed Oct 10 16:30:00 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3E821F849B for ; Wed, 10 Oct 2012 16:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.852 X-Spam-Level: X-Spam-Status: No, score=-100.852 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sr-eh60lA2vj for ; Wed, 10 Oct 2012 16:29:59 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id BA77D21F848F for ; Wed, 10 Oct 2012 16:29:58 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 1A6A7224B3CD for ; Thu, 11 Oct 2012 01:29:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id tmh9scuVDnTv for ; Thu, 11 Oct 2012 01:29:56 +0200 (CEST) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id D298D224BA39 for ; Thu, 11 Oct 2012 01:29:56 +0200 (CEST) Received: (qmail 54396 invoked from network); 10 Oct 2012 23:29:56 -0000 Received: from host-95-193-82-23.mobileonline.telia.com (HELO [192.168.43.205]) (stefan@fiddler.nu@[95.193.82.23]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 10 Oct 2012 23:29:56 -0000 User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Thu, 11 Oct 2012 01:29:56 +0200 From: Stefan Santesson To: "pkix@ietf.org" Message-ID: Thread-Topic: Request for agenda items In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3432763799_3908813" Subject: [pkix] Request for agenda items X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 23:30:00 -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_3432763799_3908813 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit All, PKIX has been rescheduled in Atlanta for a 1 hour session on Thursday afternoon. This because the AD has limited the meeting to focus on finalising adopted documents before WG closure. This means that we will not accept any presentations that is a request for new work. Presentations not focusing on current work will only be accepted if we have time over and if its inclusion in the meeting can be motivated. Please send me any requests for agenda items ASAP. /Stefan --B_3432763799_3908813 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
All,

PKIX has been rescheduled in Atlanta for a 1 hour session on Thursday afte= rnoon.
This because the AD has limited the meeting to focus on fin= alising adopted documents before WG closure.

This m= eans that we will not accept any presentations that is a request for new wor= k.

Presentations not focusing on current work will = only be accepted if we have time over and if its inclusion in the meeting ca= n be motivated.


Please send me any r= equests for agenda items ASAP.

/Stefan
&n= bsp;
--B_3432763799_3908813-- From denis.pinkas@bull.net Wed Oct 10 22:31:40 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52BB521F86D9 for ; Wed, 10 Oct 2012 22:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.168 X-Spam-Level: X-Spam-Status: No, score=-4.168 tagged_above=-999 required=5 tests=[AWL=2.080, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSpGGCaxflj6 for ; Wed, 10 Oct 2012 22:31:39 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 3D15E21F86CE for ; Wed, 10 Oct 2012 22:31:35 -0700 (PDT) Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id CF5184180DE; Thu, 11 Oct 2012 07:31:33 +0200 (CEST) Received: from [127.0.0.1] ([129.184.39.15]) by MSGC-007.bull.fr (Lotus Domino Release 8.5.3FP1) with ESMTP id 2012101107313312-660 ; Thu, 11 Oct 2012 07:31:33 +0200 Message-ID: <507659B2.8060909@bull.net> Date: Thu, 11 Oct 2012 07:31:30 +0200 From: Denis Pinkas Bull User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 11/10/2012 07:31:33, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 11/10/2012 07:31:33, Serialize complete at 11/10/2012 07:31:33 X-TNEFEvaluated: 1 Content-Type: multipart/alternative; boundary="------------010204040104040409010806" Cc: pkix Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 05:31:40 -0000 This is a multi-part message in MIME format. --------------010204040104040409010806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Stefan, You missed the point. Let me illustrate why using a simple scenario: OCSP Responder 1 receives delegation from CA x for the first 100.000=20 issued certificates. OCSP Responder 1 has only access to the revocation status of the first=20 100.000 issued certificates. The first 100.000 issued certificates contain url1 to locate OCSP=20 Responder 1. OCSP Responder 2 receives delegation from CA x for the next 100.000=20 issued certificates. OCSP Responder 2 has only access to the revocation status of the next=20 100.000 issued certificates. The next 100.000 issued certificates contains url2 to locate OCSP=20 Responder 2. A Relying Party (RP) uses url1 that is present in the target certificate=20 to query OCSP Responder 1. However, there is a man-in-the-middle-attack and this request in routed=20 to OCSP Responder 2. OCP2 responder 2 responds that it don't know the status of this certifica= te. The response from OCSP Responder 2 is routed back to the RP. The RP verifies that the response is indeed correctly signed. If the man-in-the-middle attack were not done, the RP would have known=20 that the certificate was either "revoked" or "good", since only OCSP Responder 1 knows it. Without the proposed extension, the protocol would provide incorrect=20 revocation status results. Denis Santesson a =E9crit : > Why do you need this at all? > > I don't see that this extension is required in order to split OCSP=20 > responding for chunks of certs. > You can point the client to the correct responder using information in=20 > the cert today. > The responder can determine if the requested vert is within it's=20 > handled portion of certs. > > Given that you trust the OCSP responder and the responder is honest,=20 > you will receive an appropriate response. > > So, why the extension? > > I can only imagine the extension being useful to detect if a responder=20 > responds outside of it's authority, but if the OCSP responder is=20 > dishonest, then you are screwed in any case. > > /Stefan > > > From: Santosh Chokhani > > Date: Friday, September 28, 2012 4:17 PM > To: "denis.pinkas@bull.net "=20 > >, pkix=20 > > > Subject: Re: [pkix] New Version Notification for=20 > draft-pinkas-2560bis-ocsp-locationcheck-00.txt > > Denis, > > I find the document in general acceptable. It definitely fills a ho= le. > > That said, it is effective both in general and against MITM attack > if the CA recognizes that the absence of the critical extension > you designed in the OCSP certificate means that the Responder is > authoritative for all certificates as long as the rest of the > requirements in RFC 2560 are met. > > Note that absence of IDP means that the CRL is full and complete.=20 > We do not have a similar statement in 2560 and this extension is > fully effective only if such is the case, i.e., by omitting this > extension, the CA implies that the Responder is authoritative for > all certificates signed using that CA key. > > We either need to impose this requirement, which while new, most > implementations I know impose or discuss it in the Security > Considerations section. > > *From:*pkix-bounces@ietf.org > [mailto:pkix-bounces@ietf.org] *On Behalf Of > *denis.pinkas@bull.net > *Sent:* Tuesday, September 25, 2012 11:12 AM > *To:* pkix > *Subject:* [pkix] New Version Notification for > draft-pinkas-2560bis-ocsp-locationcheck-00.txt > > To the list, > > The last comment from Santosh, triggered me to write a new draft > proposal directly related to 2560bis. > > This proposal allows to split the workload of an OCSP service from > a CA between several OCSP Responders. > This may be desirable for PKIs issuing a large number of > certificates (e.g. several hundred of thousands). > > Denis > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > A new version of I-D, draft-pinkas-2560bis-ocsp-locationcheck-00.tx= t > has been successfully submitted by Denis Pinkas and posted to the > IETF repository. > > Filename: draft-pinkas-2560bis-ocsp-locationcheck > Revision: 00 > Title: OCSP LocationCheck certificate extension > Update to OCSP > < draft-pinkas-2560bis-ocsp-locationcheck-00.txt = > > Creation date: 2012-09-25 > WG ID: Individual Submission > Number of pages: 6 > URL: > http://www.ietf.org/internet-drafts/draft-pinkas-2560bis-ocsp-locat= ioncheck-00.txt > Status: > http://datatracker.ietf.org/doc/draft-pinkas-2560bis-ocsp-locationc= heck > Htmlized: > http://tools.ietf.org/html/draft-pinkas-2560bis-ocsp-locationcheck-= 00 > > > Abstract: > > RFC 2560 [RFC2560] allows CAs to designate one or more OCSP > Responders for being responsible to provide the revocation status > of the certificates they issue under a given CA key. > > This document introduces a new feature that allows allows CAs to > split the workload between different sets of OCSP Responders in a > way that is analogous to the way CRLs can be split between > different sets of CRL issuers (using the cRLDistributionPoints > extension). > > This new feature allows a CA to designate one or more OCSP > Responders for being responsible to provide the revocation status > for a subset of the certificates they issue under a given CA key. > > This document defines a critical extension that may only be place= d > in an OCSP certificate and the way it shall be processed by OCSP > clients. > > The IETF Secretariat > > _______________________________________________ pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix=20 > --------------010204040104040409010806 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=ISO-8859-1
Stefan,

You missed the point. Let me illustrate why using a simple scenario:

OCSP Responder 1 receives delegation from CA x for the first 100.000 issued certificates.
OCSP Responder 1 has only access to the revocation status of the first 100.000 issued certificates.
The first 100.000 issued certificates contain url1 to locate OCSP Responder 1.

OCSP Responder 2 receives delegation from CA x for the next 100.000 issued certificates.
OCSP Responder 2 has only access to the revocation status of the next 100.000 issued certificates.
The next 100.000 issued certificates contains url2 to locate OCSP Responder 2.

A Relying Party (RP) uses url1 that is present in the target certificate to query OCSP Responder 1.
However, there is a man-in-the-middle-attack and this request in routed to OCSP Responder 2.
OCP2 responder 2 responds that it don't know the status of this certificate.
The response from OCSP Responder 2 is routed back to the RP.
The RP verifies that the response is indeed correctly signed.

If the man-in-the-middle attack were not done, the RP would have known that the certificate
was either "revoked" or "good", since only OCSP Responder 1 knows it.

Without the proposed extension, the protocol would provide incorrect revocation status results.

Denis



 Santesson a écrit :
Why do you need this at all?

I don't see that this extension is required in order to split OCSP responding for chunks of certs.
You can point the client to the correct responder using information in the cert today.
The responder can determine if the requested vert is within it's handled portion of certs.

Given that you trust the OCSP responder and the responder is honest, you will receive an appropriate response.

So, why the extension?

I can only imagine the extension being useful to detect if a responder responds outside of it's authority, but if the OCSP responder is dishonest, then you are screwed in any case.

/Stefan


From: Santosh Chokhani <SChokhani@cygnacom.com>
Date: Friday, September 28, 2012 4:17 PM
To: "denis.pinkas@bull.net" <denis.pinkas@bull.net>, pkix <pkix@ietf.org>
Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt

Denis,

 

I find the document in general acceptable.  It definitely fills a hole.

 

That said, it is effective both in general and against MITM attack if the CA recognizes that the absence of the critical extension you designed in the OCSP certificate means that the Responder is authoritative for all certificates as long as the rest of the requirements in RFC 2560 are met.

 

Note that absence of IDP means that the CRL is full and complete.  We do not have a similar statement in 2560 and this extension is fully effective only if such is the case, i.e., by omitting this extension, the CA implies that the Responder is authoritative for all certificates signed using that CA key.

 

We either need to impose this requirement, which while new, most implementations I know impose or discuss it in the Security Considerations section.

 

From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of denis.pinkas@bull.net
Sent: Tuesday, September 25, 2012 11:12 AM
To: pkix
Subject: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt

 

To the list,

The last comment from Santosh, triggered me to write a new draft proposal directly related to 2560bis.  

This proposal allows to split the workload of an OCSP service from a CA between several OCSP Responders.
This may be desirable for PKIs issuing a large number of certificates (e.g. several hundred of thousands).

Denis

==============================================================================================

A new version of I-D, draft-pinkas-2560bis-ocsp-locationcheck-00.txt
has been successfully submitted by Denis Pinkas and posted to the
IETF repository.

Filename:                 draft-pinkas-2560bis-ocsp-locationcheck
Revision:                 00
Title:                 OCSP LocationCheck certificate extension Update to OCSP
                  < draft-pinkas-2560bis-ocsp-locationcheck-00.txt >
Creation date:                  2012-09-25
WG ID:                                   Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-pinkas-2560bis-ocsp-locationcheck-00.txt
Status:          http://datatracker.ietf.org/doc/draft-pinkas-2560bis-ocsp-locationcheck
Htmlized:        http://tools.ietf.org/html/draft-pinkas-2560bis-ocsp-locationcheck-00


Abstract:

  RFC 2560 [RFC2560] allows CAs to designate one or more OCSP
  Responders for being responsible to provide the revocation status
  of the certificates they issue under a given CA key.

  This document introduces a new feature that allows allows CAs to
  split the workload between different sets of OCSP Responders in a
  way that is analogous to the way CRLs can be split between
  different sets of CRL issuers (using the cRLDistributionPoints
  extension).

  This new feature allows a CA to designate one or more OCSP
  Responders for being responsible to provide the revocation status
  for a subset of the certificates they issue under a given CA key.

  This document defines a critical extension that may only be placed
  in an OCSP certificate and the way it shall be processed by OCSP
  clients.

The IETF Secretariat

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

--------------010204040104040409010806-- From stefan@aaa-sec.com Wed Oct 10 22:40:36 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC03421F8625 for ; Wed, 10 Oct 2012 22:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.852 X-Spam-Level: X-Spam-Status: No, score=-100.852 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4HWB7BFyfcE for ; Wed, 10 Oct 2012 22:40:35 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 2589C21F86B2 for ; Wed, 10 Oct 2012 22:40:34 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 2EFBA224D448 for ; Thu, 11 Oct 2012 07:40:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Ty6OmcVDcxXl for ; Thu, 11 Oct 2012 07:40:32 +0200 (CEST) Received: from s328.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 3080E224D40A for ; Thu, 11 Oct 2012 07:40:32 +0200 (CEST) Received: (qmail 59321 invoked from network); 11 Oct 2012 05:40:31 -0000 Received: from host-95-193-55-82.mobileonline.telia.com (HELO [192.168.43.205]) (stefan@fiddler.nu@[95.193.55.82]) (envelope-sender ) by s328.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 11 Oct 2012 05:40:31 -0000 User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Thu, 11 Oct 2012 07:40:25 +0200 From: Stefan Santesson To: Denis Pinkas Bull Message-ID: Thread-Topic: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt In-Reply-To: <507659B2.8060909@bull.net> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3432786031_4235202" Cc: pkix Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 05:40:37 -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_3432786031_4235202 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Sorry, Still don't get it. In your example, the client receives a response that the responder is not authorised to provide information about the cert. So a man-in-the-middle can do a DoS attack. That is not new. /Stefan From: Denis Pinkas Bull Date: Thursday, October 11, 2012 7:31 AM To: Stefan Santesson Cc: Santosh Chokhani , pkix Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt > =20 > =20 > Stefan, > =20 > You missed the point. Let me illustrate why using a simple scenario: > =20 > OCSP Responder 1 receives delegation from CA x for the first 100.000 iss= ued > certificates. > OCSP Responder 1 has only access to the revocation status of the first > 100.000 issued certificates. > The first 100.000 issued certificates contain url1 to locate OCSP Respon= der > 1. > =20 > OCSP Responder 2 receives delegation from CA x for the next 100.000 issu= ed > certificates. > OCSP Responder 2 has only access to the revocation status of the next 10= 0.000 > issued certificates. > The next 100.000 issued certificates contains url2 to locate OCSP Respon= der > 2. > =20 > A Relying Party (RP) uses url1 that is present in the target certificate= to > query OCSP Responder 1. > However, there is a man-in-the-middle-attack and this request in routed = to > OCSP Responder 2. > OCP2 responder 2 responds that it don't know the status of this certific= ate. > The response from OCSP Responder 2 is routed back to the RP. > The RP verifies that the response is indeed correctly signed. > =20 > If the man-in-the-middle attack were not done, the RP would have known t= hat > the certificate=20 > was either "revoked" or "good", since only OCSP Responder 1 knows it. > =20 > Without the proposed extension, the protocol would provide incorrect > revocation status results. > =20 > Denis > =20 > =20 > =20 > Santesson a =E9crit : > =20 > =20 >> =20 >> Why do you need this at all? >> =20 >>=20 >> =20 >> =20 >> I don't see that this extension is required in order to split OCSP respo= nding >> for chunks of certs. >> =20 >> You can point the client to the correct responder using information in t= he >> cert today. >> =20 >> The responder can determine if the requested vert is within it's handled >> portion of certs. >> =20 >>=20 >> =20 >> =20 >> Given that you trust the OCSP responder and the responder is honest, you= will >> receive an appropriate response. >> =20 >>=20 >> =20 >> =20 >> So, why the extension? >> =20 >>=20 >> =20 >> =20 >> I can only imagine the extension being useful to detect if a responder >> responds outside of it's authority, but if the OCSP responder is dishone= st, >> then you are screwed in any case. >> =20 >>=20 >> =20 >> =20 >> /Stefan >> =20 >>=20 >> =20 >> =20 >>=20 >> =20 >> =20 >> From: Santosh Chokhani >> Date: Friday, September 28, 2012 4:17 PM >> To: "denis.pinkas@bull.net" , pkix >> Subject: Re: [pkix] New Version Notification for >> draft-pinkas-2560bis-ocsp-locationcheck-00.txt >> =20 >> =20 >>=20 >> =20 >> =20 >>> =20 >>> =20 >>> =20 >>> =20 >>>=20 >>> Denis, >>> =20 >>> =20 >>> =20 >>> I find the document in general acceptable. It definitely fills a hole. >>> =20 >>> =20 >>> =20 >>> That said, it is effective both in general and against MITM attack if t= he CA >>> recognizes that the absence of the critical extension you designed in t= he >>> OCSP certificate means that the Responder is authoritative for all >>> certificates as long as the rest of the requirements in RFC 2560 are me= t. >>> =20 >>> =20 >>> =20 >>> Note that absence of IDP means that the CRL is full and complete. We d= o not >>> have a similar statement in 2560 and this extension is fully effective = only >>> if such is the case, i.e., by omitting this extension, the CA implies t= hat >>> the Responder is authoritative for all certificates signed using that C= A >>> key. >>> =20 >>> =20 >>> =20 >>> We either need to impose this requirement, which while new, most >>> implementations I know impose or discuss it in the Security Considerati= ons >>> section. >>> =20 >>> =20 >>> =20 >>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >>> denis.pinkas@bull.net >>> Sent: Tuesday, September 25, 2012 11:12 AM >>> To: pkix >>> Subject: [pkix] New Version Notification for >>> draft-pinkas-2560bis-ocsp-locationcheck-00.txt >>> =20 >>> =20 >>> =20 >>> To the list,=20 >>> =20 >>> The last comment from Santosh, triggered me to write a new draft propo= sal >>> directly related to 2560bis. >>> =20 >>> This proposal allows to split the workload of an OCSP service from a C= A >>> between several OCSP Responders. >>> This may be desirable for PKIs issuing a large number of certificates = (e.g. >>> several hundred of thousands). >>> =20 >>> Denis=20 >>> =20 >>> =20 >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> =20 >>> A new version of I-D, draft-pinkas-2560bis-ocsp-locationcheck-00.txt >>> has been successfully submitted by Denis Pinkas and posted to the >>> IETF repository. >>> =20 >>> Filename: draft-pinkas-2560bis-ocsp-locationcheck >>> Revision: 00 >>> Title: OCSP LocationCheck certificate extension Update= to >>> OCSP=20 >>> < draft-pinkas-2560bis-ocsp-locationcheck-00.txt > >>> Creation date: 2012-09-25 >>> WG ID: Individual Submission >>> Number of pages: 6 >>> URL: =20 >>> http://www.ietf.org/internet-drafts/draft-pinkas-2560bis-ocsp-locationc= heck- >>> 00.txt=20 >>> >> -00.txt>=20 >>> Status: =20 >>> http://datatracker.ietf.org/doc/draft-pinkas-2560bis-ocsp-locationcheck >>> >>> Htmlized: =20 >>> http://tools.ietf.org/html/draft-pinkas-2560bis-ocsp-locationcheck-00 >>> >>> =20 >>> =20 >>> Abstract:=20 >>> =20 >>> RFC 2560 [RFC2560] allows CAs to designate one or more OCSP >>> Responders for being responsible to provide the revocation status >>> of the certificates they issue under a given CA key. >>> =20 >>> This document introduces a new feature that allows allows CAs to >>> split the workload between different sets of OCSP Responders in a >>> way that is analogous to the way CRLs can be split between >>> different sets of CRL issuers (using the cRLDistributionPoints >>> extension). >>> =20 >>> This new feature allows a CA to designate one or more OCSP >>> Responders for being responsible to provide the revocation status >>> for a subset of the certificates they issue under a given CA key. >>> =20 >>> This document defines a critical extension that may only be placed >>> in an OCSP certificate and the way it shall be processed by OCSP >>> clients. >>> =20 >>> The IETF Secretariat >>> =20 >>> =20 >>> =20 >>> _______________________________________________ pkix mailing list >>> pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix >> =20 > =20 > =20 --B_3432786031_4235202 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Sorry, Still don't get it.

In your example, the client receives a response that= the responder is not authorised to provide information about the cert.
So a man-in-the-middle can do a DoS attack. That is not new.

/Stefan


From: Denis Pinkas Bull <denis.pinkas@bull.net>
Da= te: Thursday, October 11, 2012 7:31 AM
To: Stefan Santesson <st= efan@aaa-sec.com>
Cc: Santo= sh Chokhani <SChokhani@cygnacom.c= om>, pkix <pkix@ietf.org>Subject: Re: [pkix] New Version Noti= fication for draft-pinkas-2560bis-ocsp-locationcheck-00.txt
Stefan,

You missed the point. Let me illustrate why using a simple scenario:

OCSP Responder 1 receives delegation from CA x for the first 100.000 issued certificates.
OCSP Responder 1 has only access to the revocation status of the first 100.000 issued certificates.
The first 100.000 issued certificates contain url1 to locate OCSP Responder 1.

OCSP Responder 2 receives delegation from CA x for the next 100.000 issued certificates.
OCSP Responder 2 has only access to the revocation status of the next 100.000 issued certificates.
The next 100.000 issued certificates contains url2 to locate OCSP Responder 2.

A Relying Party (RP) uses url1 that is present in the target certificate to query OCSP Responder 1.
However, there is a man-in-the-middle-attack and this request in routed to OCSP Responder 2.
OCP2 responder 2 responds that it don't know the status of this certificate.
The response from OCSP Responder 2 is routed back to the RP.
The RP verifies that the response is indeed correctly signed.

If the man-in-the-middle attack were not done, the RP would have known that the certificate
was either "revoked" or "good", since only OCSP Responder 1 knows it.

Without the proposed extension, the protocol would provide incorrect revocation status results.

Denis



 Santesson a =E9crit :
=
Why do you need this at all?

I don't see that this extension is required in order to split OCSP responding for chunks of certs.
You can point the client to the correct responder using information in the cert today.
The responder can determine if the requested vert is within it's handled portion of certs.

Given that you trust the OCSP responder and the responder is honest, you will receive an appropriate response.

So, why the extension?

I can only imagine the extension being useful to detect if a responder responds outside of it's authority, but if the OCSP responder is dishonest, then you are screwed in any case.

/Stefan


From: Santosh Chokhani <SChokhani@cygnacom.com>
Date: Friday, September 28, 2012 4:17 PM
To: "denis.pinkas@bull.net" <denis.pinkas@bull.net>, pkix <pk= ix@ietf.org>
Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt

Denis,

 

I find the document in gen= eral acceptable.  It definitely fills a hole.

 

That said, it is effective= both in general and against MITM attack if the CA recognizes that the absence of the critical extension you designed in the OCSP certificate means that the Responder is authoritative for all certificates as long as the rest of the requirements in RFC 2560 are met.

 

Note that absence of IDP m= eans that the CRL is full and complete.  We do not have a similar statement in 2560 and this extension is fully effective only if such is the case, i.e., by omitting this extension, the CA implies that the Responder is authoritative for all certificates signed using that CA key.

 

We either need to impose t= his requirement, which while new, most implementations I know impose or discuss it in the Security Considerations section.

 

From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of denis.pinkas@bull.net
Sent: Tuesday, September 25, 2012 11:12 AM
To: pkix
Subject: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt

 

To the list,

The last comment from Santosh, triggered me to write a new draft proposal directly related to 2560bis.  

This proposal allows to split the workload of an OCSP service from a CA between several OCSP Responders.
This may be desirable for PKIs issuing a large number of certificates (e.g. several hundred of thousands).

Denis

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

A new version of I-D, draft-pinkas-2560bis-ocsp-locationcheck-00.txt has been successfully submitted by Denis Pinkas and posted to the
IETF repository.

Filename:            =     draft-pinkas-2560bis-ocsp-locationcheck
Revision:            =     00
Title:             &n= bsp;   OCSP LocationCheck certificate extension Update to OCSP
              &n= bsp;   < draft-pinkas-2560bis-ocsp-locationcheck-00.txt >
Creation date:           &= nbsp;      2012-09-25
WG ID:             &n= bsp;                     Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-pinkas-2560bis-ocsp-locatio= ncheck-00.txt
Status:          http://da= tatracker.ietf.org/doc/draft-pinkas-2560bis-ocsp-locationcheck
Htmlized:        http://tools.iet= f.org/html/draft-pinkas-2560bis-ocsp-locationcheck-00


Abstract:

  RFC 2560 [RFC2560] allows CAs to designate o= ne or more OCSP
  Responders for being responsible to provide the revocation status
  of the certificates they issue under a given= CA key.

  This document introduces a new feature that allows allows CAs to
  split the workload between different sets of= OCSP Responders in a
  way that is analogous to the way CRLs can be= split between
  different sets of CRL issuers (using the cRLDistributionPoints
  extension).

  This new feature allows a CA to designate on= e or more OCSP
  Responders for being responsible to provide the revocation status
  for a subset of the certificates they issue under a given CA key.

  This document defines a critical extension that may only be placed
  in an OCSP certificate and the way it shall = be processed by OCSP
  clients.

The IETF Secretariat

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

--B_3432786031_4235202-- From denis.pinkas@bull.net Wed Oct 10 22:42:17 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED83C21F86EA for ; Wed, 10 Oct 2012 22:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.809 X-Spam-Level: X-Spam-Status: No, score=-3.809 tagged_above=-999 required=5 tests=[AWL=1.555, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKoS2W1jaxG9 for ; Wed, 10 Oct 2012 22:42:08 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 9C58D21F86E4 for ; Wed, 10 Oct 2012 22:42:07 -0700 (PDT) Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id EEDA031808B; Thu, 11 Oct 2012 07:42:06 +0200 (CEST) Received: from [127.0.0.1] ([129.184.39.15]) by MSGC-007.bull.fr (Lotus Domino Release 8.5.3FP1) with ESMTP id 2012101107420575-666 ; Thu, 11 Oct 2012 07:42:05 +0200 Message-ID: <50765C2C.3040806@bull.net> Date: Thu, 11 Oct 2012 07:42:04 +0200 From: Denis Pinkas Bull User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 11/10/2012 07:42:06, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 11/10/2012 07:42:07, Serialize complete at 11/10/2012 07:42:07 Content-Type: multipart/alternative; boundary="------------060204020504060609010404" Cc: "pkix@ietf.org" Subject: Re: [pkix] draft-pinkas-rfc2560bis-03 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 05:42:18 -0000 This is a multi-part message in MIME format. --------------060204020504060609010404 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed Stefan, Thank you for your comments. However, your first two comments are not specific enough to know portions of text you would like to be removed. Would you be able to be more specific ? On your third comment, you say: The distinction between OCSP responder, OCSP server and OCSP service is in this context confusing and adds nothing useful to an implementer on either side of the protocol. You are right to say that there is no need to make a difference between an OCSP server and an OCSP responder, and I can change this in the draft. However, the distinction between an OCSP service supported by one or more OCSP responders should be maintained. Denis > Denis, > > Posting my major comments on this draft: > > - This is a substantial rewrite of the original standard. There has been a > WG decision to limit changes to RFC 2560 to what is necessary to resolve > previous ambiguity. In many places, the text provided in your draft adds > confusion and adds ambiguity instead of removing them. > > - This is a protocol specification. That is, it defines the data elements > exchanged for the purpose of doing OCSP checks. It is NOT a system design > specification. Processing rules are only relevant if they have a direct > impact on the bits on the wire. > > - The distinction between OCSP responder, OCSP server and OCSP service is > in this context confusing and adds nothing useful to an implementer on > either side of the protocol. > > /Stefan > > From: > > Date: Tuesday, September 25, 2012 5:01 PM > To: Santosh Chokhani > > Cc: "pkix@ietf.org " > > Subject: [pkix] draft-pinkas-rfc2560bis-03 > > Santosh, > > This text change has been included in draft -03 which is now > available at : > > http://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-03.txt > > Denis > > > > De : Santosh Chokhani > > A : "denis.pinkas@bull.net " > > > Cc : "pkix@ietf.org " > > Date : 24/09/2012 18:21 > Objet : RE: draft-pinkas-rfc2560bis-02 > ------------------------------------------------------------------------ > > > > Denis, > > OK except a nit (replace "accessLocation field from" to > "accessLocation field of") > > *From:* denis.pinkas@bull.net > [mailto:denis.pinkas@bull.net] * > Sent:* Monday, September 24, 2012 2:17 AM* > To:* Santosh Chokhani* > Cc:* pkix@ietf.org * > Subject:* RE: draft-pinkas-rfc2560bis-02 > > Santosh, > > Your point is valid. Here is a proposed change to solve the issue. > > OLD TEXT: > > For a given URI value identifying the location of an OCSP > Responder, > the OCSP Responder SHALL only use one OCSP key pair value for a > given period of time. For example, it is acceptable for an OCSP > Responder to rekey, stop using the old key, and continue to use the > same URI while using the new key. > > NEW TEXT: > > An OCSP Responder key rollover does not affect the values of the > URIs that are placed in the accessLocation field from the target > certificates. One or more OCSP Responder MAY respond to an OCSP > request addressed at a given URI picked from the accessLocation > field from a target certificate. Each OCSP Responder MAY use a > different signing key, as long as it got an OCSP certificate > appropriate for that signing key and for the target certificate. > > Denis > > > > De : Santosh Chokhani <_SChokhani@cygnacom.com_ > > > A : "_denis.pinkas@bull.net_ " > <_denis.pinkas@bull.net_ > > Cc : "_pkix@ietf.org_ " <_pkix@ietf.org_ > > > Date : 21/09/2012 17:42 > Objet : RE: draft-pinkas-rfc2560bis-02 > > ------------------------------------------------------------------------ > > > > > Denis, > > Thanks. I am ok with your changes. > > One thing listed below is troubling me and I would like your and > others' opinion on it. > > While you have revised the text in Section 3.3.3 as I requested, > it is overly constraining and has been troublesome from the > beginning. The text I refer to is: "For a given URI value > identifying the location of an OCSP Responder, the OCSP Responder > SHALL only use one OCSP key pair value for a given period of time". > > While I can see how this assertion simplifies the sausage-making > of the standard and the data structures you spell out, it is > something these need not be applies in order for the OCSP to work. > It is generally a bad ideas in a standard to impose a constraint > that is not necessary for feasibility, security or > interoperability reasons. > > For example, one could have geographical load balancing and/or > geographicalredundancy for the URL and rather than porting the > same key, have differentkeys for the Servers. In that case, the > actual Server that got the request routed would sign the response. > > Another example, is the URL and the server map to the same machine > and it has multiple keys and can use any one of them. > > I do agree that there needs to be some constraint that specifies > that the server must be able to provide response to all the > queries it is authoritative for and meet the cryptographic binding > requirement. > I think we need to work the 3.3.3 language so that the constraint > is specified such that it does not prohibit valid architectures. > * > From:* _denis.pinkas@bull.net_ > [_mailto:denis.pinkas@bull.net_] * > Sent:* Friday, September 21, 2012 9:22 AM* > To:* Santosh Chokhani* > Cc:* _pkix@ietf.org_ * > Subject:* draft-pinkas-rfc2560bis-02 > > Santosh, > > Thank you for these new comments. I have one comment back and two > nits. > > You suggested to add text at the end of STEP 2, since the current > draft does not cover when the response is signed by the OCSP > Responder. > Your rational is quite true. However, your propose change does not > fit well. I have changed the text differently > > Please take a look at draft -02 which has been issued today._ > __http://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-02.txt_ > > First nit : > > PROPOSED TEXT: > > Note: The CA may need to continue issuing certificates to the OCSP > Responder using the old CA key until > all the certificates issued under the CA' old key for which the > OCSP Responder is authoritative *for expire*. > > NEW TEXT: > > Note: The CA may need to continue issuing certificates to the OCSP > Responder using the old CA key until > all the certificates issued under the CA' old key for which the > OCSP Responder is authoritative *have*expire*d*. > > Second nit : > > PROPOSED TEXT: > > For example, it is acceptable for an OCSP Responder to rekey, stop > using the old key, and continue to use > the *old* URI while using the new key" > > NEW TEXT: > > For example, it is acceptable for an OCSP Responder to rekey, stop > using the old key, and continue to use > the *same* URI while using the new key. > > Denis > > > > De : Santosh Chokhani <_SChokhani@cygnacom.com_ > > > A : "_denis.pinkas@bull.net_ " > <_denis.pinkas@bull.net_ > > Cc : "_pkix@ietf.org_ " <_pkix@ietf.org_ > > > Date : 18/09/2012 21:27 > Objet : RE: [pkix] draft-pinkas-rfc2560bis-00 > > > ------------------------------------------------------------------------ > > > > > > Denis, > > Thanks. Below are my updated recommended changes: > > Section 3.2 > > Add the following Note after the second dash: > > Note: The change in accessLocation is necessary when the CA rekeys > to meet the following constraints imposed by this standard: 1) a > BasicOCSPResponse can only be signed using a single private key; > 2) the response must be signed using the same CA key that was used > to sign the certificate in question; and 3) the OCSP response > needs to cover all the certificates queried in the OCSP request. > > Section 3.3.2: > > Add the following Note to the 3^rd and the last paragraph: > > Note: The CA may need to continue issuing certificates to the OCSP > Responder using the old CA key until all the certificates issued > under the CA' old key for which the OCSP Responder is > authoritative for expire. > > Section 3.3.3: > > OLD TEXT: > > "For a given URI value identifying the location of an OCSP > Responder, the OCSP Responder SHALL only use one OCSP key pair value." > > NEW TEXT: > > "For a given URI value identifying the location of an OCSP > Responder, the OCSP Responder SHALL only use one OCSP key pair > value for a given period of time. For example, it is acceptable > for an OCSP Responder to rekey, stop using the old key, and > continue to use the old URI while using the new key" > > Section 3.4: > > OLD TEXT: > > Note: For each candidate certificate, when performing the path > validation algorithm, the OCSP client will verify that the > current time is within the validity period of the target > certificate. Thus, certificates which are outside their > validity period will not be included in the request or will > be rejected later on by the OCSP responder. > > > NEW TEXT: > > Note: For each candidate certificate, when performing the path > validation algorithm, the OCSP client SHOULDverify that the > current time is within the validity period of the target > certificate. Thus, certificates which are outside their > validity period SHOULDnot be included in the request. > > Section 4.3.1.3: > > OLD TEXT: > > For each CA from which the locally trusted Responder has received a > delegation, the OCSP Responder SHALL maintain a list of entries. > > > NEW TEXT: > > For each CA forwhich the locally trusted Responder is > authoritative, the OCSP Responder SHALL maintain a list of entries. > > RATIONALE: > > The locally trusted responder need not have delegation from the CA > > Section 4.3.2: > > Add the following at the end of STEP 2: > > check whether the response is signed using the OCSP Responder key: > > If it is the case, then the revocation status of that > certificate as indicated in the certStatus field is > accepted and proceed to step 3. > > If it is not the case, then the revocation status of that > certificate is "unknown" and proceed to step 3. > > Rationale: Current draft does not cover when the response is > signed by the OCSP Responder > > Change S. Shokhani to S. Chokhani > > * > From:* _denis.pinkas@bull.net_ > [_mailto:denis.pinkas@bull.net_] * > Sent:* Monday, September 17, 2012 3:59 AM* > To:* Santosh Chokhani* > Cc:* _pkix@ietf.org_ * > Subject:* RE: [pkix] draft-pinkas-rfc2560bis-00 > > Santosh, > > Thank you for your very valuable comments. It took me "some time" > to process them. > It will take you "some time" to review them. :-) > > Since the comments and the changes were numerous, I have issued a > new draftwhich is available at:_ > __http://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-01.txt_ > > For Santosh in particular, see my responses below in lines. > > Denis, > > Thanks for this. My initial review indicates that this a very > good first draft. > Note that I did not review ASN.1 carefully (I assume it was copied > from the existing RFC). > > It was copied from the draft prepared by Stefan, but the ASN. 1 > module needs to be modified > since the syntax of nonce has been omitted. > > I have added: > > Nonce ::= OCTET STRING > > Since the syntax of the nocheck extension was missing, I have also > added: > > NoCheck ::= NULL > > In the introduction, I have also added: > > o Section 4.3.2 now indicates that the value of the nocheck > extension SHALL be NULL. > > The ASN.1 module that conforms to the 2002 version of ASN.1 which > may be found in Section 4 > of RFC5912 has another problem, since the nocheck extension has > been omitted. > > I have added: > > -- Certificate Extension > > ocsp-nocheck EXTENSION ::= { SYNTAX NULL > IDENTIFIED BY > id-pkix-ocsp-nocheck } > > This means that we cannot keep the same OID for the two ASN. 1 > modules and thus we will need two new ones. > > I have now included both syntaxes in draft -01. > > In the introduction, I have also added: > > o Annex B includes a new ASN.1 module using the 1988 syntax > since the syntax of nonce had been omitted. It also includes > a new ASN.1 module using the 2002 syntax since in the ASN.1 > module which may be found in Section 4 of RFC5912 the nocheck > extension had been omitted. > > I do have the following comment though: > > Section 2.2: When the CA is signing the response, should it not > also use the same key to sign the response > as the certificate in question? The later part of the section > indicates this as a requirement. > In that case, why not make this explicit like the OCSP Responder. > > You are correct: I have added: > > In the former case, the CA MUST use the same key as the one that was > used to issue the target certificate. > > Section 3.1.3, First paragraph, the rational for CA certificates > to have digital signature bit set because > they sign OCSP certificates is incorrect. May be what you mean is > that a CA that signs OCSP responses > needs to have digital signature bit set in its own certificate > (i.e., the certificate for which the CA is the subject). > > Oups! The text was: > > Therefore the digitalSignature bit in the keyUsage extension MUST > be set. > > Note 1: Since the CA issues certificates, the keyCertSign bit MUST > also > be set. > > Note 2: If the CA supports CRLs, in particular to revoke the > certificate of the OCSP Responders, then the cRLSign bit, the > digitalSignature bit and the keyCertSig bit MUST be set. > > I have changed it into: > > Therefore the keyCertSign bit in the keyUsage extension MUST be set. > > If the CA supports CRLs, in particular to revoke the certificate of > the OCSP Responders, then both the cRLSign bit and the keyCertSig > bit MUST be set. > > Section 3.1.3, Note 2, Again there is no requirement for digital > signature bit to be set just because the CA signs > certificates and CRLs. > > You are correct. See the correction proposed above. > > Section 3.2: It not clear which accessLocation is being referred > to here (cAissuers or OCSP). If this is OCSP, > the RFC is overly implementation specific. A CA can use the same > OCSP location and sign the response with > appropriate key and include the appropriate CA certificate without > having to change the OCSP pointer. > > Section 3.2 addresses the case of CA that directly supports an > OCSP serviceand which performs a key rollover. > If the CA key changes, the OCSP location must change since it is > only possible use a single key to sign the OCSP > responses. Nevertheless, I take your other point to be more > specific about the accessLocation. > The point is addressed later on in another comment from you. > > General: The I-D does not address how the CA deals with the > situation when status of multiple certificates issued by the CA, > but using different keys is requested. May be the restriction in > 3.2 is used to ensure that such situation does not occur. > If so, a short discussion would be helpful. > > Your comment is related to section 4.3.1.1. ("Processing by a CA > acting as an OCSP responder"). > The case is already addressed with the following text: > > For each target certificate, the OCSP responder SHALL verify whether > both the hash of the issuer's DN and the hash of the issuer public > key which are present in the request match respectively with the DN > and the hash of the public key of contained in an entry from the > list of entries maintained by this OCSP responder. > > When there is no match, then the OCSP responder SHALL indicate the > "unknown" status and proceed with the next target certificate from > the OCSP request. > > General: It not clear which accessLocation is being referred to in > most places. > It would be worth stating that it refers to OCSP in all cases > unless otherwise stated. > > I have added a note after the first occurrence of the word in > section 3.1.1. > > Note: accessLocation is mentioned in several places of this document. > It refers in all cases to the accessLocation field that is present > in an AIA extension field to designate the location of the OCSP > responder. In that case, the accessMethod field contains the > id-ad-ocsp OID. > > Section 3.3.2 does not fully and explicitly cover the most common > implementation I have seen and that is short life certificates. > In that scenario, the CA needs to continue to issue the OCSP > Responder certificate using the old CA key until all the certificates > issued by the CA using the old key and for which the OCSP > Responder is authoritative expire. > The text in 3.3.3 can form a model for this when CA rekeys and > OCSP Responder has the old keys. > > The text in section 3.3.2 does not say what you say. Please be > more specific or since the text is short, provide an alternative > > Section 3.3.3, the last sentence is not desirable and can cause > problems with some implementations. > It is perfectly ok for a Responder to change its key independent > of certificate it is authoritative for. > Note that OCSP field in a issue certificate cannot be changed just > because the Responder rekyed, > be it routine or due to loss or compromise of Responder key. > > The text in section 3.3.3 does not say what you say. Please be > more specific or since the text is short, provide an alternative. > > Section 3.4, last paragraph, I would think that expiration > checking need not be part of OCSP client. > Expiration checking should come under 5280 certificate validation. > > The text was: > > For each candidate certificate, the OCSP client SHALL verify that > the current time is within the validity period of the target > certificate. If this is not the case, the candidate certificate > SHALL be discarded. > > I have changed it into; > > Note: For each candidate certificate, when performing the path > validation algorithm, the OCSP client will verify that the > current time is within the validity period of the target > certificate. Thus, certificates which are outside their > validity period will not be included in the request or will > be rejected later on by the OCSP responder. > > Section 4.1, We should dilute two CAs "never have the same > issuerKeyHash" to something more akin > to statistically infeasible. > > The text was: > > Two CAs will never, however, have the same public key unless the > CAs either explicitly decided to share their private key, or the > key of one of the CAs was compromised. > > I have changed it into: > > However, it is statistically infeasible that two CAs use the same > public key unless the CAs either explicitly decided to share > their private key, or the key of one of the CAs was compromised. > > Titles of subsections under 4.3 could stand improvements. > Responders process request and produce response; > they do not process responses. Clients process responses. > > The titles were: > > 4.3. Response processing > 4.3.1. Response processing by OCSP servers > 4.3.1.1. Processing by a CA acting as an OCSP responder > 4.3.1.2. Processing by an OCSP Responder > 4.3.2. Response processing by an OCSP client > > I have changed them into: > > 4.3. Processing of requests and responses > 4.3.1. Request processing by OCSP servers > 4.3.1.1. Processing by a CA acting as an OCSP responder > 4.3.1.2. Processing by an OCSP Responder > 4.3.2. Response processing by an OCSP client > > Section 4.3.1.1, The entry should contain method used to gain > access and sign just like the text in 4.3.1.2 > as opposed to the private key. In other words, align the two > texts for accessing and using private key > to sign OCSP responses. > > Both sections have been aligned. > > Section 4.3.1,1, page 18 "defined in entry" could be > misinterpreted as method define in request entry. > > I don't think that a change is necessary, since it uses the term > "for each target certificate" and the entry thus > refers to one of the entries from the tables of entries advertised > at the beginning of the section. > If you believe that a change is necessary, would you be able to > make a proposal ? > > Section 4.3.1.2, Again the same comment, for the delegated OCSP > Responder, changing the URL > when key is changed is not required and breaks many > implementations and hence is unacceptable. > > Would you be able to be more specific, since I don't see that the > text states what you mean ? > > Section 4.3.2, the check for thisUpdate is flawed since this value > may be derived from CRL even for responses > that are not pre-generated and hence can be hours or days off > depending on CRL issuance frequency, > It is better to replace it with producedAt field in the response > whether it is related to current time or time in the past. > > Good catch ! > > The text has been changed into : > > If the checking time is the current time, and if no nonce has been > used in the request, OCSP clients MUST check that the producedAt > field is within a time window that is "close enough" to the current > time. > > If the checking time is a time in the past, verifiers MUST check > that the producedAt field is in accordance with the verification > rules (e.g. close and/or after the date of a time-stamp token). > > Section 4,3,2 is missing processing signature on the response and > processing response extension. > > I don't understand your request about "missing processing > signature on the response", since this point is addressed > under STEP 2. If you believe that a change is necessary, would you > be able to be more specific ? > > Processing response extension is only covered for singleExtensions > when the criticality flag is set and > the extension is not understood. So you are correct to request > additional text to handle the other cases. > > The following text has been added for the processing of > responseExtensions: > > OCSP clients or verifiers SHALL check if the response contains a > critical responseExtensions. If such an extension is found and is > recognized, it MUST be processed. If such an extension is found and > is not recognized, the whole OCSP response MUST be considered as > invalid. > > The following text has been added for the processing of > singleExtensions: > > If checks are successful, then OCSP clients MUST process the > singleExtensions field, if it is present. > > If the criticality flag is set and the extension is not understood, > then the status of the certificate shall be "unknown" and proceed to > step 3. Otherwise, proceed to step 2. > > If the extension is understood, then the extension MUST be > processed. According to its content proceed either to step 2 or to > step 3. > > Section 5.5: Replay attack is also possible when not using > pre-computed responses. > > I have added in new section with the following text: > > 5.7. Other replay attacks > > As already mentioned in section 5.5, replay attacks are possible > using precomputed responses. Replay attacks are also possible when > no nonce is being used in the OCSP request and the time window > mentioned in section 4.3.2 (STEP 1)is too large. > > General: Removal of locally trusted Responder from the I-D is > unacceptable. > > The intent was not to remove the "locally trusted Responder". > Nevertheless, the current text has been improved > in several places. For example, in the introduction, I have added: > > The term "locally trusted Responder" is used to designate an OCSP > responder that is trusted using local rules. > > In section 2.2, the text now states: > > A response message MUST be signed either by a certificate's issuer, > by an authorized OCSP Responder or according to local rules. > > In the first case, the CA MUST use the same key as the one that was > used to issue the target certificate. > > In the second case, the CA MUST explicitly designate the OCSP > Responder by issuing an OCSP certificate to the OCSP Responder. > OCSP signing delegation SHALL be indicated by the inclusion of > id-kp-OCSPSigning in an extendedKeyUsage certificate extension > included in the OCSP response signer's certificate. This > certificate MUST be issued directly by the CA and under the same key > that was used to issue the target certificate. > > For these two cases, systems or applications that rely on OCSP > responses MUST be capable of detecting and enforcing use of the > id-ad-ocspSigning value as described above. > > In the third case, the OCSP client uses a locally trusted Responder. > The key used to sign OCSP responses may be directly trusted or be a > key contained in an OCSP certificate which is verified according to > local rules, instead of the rules detailed in this document. > > In section I have changed the following text : > > The OCSP certificate SHALL be signed by the CA issuing private key > which corresponds to the issuing CA public key that is in this > entry, unless some specific rules are agreed between the OCSP > Responder and OCSP clients. In that later case, the OCSP > certificate MAY be signed by a different entity. > > into: > > The OCSP certificate SHALL be signed by the CA issuing private key > which corresponds to the issuing CA public key that is in this > entry, unless some specific rules are agreed between the OCSP > Responder and OCSP clients. In that later case, which corresponds > to the case of a locally trusted Responder, the OCSP certificate MAY > be signed by a different entity. > > There is now also a completely new section: 4.3.1.3, called > "Processing by a locally trusted Responder". > > When reviewing the text, I found that, in section 4.3.1.2, the > list only mentioned: > > - the method(s) used to obtain the revocation status of the > certificates issued under that CA issuing public key, > > In practice, an OCSP responder may not be responsible for all the > certificates issued by a CA. > So it also needs to know which subset of the certificates issued > by each CA it is responsible for. > > Thus I have changed the text into: > > - the method(s) used to know for which subset of certificates > issued by the CA it is responsible for, > > - the method(s) used to obtain the revocation status of that > subset of certificates issued under that CA issuing public key, > > > Denis > > > A new Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > Title : X.509 Internet PublicKey Infrastructure Online > > Certificate Status Protocol - OCSP > > Author(s) : D. Pinkas > > Filename : draft-pinkas-rfc2560bis > > Pages : 41 > > Date : Aug. 27, 2012 > > > > This document specifies a protocol useful in determining the > current > > status of a digital certificate without requiring CRLs. > Additional > > mechanisms addressing PKIX operational requirements are > specified in > > separate documents. This document obsoletes RFC 2560 and RFC 6277. > > > > A URL for this Internet-Draft is: > > _http://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-00.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. > > > > <_ftp://ftp.ietf.org/internet-drafts/draft-pinkas-rfc2560bis_> > > > > A few explanations about the content of > draft-ietf-pinkas-rfc2560bis-00. > > > > 25 changes are indicated at the beginning of the document. > > I will only mention a few of them: > > > > A - Explanations were missing to describe: > > > > - the building of a request by an OCSP client, > > - the processing of a request by an OCSP server, > > - the building of a response by an OCSP server, and > > - the processing of a response by an OCSP client. > > > > These explanations have been added. > > > > B - Explanations were missing to address CA key rollover and OCSP > > key rollover. These explanations have been added. > > > > C - Backwards compatibility has been addressed in the following > way: > > > > 1) An OCSP response by be signed either by a CA or by an > OCSP Responder. > > > > 2) Besides local configuration settings which are optional, > > only two cases SHALL be supported by OCSP clients (and > thus OCSP servers) > > as explained below. > > > > The key to be used to verify a SingleResponse (within a > > BasicOCSPResponse) MUST: > > > > (1) either be the same key that the one used to sign the > > target certificate, > > > > (2) or be the public key from an OCSP responder that is > > contained in an OCSP certificate that has been > signed by the same key > > that the one used to sign the target certificate. > > . > > The text allows to use the same general processing for a few other > > cases, since "escape" sentences are provided to allow for these > other cases, > > but only using "local configuration settings". > > > > This means in particular that the Identrust model may be supported > > and that the "several many cases" that were detailed in the > annexes f > > from draft -04 from David Cooper and Stefan Santesson (but which > were not > > interoperable with most current implementations) can take > benefit of the description > > of the general processing. > > > > Denis > _______________________________________________ pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > --------------060204020504060609010404 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=ISO-8859-1
Stefan,

Thank you for your comments.

However, your first two comments are not specific enough to know portions of text you would like to be removed.
Would you be able to be more specific ?

On your third comment, you say: The distinction between OCSP responder, OCSP server and OCSP service is
in this context confusing and adds nothing useful to an implementer on either side of the protocol.

You are right to say that there is no need to make a difference between an OCSP server and
an OCSP responder, and I can change this in the draft.

However, the distinction between an OCSP service supported by one or more OCSP responders should be maintained.

Denis

Denis,

Posting my major comments on this draft:

- This is a substantial rewrite of the original standard. There has been a
WG decision to limit changes to RFC 2560 to what is necessary to resolve
previous ambiguity. In many places, the text provided in your draft adds
confusion and adds ambiguity instead of removing them.

- This is a protocol specification. That is, it defines the data elements
exchanged for the purpose of doing OCSP checks. It is NOT a system design
specification. Processing rules are only relevant if they have a direct
impact on the bits on the wire.

- The distinction between OCSP responder, OCSP server and OCSP service is
in this context confusing and adds nothing useful to an implementer on
either side of the protocol.

/Stefan

From: <denis.pinkas@bull.net>
Date: Tuesday, September 25, 2012 5:01 PM
To: Santosh Chokhani <SChokhani@cygnacom.com>
Cc: "pkix@ietf.org" <pkix@ietf.org>
Subject: [pkix] draft-pinkas-rfc2560bis-03

Santosh,

This text change has been included in draft -03 which is now available at :

http://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-03.txt

Denis



De :        Santosh Chokhani <SChokhani@cygnacom.com>
A :        "denis.pinkas@bull.net" <denis.pinkas@bull.net>
Cc :        "pkix@ietf.org" <pkix@ietf.org>
Date :        24/09/2012 18:21
Objet :        RE: draft-pinkas-rfc2560bis-02



Denis,
 
OK except a nit (replace “accessLocation field from” to “accessLocation field of”)
 
From: denis.pinkas@bull.net [mailto:denis.pinkas@bull.net]
Sent: Monday, September 24, 2012 2:17 AM
To: Santosh Chokhani
Cc: pkix@ietf.org
Subject: RE: draft-pinkas-rfc2560bis-02
 
Santosh,

Your point is valid. Here is a proposed change to solve the issue.

OLD TEXT:

  For a given URI value identifying the location of an OCSP Responder,
  the OCSP Responder SHALL only use one OCSP key pair value for a
  given period of time.  For example, it is acceptable for an OCSP
  Responder to rekey, stop using the old key, and continue to use the
  same URI while using the new key.

NEW TEXT:

  An OCSP Responder key rollover does not affect the values of the
  URIs that are placed in the accessLocation field from the target
  certificates.  One or more OCSP Responder MAY respond to an OCSP
  request addressed at a given URI picked from the accessLocation
  field from a target certificate.  Each OCSP Responder MAY use a
  different signing key, as long as it got an OCSP certificate
  appropriate for that signing key and for the target certificate.

Denis



De :        Santosh Chokhani <SChokhani@cygnacom.com>
A :        "denis.pinkas@bull.net" <denis.pinkas@bull.net>
Cc :        "pkix@ietf.org" <pkix@ietf.org>
Date :        21/09/2012 17:42
Objet :        RE: draft-pinkas-rfc2560bis-02





Denis,
 
Thanks.  I am ok with your changes.
 
One thing listed below is troubling me and I would like your and others’ opinion on it.
 
While you have revised the text in Section 3.3.3 as I requested, it is overly constraining and has been troublesome from the beginning.  The text I refer to is: “For a given URI value identifying the location of an OCSP Responder, the OCSP Responder SHALL only use one OCSP key pair value for a given period of time”.
 
While I can see how this assertion simplifies the sausage-making of the standard and the data structures you spell out, it is something these need not be applies in order for the OCSP to work.   It is generally a bad ideas in a standard to impose a constraint that is not necessary for feasibility, security or interoperability reasons.
 
For example, one could have geographical load balancing and/or geographicalredundancy for the URL and rather than porting the same key, have differentkeys for the Servers.  In that case, the actual Server that got the request routed would sign the response.
 
Another example, is the URL and the server map to the same machine and it has multiple keys and can use any one of them.
 
I do agree that there needs to be some constraint that specifies that the server must be able to provide response to all the queries it is authoritative for and meet the cryptographic binding requirement.
I think we need to work the 3.3.3 language so that the constraint is specified such that it does not prohibit valid architectures.
 
From: denis.pinkas@bull.net [mailto:denis.pinkas@bull.net]
Sent: Friday, September 21, 2012 9:22 AM
To: Santosh Chokhani
Cc: pkix@ietf.org
Subject: draft-pinkas-rfc2560bis-02
 
Santosh,

Thank you for these new comments. I have one comment back and two nits.

You suggested to add text at the end of STEP 2, since the current draft does not cover when the response is signed by the OCSP Responder.
Your rational is quite true. However, your propose change does not fit well. I have changed the text differently

Please take a look at draft -02 which has been issued today.
http://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-02.txt

First nit :

PROPOSED TEXT:

Note: The CA may need to continue issuing certificates to the OCSP Responder using the old CA key until
all the certificates issued under the CA’ old key for which the OCSP Responder is authoritative for expire.

NEW TEXT:

Note: The CA may need to continue issuing certificates to the OCSP Responder using the old CA key until
all the certificates issued under the CA’ old key for which the OCSP Responder is authoritative have expired.

Second nit :

PROPOSED TEXT:

For example, it is acceptable for an OCSP Responder to rekey, stop using the old key, and continue to use
the old URI while using the new key”

NEW TEXT:

For example, it is acceptable for an OCSP Responder to rekey, stop using the old key, and continue to use
the same URI while using the new key.

Denis



De :        Santosh Chokhani <SChokhani@cygnacom.com>
A :        "denis.pinkas@bull.net" <denis.pinkas@bull.net>
Cc :        "pkix@ietf.org" <pkix@ietf.org>
Date :        18/09/2012 21:27
Objet :        RE: [pkix] draft-pinkas-rfc2560bis-00

 





Denis,

Thanks.  Below are my updated recommended changes:

Section 3.2

Add the following Note after the second dash:

Note: The change in accessLocation is necessary when the CA rekeys to meet the following constraints imposed by this standard: 1) a BasicOCSPResponse can only be signed using a single private key; 2) the response must be signed using the same CA key that was used to sign the certificate in question; and 3) the OCSP response needs to cover all the certificates queried in the OCSP request.

Section 3.3.2:

Add the following Note to the 3rd and the last paragraph:

Note: The CA may need to continue issuing certificates to the OCSP Responder using the old CA key until all the certificates issued under the CA’ old key for which the OCSP Responder is authoritative for expire.

Section 3.3.3:

OLD TEXT:

“For a given URI value identifying the location of an OCSP Responder, the OCSP Responder SHALL only use one OCSP key pair value.”

NEW TEXT:

“For a given URI value identifying the location of an OCSP Responder, the OCSP Responder SHALL only use one OCSP key pair value for a given period of time.  For example, it is acceptable for an OCSP Responder to rekey, stop using the old key, and continue to use the old URI while using the new key”

Section 3.4:

OLD TEXT:

Note:  For each candidate certificate, when performing the path
     validation algorithm, the OCSP client will verify that the
     current time is within the validity period of the target
     certificate.  Thus, certificates which are outside their
     validity period will not be included in the request or will
     be rejected later on by the OCSP responder.


NEW TEXT:

Note:  For each candidate certificate, when performing the path
     validation algorithm, the OCSP client SHOULD verify that the
     current time is within the validity period of the target
     certificate.  Thus, certificates which are outside their
     validity period SHOULD not be included in the request.

Section 4.3.1.3:

OLD TEXT:

 For each CA from which the locally trusted Responder has received a
 delegation, the OCSP Responder SHALL maintain a list of entries.


NEW TEXT:

For each CA for which the locally trusted Responder is authoritative, the OCSP Responder SHALL maintain a list of entries.

RATIONALE:

The locally trusted responder need not have delegation from the CA

Section 4.3.2:

Add the following at the end of STEP 2:

check whether the response is signed using the OCSP Responder key:

           If it is the case, then the revocation status of that
           certificate as indicated in the certStatus field is
           accepted and proceed to step 3.

           If it is not the case, then the revocation status of that
           certificate is "unknown" and proceed to step 3.

Rationale: Current draft does not cover when the response is signed by the OCSP Responder

Change S. Shokhani to S. Chokhani


From: denis.pinkas@bull.net [mailto:denis.pinkas@bull.net]
Sent: Monday, September 17, 2012 3:59 AM
To: Santosh Chokhani
Cc: pkix@ietf.org
Subject: RE: [pkix] draft-pinkas-rfc2560bis-00

Santosh,

Thank you for your very valuable comments. It took me "some time" to process them.
It will take you "some time" to review them. :-)

Since the comments and the changes were numerous, I have issued a new draftwhich is available at:
http://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-01.txt

For Santosh in particular, see my responses below in lines.

Denis,

Thanks for this.  My initial review indicates that this a very good first draft.  
Note that I did not review ASN.1 carefully (I assume it was copied from the existing RFC).

It was copied from the draft prepared by Stefan, but the ASN. 1 module needs to be modified
since the syntax of nonce has been omitted.

I have added:

Nonce ::= OCTET STRING

Since the syntax of the nocheck extension was missing, I have also added:

NoCheck ::= NULL

In the introduction, I have also added:

   o  Section 4.3.2 now indicates that the value of the nocheck
      extension SHALL be NULL.

The ASN.1 module that conforms to the 2002 version of ASN.1 which may be found in Section 4
of RFC5912 has another problem, since the nocheck extension has been omitted.

I have added:

--  Certificate Extension

ocsp-nocheck EXTENSION ::= { SYNTAX NULL
                                      IDENTIFIED BY
                                      id-pkix-ocsp-nocheck }

This means that we cannot keep the same OID for the two ASN. 1 modules and thus we will need two new ones.

I have now included both syntaxes in draft -01.

In the introduction, I have also added:

   o  Annex B includes a new ASN.1 module using the 1988 syntax
      since the syntax of nonce had been omitted.  It also includes
      a new ASN.1 module using the 2002 syntax since in the ASN.1
      module which may be found in Section 4 of RFC5912 the nocheck
      extension had been omitted.

I do have the following comment though:

Section 2.2: When the CA is signing the response, should it not also use the same key to sign the response
as the certificate in question?  The later part of the section indicates this as a requirement.  
In that case, why not make this explicit like the OCSP Responder.

You are correct: I have added:

In the former case, the CA MUST use the same key as the one that was
used to issue the target certificate.

Section 3.1.3, First paragraph, the rational for CA certificates to have digital signature bit set because
they sign OCSP certificates is incorrect.  May be what you mean is that a CA that signs OCSP responses
needs to have digital signature bit set in its own certificate (i.e., the certificate for which the CA is the subject).

Oups! The text was:

Therefore the digitalSignature bit in the keyUsage extension MUST
be set.

Note 1: Since the CA issues certificates, the keyCertSign bit MUST also
     be set.

Note 2: If the CA supports CRLs, in particular to revoke the
     certificate of the OCSP Responders, then the cRLSign bit, the
     digitalSignature bit and the keyCertSig bit MUST be set.

I have changed it into:

Therefore the keyCertSign bit in the keyUsage extension MUST be set.

If the CA supports CRLs, in particular to revoke the certificate of
the OCSP Responders, then both the cRLSign bit and the keyCertSig
bit MUST be set.

Section 3.1.3, Note 2, Again there is no requirement for digital signature bit to be set just because the CA signs
certificates and CRLs.

You are correct. See the correction proposed above.

Section 3.2: It not clear which accessLocation is being referred to here (cAissuers or OCSP).  If this is OCSP,
the RFC is overly implementation specific.  A CA can use the same OCSP location and sign the response with
appropriate key and include the appropriate CA certificate without having to change the OCSP pointer.

Section 3.2 addresses the case of CA that directly supports an OCSP serviceand which performs a key rollover.  
If the CA key changes, the OCSP location must change since it is only possible use a single key to sign the OCSP
responses. Nevertheless, I take your other point to be more specific about the accessLocation.
The point is addressed later on in another comment from you.

General: The I-D does not address how the CA deals with the situation when status of multiple certificates issued by the CA,
but using different keys is requested.  May be the restriction in 3.2 is used to ensure that such situation does not occur.  
If so, a short discussion would be helpful.

Your comment is related to section 4.3.1.1. (“Processing by a CA acting as an OCSP responder”).
The case is already addressed with the following text:

For each target certificate, the OCSP responder SHALL verify whether
both the hash of the issuer's DN and the hash of the issuer public
key which are present in the request match respectively with the DN
and the hash of the public key of contained in an entry from the
list of entries maintained by this OCSP responder.

When there is no match, then the OCSP responder SHALL indicate the
"unknown" status and proceed with the next target certificate from
the OCSP request.

General: It not clear which accessLocation is being referred to in most places.
It would be worth stating that it refers to OCSP in all cases unless otherwise stated.

I have added a note after the first occurrence of the word in section 3.1.1.

Note: accessLocation is mentioned in several places of this document.
   It refers in all cases to the accessLocation field that is present
   in an AIA extension field to designate the location of the OCSP
   responder.  In that case, the accessMethod field contains the
   id-ad-ocsp OID.

Section 3.3.2 does not fully and explicitly cover the most common implementation I have seen and that is short life certificates.  
In that scenario, the CA needs to continue to issue the OCSP Responder certificate using the old CA key until all the certificates
issued by the CA using the old key and for which the OCSP Responder is authoritative expire.  
The text in 3.3.3 can form a model for this when CA rekeys and OCSP Responder has the old keys.

The text in section 3.3.2 does not say what you say. Please be more specific or since the text is short, provide an alternative

Section 3.3.3, the last sentence is not desirable and can cause problems with some implementations.
It is perfectly ok for a Responder to change its key independent of certificate it is authoritative for.  
Note that OCSP field in a issue certificate cannot be changed just because the Responder rekyed,
be it routine or due to loss or compromise of Responder key.

The text in section 3.3.3 does not say what you say. Please be more specific or since the text is short, provide an alternative.

Section 3.4, last paragraph, I would think that expiration checking need not be part of OCSP client.  
Expiration checking should come under 5280 certificate validation.

The text was:

For each candidate certificate, the OCSP client SHALL verify that
the current time is within the validity period of the target
certificate.  If this is not the case, the candidate certificate
SHALL be discarded.

I have changed it into;

Note:  For each candidate certificate, when performing the path
    validation algorithm, the OCSP client will verify that the
    current time is within the validity period of the target
    certificate.  Thus, certificates which are outside their
    validity period will not be included in the request or will
    be rejected later on by the OCSP responder.

Section 4.1, We should dilute two CAs “never have the same issuerKeyHash” to something more akin
to statistically infeasible.

The text was:

   Two CAs will never, however, have the same public key unless the
   CAs either explicitly decided to share their private key, or the
   key of one of the CAs was compromised.

I have changed it into:

   However, it is statistically infeasible that two CAs use the same
   public key unless the CAs either explicitly decided to share
   their private key, or the key of one of the CAs was compromised.

Titles of subsections under 4.3 could stand improvements.  Responders process request and produce response;
they do not process responses.  Clients process responses.

The titles were:

  4.3. Response processing
    4.3.1. Response processing by OCSP servers
      4.3.1.1. Processing by a CA acting as an OCSP responder
      4.3.1.2. Processing by an OCSP Responder
    4.3.2. Response processing by an OCSP client

I have changed them into:

  4.3. Processing of requests and responses
    4.3.1. Request processing by OCSP servers
      4.3.1.1. Processing by a CA acting as an OCSP responder
      4.3.1.2. Processing by an OCSP Responder
    4.3.2. Response processing by an OCSP client

Section 4.3.1.1, The entry should contain method used to gain access and sign just like the text in 4.3.1.2
as opposed to the private key.  In other words, align the two texts for accessing and using private key
to sign OCSP responses.

Both sections have been aligned.

Section 4.3.1,1, page 18 “defined in entry” could be misinterpreted as method define in request entry.

I don’t think that a change is necessary, since it uses the term “for each target certificate” and the entry thus
refers to one of the entries from the tables of entries advertised at the beginning of the section.
If you believe that a change is necessary, would you be able to make a proposal ?

Section 4.3.1.2, Again the same comment, for the delegated OCSP Responder, changing the URL
when key is changed is not required and breaks many implementations and hence is unacceptable.

Would you be able to be more specific, since I don’t see that the text states what you mean ?

Section 4.3.2, the check for thisUpdate is flawed since this value may be derived from CRL even for responses
that are not pre-generated and hence can be hours or days off depending on CRL issuance frequency,
It is better to replace it with producedAt field in the response whether it is related to current time or time in the past.

Good catch !

The text has been changed into :

If the checking time is the current time, and if no nonce has been
used in the request, OCSP clients MUST check that the producedAt
field is within a time window that is "close enough" to the current
time.

If the checking time is a time in the past, verifiers MUST check
that the producedAt field is in accordance with the verification
rules (e.g. close and/or after the date of a time-stamp token).

Section 4,3,2 is missing processing signature on the response and processing response extension.

I don’t understand your request about “missing processing signature on the response”, since this point is addressed
under STEP 2. If you believe that a change is necessary, would you be able to be more specific ?

Processing response extension is only covered for singleExtensions when the criticality flag is set and
the extension is not understood. So you are correct to request additional text to handle the other cases.

The following text has been added for the processing of responseExtensions:

OCSP clients or verifiers SHALL check if the response contains a
critical responseExtensions. If such an extension is found and is
recognized, it MUST be processed.  If such an extension is found and
is not recognized, the whole OCSP response MUST be considered as
invalid.

The following text has been added for the processing of singleExtensions:

If checks are successful, then OCSP clients MUST process the
singleExtensions field, if it is present.

If the criticality flag is set and the extension is not understood,
then the status of the certificate shall be "unknown" and proceed to
step 3.  Otherwise, proceed to step 2.

If the extension is understood, then the extension MUST be
processed.  According to its content proceed either to step 2 or to
step 3.

Section 5.5: Replay attack is also possible when not using pre-computed responses.

I have added in new section with the following text:

5.7. Other replay attacks

As already mentioned in section 5.5, replay attacks are possible
using precomputed responses.  Replay attacks are also possible when
no nonce is being used in the OCSP request and the time window
mentioned in section 4.3.2 (STEP 1)is too large.

General: Removal of locally trusted Responder from the I-D is unacceptable.

The intent was not to remove the “locally trusted Responder”. Nevertheless, the current text has been improved
in several places. For example, in the introduction, I have added:

   The term “locally trusted Responder” is used to designate an OCSP
   responder that is trusted using local rules.

In section 2.2, the text now states:

A response message MUST be signed either by a certificate's issuer,
by an authorized OCSP Responder or according to local rules.

In the first case, the CA MUST use the same key as the one that was
used to issue the target certificate.

In the second case, the CA MUST explicitly designate the OCSP
Responder by issuing an OCSP certificate to the OCSP Responder.
OCSP signing delegation SHALL be indicated by the inclusion of
id-kp-OCSPSigning in an extendedKeyUsage certificate extension
included in the OCSP response signer's certificate.  This
certificate MUST be issued directly by the CA and under the same key
that was used to issue the target certificate.

For these two cases, systems or applications that rely on OCSP
responses MUST be capable of detecting and enforcing use of the
id-ad-ocspSigning value as described above.

In the third case, the OCSP client uses a locally trusted Responder.
The key used to sign OCSP responses may be directly trusted or be a
key contained in an OCSP certificate which is verified according to
local rules, instead of the rules detailed in this document.

In section I have changed the following text :

The OCSP certificate SHALL be signed by the CA issuing private key
which corresponds to the issuing CA public key that is in this
entry, unless some specific rules are agreed between the OCSP
Responder and OCSP clients.  In that later case, the OCSP
certificate MAY be signed by a different entity.

into:

The OCSP certificate SHALL be signed by the CA issuing private key
which corresponds to the issuing CA public key that is in this
entry, unless some specific rules are agreed between the OCSP
Responder and OCSP clients.  In that later case, which corresponds
to the case of a locally trusted Responder, the OCSP certificate MAY
be signed by a different entity.

There is now also a completely new section: 4.3.1.3, called “Processing by a locally trusted Responder”.

When reviewing the text, I found that, in section 4.3.1.2, the list only mentioned:

  - the method(s) used to obtain the revocation status of the
    certificates issued under that CA issuing public key,

In practice, an OCSP responder may not be responsible for all the certificates issued by a CA.
So it also needs to know which subset of the certificates issued by each CA it is responsible for.

Thus I have changed the text into:

  - the method(s) used to know for which subset of certificates
    issued by the CA it is responsible for,

  - the method(s) used to obtain the revocation status of that
    subset of certificates issued under that CA issuing public key,


Denis

> A new Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>    Title         : X.509 Internet PublicKey Infrastructure Online
>                    Certificate Status Protocol - OCSP
>    Author(s)     : D. Pinkas
>    Filename      : draft-pinkas-rfc2560bis
>    Pages         : 41
>    Date          : Aug. 27, 2012
>    
>   This document specifies a protocol useful in determining the current
>   status of a digital certificate without requiring CRLs.  Additional
>   mechanisms addressing PKIX operational requirements are specified in
>   separate documents. This document obsoletes RFC 2560 and RFC 6277.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-00.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.
>
> <ftp://ftp.ietf.org/internet-drafts/draft-pinkas-rfc2560bis>
>
> A few explanations about the content of draft-ietf-pinkas-rfc2560bis-00.
>
> 25 changes are indicated at the beginning of the document.
> I will only mention a few of them:
>
> A - Explanations were missing to describe:
>
>      - the building of a request by an OCSP client,
>      - the processing of a request by an OCSP server,
>      - the building of a response  by an OCSP server, and
>      - the processing of a response by an OCSP client.
>
> These explanations have been added.
>
> B - Explanations were missing to address CA key rollover and OCSP
>     key rollover. These explanations have been added.
>
> C - Backwards compatibility has been addressed in the following way:
>
>       1) An OCSP response by be signed either by a CA or by an OCSP Responder.
>
>       2) Besides local configuration settings which are optional,
>          only two cases SHALL be supported by OCSP clients (and thus OCSP servers)
>          as explained below.
>
>        The key to be used to verify a SingleResponse (within a
>        BasicOCSPResponse) MUST:
>
>           (1) either be the same key that the one used to sign the
>               target certificate,
>
>           (2) or be the public key from an OCSP responder that is
>               contained in an OCSP certificate that has been signed by the same key
>               that the one used to sign the target certificate.
>    .
> The text allows to use the same general processing for a few other
> cases, since "escape"  sentences are provided to allow for these other cases,
> but only using "local configuration settings".
>
> This means in particular that the Identrust model may be supported
> and that the "several many cases" that were detailed in the annexes f
> from draft -04 from David Cooper and Stefan Santesson (but which were not
> interoperable with most current implementations) can take benefit of the description
> of the general processing.
>
> Denis
_______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix

--------------060204020504060609010404-- From denis.pinkas@bull.net Wed Oct 10 22:53:09 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2106321F86E4 for ; Wed, 10 Oct 2012 22:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[AWL=1.937, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DhUnPmetnML9 for ; Wed, 10 Oct 2012 22:53:07 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 1AAF321F8697 for ; Wed, 10 Oct 2012 22:53:07 -0700 (PDT) Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id 516C731803A; Thu, 11 Oct 2012 07:53:06 +0200 (CEST) Received: from [127.0.0.1] ([129.184.39.15]) by MSGC-007.bull.fr (Lotus Domino Release 8.5.3FP1) with ESMTP id 2012101107530593-668 ; Thu, 11 Oct 2012 07:53:05 +0200 Message-ID: <50765EC0.9040705@bull.net> Date: Thu, 11 Oct 2012 07:53:04 +0200 From: Denis Pinkas Bull User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 11/10/2012 07:53:06, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 11/10/2012 07:53:06, Serialize complete at 11/10/2012 07:53:06 X-TNEFEvaluated: 1 Content-Type: multipart/alternative; boundary="------------020506040502000506090306" Cc: pkix Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 05:53:09 -0000 This is a multi-part message in MIME format. --------------020506040502000506090306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Stefan, As fas as I know, there are only three major status: "good", "revoked"=20 or "unknown". Error messages are: -- malformedRequest, -- internalError, -- tryLater, -- sigRequired, -- unauthorized. There is no response like: "the responder is not authorised to provide=20 information about the cert". In the example, the RP gets "unknown" (witha correct signature from the=20 OCSP responder), whereas it would have received either "good" or "revoked", if there had=20 been no attack. Denis > Sorry, Still don't get it. > > In your example, the client receives a response that the responder is=20 > not authorised to provide information about the cert. > So a man-in-the-middle can do a DoS attack. That is not new. > > /Stefan > > > From: Denis Pinkas Bull > > Date: Thursday, October 11, 2012 7:31 AM > To: Stefan Santesson > > Cc: Santosh Chokhani >, pkix > > Subject: Re: [pkix] New Version Notification for=20 > draft-pinkas-2560bis-ocsp-locationcheck-00.txt > > Stefan, > > You missed the point. Let me illustrate why using a simple scenario= : > > OCSP Responder 1 receives delegation from CA x for the first > 100.000 issued certificates. > OCSP Responder 1 has only access to the revocation status of the > first 100.000 issued certificates. > The first 100.000 issued certificates contain url1 to locate OCSP > Responder 1. > > OCSP Responder 2 receives delegation from CA x for the next > 100.000 issued certificates. > OCSP Responder 2 has only access to the revocation status of the > next 100.000 issued certificates. > The next 100.000 issued certificates contains url2 to locate OCSP > Responder 2. > > A Relying Party (RP) uses url1 that is present in the target > certificate to query OCSP Responder 1. > However, there is a man-in-the-middle-attack and this request in > routed to OCSP Responder 2. > OCP2 responder 2 responds that it don't know the status of this > certificate. > The response from OCSP Responder 2 is routed back to the RP. > The RP verifies that the response is indeed correctly signed. > > If the man-in-the-middle attack were not done, the RP would have > known that the certificate > was either "revoked" or "good", since only OCSP Responder 1 knows i= t. > > Without the proposed extension, the protocol would provide > incorrect revocation status results. > > Denis > > > > Santesson a =E9crit : >> Why do you need this at all? >> >> I don't see that this extension is required in order to split >> OCSP responding for chunks of certs. >> You can point the client to the correct responder using >> information in the cert today. >> The responder can determine if the requested vert is within it's >> handled portion of certs. >> >> Given that you trust the OCSP responder and the responder is >> honest, you will receive an appropriate response. >> >> So, why the extension? >> >> I can only imagine the extension being useful to detect if a >> responder responds outside of it's authority, but if the OCSP >> responder is dishonest, then you are screwed in any case. >> >> /Stefan >> >> >> From: Santosh Chokhani > > >> Date: Friday, September 28, 2012 4:17 PM >> To: "denis.pinkas@bull.net " >> >, pkix >> > >> Subject: Re: [pkix] New Version Notification for >> draft-pinkas-2560bis-ocsp-locationcheck-00.txt >> >> Denis, >> >> I find the document in general acceptable. It definitely >> fills a hole. >> >> That said, it is effective both in general and against MITM >> attack if the CA recognizes that the absence of the critical >> extension you designed in the OCSP certificate means that the >> Responder is authoritative for all certificates as long as >> the rest of the requirements in RFC 2560 are met. >> >> Note that absence of IDP means that the CRL is full and >> complete. We do not have a similar statement in 2560 and >> this extension is fully effective only if such is the case, >> i.e., by omitting this extension, the CA implies that the >> Responder is authoritative for all certificates signed using >> that CA key. >> >> We either need to impose this requirement, which while new, >> most implementations I know impose or discuss it in the >> Security Considerations section. >> >> *From:*pkix-bounces@ietf.org >> [mailto:pkix-bounces@ietf.org] *On Behalf Of >> *denis.pinkas@bull.net >> *Sent:* Tuesday, September 25, 2012 11:12 AM >> *To:* pkix >> *Subject:* [pkix] New Version Notification for >> draft-pinkas-2560bis-ocsp-locationcheck-00.txt >> >> To the list, >> >> The last comment from Santosh, triggered me to write a new >> draft proposal directly related to 2560bis. >> >> This proposal allows to split the workload of an OCSP service >> from a CA between several OCSP Responders. >> This may be desirable for PKIs issuing a large number of >> certificates (e.g. several hundred of thousands). >> >> Denis >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> >> A new version of I-D, >> draft-pinkas-2560bis-ocsp-locationcheck-00.txt >> has been successfully submitted by Denis Pinkas and posted to = the >> IETF repository. >> >> Filename: draft-pinkas-2560bis-ocsp-locationcheck >> Revision: 00 >> Title: OCSP LocationCheck certificate >> extension Update to OCSP >> < >> draft-pinkas-2560bis-ocsp-locationcheck-00.txt > >> Creation date: 2012-09-25 >> WG ID: Individual Submission >> Number of pages: 6 >> URL: >> http://www.ietf.org/internet-drafts/draft-pinkas-2560bis-ocsp-= locationcheck-00.txt >> Status: >> http://datatracker.ietf.org/doc/draft-pinkas-2560bis-ocsp-loca= tioncheck >> Htmlized: >> http://tools.ietf.org/html/draft-pinkas-2560bis-ocsp-locationc= heck-00 >> >> >> Abstract: >> >> RFC 2560 [RFC2560] allows CAs to designate one or more OCSP >> Responders for being responsible to provide the revocation >> status >> of the certificates they issue under a given CA key. >> >> This document introduces a new feature that allows allows >> CAs to >> split the workload between different sets of OCSP >> Responders in a >> way that is analogous to the way CRLs can be split between >> different sets of CRL issuers (using the cRLDistributionPoin= ts >> extension). >> >> This new feature allows a CA to designate one or more OCSP >> Responders for being responsible to provide the revocation >> status >> for a subset of the certificates they issue under a given >> CA key. >> >> This document defines a critical extension that may only be >> placed >> in an OCSP certificate and the way it shall be processed by >> OCSP >> clients. >> >> The IETF Secretariat >> >> _______________________________________________ pkix mailing >> list pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix=20 >> > --------------020506040502000506090306 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=ISO-8859-1
Stefan,

As fas as I know, there are only three major status: "good", "revoked" or "unknown".

Error messages are:

   -- malformedRequest,
   -- internalError,
   -- tryLater,
   -- sigRequired,
   -- unauthorized.

There is no response like: "the responder is not authorised to provide information about the cert".
In the example, the RP gets "unknown" (with a correct signature from the OCSP responder),
whereas it would have received either "good" or "revoked", if there had been no attack.

Denis

Sorry, Still don't get it.

In your example, the client receives a response that the responder is not authorised to provide information about the cert.
So a man-in-the-middle can do a DoS attack. That is not new.

/Stefan


From: Denis Pinkas Bull <denis.pinkas@bull.net>
Date: Thursday, October 11, 2012 7:31 AM
To: Stefan Santesson <stefan@aaa-sec.com>
Cc: Santosh Chokhani <SChokhani@cygnacom.com>, pkix <pkix@ietf.org>
Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt

Stefan,

You missed the point. Let me illustrate why using a simple scenario:

OCSP Responder 1 receives delegation from CA x for the first 100.000 issued certificates.
OCSP Responder 1 has only access to the revocation status of the first 100.000 issued certificates.
The first 100.000 issued certificates contain url1 to locate OCSP Responder 1.

OCSP Responder 2 receives delegation from CA x for the next 100.000 issued certificates.
OCSP Responder 2 has only access to the revocation status of the next 100.000 issued certificates.
The next 100.000 issued certificates contains url2 to locate OCSP Responder 2.

A Relying Party (RP) uses url1 that is present in the target certificate to query OCSP Responder 1.
However, there is a man-in-the-middle-attack and this request in routed to OCSP Responder 2.
OCP2 responder 2 responds that it don't know the status of this certificate.
The response from OCSP Responder 2 is routed back to the RP.
The RP verifies that the response is indeed correctly signed.

If the man-in-the-middle attack were not done, the RP would have known that the certificate
was either "revoked" or "good", since only OCSP Responder 1 knows it.

Without the proposed extension, the protocol would provide incorrect revocation status results.

Denis



 Santesson a écrit :
Why do you need this at all?

I don't see that this extension is required in order to split OCSP responding for chunks of certs.
You can point the client to the correct responder using information in the cert today.
The responder can determine if the requested vert is within it's handled portion of certs.

Given that you trust the OCSP responder and the responder is honest, you will receive an appropriate response.

So, why the extension?

I can only imagine the extension being useful to detect if a responder responds outside of it's authority, but if the OCSP responder is dishonest, then you are screwed in any case.

/Stefan


From: Santosh Chokhani <SChokhani@cygnacom.com>
Date: Friday, September 28, 2012 4:17 PM
To: "denis.pinkas@bull.net" <denis.pinkas@bull.net>, pkix <pkix@ietf.org>
Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt

Denis,

 

I find the document in general acceptable.  It definitely fills a hole.

 

That said, it is effective both in general and against MITM attack if the CA recognizes that the absence of the critical extension you designed in the OCSP certificate means that the Responder is authoritative for all certificates as long as the rest of the requirements in RFC 2560 are met.

 

Note that absence of IDP means that the CRL is full and complete.  We do not have a similar statement in 2560 and this extension is fully effective only if such is the case, i.e., by omitting this extension, the CA implies that the Responder is authoritative for all certificates signed using that CA key.

 

We either need to impose this requirement, which while new, most implementations I know impose or discuss it in the Security Considerations section.

 

From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of denis.pinkas@bull.net
Sent: Tuesday, September 25, 2012 11:12 AM
To: pkix
Subject: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt

 

To the list,

The last comment from Santosh, triggered me to write a new draft proposal directly related to 2560bis.  

This proposal allows to split the workload of an OCSP service from a CA between several OCSP Responders.
This may be desirable for PKIs issuing a large number of certificates (e.g. several hundred of thousands).

Denis

==============================================================================================

A new version of I-D, draft-pinkas-2560bis-ocsp-locationcheck-00.txt
has been successfully submitted by Denis Pinkas and posted to the
IETF repository.

Filename:                 draft-pinkas-2560bis-ocsp-locationcheck
Revision:                 00
Title:                 OCSP LocationCheck certificate extension Update to OCSP
                  < draft-pinkas-2560bis-ocsp-locationcheck-00.txt >
Creation date:                  2012-09-25
WG ID:                                   Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-pinkas-2560bis-ocsp-locationcheck-00.txt
Status:          http://datatracker.ietf.org/doc/draft-pinkas-2560bis-ocsp-locationcheck
Htmlized:        http://tools.ietf.org/html/draft-pinkas-2560bis-ocsp-locationcheck-00


Abstract:

  RFC 2560 [RFC2560] allows CAs to designate one or more OCSP
  Responders for being responsible to provide the revocation status
  of the certificates they issue under a given CA key.

  This document introduces a new feature that allows allows CAs to
  split the workload between different sets of OCSP Responders in a
  way that is analogous to the way CRLs can be split between
  different sets of CRL issuers (using the cRLDistributionPoints
  extension).

  This new feature allows a CA to designate one or more OCSP
  Responders for being responsible to provide the revocation status
  for a subset of the certificates they issue under a given CA key.

  This document defines a critical extension that may only be placed
  in an OCSP certificate and the way it shall be processed by OCSP
  clients.

The IETF Secretariat

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


--------------020506040502000506090306-- From stefan@aaa-sec.com Thu Oct 11 01:25:03 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D258721F8678 for ; Thu, 11 Oct 2012 01:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.852 X-Spam-Level: X-Spam-Status: No, score=-100.852 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2IOFR4dZ+3y for ; Thu, 11 Oct 2012 01:25:02 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id E867A21F8672 for ; Thu, 11 Oct 2012 01:25:01 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 0F37A224E448 for ; Thu, 11 Oct 2012 10:24:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id KQlh_lUnrSob for ; Thu, 11 Oct 2012 10:24:19 +0200 (CEST) Received: from s376.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 86A32224E432 for ; Thu, 11 Oct 2012 10:24:19 +0200 (CEST) Received: (qmail 99992 invoked from network); 11 Oct 2012 08:24:15 -0000 Received: from host-95-193-55-82.mobileonline.telia.com (HELO [192.168.43.205]) (stefan@fiddler.nu@[95.193.55.82]) (envelope-sender ) by s376.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 11 Oct 2012 08:24:15 -0000 User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Thu, 11 Oct 2012 10:24:05 +0200 From: Stefan Santesson To: Denis Pinkas Bull Message-ID: Thread-Topic: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt In-Reply-To: <50765EC0.9040705@bull.net> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3432795855_4848058" Cc: pkix Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 08:25:03 -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_3432795855_4848058 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable The "unauthorized" response seems suitable to me. "The response "unauthorized" is returned in cases where the client is not authorized to make this query to this server or the server is not capable o= f responding authoritatively (cf. [RFC5019], Section 2.2.3)" /Stefan From: Denis Pinkas Bull Date: Thursday, October 11, 2012 7:53 AM To: Stefan Santesson Cc: Santosh Chokhani , pkix Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt > =20 > =20 > Stefan, > =20 > As fas as I know, there are only three major status: "good", "revoked" o= r > "unknown". > =20 > Error messages are: > =20 > -- malformedRequest, > -- internalError, > -- tryLater, > -- sigRequired, > -- unauthorized. > =20 > There is no response like: "the responder is not authorised to provide > information about the cert". > In the example, the RP gets "unknown" (with a correct signature from the= OCSP > responder),=20 > whereas it would have received either "good" or "revoked", if there had= been > no attack. > =20 > Denis > =20 > =20 > =20 >> =20 >> Sorry, Still don't get it. >> =20 >>=20 >> =20 >> =20 >> In your example, the client receives a response that the responder is no= t >> authorised to provide information about the cert. >> =20 >> So a man-in-the-middle can do a DoS attack. That is not new. >> =20 >>=20 >> =20 >> =20 >> /Stefan >> =20 >>=20 >> =20 >> =20 >>=20 >> =20 >> =20 >> From: Denis Pinkas Bull >> Date: Thursday, October 11, 2012 7:31 AM >> To: Stefan Santesson >> Cc: Santosh Chokhani , pkix >> Subject: Re: [pkix] New Version Notification for >> draft-pinkas-2560bis-ocsp-locationcheck-00.txt >> =20 >> =20 >>=20 >> =20 >> =20 >>> =20 >>> =20 >>> =20 >>> Stefan, >>> =20 >>> You missed the point. Let me illustrate why using a simple scenario: >>> =20 >>> OCSP Responder 1 receives delegation from CA x for the first 100.000 i= ssued >>> certificates. >>> OCSP Responder 1 has only access to the revocation status of the first >>> 100.000 issued certificates. >>> The first 100.000 issued certificates contain url1 to locate OCSP Resp= onder >>> 1. >>> =20 >>> OCSP Responder 2 receives delegation from CA x for the next 100.000 is= sued >>> certificates. >>> OCSP Responder 2 has only access to the revocation status of the next >>> 100.000 issued certificates. >>> The next 100.000 issued certificates contains url2 to locate OCSP Resp= onder >>> 2. >>> =20 >>> A Relying Party (RP) uses url1 that is present in the target certifica= te to >>> query OCSP Responder 1. >>> However, there is a man-in-the-middle-attack and this request in route= d to >>> OCSP Responder 2. >>> OCP2 responder 2 responds that it don't know the status of this >>> certificate. >>> The response from OCSP Responder 2 is routed back to the RP. >>> The RP verifies that the response is indeed correctly signed. >>> =20 >>> If the man-in-the-middle attack were not done, the RP would have known= that >>> the certificate >>> was either "revoked" or "good", since only OCSP Responder 1 knows it. >>> =20 >>> Without the proposed extension, the protocol would provide incorrect >>> revocation status results. >>> =20 >>> Denis >>> =20 >>> =20 >>> =20 >>> Santesson a =E9crit : >>> =20 >>> =20 >>>> =20 >>>> Why do you need this at all? >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> I don't see that this extension is required in order to split OCSP >>>> responding for chunks of certs. >>>> =20 >>>> You can point the client to the correct responder using information in= the >>>> cert today. >>>> =20 >>>> The responder can determine if the requested vert is within it's handl= ed >>>> portion of certs. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> Given that you trust the OCSP responder and the responder is honest, y= ou >>>> will receive an appropriate response. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> So, why the extension? >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> I can only imagine the extension being useful to detect if a responder >>>> responds outside of it's authority, but if the OCSP responder is disho= nest, >>>> then you are screwed in any case. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> /Stefan >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> From: Santosh Chokhani >>>> Date: Friday, September 28, 2012 4:17 PM >>>> To: "denis.pinkas@bull.net" , pkix >>>> >>>> Subject: Re: [pkix] New Version Notification for >>>> draft-pinkas-2560bis-ocsp-locationcheck-00.txt >>>> =20 >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>>=20 >>>>> Denis, >>>>> =20 >>>>> =20 >>>>> =20 >>>>> I find the document in general acceptable. It definitely fills a hol= e. >>>>> =20 >>>>> =20 >>>>> =20 >>>>> That said, it is effective both in general and against MITM attack if= the >>>>> CA recognizes that the absence of the critical extension you designed= in >>>>> the OCSP certificate means that the Responder is authoritative for al= l >>>>> certificates as long as the rest of the requirements in RFC 2560 are = met. >>>>> =20 >>>>> =20 >>>>> =20 >>>>> Note that absence of IDP means that the CRL is full and complete. We= do >>>>> not have a similar statement in 2560 and this extension is fully effe= ctive >>>>> only if such is the case, i.e., by omitting this extension, the CA im= plies >>>>> that the Responder is authoritative for all certificates signed using= that >>>>> CA key. >>>>> =20 >>>>> =20 >>>>> =20 >>>>> We either need to impose this requirement, which while new, most >>>>> implementations I know impose or discuss it in the Security Considera= tions >>>>> section. >>>>> =20 >>>>> =20 >>>>> =20 >>>>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf = Of >>>>> denis.pinkas@bull.net >>>>> Sent: Tuesday, September 25, 2012 11:12 AM >>>>> To: pkix >>>>> Subject: [pkix] New Version Notification for >>>>> draft-pinkas-2560bis-ocsp-locationcheck-00.txt >>>>> =20 >>>>> =20 >>>>> =20 >>>>> To the list,=20 >>>>> =20 >>>>> The last comment from Santosh, triggered me to write a new draft pro= posal >>>>> directly related to 2560bis. >>>>> =20 >>>>> This proposal allows to split the workload of an OCSP service from a= CA >>>>> between several OCSP Responders. >>>>> This may be desirable for PKIs issuing a large number of certificate= s >>>>> (e.g. several hundred of thousands). >>>>> =20 >>>>> Denis=20 >>>>> =20 >>>>> =20 >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> =20 >>>>> A new version of I-D, draft-pinkas-2560bis-ocsp-locationcheck-00.txt >>>>> has been successfully submitted by Denis Pinkas and posted to the >>>>> IETF repository. >>>>> =20 >>>>> Filename: draft-pinkas-2560bis-ocsp-locationcheck >>>>> Revision: 00 >>>>> Title: OCSP LocationCheck certificate extension Upda= te to >>>>> OCSP=20 >>>>> < draft-pinkas-2560bis-ocsp-locationcheck-00.txt > >>>>> Creation date: 2012-09-25 >>>>> WG ID: Individual Submission >>>>> Number of pages: 6 >>>>> URL: =20 >>>>> http://www.ietf.org/internet-drafts/draft-pinkas-2560bis-ocsp-locatio= nchec >>>>> k-00.txt=20 >>>>> >>>> ck-00.txt>=20 >>>>> Status: =20 >>>>> http://datatracker.ietf.org/doc/draft-pinkas-2560bis-ocsp-locationche= ck >>>>> >>>>> Htmlized: =20 >>>>> http://tools.ietf.org/html/draft-pinkas-2560bis-ocsp-locationcheck-00 >>>>> >>>>> =20 >>>>> =20 >>>>> Abstract:=20 >>>>> =20 >>>>> RFC 2560 [RFC2560] allows CAs to designate one or more OCSP >>>>> Responders for being responsible to provide the revocation status >>>>> of the certificates they issue under a given CA key. >>>>> =20 >>>>> This document introduces a new feature that allows allows CAs to >>>>> split the workload between different sets of OCSP Responders in a >>>>> way that is analogous to the way CRLs can be split between >>>>> different sets of CRL issuers (using the cRLDistributionPoints >>>>> extension). >>>>> =20 >>>>> This new feature allows a CA to designate one or more OCSP >>>>> Responders for being responsible to provide the revocation status >>>>> for a subset of the certificates they issue under a given CA key. >>>>> =20 >>>>> This document defines a critical extension that may only be placed >>>>> in an OCSP certificate and the way it shall be processed by OCSP >>>>> clients. >>>>> =20 >>>>> The IETF Secretariat >>>>> =20 >>>>> =20 >>>>> =20 >>>>> _______________________________________________ pkix mailing list >>>>> pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix >>>> =20 >>> =20 >>> =20 >>> =20 >>> =20 >> =20 > =20 > =20 --B_3432795855_4848058 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
The "unauthorized" = response seems suitable to me. 

"The response "unauthorized" is returned in cases whe= re the client is not authorized to make this query to this server or the ser= ver is not capable of responding authoritatively (cf. [RFC5019], Section 2.2= .3)"

/Stefan



From: Denis Pinkas Bull <= denis.pinkas@bull.net>
Date: Thursday, October 11, 2012 7:53 AM
To: <= /span> Stefan Santesson <stefan@aaa-s= ec.com>
Cc: Santosh Chokhan= i <SChokhani@cygnacom.com>= , pkix <pkix@ietf.org>
Subject: Re: [pkix] New Version Notification f= or draft-pinkas-2560bis-ocsp-locationcheck-00.txt

Stefan,

As fas as I know, there are only three major status: "good", "revoked" or "unknown".

Error messages are:

   -- malformedRequest,
   -- internalError,
   -- tryLater,
   -- sigRequired,
   -- unauthorized.

There is no response like: "the responder is not authorised to provide information about the cert".
In the example, the RP gets "unknown" (with a correct= signature from the OCSP responder),
whereas it would have received either "good" or "revoked", if there had been no attack.

Denis

=
Sorry, Still don't get it.

In your example, the client receives a response that the responder is not authorised to provide information about the cert.
So a man-in-the-middle can do a DoS attack. That is not new.

/Stefan


From: Denis Pinkas Bull <denis.pinkas@bull.net>
Date: Thursday, October 11, 2012 7:31 AM
To: Stefan Santesson <st= efan@aaa-sec.com>
Cc: Santosh Chokhani <SChokhani@cygnacom.com>, pkix <pk= ix@ietf.org>
Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt

Stefan,

You missed the point. Let me illustrate why using a simple scenario:

OCSP Responder 1 receives delegation from CA x for the first 100.000 issued certificates.
OCSP Responder 1 has only access to the revocation status of the first 100.000 issued certificates.
The first 100.000 issued certificates contain url1 to locate OCSP Responder 1.

OCSP Responder 2 receives delegation from CA x for the next 100.000 issued certificates.
OCSP Responder 2 has only access to the revocation status of the next 100.000 issued certificates.
The next 100.000 issued certificates contains url2 to locate OCSP Responder 2.

A Relying Party (RP) uses url1 that is present in the target certificate to query OCSP Responder 1.
However, there is a man-in-the-middle-attack and this request in routed to OCSP Responder 2.
OCP2 responder 2 responds that it don't know the status of this certificate.
The response from OCSP Responder 2 is routed back to the RP.
The RP verifies that the response is indeed correctly signed.

If the man-in-the-middle attack were not done, the RP would have known that the certificate
was either "revoked" or "good", since only OCSP Responder 1 knows it.

Without the proposed extension, the protocol would provide incorrect revocation status results.

Denis



 Santesson a =E9crit :
Why do you need this at all?

I don't see that this extension is required in order to split OCSP responding for chunks of certs.
=
You can point the client to the correct responder using information in the cert today.
The responder can determine if the requested vert is within it's handled portion of certs.

Given that you trust the OCSP responder and the responder is honest, you will receive an appropriate response.

So, why the extension?

I can only imagine the extension being useful to detect if a responder responds outside of it's authority, but if the OCSP responder is dishonest, then you are screwed in any case.

/Stefan


From: Santosh Chokhani <SChokhani@cygnacom.com>
Date: Friday, September 28, 2012 4:17 PM
To: "denis.pinkas@bull.net= " <denis.pinkas@bull.net>, pkix <pkix@ietf.org>
Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt

Denis,

 

I find the document in general acceptable.  It definitely fills a hole.

 

That said, it is effective both in general and against MITM attack if the CA recognizes that the absence of the critical extension you designed in the OCSP certificate means that the Responder is authoritative for all certificates as long as the rest of the requirements in RFC 2560 are met.

 

Note that absence of IDP means that the CRL is full and complete.  We do not have a similar statement in 2560 and this extension is fully effective only if such is the case, i.e., by omitting this extension, the CA implies that the Responder is authoritative for all certificates signed using that CA key.

 

We either need to impose this requirement, which while new, most implementations I know impose or discuss it in the Security Considerations section.

 

From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of denis.pinkas@bull.net
Sent: Tuesday, September 25, 2012 11:12 AM
To: pkix
Subject: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.tx= t

 

To the list,

The last comment from Santosh, triggered me to write a new draft proposal directly related to 2560bis.  <= /span>

This proposal allows to split the workload of an OCSP service from a CA between several OCSP Responders.
This may be desirable for PKIs issuing a large number of certificates (e.g. several hundred of thousands).

Denis

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

A new version of I-D, draft-pinkas-2560bis-ocsp-locationcheck-00.= txt
has been successfully submitted by Denis Pinkas and posted to the
IETF repository.

Filename:         &nb= sp;       draft-pinkas-2560bis-ocsp-locationcheck
Revision:         &nb= sp;       00
Title:          =       OCSP LocationCheck certificate extension Update to OCSP
           =       < draft-pinkas-2560bis-ocsp-locationcheck-00.= txt >
Creation date:        = ;          2012-09-25
WG ID:          =                      = ;   Individual Submission
Number of pages: 6
URL:           &= nbsp; http://www.ietf.org/internet-drafts/draft-pinkas-2560bis-oc= sp-locationcheck-00.txt
Status:          = ;http://datatracker.ietf.org/doc/draft-pinkas-2560bis-ocsp-locationcheck
= Htmlized:        http:/= /tools.ietf.org/html/draft-pinkas-2560bis-ocsp-locationcheck-00<= /a>


Abstract:

  RFC 2560 [RFC2560] allows CAs to designate one or more OCSP
  Responders for being responsible t= o provide the revocation status
  of the certificates they issue und= er a given CA key.

  This document introduces a new feature that allows allows CAs to
  split the workload between differe= nt sets of OCSP Responders in a
  way that is analogous to the way CRLs can be split between
  different sets of CRL issuers (usi= ng the cRLDistributionPoints
  extension).

  This new feature allows a CA to designate one or more OCSP
  Responders for being responsible t= o provide the revocation status
  for a subset of the certificates they issue under a given CA key.

  This document defines a critical extension that may only be placed
  in an OCSP certificate and the way= it shall be processed by OCSP
  clients.

The IETF Secretariat

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


--B_3432795855_4848058-- From denis.pinkas@bull.net Thu Oct 11 05:25:45 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C191321F8737 for ; Thu, 11 Oct 2012 05:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.382 X-Spam-Level: X-Spam-Status: No, score=-4.382 tagged_above=-999 required=5 tests=[AWL=1.866, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PqqPov6IEW1 for ; Thu, 11 Oct 2012 05:25:44 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 623FD21F8734 for ; Thu, 11 Oct 2012 05:25:43 -0700 (PDT) Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id 1DBE51C131; Thu, 11 Oct 2012 14:25:42 +0200 (CEST) Received: from [127.0.0.1] ([129.184.39.15]) by MSGC-007.bull.fr (Lotus Domino Release 8.5.3FP1) with ESMTP id 2012101114254134-733 ; Thu, 11 Oct 2012 14:25:41 +0200 Message-ID: <5076BAC3.3050402@bull.net> Date: Thu, 11 Oct 2012 14:25:39 +0200 From: Denis Pinkas User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 11/10/2012 14:25:41, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 11/10/2012 14:25:42, Serialize complete at 11/10/2012 14:25:42 X-TNEFEvaluated: 1 Content-Type: multipart/alternative; boundary="------------000703040602080905000300" Cc: pkix Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 12:25:45 -0000 This is a multi-part message in MIME format. --------------000703040602080905000300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Stefan, RFC 2560 states: "In case of errors, the OCSP Responder may return an error message. These messages are not signed". So an "unauthorized" response is not signed. The text from RFC 2560 states: The response "unauthorized" is returned in cases where the client is not authorized to make this query to this server. The text from RFC 5019 states the following: As long as the OCSP infrastructure has authoritative records for a particular certificate, an OCSPResponseStatus of "successful" will be returned.When access to authoritative records for a particular certificate is not available, the responder MUST return an OCSPResponseStatus of "unauthorized".As such, this profile extends the RFC 2560 [OCSP] definition of "unauthorized" as follows: The response "unauthorized" is returned in cases where the client is not authorized to make this query to this server or the server is not capable of responding authoritatively. In the absence of the proposed extension, RFC 5019 could not do better. With the proposed extension, it is possible to do better and to get a=20 signed "unknown" status in a signed response rather than an "unauthorized" error in an unsigned response, that is=20 harder to interpret and subject to attacks: - was there a substitution attack, since this may not be a response=20 from the authorized responder ? - am I using a wrong URL, since I am not sure this response comes from=20 the right URL ? - am I missing an authorization to get the status ? Denis > The "unauthorized" response seems suitable to me. > > "The response "unauthorized" is returned in cases where the client is=20 > not authorized to make this query to this server or the server is not=20 > capable of responding authoritatively (cf. [RFC5019], Section 2.2.3)" > > /Stefan > > > > From: Denis Pinkas Bull > > Date: Thursday, October 11, 2012 7:53 AM > To: Stefan Santesson > > Cc: Santosh Chokhani >, pkix > > Subject: Re: [pkix] New Version Notification for=20 > draft-pinkas-2560bis-ocsp-locationcheck-00.txt > > Stefan, > > As fas as I know, there are only three major status: "good", > "revoked" or "unknown". > > Error messages are: > > -- malformedRequest, > -- internalError, > -- tryLater, > -- sigRequired, > -- unauthorized. > > There is no response like: "the responder is not authorised to > provide information about the cert". > In the example, the RP gets "unknown" (witha correct signature > from the OCSP responder), > whereas it would have received either "good" or "revoked", if > there had been no attack. > > Denis > >> Sorry, Still don't get it. >> >> In your example, the client receives a response that the >> responder is not authorised to provide information about the cert. >> So a man-in-the-middle can do a DoS attack. That is not new. >> >> /Stefan >> >> >> From: Denis Pinkas Bull > > >> Date: Thursday, October 11, 2012 7:31 AM >> To: Stefan Santesson > >> Cc: Santosh Chokhani > >, pkix > > >> Subject: Re: [pkix] New Version Notification for >> draft-pinkas-2560bis-ocsp-locationcheck-00.txt >> >> Stefan, >> >> You missed the point. Let me illustrate why using a simple >> scenario: >> >> OCSP Responder 1 receives delegation from CA x for the first >> 100.000 issued certificates. >> OCSP Responder 1 has only access to the revocation status of >> the first 100.000 issued certificates. >> The first 100.000 issued certificates contain url1 to locate >> OCSP Responder 1. >> >> OCSP Responder 2 receives delegation from CA x for the next >> 100.000 issued certificates. >> OCSP Responder 2 has only access to the revocation status of >> the next 100.000 issued certificates. >> The next 100.000 issued certificates contains url2 to locate >> OCSP Responder 2. >> >> A Relying Party (RP) uses url1 that is present in the target >> certificate to query OCSP Responder 1. >> However, there is a man-in-the-middle-attack and this request >> in routed to OCSP Responder 2. >> OCP2 responder 2 responds that it don't know the status of >> this certificate. >> The response from OCSP Responder 2 is routed back to the RP. >> The RP verifies that the response is indeed correctly signed. >> >> If the man-in-the-middle attack were not done, the RP would >> have known that the certificate >> was either "revoked" or "good", since only OCSP Responder 1 >> knows it. >> >> Without the proposed extension, the protocol would provide >> incorrect revocation status results. >> >> Denis >> >> >> >> Santesson a =E9crit : >>> Why do you need this at all? >>> >>> I don't see that this extension is required in order to >>> split OCSP responding for chunks of certs. >>> You can point the client to the correct responder using >>> information in the cert today. >>> The responder can determine if the requested vert is within >>> it's handled portion of certs. >>> >>> Given that you trust the OCSP responder and the responder is >>> honest, you will receive an appropriate response. >>> >>> So, why the extension? >>> >>> I can only imagine the extension being useful to detect if a >>> responder responds outside of it's authority, but if the >>> OCSP responder is dishonest, then you are screwed in any case= . >>> >>> /Stefan >>> >>> >>> From: Santosh Chokhani >> > >>> Date: Friday, September 28, 2012 4:17 PM >>> To: "denis.pinkas@bull.net " >>> >, pkix >>> > >>> Subject: Re: [pkix] New Version Notification for >>> draft-pinkas-2560bis-ocsp-locationcheck-00.txt >>> >>> Denis, >>> >>> I find the document in general acceptable. It >>> definitely fills a hole. >>> >>> That said, it is effective both in general and against >>> MITM attack if the CA recognizes that the absence of the >>> critical extension you designed in the OCSP certificate >>> means that the Responder is authoritative for all >>> certificates as long as the rest of the requirements in >>> RFC 2560 are met. >>> >>> Note that absence of IDP means that the CRL is full and >>> complete. We do not have a similar statement in 2560 and >>> this extension is fully effective only if such is the >>> case, i.e., by omitting this extension, the CA implies >>> that the Responder is authoritative for all certificates >>> signed using that CA key. >>> >>> We either need to impose this requirement, which while >>> new, most implementations I know impose or discuss it in >>> the Security Considerations section. >>> >>> *From:*pkix-bounces@ietf.org >>> >>> [mailto:pkix-bounces@ietf.org] *On Behalf Of >>> *denis.pinkas@bull.net >>> *Sent:* Tuesday, September 25, 2012 11:12 AM >>> *To:* pkix >>> *Subject:* [pkix] New Version Notification for >>> draft-pinkas-2560bis-ocsp-locationcheck-00.txt >>> >>> To the list, >>> >>> The last comment from Santosh, triggered me to write a >>> new draft proposal directly related to 2560bis. >>> >>> This proposal allows to split the workload of an OCSP >>> service from a CA between several OCSP Responders. >>> This may be desirable for PKIs issuing a large number of >>> certificates (e.g. several hundred of thousands). >>> >>> Denis >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> >>> A new version of I-D, >>> draft-pinkas-2560bis-ocsp-locationcheck-00.txt >>> has been successfully submitted by Denis Pinkas and >>> posted to the >>> IETF repository. >>> >>> Filename: draft-pinkas-2560bis-ocsp-locationcheck >>> Revision: 00 >>> Title: OCSP LocationCheck certificate >>> extension Update to OCSP >>> < >>> draft-pinkas-2560bis-ocsp-locationcheck-00.txt > >>> Creation date: 2012-09-25 >>> WG ID: Individual Submission >>> Number of pages: 6 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-pinkas-2560bis-= ocsp-locationcheck-00.txt >>> Status: >>> http://datatracker.ietf.org/doc/draft-pinkas-2560bis-ocsp= -locationcheck >>> Htmlized: >>> http://tools.ietf.org/html/draft-pinkas-2560bis-ocsp-loca= tioncheck-00 >>> >>> >>> Abstract: >>> >>> RFC 2560 [RFC2560] allows CAs to designate one or more >>> OCSP >>> Responders for being responsible to provide the >>> revocation status >>> of the certificates they issue under a given CA key. >>> >>> This document introduces a new feature that allows >>> allows CAs to >>> split the workload between different sets of OCSP >>> Responders in a >>> way that is analogous to the way CRLs can be split betw= een >>> different sets of CRL issuers (using the >>> cRLDistributionPoints >>> extension). >>> >>> This new feature allows a CA to designate one or more O= CSP >>> Responders for being responsible to provide the >>> revocation status >>> for a subset of the certificates they issue under a >>> given CA key. >>> >>> This document defines a critical extension that may >>> only be placed >>> in an OCSP certificate and the way it shall be >>> processed by OCSP >>> clients. >>> >>> The IETF Secretariat >>> >>> _______________________________________________ pkix >>> mailing list pkix@ietf.org >>> https://www.ietf.org/mailman/listinfo/pkix=20 >>> >> > --------------000703040602080905000300 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=ISO-8859-1
Stefan,

RFC 2560 states:

 "In case of errors, the OCSP Responder may return an error message.
These messages are not signed".

So an "unauthorized" response is not signed.

The text from RFC 2560 states:

   The response "unauthorized" is returned in cases where the client is
   not authorized to make this query to this server.

The text from RFC 5019 states the following:

   As long as the OCSP infrastructure has authoritative records for a

   particular certificate, an OCSPResponseStatus of "successful" will be

   returned.  When access to authoritative records for a particular

   certificate is not available, the responder MUST return an

   OCSPResponseStatus of "unauthorized".  As such, this profile extends

   the RFC 2560 [OCSP] definition of "unauthorized" as follows:

 

      The response "unauthorized" is returned in cases where the client

      is not authorized to make this query to this server or the server

      is not capable of responding authoritatively.


In the absence of the proposed extension, RFC 5019 could not do better.
 
With the proposed extension, it is possible to do better and to get a signed "unknown" status in a signed response
rather than an "unauthorized" error in an unsigned response, that is harder to interpret and subject to attacks:

 - was there a substitution attack, since this may not be a response from the authorized responder ?
 - am I using a wrong URL, since I am not sure this response comes from the right URL ?
 - am I missing an authorization to get the status ?

Denis

 
The "unauthorized" response seems suitable to me. 

"The response "unauthorized" is returned in cases where the client is not authorized to make this query to this server or the server is not capable of responding authoritatively (cf. [RFC5019], Section 2.2.3)"

/Stefan



From: Denis Pinkas Bull <denis.pinkas@bull.net>
Date: Thursday, October 11, 2012 7:53 AM
To: Stefan Santesson <stefan@aaa-sec.com>
Cc: Santosh Chokhani <SChokhani@cygnacom.com>, pkix <pkix@ietf.org>
Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt

Stefan,

As fas as I know, there are only three major status: "good", "revoked" or "unknown".

Error messages are:

   -- malformedRequest,
   -- internalError,
   -- tryLater,
   -- sigRequired,
   -- unauthorized.

There is no response like: "the responder is not authorised to provide information about the cert".
In the example, the RP gets "unknown" (with a correct signature from the OCSP responder),
whereas it would have received either "good" or "revoked", if there had been no attack.

Denis

Sorry, Still don't get it.

In your example, the client receives a response that the responder is not authorised to provide information about the cert.
So a man-in-the-middle can do a DoS attack. That is not new.

/Stefan


From: Denis Pinkas Bull <denis.pinkas@bull.net>
Date: Thursday, October 11, 2012 7:31 AM
To: Stefan Santesson <stefan@aaa-sec.com>
Cc: Santosh Chokhani <SChokhani@cygnacom.com>, pkix <pkix@ietf.org>
Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt

Stefan,

You missed the point. Let me illustrate why using a simple scenario:

OCSP Responder 1 receives delegation from CA x for the first 100.000 issued certificates.
OCSP Responder 1 has only access to the revocation status of the first 100.000 issued certificates.
The first 100.000 issued certificates contain url1 to locate OCSP Responder 1.

OCSP Responder 2 receives delegation from CA x for the next 100.000 issued certificates.
OCSP Responder 2 has only access to the revocation status of the next 100.000 issued certificates.
The next 100.000 issued certificates contains url2 to locate OCSP Responder 2.

A Relying Party (RP) uses url1 that is present in the target certificate to query OCSP Responder 1.
However, there is a man-in-the-middle-attack and this request in routed to OCSP Responder 2.
OCP2 responder 2 responds that it don't know the status of this certificate.
The response from OCSP Responder 2 is routed back to the RP.
The RP verifies that the response is indeed correctly signed.

If the man-in-the-middle attack were not done, the RP would have known that the certificate
was either "revoked" or "good", since only OCSP Responder 1 knows it.

Without the proposed extension, the protocol would provide incorrect revocation status results.

Denis



 Santesson a écrit :
Why do you need this at all?

I don't see that this extension is required in order to split OCSP responding for chunks of certs.
You can point the client to the correct responder using information in the cert today.
The responder can determine if the requested vert is within it's handled portion of certs.

Given that you trust the OCSP responder and the responder is honest, you will receive an appropriate response.

So, why the extension?

I can only imagine the extension being useful to detect if a responder responds outside of it's authority, but if the OCSP responder is dishonest, then you are screwed in any case.

/Stefan


From: Santosh Chokhani <SChokhani@cygnacom.com>
Date: Friday, September 28, 2012 4:17 PM
To: "denis.pinkas@bull.net" <denis.pinkas@bull.net>, pkix <pkix@ietf.org>
Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt

Denis,

 

I find the document in general acceptable.  It definitely fills a hole.

 

That said, it is effective both in general and against MITM attack if the CA recognizes that the absence of the critical extension you designed in the OCSP certificate means that the Responder is authoritative for all certificates as long as the rest of the requirements in RFC 2560 are met.

 

Note that absence of IDP means that the CRL is full and complete.  We do not have a similar statement in 2560 and this extension is fully effective only if such is the case, i.e., by omitting this extension, the CA implies that the Responder is authoritative for all certificates signed using that CA key.

 

We either need to impose this requirement, which while new, most implementations I know impose or discuss it in the Security Considerations section.

 

From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of denis.pinkas@bull.net
Sent: Tuesday, September 25, 2012 11:12 AM
To: pkix
Subject: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt

 

To the list,

The last comment from Santosh, triggered me to write a new draft proposal directly related to 2560bis.  

This proposal allows to split the workload of an OCSP service from a CA between several OCSP Responders.
This may be desirable for PKIs issuing a large number of certificates (e.g. several hundred of thousands).

Denis

==============================================================================================

A new version of I-D, draft-pinkas-2560bis-ocsp-locationcheck-00.txt
has been successfully submitted by Denis Pinkas and posted to the
IETF repository.

Filename:                 draft-pinkas-2560bis-ocsp-locationcheck
Revision:                 00
Title:                 OCSP LocationCheck certificate extension Update to OCSP
                  < draft-pinkas-2560bis-ocsp-locationcheck-00.txt >
Creation date:                  2012-09-25
WG ID:                                   Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-pinkas-2560bis-ocsp-locationcheck-00.txt
Status:          http://datatracker.ietf.org/doc/draft-pinkas-2560bis-ocsp-locationcheck
Htmlized:        http://tools.ietf.org/html/draft-pinkas-2560bis-ocsp-locationcheck-00


Abstract:

  RFC 2560 [RFC2560] allows CAs to designate one or more OCSP
  Responders for being responsible to provide the revocation status
  of the certificates they issue under a given CA key.

  This document introduces a new feature that allows allows CAs to
  split the workload between different sets of OCSP Responders in a
  way that is analogous to the way CRLs can be split between
  different sets of CRL issuers (using the cRLDistributionPoints
  extension).

  This new feature allows a CA to designate one or more OCSP
  Responders for being responsible to provide the revocation status
  for a subset of the certificates they issue under a given CA key.

  This document defines a critical extension that may only be placed
  in an OCSP certificate and the way it shall be processed by OCSP
  clients.

The IETF Secretariat

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




--------------000703040602080905000300-- From stefan@aaa-sec.com Thu Oct 11 05:37:37 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6D921F86BB for ; Thu, 11 Oct 2012 05:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.41 X-Spam-Level: X-Spam-Status: No, score=-100.41 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LmXpcd+DYk73 for ; Thu, 11 Oct 2012 05:37:21 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id E4A1421F867C for ; Thu, 11 Oct 2012 05:37:20 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 7FE07224F0DC for ; Thu, 11 Oct 2012 14:37:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id G9yqKMlinmfW for ; Thu, 11 Oct 2012 14:37:04 +0200 (CEST) Received: from s326.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 5454D224ED1B for ; Thu, 11 Oct 2012 14:37:04 +0200 (CEST) Received: (qmail 68393 invoked from network); 11 Oct 2012 12:37:04 -0000 Received: from static-213-115-40-164.sme.bredbandsbolaget.se (HELO [172.16.50.125]) (stefan@fiddler.nu@[213.115.40.164]) (envelope-sender ) by s326.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 11 Oct 2012 12:37:04 -0000 User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Thu, 11 Oct 2012 14:37:02 +0200 From: Stefan Santesson To: Denis Pinkas Bull Message-ID: Thread-Topic: [pkix] draft-pinkas-rfc2560bis-03 In-Reply-To: <50765C2C.3040806@bull.net> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3432811024_5404890" Cc: "pkix@ietf.org" Subject: Re: [pkix] draft-pinkas-rfc2560bis-03 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 12:37:37 -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_3432811024_5404890 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Denis, Unfortunately, the number changes are too many to make a fast detailed review providing suggestions on corrections to all issues. I could provide examples, but that would not be a complete list. However, As the WG and AD has decided that we should start with as few changes as possible and only add what is necessary, I would like to reverse this. Could you provide an argument for each change to the current WG draft that you think is necessary? /Stefan From: Denis Pinkas Bull Date: Thursday, October 11, 2012 7:42 AM To: Stefan Santesson Cc: Santosh Chokhani , "pkix@ietf.org" Subject: Re: [pkix] draft-pinkas-rfc2560bis-03 > =20 > =20 > Stefan, > =20 > Thank you for your comments. > =20 > However, your first two comments are not specific enough to know portion= s of > text you would like to be removed. > Would you be able to be more specific ? > =20 > On your third comment, you say: The distinction between OCSP responder, = OCSP > server and OCSP service is > in this context confusing and adds nothing useful to an implementer on ei= ther > side of the protocol. > =20 > You are right to say that there is no need to make a difference between = an > OCSP server and=20 > an OCSP responder, and I can change this in the draft. > =20 > However, the distinction between an OCSP service supported by one or mor= e > OCSP responders should be maintained. > =20 > Denis > =20 > =20 > =20 >> =20 >> Denis, >> =20 >>=20 >> =20 >> =20 >> Posting my major comments on this draft: >> =20 >> =20 >>=20 >> =20 >> =20 >> - This is a substantial rewrite of the original standard. There has been= a >> =20 >> WG decision to limit changes to RFC 2560 to what is necessary to resolve >> =20 >> previous ambiguity. In many places, the text provided in your draft adds >> =20 >> confusion and adds ambiguity instead of removing them. >> =20 >>=20 >> =20 >> =20 >> - This is a protocol specification. That is, it defines the data element= s >> =20 >> exchanged for the purpose of doing OCSP checks. It is NOT a system desig= n >> =20 >> specification. Processing rules are only relevant if they have a direct >> =20 >> impact on the bits on the wire. >> =20 >>=20 >> =20 >> =20 >> - The distinction between OCSP responder, OCSP server and OCSP service i= s >> =20 >> in this context confusing and adds nothing useful to an implementer on >> =20 >> either side of the protocol. >> =20 >> =20 >>=20 >> =20 >> =20 >> /Stefan >> =20 >>=20 >> =20 >> =20 >> From: >> Date: Tuesday, September 25, 2012 5:01 PM >> To: Santosh Chokhani >> Cc: "pkix@ietf.org" >> Subject: [pkix] draft-pinkas-rfc2560bis-03 >> =20 >> =20 >>=20 >> =20 >> =20 >>> Santosh, >>> =20 >>> This text change has been included in draft -03 which is now available= at : >>> =20 >>> http://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-03.txt >>> >>> =20 >>> Denis >>> =20 >>> =20 >>> =20 >>> De : Santosh Chokhani >>> A : "denis.pinkas@bull.net" >>> Cc : "pkix@ietf.org" >>> Date : 24/09/2012 18:21 >>> Objet : RE: draft-pinkas-rfc2560bis-02 >>> =20 >>>=20 >>>=20 >>> =20 >>> =20 >>> Denis, >>> =20 >>> OK except a nit (replace =B3accessLocation field from=B2 to =B3accessLocatio= n >>> field of=B2) >>> =20 >>> From: denis.pinkas@bull.net [mailto:denis.pinkas@bull.net >>> ] >>> Sent: Monday, September 24, 2012 2:17 AM >>> To: Santosh Chokhani >>> Cc: pkix@ietf.org >>> Subject: RE: draft-pinkas-rfc2560bis-02 >>> =20 >>> Santosh, >>> =20 >>> Your point is valid. Here is a proposed change to solve the issue. >>> =20 >>> OLD TEXT:=20 >>> =20 >>> For a given URI value identifying the location of an OCSP Responder, >>> the OCSP Responder SHALL only use one OCSP key pair value for a >>> given period of time. For example, it is acceptable for an OCSP >>> Responder to rekey, stop using the old key, and continue to use the >>> same URI while using the new key. >>> =20 >>> NEW TEXT:=20 >>> =20 >>> An OCSP Responder key rollover does not affect the values of the >>> URIs that are placed in the accessLocation field from the target >>> certificates. One or more OCSP Responder MAY respond to an OCSP >>> request addressed at a given URI picked from the accessLocation >>> field from a target certificate. Each OCSP Responder MAY use a >>> different signing key, as long as it got an OCSP certificate >>> appropriate for that signing key and for the target certificate. >>> =20 >>> Denis=20 >>> =20 >>> =20 >>> =20 >>> De : Santosh Chokhani >> > >>> A : "denis.pinkas@bull.net " >>> > >>> Cc : "pkix@ietf.org " >> > >>> Date : 21/09/2012 17:42 >>> Objet : RE: draft-pinkas-rfc2560bis-02 >>>=20 >>> =20 >>>=20 >>> =20 >>> =20 >>> =20 >>> =20 >>> Denis,=20 >>> =20 >>> Thanks. I am ok with your changes. >>> =20 >>> One thing listed below is troubling me and I would like your and other= s=B9 >>> opinion on it.=20 >>> =20 >>> While you have revised the text in Section 3.3.3 as I requested, it is >>> overly constraining and has been troublesome from the beginning. The t= ext I >>> refer to is: =B3For a given URI value identifying the location of an OCSP >>> Responder, the OCSP Responder SHALL only use one OCSP key pair value fo= r a >>> given period of time=B2. >>> =20 >>> While I can see how this assertion simplifies the sausage-making of th= e >>> standard and the data structures you spell out, it is something these n= eed >>> not be applies in order for the OCSP to work. It is generally a bad i= deas >>> in a standard to impose a constraint that is not necessary for feasibil= ity, >>> security or interoperability reasons. >>> =20 >>> For example, one could have geographical load balancing and/or >>> geographicalredundancy for the URL and rather than porting the same key= , >>> have differentkeys for the Servers. In that case, the actual Server th= at >>> got the request routed would sign the response. >>> =20 >>> Another example, is the URL and the server map to the same machine and= it >>> has multiple keys and can use any one of them. >>> =20 >>> I do agree that there needs to be some constraint that specifies that = the >>> server must be able to provide response to all the queries it is >>> authoritative for and meet the cryptographic binding requirement. >>> I think we need to work the 3.3.3 language so that the constraint is >>> specified such that it does not prohibit valid architectures. >>> =20 >>> From: denis.pinkas@bull.net >>> [mailto:denis.pinkas@bull.net ] >>> Sent: Friday, September 21, 2012 9:22 AM >>> To: Santosh Chokhani >>> Cc: pkix@ietf.org >>> Subject: draft-pinkas-rfc2560bis-02 >>> =20 >>> Santosh,=20 >>> =20 >>> Thank you for these new comments. I have one comment back and two nits= . >>> =20 >>> You suggested to add text at the end of STEP 2, since the current draf= t >>> does not cover when the response is signed by the OCSP Responder. >>> Your rational is quite true. However, your propose change does not fit >>> well. I have changed the text differently >>> =20 >>> Please take a look at draft -02 which has been issued today. >>> http://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-02.txt >>> >>> =20 >>> First nit :=20 >>> =20 >>> PROPOSED TEXT: >>> =20 >>> Note: The CA may need to continue issuing certificates to the OCSP >>> Responder using the old CA key until >>> all the certificates issued under the CA=B9 old key for which the OCSP >>> Responder is authoritative for expire. >>> =20 >>> NEW TEXT:=20 >>> =20 >>> Note: The CA may need to continue issuing certificates to the OCSP >>> Responder using the old CA key until >>> all the certificates issued under the CA=B9 old key for which the OCSP >>> Responder is authoritative have expired. >>> =20 >>> Second nit :=20 >>> =20 >>> PROPOSED TEXT: >>> =20 >>> For example, it is acceptable for an OCSP Responder to rekey, stop usi= ng >>> the old key, and continue to use >>> the old URI while using the new key=B2 >>> =20 >>> NEW TEXT:=20 >>> =20 >>> For example, it is acceptable for an OCSP Responder to rekey, stop usi= ng >>> the old key, and continue to use >>> the same URI while using the new key. >>> =20 >>> Denis=20 >>> =20 >>> =20 >>> =20 >>> De : Santosh Chokhani >> > >>> A : "denis.pinkas@bull.net " >>> > >>> Cc : "pkix@ietf.org " >> > >>> Date : 18/09/2012 21:27 >>> Objet : RE: [pkix] draft-pinkas-rfc2560bis-00 >>>=20 >>> =20 >>> =20 >>>=20 >>> =20 >>> =20 >>> =20 >>> =20 >>> =20 >>> Denis,=20 >>> =20 >>> Thanks. Below are my updated recommended changes: >>> =20 >>> Section 3.2=20 >>> =20 >>> Add the following Note after the second dash: >>> =20 >>> Note: The change in accessLocation is necessary when the CA rekeys to = meet >>> the following constraints imposed by this standard: 1) a BasicOCSPRespo= nse >>> can only be signed using a single private key; 2) the response must be >>> signed using the same CA key that was used to sign the certificate in >>> question; and 3) the OCSP response needs to cover all the certificates >>> queried in the OCSP request. >>> =20 >>> Section 3.3.2: >>> =20 >>> Add the following Note to the 3rd and the last paragraph: >>> =20 >>> Note: The CA may need to continue issuing certificates to the OCSP >>> Responder using the old CA key until all the certificates issued under = the >>> CA=B9 old key for which the OCSP Responder is authoritative for expire. >>> =20 >>> Section 3.3.3: >>> =20 >>> OLD TEXT:=20 >>> =20 >>> =B3For a given URI value identifying the location of an OCSP Responder, = the >>> OCSP Responder SHALL only use one OCSP key pair value.=B2 >>> =20 >>> NEW TEXT:=20 >>> =20 >>> =B3For a given URI value identifying the location of an OCSP Responder, = the >>> OCSP Responder SHALL only use one OCSP key pair value for a given perio= d of >>> time. For example, it is acceptable for an OCSP Responder to rekey, st= op >>> using the old key, and continue to use the old URI while using the new = key=B2 >>> =20 >>> Section 3.4:=20 >>> =20 >>> OLD TEXT:=20 >>> =20 >>> Note: For each candidate certificate, when performing the path >>> validation algorithm, the OCSP client will verify that the >>> current time is within the validity period of the target >>> certificate. Thus, certificates which are outside their >>> validity period will not be included in the request or will >>> be rejected later on by the OCSP responder. >>> =20 >>> =20 >>> NEW TEXT:=20 >>> =20 >>> Note: For each candidate certificate, when performing the path >>> validation algorithm, the OCSP client SHOULD verify that the >>> current time is within the validity period of the target >>> certificate. Thus, certificates which are outside their >>> validity period SHOULD not be included in the request. >>> =20 >>> Section 4.3.1.3: >>> =20 >>> OLD TEXT:=20 >>> =20 >>> For each CA from which the locally trusted Responder has received a >>> delegation, the OCSP Responder SHALL maintain a list of entries. >>> =20 >>> =20 >>> NEW TEXT:=20 >>> =20 >>> For each CA for which the locally trusted Responder is authoritative, = the >>> OCSP Responder SHALL maintain a list of entries. >>> =20 >>> RATIONALE:=20 >>> =20 >>> The locally trusted responder need not have delegation from the CA >>> =20 >>> Section 4.3.2: >>> =20 >>> Add the following at the end of STEP 2: >>> =20 >>> check whether the response is signed using the OCSP Responder key: >>> =20 >>> If it is the case, then the revocation status of that >>> certificate as indicated in the certStatus field is >>> accepted and proceed to step 3. >>> =20 >>> If it is not the case, then the revocation status of that >>> certificate is "unknown" and proceed to step 3. >>> =20 >>> Rationale: Current draft does not cover when the response is signed by= the >>> OCSP Responder=20 >>> =20 >>> Change S. Shokhani to S. Chokhani >>> =20 >>> =20 >>> From: denis.pinkas@bull.net >>> [mailto:denis.pinkas@bull.net ] >>> Sent: Monday, September 17, 2012 3:59 AM >>> To: Santosh Chokhani >>> Cc: pkix@ietf.org >>> Subject: RE: [pkix] draft-pinkas-rfc2560bis-00 >>> =20 >>> Santosh,=20 >>> =20 >>> Thank you for your very valuable comments. It took me "some time" to >>> process them.=20 >>> It will take you "some time" to review them. :-) >>> =20 >>> Since the comments and the changes were numerous, I have issued a new >>> draftwhich is available at: >>> http://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-01.txt >>> >>> =20 >>> For Santosh in particular, see my responses below in lines. >>> =20 >>> Denis,=20 >>> =20 >>> Thanks for this. My initial review indicates that this a very good fi= rst >>> draft. =20 >>> Note that I did not review ASN.1 carefully (I assume it was copied fro= m the >>> existing RFC).=20 >>> =20 >>> It was copied from the draft prepared by Stefan, but the ASN. 1 module >>> needs to be modified >>> since the syntax of nonce has been omitted. >>> =20 >>> I have added:=20 >>> =20 >>> Nonce ::=3D OCTET STRING >>> =20 >>> Since the syntax of the nocheck extension was missing, I have also add= ed: >>> =20 >>> NoCheck ::=3D NULL >>> =20 >>> In the introduction, I have also added: >>> =20 >>> o Section 4.3.2 now indicates that the value of the nocheck >>> extension SHALL be NULL. >>> =20 >>> The ASN.1 module that conforms to the 2002 version of ASN.1 which may = be >>> found in Section 4 >>> of RFC5912 has another problem, since the nocheck extension has been >>> omitted. >>> =20 >>> I have added:=20 >>> =20 >>> -- Certificate Extension >>> =20 >>> ocsp-nocheck EXTENSION ::=3D { SYNTAX NULL >>> IDENTIFIED BY >>> id-pkix-ocsp-nocheck } >>> =20 >>> This means that we cannot keep the same OID for the two ASN. 1 modules= and >>> thus we will need two new ones. >>> =20 >>> I have now included both syntaxes in draft -01. >>> =20 >>> In the introduction, I have also added: >>> =20 >>> o Annex B includes a new ASN.1 module using the 1988 syntax >>> since the syntax of nonce had been omitted. It also includes >>> a new ASN.1 module using the 2002 syntax since in the ASN.1 >>> module which may be found in Section 4 of RFC5912 the nocheck >>> extension had been omitted. >>> =20 >>> I do have the following comment though: >>> =20 >>> Section 2.2: When the CA is signing the response, should it not also u= se >>> the same key to sign the response >>> as the certificate in question? The later part of the section indicat= es >>> this as a requirement. >>> In that case, why not make this explicit like the OCSP Responder. >>> =20 >>> You are correct: I have added: >>> =20 >>> In the former case, the CA MUST use the same key as the one that was >>> used to issue the target certificate. >>> =20 >>> Section 3.1.3, First paragraph, the rational for CA certificates to ha= ve >>> digital signature bit set because >>> they sign OCSP certificates is incorrect. May be what you mean is tha= t a >>> CA that signs OCSP responses >>> needs to have digital signature bit set in its own certificate (i.e., = the >>> certificate for which the CA is the subject). >>> =20 >>> Oups! The text was: >>> =20 >>> Therefore the digitalSignature bit in the keyUsage extension MUST >>> be set.=20 >>> =20 >>> Note 1: Since the CA issues certificates, the keyCertSign bit MUST als= o >>> be set. >>> =20 >>> Note 2: If the CA supports CRLs, in particular to revoke the >>> certificate of the OCSP Responders, then the cRLSign bit, the >>> digitalSignature bit and the keyCertSig bit MUST be set. >>> =20 >>> I have changed it into: >>> =20 >>> Therefore the keyCertSign bit in the keyUsage extension MUST be set. >>> =20 >>> If the CA supports CRLs, in particular to revoke the certificate of >>> the OCSP Responders, then both the cRLSign bit and the keyCertSig >>> bit MUST be set. >>> =20 >>> Section 3.1.3, Note 2, Again there is no requirement for digital signa= ture >>> bit to be set just because the CA signs >>> certificates and CRLs. >>> =20 >>> You are correct. See the correction proposed above. >>> =20 >>> Section 3.2: It not clear which accessLocation is being referred to he= re >>> (cAissuers or OCSP). If this is OCSP, >>> the RFC is overly implementation specific. A CA can use the same OCSP >>> location and sign the response with >>> appropriate key and include the appropriate CA certificate without hav= ing >>> to change the OCSP pointer. >>> =20 >>> Section 3.2 addresses the case of CA that directly supports an OCSP >>> serviceand which performs a key rollover. >>> If the CA key changes, the OCSP location must change since it is only >>> possible use a single key to sign the OCSP >>> responses. Nevertheless, I take your other point to be more specific a= bout >>> the accessLocation. >>> The point is addressed later on in another comment from you. >>> =20 >>> General: The I-D does not address how the CA deals with the situation = when >>> status of multiple certificates issued by the CA, >>> but using different keys is requested. May be the restriction in 3.2 = is >>> used to ensure that such situation does not occur. >>> If so, a short discussion would be helpful. >>> =20 >>> Your comment is related to section 4.3.1.1. (=B3Processing by a CA actin= g as >>> an OCSP responder=B2). >>> The case is already addressed with the following text: >>> =20 >>> For each target certificate, the OCSP responder SHALL verify whether >>> both the hash of the issuer's DN and the hash of the issuer public >>> key which are present in the request match respectively with the DN >>> and the hash of the public key of contained in an entry from the >>> list of entries maintained by this OCSP responder. >>> =20 >>> When there is no match, then the OCSP responder SHALL indicate the >>> "unknown" status and proceed with the next target certificate from >>> the OCSP request. >>> =20 >>> General: It not clear which accessLocation is being referred to in mos= t >>> places.=20 >>> It would be worth stating that it refers to OCSP in all cases unless >>> otherwise stated. >>> =20 >>> I have added a note after the first occurrence of the word in section >>> 3.1.1. >>> =20 >>> Note: accessLocation is mentioned in several places of this document. >>> It refers in all cases to the accessLocation field that is present >>> in an AIA extension field to designate the location of the OCSP >>> responder. In that case, the accessMethod field contains the >>> id-ad-ocsp OID. >>> =20 >>> Section 3.3.2 does not fully and explicitly cover the most common >>> implementation I have seen and that is short life certificates. >>> In that scenario, the CA needs to continue to issue the OCSP Responder >>> certificate using the old CA key until all the certificates >>> issued by the CA using the old key and for which the OCSP Responder is >>> authoritative expire. >>> The text in 3.3.3 can form a model for this when CA rekeys and OCSP >>> Responder has the old keys. >>> =20 >>> The text in section 3.3.2 does not say what you say. Please be more >>> specific or since the text is short, provide an alternative >>> =20 >>> Section 3.3.3, the last sentence is not desirable and can cause proble= ms >>> with some implementations. >>> It is perfectly ok for a Responder to change its key independent of >>> certificate it is authoritative for. >>> Note that OCSP field in a issue certificate cannot be changed just bec= ause >>> the Responder rekyed, >>> be it routine or due to loss or compromise of Responder key. >>> =20 >>> The text in section 3.3.3 does not say what you say. Please be more >>> specific or since the text is short, provide an alternative. >>> =20 >>> Section 3.4, last paragraph, I would think that expiration checking ne= ed >>> not be part of OCSP client. >>> Expiration checking should come under 5280 certificate validation. >>> =20 >>> The text was:=20 >>> =20 >>> For each candidate certificate, the OCSP client SHALL verify that >>> the current time is within the validity period of the target >>> certificate. If this is not the case, the candidate certificate >>> SHALL be discarded. >>> =20 >>> I have changed it into; >>> =20 >>> Note: For each candidate certificate, when performing the path >>> validation algorithm, the OCSP client will verify that the >>> current time is within the validity period of the target >>> certificate. Thus, certificates which are outside their >>> validity period will not be included in the request or will >>> be rejected later on by the OCSP responder. >>> =20 >>> Section 4.1, We should dilute two CAs =B3never have the same issuerKeyHa= sh=B2 >>> to something more akin >>> to statistically infeasible. >>> =20 >>> The text was:=20 >>> =20 >>> Two CAs will never, however, have the same public key unless the >>> CAs either explicitly decided to share their private key, or the >>> key of one of the CAs was compromised. >>> =20 >>> I have changed it into: >>> =20 >>> However, it is statistically infeasible that two CAs use the same >>> public key unless the CAs either explicitly decided to share >>> their private key, or the key of one of the CAs was compromised. >>> =20 >>> Titles of subsections under 4.3 could stand improvements. Responders >>> process request and produce response; >>> they do not process responses. Clients process responses. >>> =20 >>> The titles were: >>> =20 >>> 4.3. Response processing >>> 4.3.1. Response processing by OCSP servers >>> 4.3.1.1. Processing by a CA acting as an OCSP responder >>> 4.3.1.2. Processing by an OCSP Responder >>> 4.3.2. Response processing by an OCSP client >>> =20 >>> I have changed them into: >>> =20 >>> 4.3. Processing of requests and responses >>> 4.3.1. Request processing by OCSP servers >>> 4.3.1.1. Processing by a CA acting as an OCSP responder >>> 4.3.1.2. Processing by an OCSP Responder >>> 4.3.2. Response processing by an OCSP client >>> =20 >>> Section 4.3.1.1, The entry should contain method used to gain access a= nd >>> sign just like the text in 4.3.1.2 >>> as opposed to the private key. In other words, align the two texts fo= r >>> accessing and using private key >>> to sign OCSP responses. >>> =20 >>> Both sections have been aligned. >>> =20 >>> Section 4.3.1,1, page 18 =B3defined in entry=B2 could be misinterpreted as >>> method define in request entry. >>> =20 >>> I don=B9t think that a change is necessary, since it uses the term =B3for = each >>> target certificate=B2 and the entry thus >>> refers to one of the entries from the tables of entries advertised at = the >>> beginning of the section. >>> If you believe that a change is necessary, would you be able to make a >>> proposal ?=20 >>> =20 >>> Section 4.3.1.2, Again the same comment, for the delegated OCSP Respon= der, >>> changing the URL >>> when key is changed is not required and breaks many implementations an= d >>> hence is unacceptable. >>> =20 >>> Would you be able to be more specific, since I don=B9t see that the text >>> states what you mean ? >>> =20 >>> Section 4.3.2, the check for thisUpdate is flawed since this value may= be >>> derived from CRL even for responses >>> that are not pre-generated and hence can be hours or days off dependin= g on >>> CRL issuance frequency, >>> It is better to replace it with producedAt field in the response wheth= er it >>> is related to current time or time in the past. >>> =20 >>> Good catch !=20 >>> =20 >>> The text has been changed into : >>> =20 >>> If the checking time is the current time, and if no nonce has been >>> used in the request, OCSP clients MUST check that the producedAt >>> field is within a time window that is "close enough" to the current >>> time.=20 >>> =20 >>> If the checking time is a time in the past, verifiers MUST check >>> that the producedAt field is in accordance with the verification >>> rules (e.g. close and/or after the date of a time-stamp token). >>> =20 >>> Section 4,3,2 is missing processing signature on the response and >>> processing response extension. >>> =20 >>> I don=B9t understand your request about =B3missing processing signature on= the >>> response=B2, since this point is addressed >>> under STEP 2. If you believe that a change is necessary, would you be = able >>> to be more specific ? >>> =20 >>> Processing response extension is only covered for singleExtensions whe= n the >>> criticality flag is set and >>> the extension is not understood. So you are correct to request additio= nal >>> text to handle the other cases. >>> =20 >>> The following text has been added for the processing of responseExtens= ions: >>> =20 >>> OCSP clients or verifiers SHALL check if the response contains a >>> critical responseExtensions. If such an extension is found and is >>> recognized, it MUST be processed. If such an extension is found and >>> is not recognized, the whole OCSP response MUST be considered as >>> invalid.=20 >>> =20 >>> The following text has been added for the processing of singleExtensio= ns: >>> =20 >>> If checks are successful, then OCSP clients MUST process the >>> singleExtensions field, if it is present. >>> =20 >>> If the criticality flag is set and the extension is not understood, >>> then the status of the certificate shall be "unknown" and proceed to >>> step 3. Otherwise, proceed to step 2. >>> =20 >>> If the extension is understood, then the extension MUST be >>> processed. According to its content proceed either to step 2 or to >>> step 3.=20 >>> =20 >>> Section 5.5: Replay attack is also possible when not using pre-compute= d >>> responses.=20 >>> =20 >>> I have added in new section with the following text: >>> =20 >>> 5.7. Other replay attacks >>> =20 >>> As already mentioned in section 5.5, replay attacks are possible >>> using precomputed responses. Replay attacks are also possible when >>> no nonce is being used in the OCSP request and the time window >>> mentioned in section 4.3.2 (STEP 1)is too large. >>> =20 >>> General: Removal of locally trusted Responder from the I-D is unaccept= able. >>> =20 >>> The intent was not to remove the =B3locally trusted Responder=B2. Neverthe= less, >>> the current text has been improved >>> in several places. For example, in the introduction, I have added: >>> =20 >>> The term =B3locally trusted Responder=B2 is used to designate an OCSP >>> responder that is trusted using local rules. >>> =20 >>> In section 2.2, the text now states: >>> =20 >>> A response message MUST be signed either by a certificate's issuer, >>> by an authorized OCSP Responder or according to local rules. >>> =20 >>> In the first case, the CA MUST use the same key as the one that was >>> used to issue the target certificate. >>> =20 >>> In the second case, the CA MUST explicitly designate the OCSP >>> Responder by issuing an OCSP certificate to the OCSP Responder. >>> OCSP signing delegation SHALL be indicated by the inclusion of >>> id-kp-OCSPSigning in an extendedKeyUsage certificate extension >>> included in the OCSP response signer's certificate. This >>> certificate MUST be issued directly by the CA and under the same key >>> that was used to issue the target certificate. >>> =20 >>> For these two cases, systems or applications that rely on OCSP >>> responses MUST be capable of detecting and enforcing use of the >>> id-ad-ocspSigning value as described above. >>> =20 >>> In the third case, the OCSP client uses a locally trusted Responder. >>> The key used to sign OCSP responses may be directly trusted or be a >>> key contained in an OCSP certificate which is verified according to >>> local rules, instead of the rules detailed in this document. >>> =20 >>> In section I have changed the following text : >>> =20 >>> The OCSP certificate SHALL be signed by the CA issuing private key >>> which corresponds to the issuing CA public key that is in this >>> entry, unless some specific rules are agreed between the OCSP >>> Responder and OCSP clients. In that later case, the OCSP >>> certificate MAY be signed by a different entity. >>> =20 >>> into:=20 >>> =20 >>> The OCSP certificate SHALL be signed by the CA issuing private key >>> which corresponds to the issuing CA public key that is in this >>> entry, unless some specific rules are agreed between the OCSP >>> Responder and OCSP clients. In that later case, which corresponds >>> to the case of a locally trusted Responder, the OCSP certificate MAY >>> be signed by a different entity. >>> =20 >>> There is now also a completely new section: 4.3.1.3, called =B3Processin= g by >>> a locally trusted Responder=B2. >>> =20 >>> When reviewing the text, I found that, in section 4.3.1.2, the list on= ly >>> mentioned:=20 >>> =20 >>> - the method(s) used to obtain the revocation status of the >>> certificates issued under that CA issuing public key, >>> =20 >>> In practice, an OCSP responder may not be responsible for all the >>> certificates issued by a CA. >>> So it also needs to know which subset of the certificates issued by ea= ch CA >>> it is responsible for. >>> =20 >>> Thus I have changed the text into: >>> =20 >>> - the method(s) used to know for which subset of certificates >>> issued by the CA it is responsible for, >>> =20 >>> - the method(s) used to obtain the revocation status of that >>> subset of certificates issued under that CA issuing public key, >>> =20 >>> =20 >>> Denis=20 >>> =20 >>>> > A new Internet-Draft is available from the on-line Internet-Drafts >>>> > directories. >>>> >=20 >>>> > Title : X.509 Internet PublicKey Infrastructure Online >>>> > Certificate Status Protocol - OCSP >>>> > Author(s) : D. Pinkas >>>> > Filename : draft-pinkas-rfc2560bis >>>> > Pages : 41 >>>> > Date : Aug. 27, 2012 >>>> > =20 >>>> > This document specifies a protocol useful in determining the curr= ent >>>> > status of a digital certificate without requiring CRLs. Addition= al >>>> > mechanisms addressing PKIX operational requirements are specified= in >>>> > separate documents. This document obsoletes RFC 2560 and RFC 6277= . >>>> >=20 >>>> > A URL for this Internet-Draft is: >>>> > http://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-00.txt >>>> >>>> >=20 >>>> > Internet-Drafts are also available by anonymous FTP at: >>>> > ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> >=20 >>>> > Below is the data which will enable a MIME compliant mail reader >>>> > implementation to automatically retrieve the ASCII version of the >>>> Internet-Draft. >>>> >=20 >>>> > >>> > >>>> >=20 >>>> > A few explanations about the content of draft-ietf-pinkas-rfc2560bi= s-00. >>>> >=20 >>>> > 25 changes are indicated at the beginning of the document. >>>> > I will only mention a few of them: >>>> >=20 >>>> > A - Explanations were missing to describe: >>>> >=20 >>>> > - the building of a request by an OCSP client, >>>> > - the processing of a request by an OCSP server, >>>> > - the building of a response by an OCSP server, and >>>> > - the processing of a response by an OCSP client. >>>> >=20 >>>> > These explanations have been added. >>>> >=20 >>>> > B - Explanations were missing to address CA key rollover and OCSP >>>> > key rollover. These explanations have been added. >>>> >=20 >>>> > C - Backwards compatibility has been addressed in the following way= : >>>> >=20 >>>> > 1) An OCSP response by be signed either by a CA or by an OCSP >>>> Responder. >>>> >=20 >>>> > 2) Besides local configuration settings which are optional, >>>> > only two cases SHALL be supported by OCSP clients (and thu= s >>>> OCSP servers)=20 >>>> > as explained below. >>>> >=20 >>>> > The key to be used to verify a SingleResponse (within a >>>> > BasicOCSPResponse) MUST: >>>> >=20 >>>> > (1) either be the same key that the one used to sign the=20 >>>> > target certificate, >>>> >=20 >>>> > (2) or be the public key from an OCSP responder that is=20 >>>> > contained in an OCSP certificate that has been signed= by=20 >>>> the same key=20 >>>> > that the one used to sign the target certificate. >>>> > .=20 >>>> > The text allows to use the same general processing for a few other=20 >>>> > cases, since "escape" sentences are provided to allow for these ot= her=20 >>>> cases,=20 >>>> > but only using "local configuration settings".=20 >>>> >=20 >>>> > This means in particular that the Identrust model may be supported=20 >>>> > and that the "several many cases" that were detailed in the annexes= f >>>> > from draft -04 from David Cooper and Stefan Santesson (but which we= re=20 >>>> not=20 >>>> > interoperable with most current implementations) can take benefit o= f the=20 >>>> description=20 >>>> > of the general processing.=20 >>>> >=20 >>>> > Denis=20 >>> _______________________________________________ pkix mailing list=20 >>> pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix=20 >> =20 > =20 > =20 --B_3432811024_5404890 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Denis,

<= div>Unfortunately, the number changes are too many to make a fast detailed r= eview providing suggestions on corrections to all issues.
I could = provide examples, but that would not be a complete list.

However,

As the WG and AD has decided that we= should start with as few changes as possible and only add what is necessary= , I would like to reverse this.
Could you provide an argument for = each change to the current WG draft that you think is necessary?
<= br>
/Stefan


From: Denis Pinkas Bull <denis.pinkas@bull.net>
Date= : Thursday, October 11, 2012 7:42 AM
To: Stefan Santesson <stef= an@aaa-sec.com>
Cc: Santosh= Chokhani <SChokhani@cygnacom.com= >, "pkix@ietf.org" <pkix@ietf.org>
= Subject: Re: [pkix] draft-pinkas-rfc2560bis-03

Stefan,

Thank you for your comments.

However, your first two comments are not specific enough to know portions of text you would like to be removed.
Would you be able to be more specific ?

On your third comment, you say: The distinction between OCSP responder, OCSP server and OCSP service is
in this context confusing and adds nothing useful to an implementer on either side of the protocol.

You are right to say that there is no need to make a difference between an OCSP server and
an OCSP responder, and I can change this in the draft.

However, the distinction between an OCSP service supported by one or more OCSP responders should be maintained.

Denis

=
Denis,

Posting my major comments on this draft:

- This is a substantial rewrite of the original standard. There has been a
=
WG decision to limit changes to RFC 2560 to what is necessary to resolve
previous ambiguity. In many places, the text provided in your draft adds
confusion and adds ambiguity instead of removing them.

- This is a protocol specification. That is, it defines the data elements
exchanged for the purpose of doing OCSP checks. It is NOT a system design
specification. Processing rules are only relevant if they have a direct
impact on the bits on the wire.

- The distinction between OCSP responder, OCSP server and OCSP service is
in this context confusing and adds nothing useful to an implementer on
either side of the protocol.

/Stefan

From: <denis.pinkas@bull.net>
Date: Tuesday, September 25, 2012 5:01 PM
To: Santosh Chokhani <SChokhani@cygnacom.com>
Cc: "pkix@ietf.org" <pkix@ie= tf.org>
Subject: [pkix] draft-pinkas-rfc2560bis-03

Santosh,

This text change has been included in draft -03 which is now available at :

http://www.ietf.org/in= ternet-drafts/draft-pinkas-rfc2560bis-03.txt

Denis



De :   &nbs= p;    Santosh Chokhani <SChokhani@cygnacom.com>
A :    = ;    "denis.pinkas@bull.net" <denis.pinkas@bull.net>
Cc :  =      "pkix@ietf.org" <pkix@= ietf.org>
Date :   &n= bsp;    24/09/2012 18:21<= /font>
Objet :   &= nbsp;    RE: draft-pinkas-rfc2560bis-02



Denis,
 
OK except a nit (replace “accessLocation field from” to “accessLocation field of”)
 
From: denis.pinkas@bull.net [mailto:denis.pinkas@bull.net<= font size=3D"3" face=3D"Tahoma">]
Sent: Monday, September 24, 2012 2:17 AM
To: Santosh Chokhani
Cc: pkix@ietf.org
Subject: RE: draft-pinkas-rfc2560bis-02
 
Santosh,

Your point is valid. Here is a proposed change to solve the issue.

OLD TEXT:

  For a given URI value identifying the location of an OCS= P Responder,
  the OCSP Responder SHALL only use one OCSP key pair valu= e for a
  given period of time.  For example, it is acceptabl= e for an OCSP
  Responder to rekey, stop using the old key, and continue= to use the
  same URI while using the new key.

NEW TEXT:

  An OCSP Responder key rollover does not affect the value= s of the
  URIs that are placed in the accessLocation field from th= e target
  certificates.  One or more OCSP Responder MAY respo= nd to an OCSP
  request addressed at a given URI picked from the accessLocation
  field from a target certificate.  Each OCSP Respond= er MAY use a
  different signing key, as long as it got an OCSP certificate
  appropriate for that signing key and for the target certificate.

Denis



De :        Santosh Chokhani <SChokhani@cy= gnacom.com>
A :        "denis.pinkas@bull.net" <denis.pinkas@bull.net<= /u>>
Cc :        "pkix@ietf.org" <pkix@ietf.org>
Date :        21/09/2012 17:42
Objet :        RE: draft-pinkas-rfc2560bis-02





Denis,
 
Thanks.  I am ok with your changes.
 
One thing listed below is troubling me and I would like your and others’ opinion on it.
 
While you have revised the text in Section 3.3.3 as I requested, it is overly constraining and has been troublesome from the beginning.  The text I refer to is: “For a given URI value identifying th= e location of an OCSP Responder, the OCSP Responder SHALL only use one OCSP key pair value for a given period of time”.
 
While I can see how this assertion simplifies the sausage-making of the standard and the data structures you spell out, it is something these need not be applies in order for the OCSP to work.   It is generally a bad ideas in a standard to impose a constraint that is not necessary for feasibility, security or interoperability reasons.
 
For example, one could have geographical load balancing and/or geographicalredundancy for the URL and rather than porting the same key, have differentkeys for the Servers.  In that case, the actual Server that got the request routed would sign the response.
 
Another example, is the URL and the server map to the same machine and it has multiple keys and can use any one of them.
 
I do agree that there needs to be some constraint that specifies that the server must be able to provide response to all the queries it is authoritative for and meet the cryptographic binding requirement.
I think we need to work the 3.3.3 language so that the constraint is specified such that it does not prohibit valid architectures.
 
From: denis.pinkas@= bull.net [mailto:denis.pinkas@bull= .net]
Sent: Friday, September 21, 2012 9:22 AM
To: Santosh Chokhani
Cc: pkix@ietf.org
Subject: draft-pinkas-rfc2560bis-02
 
Santosh,

Thank you for these new comments. I have one comment back and two nits.

You suggested to add text at the end of STEP 2, since the current draft does not cover when the response is signed by the OCSP Responder.
Your rational is quite true. However, your propose change does not fit well. I have changed the text differently

Please take a look at draft -02 which has been issued today.
http://www.ietf.org/internet-drafts/draft-pinkas-rfc25= 60bis-02.txt

First nit :

PROPOSED TEXT:

Note: The CA may need to continue issuing certificates to the OCSP Responder using the old CA key until
all the certificates issued under the CA’ old key for whi= ch the OCSP Responder is authoritative for expire.

NEW TEXT: <= font size=3D"3" color=3D"red" face=3D"Courier New">

Note: The CA may need to continue issuing certificates to the OCSP Responder using the old CA key until
all the certificates issued under the CA’ old key for whi= ch the OCSP Responder is authoritative have expired.

Second nit :

PROPOSED TEXT:

For example, it is acceptable for an OCSP Responder to rekey, stop using the old key, and continue to use
the old URI while using the new key”

NEW TEXT: <= font size=3D"3" color=3D"#ff0041" face=3D"Courier New">

For example, it is acceptable for an OCSP Responder to rekey, stop using the old key, and continue to use
the same URI while using the new key.

Denis



De :        Santosh Chokhani <SChokhani@cy= gnacom.com>
A :        "denis.pinkas@bull.net" <denis.pinkas@bull.net<= /u>>
Cc :        "pkix@ietf.org" <pkix@ietf.org>
Date :        18/09/2012 21:27
Objet :        RE: [pkix] draft-pinkas-rfc2560bis-00

 





Denis,

Thanks.  Below are my updated recommended changes:<= font size=3D"3" face=3D"Times New Roman">

Section 3.2

Add the following Note after the second dash:

Note: The change in accessLocation is necessary when the CA rekeys to meet the following constraints imposed by this standard: 1) a BasicOCSPResponse can only be signed using a single private key; 2) the response must be signed using the same CA key that was used to sign the certificate in question; and 3) the OCSP response needs to cover all the certificates queried in the OCSP request.

Section 3.3.2:

Add the following Note to the 3rd and the last paragraph:

Note: The CA may need to continue issuing certificates to the OCSP Responder using the old CA key until all the certificates issued under the CA’ old key for which the OCSP Responder is authoritative for expire.

Section 3.3.3:

OLD TEXT:

“For a given URI= value identifying the location of an OCSP Responder, the OCSP Responder SHALL only use one OCSP key pair value.”

NEW TEXT:

“For a given URI= value identifying the location of an OCSP Responder, the OCSP Responder SHALL only use one OCSP key pair value for a given period of time.  For example, it is acceptable for= an OCSP Responder to rekey, stop using the old key, and continue to use the old URI while using the new key”

Section 3.4:

OLD TEXT:

Note:  For each candidate certificate, when performing the= path
     validation algorithm, the OCSP client will = verify that the
     current time is within the validity period = of the target
     certificate.  Thus, certificates which= are outside their
     validity period will not be included in the= request or will
     be rejected later on by the OCSP responder.=


NEW TEXT:

Note:  For each candidate certificate, when performing the= path
     validation algorithm, the OCSP client SHOULD verify that the
     current time is within the validity period = of the target
     certificate.  Thus, certificates which= are outside their
     validity period SHOULD not be included in the request.

Section 4.3.1.3:

OLD TEXT:

 For each CA from which the locally trusted Responder has received a
 delegation, the OCSP Responder SHALL maintain a list of entries.


NEW TEXT:

For each CA for which the locally trusted Responder is authoritative, the OCSP Responder SHALL maintain a list of entries.

RATIONALE:

The locally trusted responder need not have delegation from the CA

Section 4.3.2:

Add the following at the end of STEP 2:

check whether the response is signed using the OCSP Responder key:
=
           If it is the case, the= n the revocation status of that
           certificate as indicat= ed in the certStatus field is
           accepted and proceed t= o step 3.

           If it is not the case,= then the revocation status of that
           certificate is "unknow= n" and proceed to step 3.

Rationale: Current draft does not cover when the response is signed by the OCSP Responder

Change S. Shokhani to S. Chokhani


From: denis.pinkas@= bull.net [mailto:denis.pinkas@bull= .net]
Sent: Monday, September 17, 2012 3:59 AM
To: Santosh Chokhani
Cc: pkix@ietf.org
Subject: RE: [pkix] draft-pinkas-rfc2560bis-00

Santosh,

Thank you for your very valuable comments. It took me "some time" to process them.
It will take you "some time" to review them. :-)

Since the comments and the changes were numerous, I have issued a new draftwhich is available at:
http://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-= 01.txt

For Santosh in particular, see my responses below in lines.

Denis,

Thanks for this.  My initial review indicates that this a very good first draft.  
Note that I did not review ASN.1 carefully (I assume it was copied from the existing RFC).

It was copied from the draft prepared by Stefan, but the ASN. 1 module needs to be modified
since the syntax of nonce has been omitted.

I have added:

Nonce ::=3D OCTET STRING

Since the syntax of the nocheck extension was missing, I have also added:

NoCheck ::=3D NULL

In the introduction, I have also added:

   o  Section 4.3.2 now indicates that the value= of the nocheck
      extension SHALL be NULL.

The ASN.1 module that conforms to the 2002 version of ASN.1 which may be found in Section 4
of RFC5912 has another problem, since the nocheck extension has been omitted.

I have added:

--  Certificate Extension

ocsp-nocheck EXTENSION ::=3D { SYNTAX NULL
                  =                     = IDENTIFIED BY
                  =                     = id-pkix-ocsp-nocheck }

This means that we cannot keep the same OID for the two ASN. 1 modules and thus we will need two new ones.

I have now included both syntaxes in draft -01.

In the introduction, I have also added:

   o  Annex B includes a new ASN.1 module using = the 1988 syntax
      since the syntax of nonce had been omitted= .  It also includes
      a new ASN.1 module using the 2002 syntax s= ince in the ASN.1
      module which may be found in Section 4 of = RFC5912 the nocheck
      extension had been omitted.

I do have the following comment though:

Section 2.2: When the CA is signing the response, should it not also use the same key to sign the response
as the certificate in question?  The later part of the section indicates this as a requirement.  
In that case, why not make this explicit like the OCSP Responder.

You are correct: I have added:

In the former case, the CA MUST use the same key as the one that was
used to issue the target certificate.

Section 3.1.3, First paragraph, the rational for CA certificates to have digital signature bit set because
they sign OCSP certificates is incorrect.  May be what you= mean is that a CA that signs OCSP responses
needs to have digital signature bit set in its own certificate (i.e., the certificate for which the CA is the subject).

Oups! The text was:

Therefore the digitalSignature bit in the keyUsage extension MUST
be set.

Note 1: Since the CA issues certificates, the keyCertSign bit MUST also
     be set.

Note 2: If the CA supports CRLs, in particular to revoke the
     certificate of the OCSP Responders, then th= e cRLSign bit, the
     digitalSignature bit and the keyCertSig bit= MUST be set.

I have changed it into:

Therefore the keyCertSign bit in the keyUsage extension MUST be set.

If the CA supports CRLs, in particular to revoke the certificate of
the OCSP Responders, then both the cRLSign bit and the keyCertSig
bit MUST be set.

Section 3.1.3, Note 2, Again there is no requirement for digital signature bit to be set just because the CA signs
certificates and CRLs.

You are correct. See the correction proposed above.

Section 3.2: It not clear which accessLocation is being referred to here (cAissuers or OCSP).  If this is OCSP,
the RFC is overly implementation specific.  A CA can use t= he same OCSP location and sign the response with
appropriate key and include the appropriate CA certificate without having to change the OCSP pointer.<= br>
Section 3.2 addresses the case of CA that directly supports an OCSP serviceand which performs a key rollover.  
If the CA key changes, the OCSP location must change since it is only possible use a single key to sign the OCSP
responses. Nevertheless, I take your other point to be more specific about the accessLocation.
The point is addressed later on in another comment from you.

General: The I-D does not address how the CA deals with the situation when status of multiple certificates issued by the CA,
but using different keys is requested.  May be the restriction in 3.2 is used to ensure that such situation does not occur.  = ;
If so, a short discussion would be helpful.

Your comment is related to section 4.3.1.1. (“Processing = by a CA acting as an OCSP responder”).
The case is already addressed with the following text:

For each target certificate, the OCSP responder SHALL verify whether
both the hash of the issuer's DN and the hash of the issuer public
key which are present in the request match respectively with the DN
and the hash of the public key of contained in an entry from the
list of entries maintained by this OCSP responder.

When there is no match, then the OCSP responder SHALL indicate the
"unknown" status and proceed with the next target certificate from
the OCSP request.
=
General: It not clear which accessLocation is being referred to in most places.
It would be worth stating that it refers to OCSP in all cases unless otherwise stated.

I have added a note after the first occurrence of the word in section 3.1.1.

Note: accessLocation is mentioned in several places of this document.
   It refers in all cases to the accessLocation field= that is present
   in an AIA extension field to designate the locatio= n of the OCSP
   responder.  In that case, the accessMethod fi= eld contains the
   id-ad-ocsp OID.

Section 3.3.2 does not fully and explicitly cover the most common implementation I have seen and that is short life certificates.  
In that scenario, the CA needs to continue to issue the OCSP Responder certificate using the old CA key until all the certificates
issued by the CA using the old key and for which the OCSP Responder is authoritative expire.  
The text in 3.3.3 can form a model for this when CA rekeys and OCSP Responder has the old keys.

The text in section 3.3.2 does not say what you say. Please be more specific or since the text is short, provide an alternative

Section 3.3.3, the last sentence is not desirable and can cause problems with some implementations.
It is perfectly ok for a Responder to change its key independent of certificate it is authoritative for.  
Note that OCSP field in a issue certificate cannot be changed just because the Responder rekyed,
be it routine or due to loss or compromise of Responder key.

The text in section 3.3.3 does not say what you say. Please be more specific or since the text is short, provide an alternative.

Section 3.4, last paragraph, I would think that expiration checking need not be part of OCSP client.  
Expiration checking should come under 5280 certificate validation.

The text was:

For each candidate certificate, the OCSP client SHALL verify that
the current time is within the validity period of the target
certificate.  If this is not the case, the candidate certificate
SHALL be discarded.

I have changed it into;

Note:  For each candidate certificate, when performing the= path
    validation algorithm, the OCSP client will verify= that the
    current time is within the validity period of the= target
    certificate.  Thus, certificates which are o= utside their
    validity period will not be included in the reque= st or will
    be rejected later on by the OCSP responder.

Section 4.1, We should dilute two CAs “never have the sam= e issuerKeyHash” to something more akin
to statistically infeasible.=

The text was:

   Two CAs will never, however, have the same public = key unless the
   CAs either explicitly decided to share their priva= te key, or the
   key of one of the CAs was compromised.

I have changed it into:

   However, it is statistically infeasible that two C= As use the same
   public key unless the CAs either explicitly decide= d to share
   their private key, or the key of one of the CAs wa= s compromised.=

Titles of subsections under 4.3 could stand improvements.  Responders process request and produce response;
they do not process responses.  Clients process responses.=

The titles were:

  4.3. Response processing
    4.3.1. Response processing by OCSP servers
      4.3.1.1. Processing by a CA acting as an O= CSP responder
      4.3.1.2. Processing by an OCSP Responder
    4.3.2. Response processing by an OCSP client

I have changed them into:

  4.3. Processing of requests and responses
    4.3.1. Request processing by OCSP servers
      4.3.1.1. Processing by a CA acting as an O= CSP responder
      4.3.1.2. Processing by an OCSP Responder <= br>     4.3.2. Response processing by an OCSP client

Section 4.3.1.1, The entry should contain method used to gain access and sign just like the text in 4.3.1.2
as opposed to the private key.  In other words, align the two texts for accessing and using private key
to sign OCSP responses.

Both sections have been aligned.

Section 4.3.1,1, page 18 “defined in entry” could b= e misinterpreted as method define in request entry.

I don’t think that a change is necessary, since it uses t= he term “for each target certificate” and the entry thus
refers to one of the entries from the tables of entries advertised at the beginning of the section.
If you believe that a change is necessary, would you be able to make a proposal ? =

Section 4.3.1.2, Again the same comment, for the delegated OCSP Responder, changing the URL
when key is changed is not required and breaks many implementations and hence is unacceptable.

Would you be able to be more specific, since I don’t see that the text states what you mean ?
=
Section 4.3.2, the check for thisUpdate is flawed since this value may be derived from CRL even for responses
that are not pre-generated and hence can be hours or days off depending on CRL issuance frequency,
It is better to replace it with producedAt field in the response whether it is related to current time or time in the past.

Good catch !

The text has been changed into :

If the checking time is the current time, and if no nonce has been
used in the request, OCSP clients MUST check that the producedAt
field is within a time window that is "close enough" to the current
time.

If the checking time is a time in the past, verifiers MUST check
that the producedAt field is in accordance with the verification
rules (e.g. close and/or after the date of a time-stamp token).

Section 4,3,2 is missing processing signature on the response and processing response extension.

I don’t understand your request about “missing proc= essing signature on the response”, since this point is addressed
under STEP 2. If you believe that a change is necessary, would you be able to be more specific ?

Processing response extension is only covered for singleExtensions when the criticality flag is set and
the extension is not understood. So you are correct to request additional text to handle the other cases.

The following text has been added for the processing of responseExtensions:
OCSP clients or verifiers SHALL check if the response contains a
critical responseExtensions. If such an extension is found and is
recognized, it MUST be processed.  If such an extension is= found and
is not recognized, the whole OCSP response MUST be considered as
invalid.

The following text has been added for the processing of singleExtensions:

If checks are successful, then OCSP clients MUST process the
singleExtensions field, if it is present.

If the criticality flag is set and the extension is not understood,
then the status of the certificate shall be "unknown" and proceed to
step 3.  Otherwise, proceed to step 2.

If the extension is understood, then the extension MUST be
= processed.  According to its content proceed either to ste= p 2 or to
step 3.
=
Section 5.5: Replay attack is also possible when not using pre-computed responses. =

I have added in new section with the following text:

5.7. Other replay attacks

As already mentioned in section 5.5, replay attacks are possible
using precomputed responses.  Replay attacks are also possible when
no nonce is being used in the OCSP request and the time window
mentioned in section 4.3.2 (STEP 1)is too large.

General: Removal of locally trusted Responder from the I-D is unacceptable.

The intent was not to remove the “locally trusted Responder”. Nevertheless, the current text has been improved
in several places. For example, in the introduction, I have added:

   The term “locally trusted Responder” i= s used to designate an OCSP
   responder that is trusted using local rules.

In section 2.2, the text now states:

A response message MUST be signed either by a certificate's issuer,
by an authorized OCSP Responder or according to local rules.

In the first case, the CA MUST use the same key as the one that was
used to issue the target certificate.

In the second case, the CA MUST explicitly designate the OCSP
Responder by issuing an OCSP certificate to the OCSP Responder.
OCSP signing delegation SHALL be indicated by the inclusion of
id-kp-OCSPSigning in an extendedKeyUsage certificate extension
included in the OCSP response signer's certificate.  This =
certificate MUST be issued directly by the CA and under the same key
that was used to issue the target certificate.

For these two cases, systems or applications that rely on OCSP
responses MUST be capable of detecting and enforcing use of the
id-ad-ocspSigning value as described above.

In the third case, the OCSP client uses a locally trusted Responder.
The key used to sign OCSP responses may be directly trusted or be a
key contained in an OCSP certificate which is verified according to
local rules, instead of the rules detailed in this document.

In section I have changed the following text :

The OCSP certificate SHALL be signed by the CA issuing private key
which corresponds to the issuing CA public key that is in this
entry, unless some specific rules are agreed between the OCSP
Responder and OCSP clients.  In that later case, the OCSP =
certificate MAY be signed by a different entity.

into:

The OCSP certificate SHALL be signed by the CA issuing private key
which corresponds to the issuing CA public key that is in this
entry, unless some specific rules are agreed between the OCSP
Responder and OCSP clients.  In that later case, which corresponds
to the case of a locally trusted Responder, the OCSP certificate MAY
be signed by a different entity.

There is now also a completely new section: 4.3.1.3, called “Processing by a locally trusted Responder”.

When reviewing the text, I found that, in section 4.3.1.2, the list only mentioned: =

  - the method(s) used to obtain the revocation status of the
    certificates issued under that CA issuing public = key,

In practice, an OCSP responder may not be responsible for all the certificates issued by a CA.
So it also needs to know which subset of the certificates issued by each CA it is responsible for.

Thus I have changed the text into:

  - the method(s) used to know for which subset of certificates
    issued by the CA it is responsible for,

  - the method(s) used to obtain the revocation status of that
    subset of certificates issued under that CA issui= ng public key,


Denis

> A new Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>    Title         : X.509 Int= ernet PublicKey Infrastructure Online
>                 &n= bsp;  Certificate Status Protocol - OCSP
>    Author(s)     : D. Pinkas
>    Filename      : draft-pinkas-r= fc2560bis
>    Pages         : 41
>    Date          : Aug.= 27, 2012
>    
>   This document specifies a protocol useful in determining the current
>   status of a digital certificate without requiring CRLs.  Additional
>   mechanisms addressing PKIX operational requirements= are specified in
>   separate documents. This document obsoletes RFC 256= 0 and RFC 6277.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-pinkas-rfc2= 560bis-00.txt
>
> Internet-Drafts are also available by anonymous FTP at: > ftp://ft= p.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.
>
> <ftp://ftp.ietf.org/internet-drafts/draft-pinkas-rfc2560bi= s>
>
> A few explanations about the content of draft-ietf-pinkas-rfc2560bis-00.
>
> 25 changes are indicated at the beginning of the document.
> I will only mention a few of them:
>
> A - Explanations were missing to describe:
>
>      - the building of a request by an OCSP= client,
>      - the processing of a request by an OC= SP server,
>      - the building of a response  by = an OCSP server, and
>      - the processing of a response by an O= CSP client.
>
> These explanations have been added.
>
> B - Explanations were missing to address CA key rollover and OCSP
>     key rollover. These explanations have been a= dded.
>
> C - Backwards compatibility has been addressed in the following way:
>
>       1) An OCSP response by be signed eith= er by a CA or by an OCSP Responder.
>
>       2) Besides local configuration settin= gs which are optional,
>          only two cases SHALL be = supported by OCSP clients (and thus OCSP servers)
>          as explained below.
= >
>        The key to be used to verify a = SingleResponse (within a
>        BasicOCSPResponse) MUST:
>
>           (1) either be the same = key that the one used to sign the
>               target ce= rtificate,
>
>           (2) or be the public ke= y from an OCSP responder that is
>               contained= in an OCSP certificate that has been signed by the same key
>               that the = one used to sign the target certificate.
>    .
> The text allows to use the same general processing for a few other
> cases, since "escape"  sentences are provided to allo= w for these other cases,
> but only using "local configuration settings".
>
> This means in particular that the Identrust model may be supported
> and that the "several many cases" that were detailed in the annexes f
> from draft -04 from David Cooper and Stefan Santesson (but which were not
> interoperable with most current implementations) can take benefit of the description
> of the general processing.
>
> Denis
_______________________________________________ pkix mailing list pkix@ietf.o= rg https://www.ietf.org/mailman/listinfo/pkix

--B_3432811024_5404890-- From denis.pinkas@bull.net Thu Oct 11 06:08:27 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE9C21F848B for ; Thu, 11 Oct 2012 06:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.007 X-Spam-Level: X-Spam-Status: No, score=-4.007 tagged_above=-999 required=5 tests=[AWL=1.357, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9OnLebOcnAp for ; Thu, 11 Oct 2012 06:08:16 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id A5B9621F873E for ; Thu, 11 Oct 2012 06:08:15 -0700 (PDT) Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id 977A71C1EF; Thu, 11 Oct 2012 15:08:14 +0200 (CEST) Received: from [127.0.0.1] ([129.184.39.15]) by MSGC-007.bull.fr (Lotus Domino Release 8.5.3FP1) with ESMTP id 2012101115081278-743 ; Thu, 11 Oct 2012 15:08:12 +0200 Message-ID: <5076C4B9.70006@bull.net> Date: Thu, 11 Oct 2012 15:08:09 +0200 From: Denis Pinkas User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 11/10/2012 15:08:14, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 11/10/2012 15:08:14, Serialize complete at 11/10/2012 15:08:14 Content-Type: multipart/alternative; boundary="------------020201080003000603090208" Cc: "pkix@ietf.org" Subject: Re: [pkix] draft-pinkas-rfc2560bis-03 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 13:08:27 -0000 This is a multi-part message in MIME format. --------------020201080003000603090208 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed Stefan, You will find detailed explanations of all the changes in the first pages of my draft. You win a special prize, if you find a major change that is not indicated ! Since the RFC was badly structured, for example, the description of the parameters for the request and the response was scattered all over the document, some descriptions were missing, then its current format could not be kept. In my draft, each parameter is now described either with the request or with the response. the processing is described just after, from a client and then from a server prospective. Some processing of the elements were missing and the most important was that the processing of the response was wrong. I have added information for handling key rollover that influence the way to use the protocol. I believe this information is important, but I would not object to move it in an annex Since we now both know that it will be possible to have a quick face to face meeting in London next week on Tuesday, I propose that we both come with a printed version of the draft and then we can discuss the changes and the rational of each change that is not always fully explained, since this will have overloaded the document (which is already sufficiently heavy). Denis > Denis, > > Unfortunately, the number changes are too many to make a fast detailed > review providing suggestions on corrections to all issues. > I could provide examples, but that would not be a complete list. > > However, > > As the WG and AD has decided that we should start with as few changes > as possible and only add what is necessary, I would like to reverse this. > Could you provide an argument for each change to the current WG draft > that you think is necessary? > > /Stefan > > > From: Denis Pinkas Bull > > Date: Thursday, October 11, 2012 7:42 AM > To: Stefan Santesson > > Cc: Santosh Chokhani >, "pkix@ietf.org > " > > Subject: Re: [pkix] draft-pinkas-rfc2560bis-03 > > Stefan, > > Thank you for your comments. > > However, your first two comments are not specific enough to know > portions of text you would like to be removed. > Would you be able to be more specific ? > > On your third comment, you say: The distinction between OCSP > responder, OCSP server and OCSP service is > in this context confusing and adds nothing useful to an > implementer on either side of the protocol. > > You are right to say that there is no need to make a difference > between an OCSP server and > an OCSP responder, and I can change this in the draft. > > However, the distinction between an OCSP service supported by one > or more OCSP responders should be maintained. > > Denis > >> Denis, >> >> Posting my major comments on this draft: >> >> - This is a substantial rewrite of the original standard. There >> has been a >> WG decision to limit changes to RFC 2560 to what is necessary to >> resolve >> previous ambiguity. In many places, the text provided in your >> draft adds >> confusion and adds ambiguity instead of removing them. >> >> - This is a protocol specification. That is, it defines the data >> elements >> exchanged for the purpose of doing OCSP checks. It is NOT a >> system design >> specification. Processing rules are only relevant if they have a >> direct >> impact on the bits on the wire. >> >> - The distinction between OCSP responder, OCSP server and OCSP >> service is >> in this context confusing and adds nothing useful to an >> implementer on >> either side of the protocol. >> >> /Stefan >> >> From: > >> Date: Tuesday, September 25, 2012 5:01 PM >> To: Santosh Chokhani > > >> Cc: "pkix@ietf.org " > > >> Subject: [pkix] draft-pinkas-rfc2560bis-03 >> >> Santosh, >> >> This text change has been included in draft -03 which is now >> available at : >> >> http://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-03.txt >> >> Denis >> >> >> >> De : Santosh Chokhani > > >> A : "denis.pinkas@bull.net " >> > >> Cc : "pkix@ietf.org " > > >> Date : 24/09/2012 18:21 >> Objet : RE: draft-pinkas-rfc2560bis-02 >> ------------------------------------------------------------------------ >> >> >> >> Denis, >> >> OK except a nit (replace "accessLocation field from" to >> "accessLocation field of") >> >> *From:* denis.pinkas@bull.net >> [mailto:denis.pinkas@bull.net] * >> Sent:* Monday, September 24, 2012 2:17 AM* >> To:* Santosh Chokhani* >> Cc:* pkix@ietf.org * >> Subject:* RE: draft-pinkas-rfc2560bis-02 >> >> Santosh, >> >> Your point is valid. Here is a proposed change to solve the >> issue. >> >> OLD TEXT: >> >> For a given URI value identifying the location of an OCSP >> Responder, >> the OCSP Responder SHALL only use one OCSP key pair value >> for a >> given period of time. For example, it is acceptable for an >> OCSP >> Responder to rekey, stop using the old key, and continue to >> use the >> same URI while using the new key. >> >> NEW TEXT: >> >> An OCSP Responder key rollover does not affect the values >> of the >> URIs that are placed in the accessLocation field from the >> target >> certificates. One or more OCSP Responder MAY respond to an >> OCSP >> request addressed at a given URI picked from the >> accessLocation >> field from a target certificate. Each OCSP Responder MAY >> use a >> different signing key, as long as it got an OCSP certificate >> appropriate for that signing key and for the target >> certificate. >> >> Denis >> >> >> >> De : Santosh Chokhani <_SChokhani@cygnacom.com_ >> > >> A : "_denis.pinkas@bull.net_ " >> <_denis.pinkas@bull.net_ > >> Cc : "_pkix@ietf.org_ " >> <_pkix@ietf.org_ > >> Date : 21/09/2012 17:42 >> Objet : RE: draft-pinkas-rfc2560bis-02 >> >> ------------------------------------------------------------------------ >> >> >> >> >> Denis, >> >> Thanks. I am ok with your changes. >> >> One thing listed below is troubling me and I would like your >> and others' opinion on it. >> >> While you have revised the text in Section 3.3.3 as I >> requested, it is overly constraining and has been troublesome >> from the beginning. The text I refer to is: "For a given URI >> value identifying the location of an OCSP Responder, the OCSP >> Responder SHALL only use one OCSP key pair value for a given >> period of time". >> >> While I can see how this assertion simplifies the >> sausage-making of the standard and the data structures you >> spell out, it is something these need not be applies in order >> for the OCSP to work. It is generally a bad ideas in a >> standard to impose a constraint that is not necessary for >> feasibility, security or interoperability reasons. >> >> For example, one could have geographical load balancing >> and/or geographicalredundancy for the URL and rather than >> porting the same key, have differentkeys for the Servers. In >> that case, the actual Server that got the request routed >> would sign the response. >> >> Another example, is the URL and the server map to the same >> machine and it has multiple keys and can use any one of them. >> >> I do agree that there needs to be some constraint that >> specifies that the server must be able to provide response to >> all the queries it is authoritative for and meet the >> cryptographic binding requirement. >> I think we need to work the 3.3.3 language so that the >> constraint is specified such that it does not prohibit valid >> architectures. >> * >> From:* _denis.pinkas@bull.net_ >> [_mailto:denis.pinkas@bull.net_] * >> Sent:* Friday, September 21, 2012 9:22 AM* >> To:* Santosh Chokhani* >> Cc:* _pkix@ietf.org_ * >> Subject:* draft-pinkas-rfc2560bis-02 >> >> Santosh, >> >> Thank you for these new comments. I have one comment back and >> two nits. >> >> You suggested to add text at the end of STEP 2, since the >> current draft does not cover when the response is signed by >> the OCSP Responder. >> Your rational is quite true. However, your propose change >> does not fit well. I have changed the text differently >> >> Please take a look at draft -02 which has been issued today._ >> __http://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-02.txt_ >> >> First nit : >> >> PROPOSED TEXT: >> >> Note: The CA may need to continue issuing certificates to the >> OCSP Responder using the old CA key until >> all the certificates issued under the CA' old key for which >> the OCSP Responder is authoritative *for expire*. >> >> NEW TEXT: >> >> Note: The CA may need to continue issuing certificates to the >> OCSP Responder using the old CA key until >> all the certificates issued under the CA' old key for which >> the OCSP Responder is authoritative *have*expire*d*. >> >> Second nit : >> >> PROPOSED TEXT: >> >> For example, it is acceptable for an OCSP Responder to rekey, >> stop using the old key, and continue to use >> the *old* URI while using the new key" >> >> NEW TEXT: >> >> For example, it is acceptable for an OCSP Responder to rekey, >> stop using the old key, and continue to use >> the *same* URI while using the new key. >> >> Denis >> >> >> >> De : Santosh Chokhani <_SChokhani@cygnacom.com_ >> > >> A : "_denis.pinkas@bull.net_ " >> <_denis.pinkas@bull.net_ > >> Cc : "_pkix@ietf.org_ " >> <_pkix@ietf.org_ > >> Date : 18/09/2012 21:27 >> Objet : RE: [pkix] draft-pinkas-rfc2560bis-00 >> >> >> ------------------------------------------------------------------------ >> >> >> >> >> >> Denis, >> >> Thanks. Below are my updated recommended changes: >> >> Section 3.2 >> >> Add the following Note after the second dash: >> >> Note: The change in accessLocation is necessary when the CA >> rekeys to meet the following constraints imposed by this >> standard: 1) a BasicOCSPResponse can only be signed using a >> single private key; 2) the response must be signed using the >> same CA key that was used to sign the certificate in >> question; and 3) the OCSP response needs to cover all the >> certificates queried in the OCSP request. >> >> Section 3.3.2: >> >> Add the following Note to the 3^rd and the last paragraph: >> >> Note: The CA may need to continue issuing certificates to the >> OCSP Responder using the old CA key until all the >> certificates issued under the CA' old key for which the OCSP >> Responder is authoritative for expire. >> >> Section 3.3.3: >> >> OLD TEXT: >> >> "For a given URI value identifying the location of an OCSP >> Responder, the OCSP Responder SHALL only use one OCSP key >> pair value." >> >> NEW TEXT: >> >> "For a given URI value identifying the location of an OCSP >> Responder, the OCSP Responder SHALL only use one OCSP key >> pair value for a given period of time. For example, it is >> acceptable for an OCSP Responder to rekey, stop using the old >> key, and continue to use the old URI while using the new key" >> >> Section 3.4: >> >> OLD TEXT: >> >> Note: For each candidate certificate, when performing the path >> validation algorithm, the OCSP client will verify that the >> current time is within the validity period of the target >> certificate. Thus, certificates which are outside their >> validity period will not be included in the request or will >> be rejected later on by the OCSP responder. >> >> >> NEW TEXT: >> >> Note: For each candidate certificate, when performing the path >> validation algorithm, the OCSP client SHOULDverify that the >> current time is within the validity period of the target >> certificate. Thus, certificates which are outside their >> validity period SHOULDnot be included in the request. >> >> Section 4.3.1.3: >> >> OLD TEXT: >> >> For each CA from which the locally trusted Responder has >> received a >> delegation, the OCSP Responder SHALL maintain a list of >> entries. >> >> >> NEW TEXT: >> >> For each CA forwhich the locally trusted Responder is >> authoritative, the OCSP Responder SHALL maintain a list of >> entries. >> >> RATIONALE: >> >> The locally trusted responder need not have delegation from >> the CA >> >> Section 4.3.2: >> >> Add the following at the end of STEP 2: >> >> check whether the response is signed using the OCSP Responder >> key: >> >> If it is the case, then the revocation status of that >> certificate as indicated in the certStatus field is >> accepted and proceed to step 3. >> >> If it is not the case, then the revocation status >> of that >> certificate is "unknown" and proceed to step 3. >> >> Rationale: Current draft does not cover when the response is >> signed by the OCSP Responder >> >> Change S. Shokhani to S. Chokhani >> >> * >> From:* _denis.pinkas@bull.net_ >> [_mailto:denis.pinkas@bull.net_] * >> Sent:* Monday, September 17, 2012 3:59 AM* >> To:* Santosh Chokhani* >> Cc:* _pkix@ietf.org_ * >> Subject:* RE: [pkix] draft-pinkas-rfc2560bis-00 >> >> Santosh, >> >> Thank you for your very valuable comments. It took me "some >> time" to process them. >> It will take you "some time" to review them. :-) >> >> Since the comments and the changes were numerous, I have >> issued a new draftwhich is available at:_ >> __http://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-01.txt_ >> >> For Santosh in particular, see my responses below in lines. >> >> Denis, >> >> Thanks for this. My initial review indicates that this a >> very good first draft. >> Note that I did not review ASN.1 carefully (I assume it was >> copied from the existing RFC). >> >> It was copied from the draft prepared by Stefan, but the ASN. >> 1 module needs to be modified >> since the syntax of nonce has been omitted. >> >> I have added: >> >> Nonce ::= OCTET STRING >> >> Since the syntax of the nocheck extension was missing, I have >> also added: >> >> NoCheck ::= NULL >> >> In the introduction, I have also added: >> >> o Section 4.3.2 now indicates that the value of the nocheck >> extension SHALL be NULL. >> >> The ASN.1 module that conforms to the 2002 version of ASN.1 >> which may be found in Section 4 >> of RFC5912 has another problem, since the nocheck extension >> has been omitted. >> >> I have added: >> >> -- Certificate Extension >> >> ocsp-nocheck EXTENSION ::= { SYNTAX NULL >> IDENTIFIED BY >> id-pkix-ocsp-nocheck } >> >> This means that we cannot keep the same OID for the two ASN. >> 1 modules and thus we will need two new ones. >> >> I have now included both syntaxes in draft -01. >> >> In the introduction, I have also added: >> >> o Annex B includes a new ASN.1 module using the 1988 syntax >> since the syntax of nonce had been omitted. It also >> includes >> a new ASN.1 module using the 2002 syntax since in the >> ASN.1 >> module which may be found in Section 4 of RFC5912 the >> nocheck >> extension had been omitted. >> >> I do have the following comment though: >> >> Section 2.2: When the CA is signing the response, should it >> not also use the same key to sign the response >> as the certificate in question? The later part of the >> section indicates this as a requirement. >> In that case, why not make this explicit like the OCSP Responder. >> >> You are correct: I have added: >> >> In the former case, the CA MUST use the same key as the one >> that was >> used to issue the target certificate. >> >> Section 3.1.3, First paragraph, the rational for CA >> certificates to have digital signature bit set because >> they sign OCSP certificates is incorrect. May be what you >> mean is that a CA that signs OCSP responses >> needs to have digital signature bit set in its own >> certificate (i.e., the certificate for which the CA is the >> subject). >> >> Oups! The text was: >> >> Therefore the digitalSignature bit in the keyUsage extension >> MUST >> be set. >> >> Note 1: Since the CA issues certificates, the keyCertSign bit >> MUST also >> be set. >> >> Note 2: If the CA supports CRLs, in particular to revoke the >> certificate of the OCSP Responders, then the cRLSign >> bit, the >> digitalSignature bit and the keyCertSig bit MUST be set. >> >> I have changed it into: >> >> Therefore the keyCertSign bit in the keyUsage extension MUST >> be set. >> >> If the CA supports CRLs, in particular to revoke the >> certificate of >> the OCSP Responders, then both the cRLSign bit and the >> keyCertSig >> bit MUST be set. >> >> Section 3.1.3, Note 2, Again there is no requirement for >> digital signature bit to be set just because the CA signs >> certificates and CRLs. >> >> You are correct. See the correction proposed above. >> >> Section 3.2: It not clear which accessLocation is being >> referred to here (cAissuers or OCSP). If this is OCSP, >> the RFC is overly implementation specific. A CA can use the >> same OCSP location and sign the response with >> appropriate key and include the appropriate CA certificate >> without having to change the OCSP pointer. >> >> Section 3.2 addresses the case of CA that directly supports >> an OCSP serviceand which performs a key rollover. >> If the CA key changes, the OCSP location must change since it >> is only possible use a single key to sign the OCSP >> responses. Nevertheless, I take your other point to be more >> specific about the accessLocation. >> The point is addressed later on in another comment from you. >> >> General: The I-D does not address how the CA deals with the >> situation when status of multiple certificates issued by the CA, >> but using different keys is requested. May be the >> restriction in 3.2 is used to ensure that such situation does >> not occur. >> If so, a short discussion would be helpful. >> >> Your comment is related to section 4.3.1.1. ("Processing by a >> CA acting as an OCSP responder"). >> The case is already addressed with the following text: >> >> For each target certificate, the OCSP responder SHALL verify >> whether >> both the hash of the issuer's DN and the hash of the issuer >> public >> key which are present in the request match respectively with >> the DN >> and the hash of the public key of contained in an entry from the >> list of entries maintained by this OCSP responder. >> >> When there is no match, then the OCSP responder SHALL >> indicate the >> "unknown" status and proceed with the next target certificate >> from >> the OCSP request. >> >> General: It not clear which accessLocation is being referred >> to in most places. >> It would be worth stating that it refers to OCSP in all cases >> unless otherwise stated. >> >> I have added a note after the first occurrence of the word in >> section 3.1.1. >> >> Note: accessLocation is mentioned in several places of this >> document. >> It refers in all cases to the accessLocation field that is >> present >> in an AIA extension field to designate the location of the >> OCSP >> responder. In that case, the accessMethod field contains the >> id-ad-ocsp OID. >> >> Section 3.3.2 does not fully and explicitly cover the most >> common implementation I have seen and that is short life >> certificates. >> In that scenario, the CA needs to continue to issue the OCSP >> Responder certificate using the old CA key until all the >> certificates >> issued by the CA using the old key and for which the OCSP >> Responder is authoritative expire. >> The text in 3.3.3 can form a model for this when CA rekeys >> and OCSP Responder has the old keys. >> >> The text in section 3.3.2 does not say what you say. Please >> be more specific or since the text is short, provide an >> alternative >> >> Section 3.3.3, the last sentence is not desirable and can >> cause problems with some implementations. >> It is perfectly ok for a Responder to change its key >> independent of certificate it is authoritative for. >> Note that OCSP field in a issue certificate cannot be changed >> just because the Responder rekyed, >> be it routine or due to loss or compromise of Responder key. >> >> The text in section 3.3.3 does not say what you say. Please >> be more specific or since the text is short, provide an >> alternative. >> >> Section 3.4, last paragraph, I would think that expiration >> checking need not be part of OCSP client. >> Expiration checking should come under 5280 certificate >> validation. >> >> The text was: >> >> For each candidate certificate, the OCSP client SHALL verify >> that >> the current time is within the validity period of the target >> certificate. If this is not the case, the candidate certificate >> SHALL be discarded. >> >> I have changed it into; >> >> Note: For each candidate certificate, when performing the path >> validation algorithm, the OCSP client will verify that the >> current time is within the validity period of the target >> certificate. Thus, certificates which are outside their >> validity period will not be included in the request or will >> be rejected later on by the OCSP responder. >> >> Section 4.1, We should dilute two CAs "never have the same >> issuerKeyHash" to something more akin >> to statistically infeasible. >> >> The text was: >> >> Two CAs will never, however, have the same public key >> unless the >> CAs either explicitly decided to share their private key, >> or the >> key of one of the CAs was compromised. >> >> I have changed it into: >> >> However, it is statistically infeasible that two CAs use >> the same >> public key unless the CAs either explicitly decided to share >> their private key, or the key of one of the CAs was >> compromised. >> >> Titles of subsections under 4.3 could stand improvements. >> Responders process request and produce response; >> they do not process responses. Clients process responses. >> >> The titles were: >> >> 4.3. Response processing >> 4.3.1. Response processing by OCSP servers >> 4.3.1.1. Processing by a CA acting as an OCSP responder >> 4.3.1.2. Processing by an OCSP Responder >> 4.3.2. Response processing by an OCSP client >> >> I have changed them into: >> >> 4.3. Processing of requests and responses >> 4.3.1. Request processing by OCSP servers >> 4.3.1.1. Processing by a CA acting as an OCSP responder >> 4.3.1.2. Processing by an OCSP Responder >> 4.3.2. Response processing by an OCSP client >> >> Section 4.3.1.1, The entry should contain method used to gain >> access and sign just like the text in 4.3.1.2 >> as opposed to the private key. In other words, align the two >> texts for accessing and using private key >> to sign OCSP responses. >> >> Both sections have been aligned. >> >> Section 4.3.1,1, page 18 "defined in entry" could be >> misinterpreted as method define in request entry. >> >> I don't think that a change is necessary, since it uses the >> term "for each target certificate" and the entry thus >> refers to one of the entries from the tables of entries >> advertised at the beginning of the section. >> If you believe that a change is necessary, would you be able >> to make a proposal ? >> >> Section 4.3.1.2, Again the same comment, for the delegated >> OCSP Responder, changing the URL >> when key is changed is not required and breaks many >> implementations and hence is unacceptable. >> >> Would you be able to be more specific, since I don't see that >> the text states what you mean ? >> >> Section 4.3.2, the check for thisUpdate is flawed since this >> value may be derived from CRL even for responses >> that are not pre-generated and hence can be hours or days off >> depending on CRL issuance frequency, >> It is better to replace it with producedAt field in the >> response whether it is related to current time or time in the >> past. >> >> Good catch ! >> >> The text has been changed into : >> >> If the checking time is the current time, and if no nonce has >> been >> used in the request, OCSP clients MUST check that the producedAt >> field is within a time window that is "close enough" to the >> current >> time. >> >> If the checking time is a time in the past, verifiers MUST check >> that the producedAt field is in accordance with the verification >> rules (e.g. close and/or after the date of a time-stamp token). >> >> Section 4,3,2 is missing processing signature on the response >> and processing response extension. >> >> I don't understand your request about "missing processing >> signature on the response", since this point is addressed >> under STEP 2. If you believe that a change is necessary, >> would you be able to be more specific ? >> >> Processing response extension is only covered for >> singleExtensions when the criticality flag is set and >> the extension is not understood. So you are correct to >> request additional text to handle the other cases. >> >> The following text has been added for the processing of >> responseExtensions: >> >> OCSP clients or verifiers SHALL check if the response contains a >> critical responseExtensions. If such an extension is found >> and is >> recognized, it MUST be processed. If such an extension is >> found and >> is not recognized, the whole OCSP response MUST be considered as >> invalid. >> >> The following text has been added for the processing of >> singleExtensions: >> >> If checks are successful, then OCSP clients MUST process the >> singleExtensions field, if it is present. >> >> If the criticality flag is set and the extension is not >> understood, >> then the status of the certificate shall be "unknown" and >> proceed to >> step 3. Otherwise, proceed to step 2. >> >> If the extension is understood, then the extension MUST be >> processed. According to its content proceed either to step 2 >> or to >> step 3. >> >> Section 5.5: Replay attack is also possible when not using >> pre-computed responses. >> >> I have added in new section with the following text: >> >> 5.7. Other replay attacks >> >> As already mentioned in section 5.5, replay attacks are possible >> using precomputed responses. Replay attacks are also >> possible when >> no nonce is being used in the OCSP request and the time window >> mentioned in section 4.3.2 (STEP 1)is too large. >> >> General: Removal of locally trusted Responder from the I-D is >> unacceptable. >> >> The intent was not to remove the "locally trusted Responder". >> Nevertheless, the current text has been improved >> in several places. For example, in the introduction, I have >> added: >> >> The term "locally trusted Responder" is used to designate >> an OCSP >> responder that is trusted using local rules. >> >> In section 2.2, the text now states: >> >> A response message MUST be signed either by a certificate's >> issuer, >> by an authorized OCSP Responder or according to local rules. >> >> In the first case, the CA MUST use the same key as the one >> that was >> used to issue the target certificate. >> >> In the second case, the CA MUST explicitly designate the OCSP >> Responder by issuing an OCSP certificate to the OCSP Responder. >> OCSP signing delegation SHALL be indicated by the inclusion of >> id-kp-OCSPSigning in an extendedKeyUsage certificate extension >> included in the OCSP response signer's certificate. This >> certificate MUST be issued directly by the CA and under the >> same key >> that was used to issue the target certificate. >> >> For these two cases, systems or applications that rely on OCSP >> responses MUST be capable of detecting and enforcing use of the >> id-ad-ocspSigning value as described above. >> >> In the third case, the OCSP client uses a locally trusted >> Responder. >> The key used to sign OCSP responses may be directly trusted >> or be a >> key contained in an OCSP certificate which is verified >> according to >> local rules, instead of the rules detailed in this document. >> >> In section I have changed the following text : >> >> The OCSP certificate SHALL be signed by the CA issuing >> private key >> which corresponds to the issuing CA public key that is in this >> entry, unless some specific rules are agreed between the OCSP >> Responder and OCSP clients. In that later case, the OCSP >> certificate MAY be signed by a different entity. >> >> into: >> >> The OCSP certificate SHALL be signed by the CA issuing >> private key >> which corresponds to the issuing CA public key that is in this >> entry, unless some specific rules are agreed between the OCSP >> Responder and OCSP clients. In that later case, which >> corresponds >> to the case of a locally trusted Responder, the OCSP >> certificate MAY >> be signed by a different entity. >> >> There is now also a completely new section: 4.3.1.3, called >> "Processing by a locally trusted Responder". >> >> When reviewing the text, I found that, in section 4.3.1.2, >> the list only mentioned: >> >> - the method(s) used to obtain the revocation status of the >> certificates issued under that CA issuing public key, >> >> In practice, an OCSP responder may not be responsible for all >> the certificates issued by a CA. >> So it also needs to know which subset of the certificates >> issued by each CA it is responsible for. >> >> Thus I have changed the text into: >> >> - the method(s) used to know for which subset of certificates >> issued by the CA it is responsible for, >> >> - the method(s) used to obtain the revocation status of that >> subset of certificates issued under that CA issuing >> public key, >> >> >> Denis >> >> > A new Internet-Draft is available from the on-line >> Internet-Drafts >> > directories. >> > >> > Title : X.509 Internet PublicKey Infrastructure >> Online >> > Certificate Status Protocol - OCSP >> > Author(s) : D. Pinkas >> > Filename : draft-pinkas-rfc2560bis >> > Pages : 41 >> > Date : Aug. 27, 2012 >> > >> > This document specifies a protocol useful in determining >> the current >> > status of a digital certificate without requiring CRLs. >> Additional >> > mechanisms addressing PKIX operational requirements are >> specified in >> > separate documents. This document obsoletes RFC 2560 and >> RFC 6277. >> > >> > A URL for this Internet-Draft is: >> > >> _http://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-00.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. >> > >> > <_ftp://ftp.ietf.org/internet-drafts/draft-pinkas-rfc2560bis_> >> > >> > A few explanations about the content of >> draft-ietf-pinkas-rfc2560bis-00. >> > >> > 25 changes are indicated at the beginning of the document. >> > I will only mention a few of them: >> > >> > A - Explanations were missing to describe: >> > >> > - the building of a request by an OCSP client, >> > - the processing of a request by an OCSP server, >> > - the building of a response by an OCSP server, and >> > - the processing of a response by an OCSP client. >> > >> > These explanations have been added. >> > >> > B - Explanations were missing to address CA key rollover >> and OCSP >> > key rollover. These explanations have been added. >> > >> > C - Backwards compatibility has been addressed in the >> --------------020201080003000603090208 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=ISO-8859-1
Stefan,

You will find detailed explanations of all the changes in the first pages of my draft.
You win a special prize, if you find a major change that is not indicated !
 
Since the RFC was badly structured, for example, the description of the parameters for the request and the response
was scattered all over the document, some descriptions were missing, then its current format could not be kept.

In my draft, each parameter is now described either with the request or with the response. the processing is described just after,
from a client and then from a server prospective.

Some processing of the elements were missing and the most important was that the processing of the response was wrong.

I have added information for handling key rollover that influence the way to use the protocol. I believe this information is important,
but I would not object to move it in an annex

Since we now both know that it will be possible to have a quick face to face meeting in London next week on Tuesday, 
I propose that we both come with a printed version of the draft and then we can discuss the changes and the rational of each change
that is not always fully explained, since this will have overloaded the document (which is already sufficiently heavy).

Denis


Denis,

Unfortunately, the number changes are too many to make a fast detailed review providing suggestions on corrections to all issues.
I could provide examples, but that would not be a complete list.

However,

As the WG and AD has decided that we should start with as few changes as possible and only add what is necessary, I would like to reverse this.
Could you provide an argument for each change to the current WG draft that you think is necessary?

/Stefan


From: Denis Pinkas Bull <denis.pinkas@bull.net>
Date: Thursday, October 11, 2012 7:42 AM
To: Stefan Santesson <stefan@aaa-sec.com>
Cc: Santosh Chokhani <SChokhani@cygnacom.com>, "pkix@ietf.org" <pkix@ietf.org>
Subject: Re: [pkix] draft-pinkas-rfc2560bis-03

Stefan,

Thank you for your comments.

However, your first two comments are not specific enough to know portions of text you would like to be removed.
Would you be able to be more specific ?

On your third comment, you say: The distinction between OCSP responder, OCSP server and OCSP service is
in this context confusing and adds nothing useful to an implementer on either side of the protocol.

You are right to say that there is no need to make a difference between an OCSP server and
an OCSP responder, and I can change this in the draft.

However, the distinction between an OCSP service supported by one or more OCSP responders should be maintained.

Denis

Denis,

Posting my major comments on this draft:

- This is a substantial rewrite of the original standard. There has been a
WG decision to limit changes to RFC 2560 to what is necessary to resolve
previous ambiguity. In many places, the text provided in your draft adds
confusion and adds ambiguity instead of removing them.

- This is a protocol specification. That is, it defines the data elements
exchanged for the purpose of doing OCSP checks. It is NOT a system design
specification. Processing rules are only relevant if they have a direct
impact on the bits on the wire.

- The distinction between OCSP responder, OCSP server and OCSP service is
in this context confusing and adds nothing useful to an implementer on
either side of the protocol.

/Stefan

From: <denis.pinkas@bull.net>
Date: Tuesday, September 25, 2012 5:01 PM
To: Santosh Chokhani <SChokhani@cygnacom.com>
Cc: "pkix@ietf.org" <pkix@ietf.org>
Subject: [pkix] draft-pinkas-rfc2560bis-03

Santosh,

This text change has been included in draft -03 which is now available at :

http://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-03.txt

Denis



De :        Santosh Chokhani <SChokhani@cygnacom.com>
A :        "denis.pinkas@bull.net" <denis.pinkas@bull.net>
Cc :        "pkix@ietf.org" <pkix@ietf.org>
Date :        24/09/2012 18:21
Objet :        RE: draft-pinkas-rfc2560bis-02



Denis,
 
OK except a nit (replace “accessLocation field from” to “accessLocation field of”)
 
From: denis.pinkas@bull.net [mailto:denis.pinkas@bull.net]
Sent: Monday, September 24, 2012 2:17 AM
To: Santosh Chokhani
Cc: pkix@ietf.org
Subject: RE: draft-pinkas-rfc2560bis-02
 
Santosh,

Your point is valid. Here is a proposed change to solve the issue.

OLD TEXT:

  For a given URI value identifying the location of an OCSP Responder,
  the OCSP Responder SHALL only use one OCSP key pair value for a
  given period of time.  For example, it is acceptable for an OCSP
  Responder to rekey, stop using the old key, and continue to use the
  same URI while using the new key.

NEW TEXT:

  An OCSP Responder key rollover does not affect the values of the
  URIs that are placed in the accessLocation field from the target
  certificates.  One or more OCSP Responder MAY respond to an OCSP
  request addressed at a given URI picked from the accessLocation
  field from a target certificate.  Each OCSP Responder MAY use a
  different signing key, as long as it got an OCSP certificate
  appropriate for that signing key and for the target certificate.

Denis



De :        Santosh Chokhani <SChokhani@cygnacom.com>
A :        "denis.pinkas@bull.net" <denis.pinkas@bull.net>
Cc :        "pkix@ietf.org" <pkix@ietf.org>
Date :        21/09/2012 17:42
Objet :        RE: draft-pinkas-rfc2560bis-02





Denis,
 
Thanks.  I am ok with your changes.
 
One thing listed below is troubling me and I would like your and others’ opinion on it.
 
While you have revised the text in Section 3.3.3 as I requested, it is overly constraining and has been troublesome from the beginning.  The text I refer to is: “For a given URI value identifying the location of an OCSP Responder, the OCSP Responder SHALL only use one OCSP key pair value for a given period of time”.
 
While I can see how this assertion simplifies the sausage-making of the standard and the data structures you spell out, it is something these need not be applies in order for the OCSP to work.   It is generally a bad ideas in a standard to impose a constraint that is not necessary for feasibility, security or interoperability reasons.
 
For example, one could have geographical load balancing and/or geographicalredundancy for the URL and rather than porting the same key, have differentkeys for the Servers.  In that case, the actual Server that got the request routed would sign the response.
 
Another example, is the URL and the server map to the same machine and it has multiple keys and can use any one of them.
 
I do agree that there needs to be some constraint that specifies that the server must be able to provide response to all the queries it is authoritative for and meet the cryptographic binding requirement.
I think we need to work the 3.3.3 language so that the constraint is specified such that it does not prohibit valid architectures.
 
From: denis.pinkas@bull.net [mailto:denis.pinkas@bull.net]
Sent: Friday, September 21, 2012 9:22 AM
To: Santosh Chokhani
Cc: pkix@ietf.org
Subject: draft-pinkas-rfc2560bis-02
 
Santosh,

Thank you for these new comments. I have one comment back and two nits.

You suggested to add text at the end of STEP 2, since the current draft does not cover when the response is signed by the OCSP Responder.
Your rational is quite true. However, your propose change does not fit well. I have changed the text differently

Please take a look at draft -02 which has been issued today.
http://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-02.txt

First nit :

PROPOSED TEXT:

Note: The CA may need to continue issuing certificates to the OCSP Responder using the old CA key until
all the certificates issued under the CA’ old key for which the OCSP Responder is authoritative for expire.

NEW TEXT:

Note: The CA may need to continue issuing certificates to the OCSP Responder using the old CA key until
all the certificates issued under the CA’ old key for which the OCSP Responder is authoritative have expired.

Second nit :

PROPOSED TEXT:

For example, it is acceptable for an OCSP Responder to rekey, stop using the old key, and continue to use
the old URI while using the new key”

NEW TEXT:

For example, it is acceptable for an OCSP Responder to rekey, stop using the old key, and continue to use
the same URI while using the new key.

Denis



De :        Santosh Chokhani <SChokhani@cygnacom.com>
A :        "denis.pinkas@bull.net" <denis.pinkas@bull.net>
Cc :        "pkix@ietf.org" <pkix@ietf.org>
Date :        18/09/2012 21:27
Objet :        RE: [pkix] draft-pinkas-rfc2560bis-00

 





Denis,

Thanks.  Below are my updated recommended changes:

Section 3.2

Add the following Note after the second dash:

Note: The change in accessLocation is necessary when the CA rekeys to meet the following constraints imposed by this standard: 1) a BasicOCSPResponse can only be signed using a single private key; 2) the response must be signed using the same CA key that was used to sign the certificate in question; and 3) the OCSP response needs to cover all the certificates queried in the OCSP request.

Section 3.3.2:

Add the following Note to the 3rd and the last paragraph:

Note: The CA may need to continue issuing certificates to the OCSP Responder using the old CA key until all the certificates issued under the CA’ old key for which the OCSP Responder is authoritative for expire.

Section 3.3.3:

OLD TEXT:

“For a given URI value identifying the location of an OCSP Responder, the OCSP Responder SHALL only use one OCSP key pair value.”

NEW TEXT:

“For a given URI value identifying the location of an OCSP Responder, the OCSP Responder SHALL only use one OCSP key pair value for a given period of time.  For example, it is acceptable for an OCSP Responder to rekey, stop using the old key, and continue to use the old URI while using the new key”

Section 3.4:

OLD TEXT:

Note:  For each candidate certificate, when performing the path
     validation algorithm, the OCSP client will verify that the
     current time is within the validity period of the target
     certificate.  Thus, certificates which are outside their
     validity period will not be included in the request or will
     be rejected later on by the OCSP responder.


NEW TEXT:

Note:  For each candidate certificate, when performing the path
     validation algorithm, the OCSP client SHOULD verify that the
     current time is within the validity period of the target
     certificate.  Thus, certificates which are outside their
     validity period SHOULD not be included in the request.

Section 4.3.1.3:

OLD TEXT:

 For each CA from which the locally trusted Responder has received a
 delegation, the OCSP Responder SHALL maintain a list of entries.


NEW TEXT:

For each CA for which the locally trusted Responder is authoritative, the OCSP Responder SHALL maintain a list of entries.

RATIONALE:

The locally trusted responder need not have delegation from the CA

Section 4.3.2:

Add the following at the end of STEP 2:

check whether the response is signed using the OCSP Responder key:

           If it is the case, then the revocation status of that
           certificate as indicated in the certStatus field is
           accepted and proceed to step 3.

           If it is not the case, then the revocation status of that
           certificate is "unknown" and proceed to step 3.

Rationale: Current draft does not cover when the response is signed by the OCSP Responder

Change S. Shokhani to S. Chokhani


From: denis.pinkas@bull.net [mailto:denis.pinkas@bull.net]
Sent: Monday, September 17, 2012 3:59 AM
To: Santosh Chokhani
Cc: pkix@ietf.org
Subject: RE: [pkix] draft-pinkas-rfc2560bis-00

Santosh,

Thank you for your very valuable comments. It took me "some time" to process them.
It will take you "some time" to review them. :-)

Since the comments and the changes were numerous, I have issued a new draftwhich is available at:
http://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-01.txt

For Santosh in particular, see my responses below in lines.

Denis,

Thanks for this.  My initial review indicates that this a very good first draft.  
Note that I did not review ASN.1 carefully (I assume it was copied from the existing RFC).

It was copied from the draft prepared by Stefan, but the ASN. 1 module needs to be modified
since the syntax of nonce has been omitted.

I have added:

Nonce ::= OCTET STRING

Since the syntax of the nocheck extension was missing, I have also added:

NoCheck ::= NULL

In the introduction, I have also added:

   o  Section 4.3.2 now indicates that the value of the nocheck
      extension SHALL be NULL.

The ASN.1 module that conforms to the 2002 version of ASN.1 which may be found in Section 4
of RFC5912 has another problem, since the nocheck extension has been omitted.

I have added:

--  Certificate Extension

ocsp-nocheck EXTENSION ::= { SYNTAX NULL
                                      IDENTIFIED BY
                                      id-pkix-ocsp-nocheck }

This means that we cannot keep the same OID for the two ASN. 1 modules and thus we will need two new ones.

I have now included both syntaxes in draft -01.

In the introduction, I have also added:

   o  Annex B includes a new ASN.1 module using the 1988 syntax
      since the syntax of nonce had been omitted.  It also includes
      a new ASN.1 module using the 2002 syntax since in the ASN.1
      module which may be found in Section 4 of RFC5912 the nocheck
      extension had been omitted.

I do have the following comment though:

Section 2.2: When the CA is signing the response, should it not also use the same key to sign the response
as the certificate in question?  The later part of the section indicates this as a requirement.  
In that case, why not make this explicit like the OCSP Responder.

You are correct: I have added:

In the former case, the CA MUST use the same key as the one that was
used to issue the target certificate.

Section 3.1.3, First paragraph, the rational for CA certificates to have digital signature bit set because
they sign OCSP certificates is incorrect.  May be what you mean is that a CA that signs OCSP responses
needs to have digital signature bit set in its own certificate (i.e., the certificate for which the CA is the subject).

Oups! The text was:

Therefore the digitalSignature bit in the keyUsage extension MUST
be set.

Note 1: Since the CA issues certificates, the keyCertSign bit MUST also
     be set.

Note 2: If the CA supports CRLs, in particular to revoke the
     certificate of the OCSP Responders, then the cRLSign bit, the
     digitalSignature bit and the keyCertSig bit MUST be set.

I have changed it into:

Therefore the keyCertSign bit in the keyUsage extension MUST be set.

If the CA supports CRLs, in particular to revoke the certificate of
the OCSP Responders, then both the cRLSign bit and the keyCertSig
bit MUST be set.

Section 3.1.3, Note 2, Again there is no requirement for digital signature bit to be set just because the CA signs
certificates and CRLs.

You are correct. See the correction proposed above.

Section 3.2: It not clear which accessLocation is being referred to here (cAissuers or OCSP).  If this is OCSP,
the RFC is overly implementation specific.  A CA can use the same OCSP location and sign the response with
appropriate key and include the appropriate CA certificate without having to change the OCSP pointer.

Section 3.2 addresses the case of CA that directly supports an OCSP serviceand which performs a key rollover.  
If the CA key changes, the OCSP location must change since it is only possible use a single key to sign the OCSP
responses. Nevertheless, I take your other point to be more specific about the accessLocation.
The point is addressed later on in another comment from you.

General: The I-D does not address how the CA deals with the situation when status of multiple certificates issued by the CA,
but using different keys is requested.  May be the restriction in 3.2 is used to ensure that such situation does not occur.  
If so, a short discussion would be helpful.

Your comment is related to section 4.3.1.1. (“Processing by a CA acting as an OCSP responder”).
The case is already addressed with the following text:

For each target certificate, the OCSP responder SHALL verify whether
both the hash of the issuer's DN and the hash of the issuer public
key which are present in the request match respectively with the DN
and the hash of the public key of contained in an entry from the
list of entries maintained by this OCSP responder.

When there is no match, then the OCSP responder SHALL indicate the
"unknown" status and proceed with the next target certificate from
the OCSP request.

General: It not clear which accessLocation is being referred to in most places.
It would be worth stating that it refers to OCSP in all cases unless otherwise stated.

I have added a note after the first occurrence of the word in section 3.1.1.

Note: accessLocation is mentioned in several places of this document.
   It refers in all cases to the accessLocation field that is present
   in an AIA extension field to designate the location of the OCSP
   responder.  In that case, the accessMethod field contains the
   id-ad-ocsp OID.

Section 3.3.2 does not fully and explicitly cover the most common implementation I have seen and that is short life certificates.  
In that scenario, the CA needs to continue to issue the OCSP Responder certificate using the old CA key until all the certificates
issued by the CA using the old key and for which the OCSP Responder is authoritative expire.  
The text in 3.3.3 can form a model for this when CA rekeys and OCSP Responder has the old keys.

The text in section 3.3.2 does not say what you say. Please be more specific or since the text is short, provide an alternative

Section 3.3.3, the last sentence is not desirable and can cause problems with some implementations.
It is perfectly ok for a Responder to change its key independent of certificate it is authoritative for.  
Note that OCSP field in a issue certificate cannot be changed just because the Responder rekyed,
be it routine or due to loss or compromise of Responder key.

The text in section 3.3.3 does not say what you say. Please be more specific or since the text is short, provide an alternative.

Section 3.4, last paragraph, I would think that expiration checking need not be part of OCSP client.  
Expiration checking should come under 5280 certificate validation.

The text was:

For each candidate certificate, the OCSP client SHALL verify that
the current time is within the validity period of the target
certificate.  If this is not the case, the candidate certificate
SHALL be discarded.

I have changed it into;

Note:  For each candidate certificate, when performing the path
    validation algorithm, the OCSP client will verify that the
    current time is within the validity period of the target
    certificate.  Thus, certificates which are outside their
    validity period will not be included in the request or will
    be rejected later on by the OCSP responder.

Section 4.1, We should dilute two CAs “never have the same issuerKeyHash” to something more akin
to statistically infeasible.

The text was:

   Two CAs will never, however, have the same public key unless the
   CAs either explicitly decided to share their private key, or the
   key of one of the CAs was compromised.

I have changed it into:

   However, it is statistically infeasible that two CAs use the same
   public key unless the CAs either explicitly decided to share
   their private key, or the key of one of the CAs was compromised.

Titles of subsections under 4.3 could stand improvements.  Responders process request and produce response;
they do not process responses.  Clients process responses.

The titles were:

  4.3. Response processing
    4.3.1. Response processing by OCSP servers
      4.3.1.1. Processing by a CA acting as an OCSP responder
      4.3.1.2. Processing by an OCSP Responder
    4.3.2. Response processing by an OCSP client

I have changed them into:

  4.3. Processing of requests and responses
    4.3.1. Request processing by OCSP servers
      4.3.1.1. Processing by a CA acting as an OCSP responder
      4.3.1.2. Processing by an OCSP Responder
    4.3.2. Response processing by an OCSP client

Section 4.3.1.1, The entry should contain method used to gain access and sign just like the text in 4.3.1.2
as opposed to the private key.  In other words, align the two texts for accessing and using private key
to sign OCSP responses.

Both sections have been aligned.

Section 4.3.1,1, page 18 “defined in entry” could be misinterpreted as method define in request entry.

I don’t think that a change is necessary, since it uses the term “for each target certificate” and the entry thus
refers to one of the entries from the tables of entries advertised at the beginning of the section.
If you believe that a change is necessary, would you be able to make a proposal ?

Section 4.3.1.2, Again the same comment, for the delegated OCSP Responder, changing the URL
when key is changed is not required and breaks many implementations and hence is unacceptable.

Would you be able to be more specific, since I don’t see that the text states what you mean ?

Section 4.3.2, the check for thisUpdate is flawed since this value may be derived from CRL even for responses
that are not pre-generated and hence can be hours or days off depending on CRL issuance frequency,
It is better to replace it with producedAt field in the response whether it is related to current time or time in the past.

Good catch !

The text has been changed into :

If the checking time is the current time, and if no nonce has been
used in the request, OCSP clients MUST check that the producedAt
field is within a time window that is "close enough" to the current
time.

If the checking time is a time in the past, verifiers MUST check
that the producedAt field is in accordance with the verification
rules (e.g. close and/or after the date of a time-stamp token).

Section 4,3,2 is missing processing signature on the response and processing response extension.

I don’t understand your request about “missing processing signature on the response”, since this point is addressed
under STEP 2. If you believe that a change is necessary, would you be able to be more specific ?

Processing response extension is only covered for singleExtensions when the criticality flag is set and
the extension is not understood. So you are correct to request additional text to handle the other cases.

The following text has been added for the processing of responseExtensions:

OCSP clients or verifiers SHALL check if the response contains a
critical responseExtensions. If such an extension is found and is
recognized, it MUST be processed.  If such an extension is found and
is not recognized, the whole OCSP response MUST be considered as
invalid.

The following text has been added for the processing of singleExtensions:

If checks are successful, then OCSP clients MUST process the
singleExtensions field, if it is present.

If the criticality flag is set and the extension is not understood,
then the status of the certificate shall be "unknown" and proceed to
step 3.  Otherwise, proceed to step 2.

If the extension is understood, then the extension MUST be
processed.  According to its content proceed either to step 2 or to
step 3.

Section 5.5: Replay attack is also possible when not using pre-computed responses.

I have added in new section with the following text:

5.7. Other replay attacks

As already mentioned in section 5.5, replay attacks are possible
using precomputed responses.  Replay attacks are also possible when
no nonce is being used in the OCSP request and the time window
mentioned in section 4.3.2 (STEP 1)is too large.

General: Removal of locally trusted Responder from the I-D is unacceptable.

The intent was not to remove the “locally trusted Responder”. Nevertheless, the current text has been improved
in several places. For example, in the introduction, I have added:

   The term “locally trusted Responder” is used to designate an OCSP
   responder that is trusted using local rules.

In section 2.2, the text now states:

A response message MUST be signed either by a certificate's issuer,
by an authorized OCSP Responder or according to local rules.

In the first case, the CA MUST use the same key as the one that was
used to issue the target certificate.

In the second case, the CA MUST explicitly designate the OCSP
Responder by issuing an OCSP certificate to the OCSP Responder.
OCSP signing delegation SHALL be indicated by the inclusion of
id-kp-OCSPSigning in an extendedKeyUsage certificate extension
included in the OCSP response signer's certificate.  This
certificate MUST be issued directly by the CA and under the same key
that was used to issue the target certificate.

For these two cases, systems or applications that rely on OCSP
responses MUST be capable of detecting and enforcing use of the
id-ad-ocspSigning value as described above.

In the third case, the OCSP client uses a locally trusted Responder.
The key used to sign OCSP responses may be directly trusted or be a
key contained in an OCSP certificate which is verified according to
local rules, instead of the rules detailed in this document.

In section I have changed the following text :

The OCSP certificate SHALL be signed by the CA issuing private key
which corresponds to the issuing CA public key that is in this
entry, unless some specific rules are agreed between the OCSP
Responder and OCSP clients.  In that later case, the OCSP
certificate MAY be signed by a different entity.

into:

The OCSP certificate SHALL be signed by the CA issuing private key
which corresponds to the issuing CA public key that is in this
entry, unless some specific rules are agreed between the OCSP
Responder and OCSP clients.  In that later case, which corresponds
to the case of a locally trusted Responder, the OCSP certificate MAY
be signed by a different entity.

There is now also a completely new section: 4.3.1.3, called “Processing by a locally trusted Responder”.

When reviewing the text, I found that, in section 4.3.1.2, the list only mentioned:

  - the method(s) used to obtain the revocation status of the
    certificates issued under that CA issuing public key,

In practice, an OCSP responder may not be responsible for all the certificates issued by a CA.
So it also needs to know which subset of the certificates issued by each CA it is responsible for.

Thus I have changed the text into:

  - the method(s) used to know for which subset of certificates
    issued by the CA it is responsible for,

  - the method(s) used to obtain the revocation status of that
    subset of certificates issued under that CA issuing public key,


Denis

> A new Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>    Title         : X.509 Internet PublicKey Infrastructure Online
>                    Certificate Status Protocol - OCSP
>    Author(s)     : D. Pinkas
>    Filename      : draft-pinkas-rfc2560bis
>    Pages         : 41
>    Date          : Aug. 27, 2012
>    
>   This document specifies a protocol useful in determining the current
>   status of a digital certificate without requiring CRLs.  Additional
>   mechanisms addressing PKIX operational requirements are specified in
>   separate documents. This document obsoletes RFC 2560 and RFC 6277.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-00.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.
>
> <ftp://ftp.ietf.org/internet-drafts/draft-pinkas-rfc2560bis>
>
> A few explanations about the content of draft-ietf-pinkas-rfc2560bis-00.
>
> 25 changes are indicated at the beginning of the document.
> I will only mention a few of them:
>
> A - Explanations were missing to describe:
>
>      - the building of a request by an OCSP client,
>      - the processing of a request by an OCSP server,
>      - the building of a response  by an OCSP server, and
>      - the processing of a response by an OCSP client.
>
> These explanations have been added.
>
> B - Explanations were missing to address CA key rollover and OCSP
>     key rollover. These explanations have been added.
>
> C - Backwards compatibility has been addressed in the

--------------020201080003000603090208-- From stefan@aaa-sec.com Thu Oct 11 06:09:17 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDDB21F8771 for ; Thu, 11 Oct 2012 06:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.705 X-Spam-Level: X-Spam-Status: No, score=-100.705 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJdqXGkHv202 for ; Thu, 11 Oct 2012 06:09:16 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 566B721F877A for ; Thu, 11 Oct 2012 06:09:15 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 60063224FC10 for ; Thu, 11 Oct 2012 15:07:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id o81iVf944e89 for ; Thu, 11 Oct 2012 15:07:06 +0200 (CEST) Received: from s376.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 88346224FBF1 for ; Thu, 11 Oct 2012 15:07:04 +0200 (CEST) Received: (qmail 51646 invoked from network); 11 Oct 2012 13:07:04 -0000 Received: from static-213-115-40-164.sme.bredbandsbolaget.se (HELO [172.16.50.125]) (stefan@fiddler.nu@[213.115.40.164]) (envelope-sender ) by s376.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 11 Oct 2012 13:07:04 -0000 User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Thu, 11 Oct 2012 15:07:02 +0200 From: Stefan Santesson To: Denis Pinkas Message-ID: Thread-Topic: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt In-Reply-To: <5076BAC3.3050402@bull.net> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3432812825_5476458" Cc: pkix Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 13:09:17 -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_3432812825_5476458 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable I still think the gain obtained by your proposal is far less than the pain of introducing a new critical extension that needs client support. I still can't see an attacker achieving anything beyond a DoS and I can't see this scaled to a DDoS attack. Signed error or not. /Stefan From: Denis Pinkas Date: Thursday, October 11, 2012 2:25 PM To: Stefan Santesson Cc: Santosh Chokhani , pkix Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt > =20 > =20 > Stefan, > =20 > RFC 2560 states: > =20 > "In case of errors, the OCSP Responder may return an error message. > These messages are not signed". > =20 > So an "unauthorized" response is not signed. > =20 > The text from RFC 2560 states: > =20 > The response "unauthorized" is returned in cases where the client is > not authorized to make this query to this server. > =20 > The text from RFC 5019 states the following: > =20 > =20 >=20 > As long as the OCSP infrastructure has authoritative records for a > =20 > particular certificate, an OCSPResponseStatus of "successful" will be > =20 > returned. When access to authoritative records for a particular > =20 > certificate is not available, the responder MUST return an > =20 > OCSPResponseStatus of "unauthorized". As such, this profile extends > =20 > the RFC 2560 [OCSP] definition of "unauthorized" as follows: > =20 > =20 > =20 > The response "unauthorized" is returned in cases where the client > =20 > is not authorized to make this query to this server or the server > =20 > is not capable of responding authoritatively. > =20 > In the absence of the proposed extension, RFC 5019 could not do better. > =20 > With the proposed extension, it is possible to do better and to get a si= gned > "unknown" status in a signed response > rather than an "unauthorized" error in an unsigned response, that is har= der > to interpret and subject to attacks: > =20 > - was there a substitution attack, since this may not be a response fro= m the > authorized responder ? > - am I using a wrong URL, since I am not sure this response comes from = the > right URL ?=20 > - am I missing an authorization to get the status ? > =20 > Denis > =20 > =20 > =20 > =20 >> =20 >> The "unauthorized" response seems suitable to me. >> =20 >>=20 >> =20 >> =20 >> "The response "unauthorized" is returned in cases where the client is no= t >> authorized to make this query to this server or the server is not capabl= e of >> responding authoritatively (cf. [RFC5019], Section 2.2.3)" >> =20 >>=20 >> =20 >> =20 >> /Stefan >> =20 >>=20 >> =20 >> =20 >>=20 >> =20 >> =20 >>=20 >> =20 >> =20 >> From: Denis Pinkas Bull >> Date: Thursday, October 11, 2012 7:53 AM >> To: Stefan Santesson >> Cc: Santosh Chokhani , pkix >> Subject: Re: [pkix] New Version Notification for >> draft-pinkas-2560bis-ocsp-locationcheck-00.txt >> =20 >> =20 >>=20 >> =20 >> =20 >>> =20 >>> =20 >>> =20 >>> Stefan, >>> =20 >>> As fas as I know, there are only three major status: "good", "revoked"= or >>> "unknown". >>> =20 >>> Error messages are: >>> =20 >>> -- malformedRequest, >>> -- internalError, >>> -- tryLater, >>> -- sigRequired, >>> -- unauthorized. >>> =20 >>> There is no response like: "the responder is not authorised to provide >>> information about the cert". >>> In the example, the RP gets "unknown" (with a correct signature from = the >>> OCSP responder), >>> whereas it would have received either "good" or "revoked", if there h= ad >>> been no attack. >>> =20 >>> Denis >>> =20 >>> =20 >>> =20 >>>> =20 >>>> Sorry, Still don't get it. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> In your example, the client receives a response that the responder is = not >>>> authorised to provide information about the cert. >>>> =20 >>>> So a man-in-the-middle can do a DoS attack. That is not new. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> /Stefan >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> From: Denis Pinkas Bull >>>> Date: Thursday, October 11, 2012 7:31 AM >>>> To: Stefan Santesson >>>> Cc: Santosh Chokhani , pkix >>>> Subject: Re: [pkix] New Version Notification for >>>> draft-pinkas-2560bis-ocsp-locationcheck-00.txt >>>> =20 >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> Stefan, >>>>> =20 >>>>> You missed the point. Let me illustrate why using a simple scenario: >>>>> =20 >>>>> OCSP Responder 1 receives delegation from CA x for the first 100.000 >>>>> issued certificates. >>>>> OCSP Responder 1 has only access to the revocation status of the fir= st >>>>> 100.000 issued certificates. >>>>> The first 100.000 issued certificates contain url1 to locate OCSP >>>>> Responder 1. >>>>> =20 >>>>> OCSP Responder 2 receives delegation from CA x for the next 100.000 >>>>> issued certificates. >>>>> OCSP Responder 2 has only access to the revocation status of the nex= t >>>>> 100.000 issued certificates. >>>>> The next 100.000 issued certificates contains url2 to locate OCSP >>>>> Responder 2. >>>>> =20 >>>>> A Relying Party (RP) uses url1 that is present in the target certifi= cate >>>>> to query OCSP Responder 1. >>>>> However, there is a man-in-the-middle-attack and this request in rou= ted >>>>> to OCSP Responder 2. >>>>> OCP2 responder 2 responds that it don't know the status of this >>>>> certificate. >>>>> The response from OCSP Responder 2 is routed back to the RP. >>>>> The RP verifies that the response is indeed correctly signed. >>>>> =20 >>>>> If the man-in-the-middle attack were not done, the RP would have kno= wn >>>>> that the certificate >>>>> was either "revoked" or "good", since only OCSP Responder 1 knows it= . >>>>> =20 >>>>> Without the proposed extension, the protocol would provide incorrect >>>>> revocation status results. >>>>> =20 >>>>> Denis >>>>> =20 >>>>> =20 >>>>> =20 >>>>> Santesson a =E9crit : >>>>> =20 >>>>> =20 >>>>>> =20 >>>>>> Why do you need this at all? >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>> =20 >>>>>> I don't see that this extension is required in order to split OCSP >>>>>> responding for chunks of certs. >>>>>> =20 >>>>>> You can point the client to the correct responder using information = in >>>>>> the cert today. >>>>>> =20 >>>>>> The responder can determine if the requested vert is within it's han= dled >>>>>> portion of certs. >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>> =20 >>>>>> Given that you trust the OCSP responder and the responder is honest,= you >>>>>> will receive an appropriate response. >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>> =20 >>>>>> So, why the extension? >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>> =20 >>>>>> I can only imagine the extension being useful to detect if a respond= er >>>>>> responds outside of it's authority, but if the OCSP responder is >>>>>> dishonest, then you are screwed in any case. >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>> =20 >>>>>> /Stefan >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>> =20 >>>>>> From: Santosh Chokhani >>>>>> Date: Friday, September 28, 2012 4:17 PM >>>>>> To: "denis.pinkas@bull.net" , pkix >>>>>> >>>>>> Subject: Re: [pkix] New Version Notification for >>>>>> draft-pinkas-2560bis-ocsp-locationcheck-00.txt >>>>>> =20 >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>>=20 >>>>>>> Denis, >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>> I find the document in general acceptable. It definitely fills a h= ole. >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>> That said, it is effective both in general and against MITM attack = if >>>>>>> the CA recognizes that the absence of the critical extension you >>>>>>> designed in the OCSP certificate means that the Responder is >>>>>>> authoritative for all certificates as long as the rest of the >>>>>>> requirements in RFC 2560 are met. >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>> Note that absence of IDP means that the CRL is full and complete. = We do >>>>>>> not have a similar statement in 2560 and this extension is fully >>>>>>> effective only if such is the case, i.e., by omitting this extensio= n, >>>>>>> the CA implies that the Responder is authoritative for all certific= ates >>>>>>> signed using that CA key. >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>> We either need to impose this requirement, which while new, most >>>>>>> implementations I know impose or discuss it in the Security >>>>>>> Considerations section. >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behal= f Of >>>>>>> denis.pinkas@bull.net >>>>>>> Sent: Tuesday, September 25, 2012 11:12 AM >>>>>>> To: pkix >>>>>>> Subject: [pkix] New Version Notification for >>>>>>> draft-pinkas-2560bis-ocsp-locationcheck-00.txt >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>> To the list, >>>>>>> =20 >>>>>>> The last comment from Santosh, triggered me to write a new draft >>>>>>> proposal directly related to 2560bis. >>>>>>> =20 >>>>>>> This proposal allows to split the workload of an OCSP service from= a CA >>>>>>> between several OCSP Responders. >>>>>>> This may be desirable for PKIs issuing a large number of certifica= tes >>>>>>> (e.g. several hundred of thousands). >>>>>>> =20 >>>>>>> Denis=20 >>>>>>> =20 >>>>>>> =20 >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>> =20 >>>>>>> A new version of I-D, draft-pinkas-2560bis-ocsp-locationcheck-00.t= xt >>>>>>> has been successfully submitted by Denis Pinkas and posted to the >>>>>>> IETF repository. >>>>>>> =20 >>>>>>> Filename: draft-pinkas-2560bis-ocsp-locationcheck >>>>>>> Revision: 00 >>>>>>> Title: OCSP LocationCheck certificate extension Up= date >>>>>>> to OCSP=20 >>>>>>> < draft-pinkas-2560bis-ocsp-locationcheck-00.txt= > >>>>>>> Creation date: 2012-09-25 >>>>>>> WG ID: Individual Submission >>>>>>> Number of pages: 6 >>>>>>> URL: =20 >>>>>>> http://www.ietf.org/internet-drafts/draft-pinkas-2560bis-ocsp-locat= ionch >>>>>>> eck-00.txt=20 >>>>>>> >>>>>> heck-00.txt> >>>>>>> Status: =20 >>>>>>> http://datatracker.ietf.org/doc/draft-pinkas-2560bis-ocsp-locationc= heck >>>>>>> >>>>>> >=20 >>>>>>> Htmlized:=20 >>>>>>> http://tools.ietf.org/html/draft-pinkas-2560bis-ocsp-locationcheck-= 00 >>>>>>> >>>>>>> =20 >>>>>>> =20 >>>>>>> Abstract:=20 >>>>>>> =20 >>>>>>> RFC 2560 [RFC2560] allows CAs to designate one or more OCSP >>>>>>> Responders for being responsible to provide the revocation statu= s >>>>>>> of the certificates they issue under a given CA key. >>>>>>> =20 >>>>>>> This document introduces a new feature that allows allows CAs to >>>>>>> split the workload between different sets of OCSP Responders in = a >>>>>>> way that is analogous to the way CRLs can be split between >>>>>>> different sets of CRL issuers (using the cRLDistributionPoints >>>>>>> extension). >>>>>>> =20 >>>>>>> This new feature allows a CA to designate one or more OCSP >>>>>>> Responders for being responsible to provide the revocation statu= s >>>>>>> for a subset of the certificates they issue under a given CA key= . >>>>>>> =20 >>>>>>> This document defines a critical extension that may only be plac= ed >>>>>>> in an OCSP certificate and the way it shall be processed by OCSP >>>>>>> clients. >>>>>>> =20 >>>>>>> The IETF Secretariat >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>> _______________________________________________ pkix mailing list >>>>>>> pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix >>>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>> =20 >>> =20 >>> =20 >>> =20 >>> =20 >> =20 > =20 > =20 > =20 --B_3432812825_5476458 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
I still think the gain obtai= ned by your proposal is far less than the pain of introducing a new critical= extension that needs client support.

I still can't= see an attacker achieving anything beyond a DoS and I can't see this scaled= to a DDoS attack.
Signed error or not.

/= Stefan


From: = Denis Pinkas <denis.pinkas= @bull.net>
Date: Thursday, = October 11, 2012 2:25 PM
To: Stefa= n Santesson <stefan@aaa-sec.com&g= t;
Cc: Santosh Chokhani <SChokhani@cygnacom.com>, pkix <<= a href=3D"mailto:pkix@ietf.org">pkix@ietf.org>
Subject: Re: [pkix] New Version Notification for draft-pin= kas-2560bis-ocsp-locationcheck-00.txt

Stefan,

RFC 2560 states:

 "In case of errors, the OCSP Responder may return an error message.
These messages are not signed".

So an "unauthorized" response is not signed.

The text from RFC 2560 states:

   The response "unauthorized" is returned in = cases where the client is
   not auth= orized to make this query to this server.

The text from RFC 5019 states the following:

   As long as the OCSP infrastructure has authoritative records for a<= /p>

   particular certificate, an OCSPResponseStatus of "successful" will be

   returned.  When access to authoritative records for a particular

   certificate is not available, the responder MUST return an

   OCSPResponseStatus of "unauthorized".  As such, this profile extends

   the RFC 2560 [OCSP] definition of "unauthorized" as follows:

 

  &nb= sp;   The response "unauthorized" is returned in cases where the client

  &nb= sp;   is not authorized to make this query to this server or the server

  &nb= sp;   is not capable of responding authoritatively.


In the absence of the proposed extension, RFC 5019 could not do better.
 
With the proposed extension, it is possible to do better and to get a signed "unknown" status in a signed response
rather than an "unauthorized" error in an unsigned response, that is harder to interpret and subject to attacks:

 - was there a substitution attack, since this may not be a response from the authorized responder ?
 - am I using a wrong URL, since I am not sure this response com= es from the right URL ?
 - am I missing an authorization to get the status ?

Denis

 
=
The "unauthorized" response seems suitable to me. 

"The response "unauthorized" is returned in cases where the client is not authorized to make this query to this server or the server is not capable of responding authoritatively (cf. [RFC5019], Section 2.2.3)"=

/Stefan



From: Denis Pinkas Bull <denis.pinkas@bull.net>
Date: Thursday, October 11, 2012 7:53 AM
To: Stefan Santesson <st= efan@aaa-sec.com>
Cc: Santosh Chokhani <SChokhani@cygnacom.com>, pkix <pk= ix@ietf.org>
Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt

Stefan,

As fas as I know, there are only three major status: "good", "revoked" or "unknown".

Error messages are:

   -- malformedRequest,
   -- internalError,
   -- tryLater,
   -- sigRequired,
   -- unauthorized.

There is no response like: "the responder is not authorised to provide information about the cert".
In the example, the RP gets "unknown" (with a correct signature from the OCSP responder),
whereas it would have received either "good" or "revoked", if there had been no attack.

Denis

Sorry, Still don't get it.

In your example, the client receives a response that the responder is not authorised to provide information about the cert.
So a man-in-the-middle can do a DoS attack. That is not new.

/Stefan


From: Denis Pinkas Bull <denis.pinkas@bull.net>
Date: Thursday, October 11, 2012 7:31 AM
To: Stefan Santesson <stefan@aaa-sec.com>
Cc: Santosh Chokhani <SChokhani@cygnacom.com>, pkix <pkix@ietf.org>
Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt

Stefan,

You missed the point. Let me illustrate why using a simple scenario:

OCSP Responder 1 receives delegation from CA x for the first 100.000 issued certificates.
OCSP Responder 1 has only access to the revocation status of the first 100.000 issued certificates.
The first 100.000 issued certificates contain url1 to locate OCSP Responder 1.

OCSP Responder 2 receives delegation from CA x for the next 100.000 issued certificates.
OCSP Responder 2 has only access to the revocation status of the next 100.000 issued certificates.
The next 100.000 issued certificates contains url2 to locate OCSP Responder 2.

A Relying Party (RP) uses url1 that is present in the target certificate to query OCSP Responder 1.
However, there is a man-in-the-middle-attack and this request in routed to OCSP Responder 2.
OCP2 responder 2 responds that it don't know the status of this certificate.
The response from OCSP Responder 2 is routed back to the RP.
The RP verifies that the response is indeed correctly signed.

If the man-in-the-middle attack were not done, the RP would have known that the certificate
= was either "revoked" or "good", since only OCSP Responder 1 knows it.

Without the proposed extension, the protocol would provide incorrect revocation status results.

Denis



 Santesson a =E9crit :
Why do you need this at all?

I don't see that this extension is required in order to split OCSP responding for chunks of certs.
You can point the client to the correct responder using information in the cert today.
The responder can determine if the requested vert is within it's handled portion of certs.

Given that you trust the OCSP responder and the responder is honest, you will receive an appropriate response.

So, why the extension?

I can only imagine the extension being useful to detect if a responder responds outside of it's authority, but if the OCSP responder is dishonest, then you are screwed in any case.

/Stefan


From: Santosh Chokhani <SChokhani@cygnacom.com>= ;
Date: Friday, September 28, 2012 4:17 PM
To: "denis.pinkas@bull.net" <denis.pinkas@bull.net>, pkix <pkix@ietf.org>
Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.tx= t

Denis,=

&= nbsp;

I find the document in general acceptable.  It definitely fil= ls a hole.

&= nbsp;

That said, it is effective both in general and against MITM attack if the CA recognizes that the absence of the critical extension you designed in the OCSP certificate means that the Responder is authoritative for all certificates as long as the rest of the requirements in RFC 2560 are met.

=

&= nbsp;

Note that absence of IDP means that the CRL is full and complete. = We do not have a similar statement in 2560 and this extension is fully effective only if such is the case, i.e., by omitting this extension, the CA implies that the Responder is authoritative for all certificates signed using that CA key.

&= nbsp;

We either need to impose this requirement, which while new, most implementations I know impose or discuss it in the Security Considerations section.

&= nbsp;

From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of denis.pinkas@bull.net
= Sent: Tuesday, September 25, 2012 11:12 AM
To: pkix
Subject: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationc= heck-00.txt

 <= /p>

To the list,

The last comment from Santosh, triggered me to write a new draft proposal directly related to 2560bis.  

This proposal allows to split the workload of an OCSP service from a CA between several OCSP Responders.
This may be desirable for PKIs issuing a large number of certificates (e.g. several hundred of thousands).

Denis

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

A new version of I-D, draft-pinkas-2560bis-ocsp-locatio= ncheck-00.txt
has been successfully submitted by Denis Pinkas and posted to the
IETF repository.

Filename:       =           draft-pinkas-2560bis-ocsp-locatio= ncheck
Revision:       =           00
Title:       &nb= sp;         OCSP LocationCheck certificate extension Update to OCSP         &nb= sp;         < draft-pinkas-2560bis-ocsp-locatio= ncheck-00.txt >
Creation date:     &n= bsp;            2012-09-25
WG ID:       &nb= sp;                        = ;   Individual Submission
Number of pages: 6
URL:        = ;     http://www.ietf.org/internet-drafts/draft-pinkas-= 2560bis-ocsp-locationcheck-00.txt
Status:       &n= bsp;  http://datatracker.ietf.org/doc/draft-pinkas-2560bis-ocsp-locatio= ncheck
Htmlized:       =  http://tools.ietf.org/html/draft-pinkas-2560bis-ocsp-locationcheck-00

Abstract:

  RFC 2560 [RFC2560] allow= s CAs to designate one or more OCSP
  Responders for being responsible to provide the revocation status
  of the certificates they= issue under a given CA key.<= br>
  This document introduces= a new feature that allows allows CAs to
  split the workload betwe= en different sets of OCSP Responders in a
  way that is analogous to= the way CRLs can be split between
  different sets of CRL issuers (using the cRLDistributionPoints
  extension).

  This new feature allows = a CA to designate one or more OCSP
  Responders for being responsible to provide the revocation status
  for a subset of the certificates they issue under a given CA key.

  This document defines a critical extension that may only be placed
  in an OCSP certificate a= nd the way it shall be processed by OCSP
  clients.

The IETF Secretariat

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




--B_3432812825_5476458-- From SChokhani@cygnacom.com Thu Oct 11 07:26:49 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89A4C21F8669 for ; Thu, 11 Oct 2012 07:26:49 -0700 (PDT) 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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3G+4MwH0OnbC for ; Thu, 11 Oct 2012 07:26:43 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id A082121F8625 for ; Thu, 11 Oct 2012 07:26:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,571,1344225600"; d="scan'208,217";a="6492316" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 11 Oct 2012 10:26:29 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Thu, 11 Oct 2012 10:26:29 -0400 From: Santosh Chokhani To: Stefan Santesson , Denis Pinkas Date: Thu, 11 Oct 2012 10:26:27 -0400 Thread-Topic: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt Thread-Index: Ac2nsZ5qayiOGgtIRDChsjhjtZ4UUAACi39Q Message-ID: References: <5076BAC3.3050402@bull.net> 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_B83745DA469B7847811819C5005244AF362ED148scygexch7cygnac_" MIME-Version: 1.0 Cc: pkix Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 14:26:49 -0000 --_000_B83745DA469B7847811819C5005244AF362ED148scygexch7cygnac_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Stefan, It is possible that a Responder will assert good (e.g., for pre-signed resp= onses) since RFC 2560 does not address if the CA splits the responsibility = among multiple responders. In that case, MITM can get and play a response = of "good" from a legitimate Responder. CAs and Responders who implement this extension are protected. For further= discussion, see my comment in this thread that Denis has not addressed. It is akin to IDP for partitioned CRL, but my concern is different than you= rs. I am concerned that unless the assumptions made by this extension are = adhered to by the CA and the Responders, there is less of a benefit. From: Stefan Santesson [mailto:stefan@aaa-sec.com] Sent: Thursday, October 11, 2012 9:07 AM To: Denis Pinkas Cc: Santosh Chokhani; pkix Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-= locationcheck-00.txt I still think the gain obtained by your proposal is far less than the pain = of introducing a new critical extension that needs client support. I still can't see an attacker achieving anything beyond a DoS and I can't s= ee this scaled to a DDoS attack. Signed error or not. /Stefan From: Denis Pinkas > Date: Thursday, October 11, 2012 2:25 PM To: Stefan Santesson > Cc: Santosh Chokhani = >, pkix > Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-= locationcheck-00.txt Stefan, RFC 2560 states: "In case of errors, the OCSP Responder may return an error message. These messages are not signed". So an "unauthorized" response is not signed. The text from RFC 2560 states: The response "unauthorized" is returned in cases where the client is not authorized to make this query to this server. The text from RFC 5019 states the following: As long as the OCSP infrastructure has authoritative records for a particular certificate, an OCSPResponseStatus of "successful" will be returned. When access to authoritative records for a particular certificate is not available, the responder MUST return an OCSPResponseStatus of "unauthorized". As such, this profile extends the RFC 2560 [OCSP] definition of "unauthorized" as follows: The response "unauthorized" is returned in cases where the client is not authorized to make this query to this server or the server is not capable of responding authoritatively. In the absence of the proposed extension, RFC 5019 could not do better. With the proposed extension, it is possible to do better and to get a signe= d "unknown" status in a signed response rather than an "unauthorized" error in an unsigned response, that is harder= to interpret and subject to attacks: - was there a substitution attack, since this may not be a response from t= he authorized responder ? - am I using a wrong URL, since I am not sure this response comes from the= right URL ? - am I missing an authorization to get the status ? Denis The "unauthorized" response seems suitable to me. "The response "unauthorized" is returned in cases where the client is not a= uthorized to make this query to this server or the server is not capable of= responding authoritatively (cf. [RFC5019], Section 2.2.3)" /Stefan From: Denis Pinkas Bull > Date: Thursday, October 11, 2012 7:53 AM To: Stefan Santesson > Cc: Santosh Chokhani = >, pkix > Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-= locationcheck-00.txt Stefan, As fas as I know, there are only three major status: "good", "revoked" or "= unknown". Error messages are: -- malformedRequest, -- internalError, -- tryLater, -- sigRequired, -- unauthorized. There is no response like: "the responder is not authorised to provide info= rmation about the cert". In the example, the RP gets "unknown" (with a correct signature from the OC= SP responder), whereas it would have received either "good" or "revoked", if there had bee= n no attack. Denis Sorry, Still don't get it. In your example, the client receives a response that the responder is not a= uthorised to provide information about the cert. So a man-in-the-middle can do a DoS attack. That is not new. /Stefan From: Denis Pinkas Bull > Date: Thursday, October 11, 2012 7:31 AM To: Stefan Santesson > Cc: Santosh Chokhani = >, pkix > Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-= locationcheck-00.txt Stefan, You missed the point. Let me illustrate why using a simple scenario: OCSP Responder 1 receives delegation from CA x for the first 100.000 issued= certificates. OCSP Responder 1 has only access to the revocation status of the first 100.= 000 issued certificates. The first 100.000 issued certificates contain url1 to locate OCSP Responder= 1. OCSP Responder 2 receives delegation from CA x for the next 100.000 issued = certificates. OCSP Responder 2 has only access to the revocation status of the next 100.0= 00 issued certificates. The next 100.000 issued certificates contains url2 to locate OCSP Responder= 2. A Relying Party (RP) uses url1 that is present in the target certificate to= query OCSP Responder 1. However, there is a man-in-the-middle-attack and this request in routed to = OCSP Responder 2. OCP2 responder 2 responds that it don't know the status of this certificate= . The response from OCSP Responder 2 is routed back to the RP. The RP verifies that the response is indeed correctly signed. If the man-in-the-middle attack were not done, the RP would have known that= the certificate was either "revoked" or "good", since only OCSP Responder 1 knows it. Without the proposed extension, the protocol would provide incorrect revoca= tion status results. Denis Santesson a =E9crit : Why do you need this at all? I don't see that this extension is required in order to split OCSP respondi= ng for chunks of certs. You can point the client to the correct responder using information in the = cert today. The responder can determine if the requested vert is within it's handled po= rtion of certs. Given that you trust the OCSP responder and the responder is honest, you wi= ll receive an appropriate response. So, why the extension? I can only imagine the extension being useful to detect if a responder resp= onds outside of it's authority, but if the OCSP responder is dishonest, the= n you are screwed in any case. /Stefan From: Santosh Chokhani > Date: Friday, September 28, 2012 4:17 PM To: "denis.pinkas@bull.net" >, pkix > Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-= locationcheck-00.txt Denis, I find the document in general acceptable. It definitely fills a hole. That said, it is effective both in general and against MITM attack if the C= A recognizes that the absence of the critical extension you designed in the= OCSP certificate means that the Responder is authoritative for all certifi= cates as long as the rest of the requirements in RFC 2560 are met. Note that absence of IDP means that the CRL is full and complete. We do no= t have a similar statement in 2560 and this extension is fully effective on= ly if such is the case, i.e., by omitting this extension, the CA implies th= at the Responder is authoritative for all certificates signed using that CA= key. We either need to impose this requirement, which while new, most implementa= tions I know impose or discuss it in the Security Considerations section. From: pkix-bounces@ietf.org [mailto:pkix-boun= ces@ietf.org] On Behalf Of denis.pinkas@bull.net Sent: Tuesday, September 25, 2012 11:12 AM To: pkix Subject: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-loca= tioncheck-00.txt To the list, The last comment from Santosh, triggered me to write a new draft proposal d= irectly related to 2560bis. This proposal allows to split the workload of an OCSP service from a CA bet= ween several OCSP Responders. This may be desirable for PKIs issuing a large number of certificates (e.g.= several hundred of thousands). Denis =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D A new version of I-D, draft-pinkas-2560bis-ocsp-locationcheck-00.txt has been successfully submitted by Denis Pinkas and posted to the IETF repository. Filename: draft-pinkas-2560bis-ocsp-locationcheck Revision: 00 Title: OCSP LocationCheck certificate extension Update to O= CSP < draft-pinkas-2560bis-ocsp-locationcheck-00.txt > Creation date: 2012-09-25 WG ID: Individual Submission Number of pages: 6 URL: http://www.ietf.org/internet-drafts/draft-pinkas-2560bis-o= csp-locationcheck-00.txt Status: http://datatracker.ietf.org/doc/draft-pinkas-2560bis-ocsp-= locationcheck Htmlized: http://tools.ietf.org/html/draft-pinkas-2560bis-ocsp-locat= ioncheck-00 Abstract: RFC 2560 [RFC2560] allows CAs to designate one or more OCSP Responders for being responsible to provide the revocation status of the certificates they issue under a given CA key. This document introduces a new feature that allows allows CAs to split the workload between different sets of OCSP Responders in a way that is analogous to the way CRLs can be split between different sets of CRL issuers (using the cRLDistributionPoints extension). This new feature allows a CA to designate one or more OCSP Responders for being responsible to provide the revocation status for a subset of the certificates they issue under a given CA key. This document defines a critical extension that may only be placed in an OCSP certificate and the way it shall be processed by OCSP clients. The IETF Secretariat _______________________________________________ pkix mailing list pkix@ietf= .org https://www.ietf.org/mailman/listinfo/pkix --_000_B83745DA469B7847811819C5005244AF362ED148scygexch7cygnac_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Stefan,=

 

It is possible that a Responder will assert good (e.g.,= for pre-signed responses) since RFC 2560 does not address if the CA splits= the responsibility among multiple responders.=A0 In that case, MITM can ge= t and play a response of “good” from a legitimate Responder.

 

CAs and Responders who implement this extension are p= rotected.=A0 For further discussion, see my comment in this thread that Den= is has not addressed.

&n= bsp;

It is akin to IDP for partiti= oned CRL, but my concern is different than yours.=A0 I am concerned that un= less the assumptions made by this extension are adhered to by the CA and th= e Responders, there is less of a benefit.

 

From: Stefan Santesson [mailto:stefan= @aaa-sec.com]
Sent: Thursday, October 11, 2012 9:07 AM
To:= Denis Pinkas
Cc: Santosh Chokhani; pkix
Subject: R= e: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationch= eck-00.txt

 

I still think the gain obtained by your proposal is far less than the= pain of introducing a new critical extension that needs client support.

 

I still can't see an attacker= achieving anything beyond a DoS and I can't see this scaled to a DDoS atta= ck.

Signed error = or not.

&nbs= p;

/Stefan<= /span>

 

=

 

From: Denis Pinkas <denis.pinkas@bull.net>
= Date: Thursday, October 11, 2012 2:25 PM
To: Stefan Santesson= <stefan@aaa-sec.com>
Cc: Santosh Chokhani <SCh= okhani@cygnacom.com>, pkix <pkix= @ietf.org>
Subject: Re: [pkix] New Version Notification fo= r draft-pinkas-2560bis-ocsp-locationcheck-00.txt

 

Stefan,

RFC 2560 states:

 "In case of errors,= the OCSP Responder may return an error message.
These messages are not = signed".

So an "unauthorized" response is not signed= .

The text from RFC 2560 states:

=A0= =A0 The response "unauthorized" is returned in cases where the cl= ient is
=A0=A0 not authorized to make this query to this server.<= span style=3D'font-size:10.5pt;font-family:"Arial","sans-serif";color:black= '>

The text from RFC 5019 states the following:

=A0=A0 As long as the OCSP infrastructure has authoritative records fo= r a

=A0=A0 particular certificate, an OCSPResponse= Status of "successful" will be

<= p class=3DMsoPlainText style=3D'margin-top:0in'>=A0=A0 re= turned.=A0 When access to authoritative records for a particular

=A0=A0 certificate is not available, the responder MUST retu= rn an

=A0=A0 OCSPResponseStatus of "unauthori= zed".=A0 As such, this profile extends

=A0=A0= the RFC 2560 [OCSP] definition of "unauthorized" as follows:

 

=A0=A0=A0=A0=A0 The r= esponse "unauthorized" is returned in cases where the client

=A0=A0=A0=A0=A0 is not authorized to make this query t= o this server or the server

=A0=A0=A0=A0=A0 is not= capable of responding authoritatively.


In the a= bsence of the proposed extension, RFC 5019 could not do better.
 With the proposed extension, it is possible to do better and to get a sig= ned "unknown" status in a signed response
rather than an &quo= t;unauthorized" error in an unsigned response, that is harder to inter= pret and subject to attacks:

 - was there a substitution attack= , since this may not be a response from the authorized responder ?
 = ;- am I using a wrong URL, since I am not sure this response comes from the= right URL ?
 - am I missing an authorization to get the status ?<= br>
Denis

 

The "unauthorized" response seem= s suitable to me. 

 

<= /div>

= "The response "unauthorized" is returned in cases where the = client is not authorized to make this query to this server or the server is= not capable of responding authoritatively (cf. [RFC5019], Section 2.2.3)&q= uot;

 

/Stefan=

 

 

=

=  

From: Denis Pinkas Bull <= denis.pinkas@bull.net>
<= b>Date: Thursday, October 11, 2012 7:53 AM
To: Stefan Santess= on <stefan@aaa-sec.com>
= Cc: Santosh Chokhani <S= Chokhani@cygnacom.com>, pkix <pk= ix@ietf.org>
Subject: Re: [pkix] New Version Notification = for draft-pinkas-2560bis-ocsp-locationcheck-00.txt

 

<= div>

Stefan,

As fas as I know, there are only three major status: "good"= ;, "revoked" or "unknown".

Error messages are:
   -- malformedRequest,
   -- internalError,   -- tryLater,
   -- sigRequired,
  = -- unauthorized.

There is no response like: "the responder is = not authorised to provide information about the cert".
In the examp= le, the RP gets "unknown" (with a correct signature from the OCSP= responder),
whereas it would have received either <= span style=3D'font-size:10.5pt;color:black'>"good" or "revok= ed", if there had been no attack.

Denis<= /span>

=

Sorry= , Still don't get it.

 

In= your example, the client receives a response that the responder is not aut= horised to provide information about the cert.

<= div>

So a m= an-in-the-middle can do a DoS attack. That is not new.

 

/Stefan

 

 

From: De= nis Pinkas Bull <denis.pinkas@b= ull.net>
Date: Thursday, October 11, 2012 7:31 AM
To= : Stefan Santesson <stefan@aaa= -sec.com>
Cc: Santosh Chokhani <SChokhani@cygnacom.com>, pkix <pkix@ietf.org>
Subject: Re: [pkix] New V= ersion Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt

 

Stefan,

You missed the point. Let me illustrate why us= ing a simple scenario:

OCSP Responder 1 receives delegation from CA = x for the first 100.000 issued certificates.
OCSP Responder 1 has only a= ccess to the revocation status of the first 100.000 issued certificates.The first 100.000 issued certificates contain url1 to locate OCSP Responde= r 1.

OCSP Responder 2 receives delegation from CA x for the next 100= .000 issued certificates.
OCSP Responder 2 has only access to the revoca= tion status of the next 100.000 issued certificates.
The next 100.000 is= sued certificates contains url2 to locate OCSP Responder 2.

A Relyin= g Party (RP) uses url1 that is present in the target certificate to query O= CSP Responder 1.
However, there is a man-in-the-middle-attack and this r= equest in routed to OCSP Responder 2.
OCP2 responder 2 responds that it = don't know the status of this certificate.
The response from OCSP Respon= der 2 is routed back to the RP.
The RP verifies that the response is ind= eed correctly signed.

If the man-in-the-middle attack were not done,= the RP would have known that the certificate
was either "revoked&= quot; or "good", since only OCSP Responder 1 knows it.

Wit= hout the proposed extension, the protocol would provide incorrect revocatio= n status results.

Denis



 Santesson a =E9crit&nbs= p;:

Why do you need this at all?

 

I don't see that this extension is required in order to spli= t OCSP responding for chunks of certs.

You can point = the client to the correct responder using information in the cert today.

The responder can determine if the requested vert is wi= thin it's handled portion of certs.

 =

Given that you trust the OCSP responder and the responder is ho= nest, you will receive an appropriate response.

=

=  

So, why the extension?

 

I can only imagine the extension being useful to = detect if a responder responds outside of it's authority, but if the OCSP r= esponder is dishonest, then you are screwed in any case.<= /p>

<= span style=3D'font-size:10.5pt;font-family:"Calibri","sans-serif";color:bla= ck'> 

/Stefan

 <= /o:p>

 

From: = Santosh Chokhani <SChokhani@cy= gnacom.com>
Date: Friday, September 28, 2012 4:17 PM
To: "denis.pinkas@bull.n= et" <denis.pinkas@bull= .net>, pkix <pkix@ietf.org&g= t;
Subject: Re: [pkix] New Version Notification for draft-pinkas-= 2560bis-ocsp-locationcheck-00.txt

&= nbsp;

Denis,

 

I find the document in general acceptable= .  It definitely fills a hole.=

 

That said, it is eff= ective both in general and against MITM attack if the CA recognizes that th= e absence of the critical extension you designed in the OCSP certificate me= ans that the Responder is authoritative for all certificates as long as the= rest of the requirements in RFC 2560 are met.

 

Note th= at absence of IDP means that the CRL is full and complete.  We do not = have a similar statement in 2560 and this extension is fully effective only= if such is the case, i.e., by omitting this extension, the CA implies that= the Responder is authoritative for all certificates signed using that CA k= ey.

 

We either need to impose this requirement, which whi= le new, most implementations I know impose or discuss it in the Security Co= nsiderations section.<= /p>

 <= /o:p>

From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of <= /b>denis.pinkas@bull.net
Sent: Tuesday, September 25, 2012 11:12 AM
To: pkix
Su= bject: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-lo= cationcheck-00.txt

=

 

To the list, <= br>
The last comment from Santosh, triggered me to write a new= draft proposal directly related to 2560bis.  

This proposal allows to split the workload of= an OCSP service from a CA between several OCSP Responders.
This may be desirable for PKIs issuing a = large number of certificates (e.g. several hundred of thousands).

Denis

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

A new version of I-D, draft-pinkas-= 2560bis-ocsp-locationcheck-00.txt
has been successfully submitted by Denis Pinkas a= nd posted to the
IETF repository.

Filename:             &= nbsp;   draft-pinkas-2560bis-ocsp-locationcheck
= Revision:      =           00
Title:           &n= bsp;     OCSP LocationCheck certificate extension Update to OCSP =
  =                 < draft-pinkas-2= 560bis-ocsp-locationcheck-00.txt >
Creation date:         &n= bsp;        2012-09-25
WG ID:          = ;                     &nb= sp;   Individual Submission
Number of pages: 6
URL:          =   http://www.ietf.org/internet-drafts/draft-pin= kas-2560bis-ocsp-locationcheck-00.txt
Status:        = ;  http://datatracker.ietf.org/doc/draft-pinkas-2560bis-ocs= p-locationcheck
Htmlized:        http://too= ls.ietf.org/html/draft-pinkas-2560bis-ocsp-locationcheck-00=


Abst= ract:

  RFC 2560 [RFC2560] allows CAs = to designate one or more OCSP
  Responders for being responsible to provide th= e revocation status
  of the certificates they issue under a given CA key.

  = This document introduces a new feature that allows allows CAs to  split the w= orkload between different sets of OCSP Responders in a
  way that is analogous= to the way CRLs can be split between
  different sets of CRL issuers (using t= he cRLDistributionPoints
  extension).

  This new feature allows a CA to de= signate one or more OCSP
  Responders for being responsible to provide the rev= ocation status
  for a subset of the certificates they issue under a given CA = key.

  This document defines a critical extension that may only be placed<= /span>
  i= n an OCSP certificate and the way it shall be processed by OCSP=
=   clients.

The IET= F Secretariat

=

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

 

<= /blockquote>

 

 

= --_000_B83745DA469B7847811819C5005244AF362ED148scygexch7cygnac_-- From denis.pinkas@bull.net Thu Oct 11 07:47:19 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D57921F86DA for ; Thu, 11 Oct 2012 07:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.496 X-Spam-Level: X-Spam-Status: No, score=-4.496 tagged_above=-999 required=5 tests=[AWL=1.752, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPTttPoWWegs for ; Thu, 11 Oct 2012 07:47:07 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 2063521F86C6 for ; Thu, 11 Oct 2012 07:47:06 -0700 (PDT) Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id 84FD5418012; Thu, 11 Oct 2012 16:47:05 +0200 (CEST) Received: from [127.0.0.1] ([129.184.39.15]) by MSGC-007.bull.fr (Lotus Domino Release 8.5.3FP1) with ESMTP id 2012101116470426-768 ; Thu, 11 Oct 2012 16:47:04 +0200 Message-ID: <5076DBE4.9010808@bull.net> Date: Thu, 11 Oct 2012 16:47:00 +0200 From: Denis Pinkas User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Santosh Chokhani References: <5076BAC3.3050402@bull.net> In-Reply-To: X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 11/10/2012 16:47:05, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 11/10/2012 16:47:05, Serialize complete at 11/10/2012 16:47:05 Content-Type: multipart/alternative; boundary="------------030702050108090005050701" Cc: Stefan Santesson , pkix Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 14:47:19 -0000 This is a multi-part message in MIME format. --------------030702050108090005050701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Santosh, Reading your message below reminded me that I forgot to respond to your=20 comment. Sorry, about that. In order to address your comment, I propose the following: Change : 4.5.X OCSP LocationCheck extension This single extension MAY only be placed in an OCSP certificate. into: 4.5.X OCSP LocationCheck extension This single extension MAY only be placed in an OCSP certificate. By omitting this extension, the CA implies that any designated OCSP=20 Responder is authoritative for all certificates signed using the key used to=20 sign the OCSP certificate. Denis > Stefan, > > It is possible that a Responder will assert good (e.g., for pre-signed=20 > responses) since RFC 2560 does not address if the CA splits the=20 > responsibility among multiple responders. In that case, MITM can get=20 > and play a response of "good" from a legitimate Responder. > > CAs and Responders who implement this extension are protected. For=20 > further discussion, see my comment in this thread that Denis has not=20 > addressed. > > It is akin to IDP for partitioned CRL, but my concern is different=20 > than yours. I am concerned that unless the assumptions made by this=20 > extension are adhered to by the CA and the Responders, there is less=20 > of a benefit. > > *From:*Stefan Santesson [mailto:stefan@aaa-sec.com] > *Sent:* Thursday, October 11, 2012 9:07 AM > *To:* Denis Pinkas > *Cc:* Santosh Chokhani; pkix > *Subject:* Re: [pkix] New Version Notification for=20 > draft-pinkas-2560bis-ocsp-locationcheck-00.txt > > I still think the gain obtained by your proposal is far less than the=20 > pain of introducing a new critical extension that needs client support. > > I still can't see an attacker achieving anything beyond a DoS and I=20 > can't see this scaled to a DDoS attack. > > Signed error or not. > > /Stefan > > *From: *Denis Pinkas > > *Date: *Thursday, October 11, 2012 2:25 PM > *To: *Stefan Santesson > > *Cc: *Santosh Chokhani >, pkix > > *Subject: *Re: [pkix] New Version Notification for=20 > draft-pinkas-2560bis-ocsp-locationcheck-00.txt > > Stefan, > > RFC 2560 states: > > "In case of errors, the OCSP Responder may return an error message= . > These messages are not signed". > > So an "unauthorized" response is not signed. > > The text from RFC 2560 states: > > The response "unauthorized" is returned in cases where the > client is > not authorized to make this query to this server. > > The text from RFC 5019 states the following: > > As long as the OCSP infrastructure has authoritative records for= a > > particular certificate, an OCSPResponseStatus of "successful" > will be > > returned. When access to authoritative records for a particular > > certificate is not available, the responder MUST return an > > OCSPResponseStatus of "unauthorized". As such, this profile > extends > > the RFC 2560 [OCSP] definition of "unauthorized" as follows: > > The response "unauthorized" is returned in cases where the > client > > is not authorized to make this query to this server or the > server > > is not capable of responding authoritatively. > > > In the absence of the proposed extension, RFC 5019 could not do > better. > > With the proposed extension, it is possible to do better and to > get a signed "unknown" status in a signed response > rather than an "unauthorized" error in an unsigned response, that > is harder to interpret and subject to attacks: > > - was there a substitution attack, since this may not be a > response from the authorized responder ? > - am I using a wrong URL, since I am not sure this response comes > from the right URL ? > - am I missing an authorization to get the status ? > > Denis > > The "unauthorized" response seems suitable to me. > > "The response "unauthorized" is returned in cases where the > client is not authorized to make this query to this server or > the server is not capable of responding authoritatively (cf. > [RFC5019], Section 2.2.3)" > > /Stefan > > *From: *Denis Pinkas Bull > > *Date: *Thursday, October 11, 2012 7:53 AM > *To: *Stefan Santesson > > *Cc: *Santosh Chokhani >, pkix > > *Subject: *Re: [pkix] New Version Notification for > draft-pinkas-2560bis-ocsp-locationcheck-00.txt > > Stefan, > > As fas as I know, there are only three major status: > "good", "revoked" or "unknown". > > Error messages are: > > -- malformedRequest, > -- internalError, > -- tryLater, > -- sigRequired, > -- unauthorized. > > There is no response like: "the responder is not > authorised to provide information about the cert". > In the example, the RP gets "unknown" (with a correct > signature from the OCSP responder), > whereas it would have received either "good" or "revoked", > if there had been no attack. > > Denis > > Sorry, Still don't get it. > > In your example, the client receives a response that > the responder is not authorised to provide information > about the cert. > > So a man-in-the-middle can do a DoS attack. That is > not new. > > /Stefan > > *From: *Denis Pinkas Bull > > *Date: *Thursday, October 11, 2012 7:31 AM > *To: *Stefan Santesson > > *Cc: *Santosh Chokhani >, pkix > > *Subject: *Re: [pkix] New Version Notification for > draft-pinkas-2560bis-ocsp-locationcheck-00.txt > > Stefan, > > You missed the point. Let me illustrate why using > a simple scenario: > > OCSP Responder 1 receives delegation from CA x for > the first 100.000 issued certificates. > OCSP Responder 1 has only access to the revocation > status of the first 100.000 issued certificates. > The first 100.000 issued certificates contain url1 > to locate OCSP Responder 1. > > OCSP Responder 2 receives delegation from CA x for > the next 100.000 issued certificates. > OCSP Responder 2 has only access to the revocation > status of the next 100.000 issued certificates. > The next 100.000 issued certificates contains url2 > to locate OCSP Responder 2. > > A Relying Party (RP) uses url1 that is present in > the target certificate to query OCSP Responder 1. > However, there is a man-in-the-middle-attack and > this request in routed to OCSP Responder 2. > OCP2 responder 2 responds that it don't know the > status of this certificate. > The response from OCSP Responder 2 is routed back > to the RP. > The RP verifies that the response is indeed > correctly signed. > > If the man-in-the-middle attack were not done, the > RP would have known that the certificate > was either "revoked" or "good", since only OCSP > Responder 1 knows it. > > Without the proposed extension, the protocol would > provide incorrect revocation status results. > > Denis > > > > Santesson a =E9crit : > > Why do you need this at all? > > I don't see that this extension is required in > order to split OCSP responding for chunks of > certs. > > You can point the client to the correct > responder using information in the cert today. > > The responder can determine if the requested > vert is within it's handled portion of certs. > > Given that you trust the OCSP responder and > the responder is honest, you will receive an > appropriate response. > > So, why the extension? > > I can only imagine the extension being useful > to detect if a responder responds outside of > it's authority, but if the OCSP responder is > dishonest, then you are screwed in any case. > > /Stefan > > *From: *Santosh Chokhani > > > *Date: *Friday, September 28, 2012 4:17 PM > *To: *"denis.pinkas@bull.net > " > >, pkix > > > *Subject: *Re: [pkix] New Version Notification > for draft-pinkas-2560bis-ocsp-locationcheck-00.= txt > > Denis, > > I find the document in general > acceptable. It definitely fills a hole. > > That said, it is effective both in general > and against MITM attack if the CA > recognizes that the absence of the > critical extension you designed in the > OCSP certificate means that the Responder > is authoritative for all certificates as > long as the rest of the requirements in > RFC 2560 are met. > > Note that absence of IDP means that the > CRL is full and complete. We do not have a > similar statement in 2560 and this > extension is fully effective only if such > is the case, i.e., by omitting this > extension, the CA implies that the > Responder is authoritative for all > certificates signed using that CA key. > > We either need to impose this requirement, > which while new, most implementations I > know impose or discuss it in the Security > Considerations section. > > *From:*pkix-bounces@ietf.org > > [mailto:pkix-bounces@ietf.org] *On Behalf > Of *denis.pinkas@bull.net > > *Sent:* Tuesday, September 25, 2012 11:12 A= M > *To:* pkix > *Subject:* [pkix] New Version Notification > for > draft-pinkas-2560bis-ocsp-locationcheck-00.= txt > > To the list, > > The last comment from Santosh, triggered > me to write a new draft proposal directly > related to 2560bis. > > This proposal allows to split the workload > of an OCSP service from a CA between > several OCSP Responders. > This may be desirable for PKIs issuing a > large number of certificates (e.g. several > hundred of thousands). > > Denis > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > A new version of I-D, > draft-pinkas-2560bis-ocsp-locationcheck-00.= txt > has been successfully submitted by Denis > Pinkas and posted to the > IETF repository. > > Filename: > draft-pinkas-2560bis-ocsp-locationcheck > Revision: 00 > Title: OCSP LocationCheck > certificate extension Update to OCSP > < > draft-pinkas-2560bis-ocsp-locationcheck-00.= txt > > > Creation date: 2012-09-25 > WG ID: Individual Submission > Number of pages: 6 > URL: > http://www.ietf.org/internet-drafts/draft-p= inkas-2560bis-ocsp-locationcheck-00.txt > Status: > http://datatracker.ietf.org/doc/draft-pinka= s-2560bis-ocsp-locationcheck > Htmlized: > http://tools.ietf.org/html/draft-pinkas-256= 0bis-ocsp-locationcheck-00 > > > Abstract: > > RFC 2560 [RFC2560] allows CAs to designate > one or more OCSP > Responders for being responsible to > provide the revocation status > of the certificates they issue under a > given CA key. > > This document introduces a new feature > that allows allows CAs to > split the workload between different sets > of OCSP Responders in a > way that is analogous to the way CRLs can > be split between > different sets of CRL issuers (using the > cRLDistributionPoints > extension). > > This new feature allows a CA to designate > one or more OCSP > Responders for being responsible to > provide the revocation status > for a subset of the certificates they > issue under a given CA key. > > This document defines a critical extension > that may only be placed > in an OCSP certificate and the way it > shall be processed by OCSP > clients. > > The IETF Secretariat > > ___________________________________________= ____ > pkix mailing list pkix@ietf.org > > https://www.ietf.org/mailman/listinfo/pkix > --------------030702050108090005050701 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=ISO-8859-1
Santosh,

Reading your message below reminded me that I forgot to respond to your comment. Sorry, about that.
In order to address your comment, I propose the following:

Change :

4.5.X OCSP LocationCheck extension

   This single extension MAY only be placed in an OCSP certificate.

into:

4.5.X OCSP LocationCheck extension

   This single extension MAY only be placed in an OCSP certificate.

   By omitting this extension, the CA implies that any designated OCSP Responder
   is authoritative for all certificates signed using the key used to sign the OCSP
   certificate.

Denis

Stefan,

 

It is possible that a Responder will assert good (e.g., for pre-signed responses) since RFC 2560 does not address if the CA splits the responsibility among multiple responders.  In that case, MITM can get and play a response of “good” from a legitimate Responder.

 

CAs and Responders who implement this extension are protected.  For further discussion, see my comment in this thread that Denis has not addressed.

 

It is akin to IDP for partitioned CRL, but my concern is different than yours.  I am concerned that unless the assumptions made by this extension are adhered to by the CA and the Responders, there is less of a benefit.

 

From: Stefan Santesson [mailto:stefan@aaa-sec.com]
Sent: Thursday, October 11, 2012 9:07 AM
To: Denis Pinkas
Cc: Santosh Chokhani; pkix
Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt

 

I still think the gain obtained by your proposal is far less than the pain of introducing a new critical extension that needs client support.

 

I still can't see an attacker achieving anything beyond a DoS and I can't see this scaled to a DDoS attack.

Signed error or not.

 

/Stefan

 

 

From: Denis Pinkas <denis.pinkas@bull.net>
Date: Thursday, October 11, 2012 2:25 PM
To: Stefan Santesson <stefan@aaa-sec.com>
Cc: Santosh Chokhani <SChokhani@cygnacom.com>, pkix <pkix@ietf.org>
Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt

 

Stefan,

RFC 2560 states:

 "In case of errors, the OCSP Responder may return an error message.
These messages are not signed".

So an "unauthorized" response is not signed.

The text from RFC 2560 states:

   The response "unauthorized" is returned in cases where the client is
   not authorized to make this query to this server.

The text from RFC 5019 states the following:

   As long as the OCSP infrastructure has authoritative records for a

   particular certificate, an OCSPResponseStatus of "successful" will be

   returned.  When access to authoritative records for a particular

   certificate is not available, the responder MUST return an

   OCSPResponseStatus of "unauthorized".  As such, this profile extends

   the RFC 2560 [OCSP] definition of "unauthorized" as follows:

 

      The response "unauthorized" is returned in cases where the client

      is not authorized to make this query to this server or the server

      is not capable of responding authoritatively.


In the absence of the proposed extension, RFC 5019 could not do better.
 
With the proposed extension, it is possible to do better and to get a signed "unknown" status in a signed response
rather than an "unauthorized" error in an unsigned response, that is harder to interpret and subject to attacks:

 - was there a substitution attack, since this may not be a response from the authorized responder ?
 - am I using a wrong URL, since I am not sure this response comes from the right URL ?
 - am I missing an authorization to get the status ?

Denis

 

The "unauthorized" response seems suitable to me. 

 

"The response "unauthorized" is returned in cases where the client is not authorized to make this query to this server or the server is not capable of responding authoritatively (cf. [RFC5019], Section 2.2.3)"

 

/Stefan

 

 

 

From: Denis Pinkas Bull <denis.pinkas@bull.net>
Date: Thursday, October 11, 2012 7:53 AM
To: Stefan Santesson <stefan@aaa-sec.com>
Cc: Santosh Chokhani <SChokhani@cygnacom.com>, pkix <pkix@ietf.org>
Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt

 

Stefan,

As fas as I know, there are only three major status: "good", "revoked" or "unknown".

Error messages are:

   -- malformedRequest,
   -- internalError,
   -- tryLater,
   -- sigRequired,
   -- unauthorized.

There is no response like: "the responder is not authorised to provide information about the cert".
In the example, the RP gets "unknown" (with a correct signature from the OCSP responder),
whereas it would have received either "good" or "revoked", if there had been no attack.

Denis

Sorry, Still don't get it.

 

In your example, the client receives a response that the responder is not authorised to provide information about the cert.

So a man-in-the-middle can do a DoS attack. That is not new.

 

/Stefan

 

 

From: Denis Pinkas Bull <denis.pinkas@bull.net>
Date: Thursday, October 11, 2012 7:31 AM
To: Stefan Santesson <stefan@aaa-sec.com>
Cc: Santosh Chokhani <SChokhani@cygnacom.com>, pkix <pkix@ietf.org>
Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt

 

Stefan,

You missed the point. Let me illustrate why using a simple scenario:

OCSP Responder 1 receives delegation from CA x for the first 100.000 issued certificates.
OCSP Responder 1 has only access to the revocation status of the first 100.000 issued certificates.
The first 100.000 issued certificates contain url1 to locate OCSP Responder 1.

OCSP Responder 2 receives delegation from CA x for the next 100.000 issued certificates.
OCSP Responder 2 has only access to the revocation status of the next 100.000 issued certificates.
The next 100.000 issued certificates contains url2 to locate OCSP Responder 2.

A Relying Party (RP) uses url1 that is present in the target certificate to query OCSP Responder 1.
However, there is a man-in-the-middle-attack and this request in routed to OCSP Responder 2.
OCP2 responder 2 responds that it don't know the status of this certificate.
The response from OCSP Responder 2 is routed back to the RP.
The RP verifies that the response is indeed correctly signed.

If the man-in-the-middle attack were not done, the RP would have known that the certificate
was either "revoked" or "good", since only OCSP Responder 1 knows it.

Without the proposed extension, the protocol would provide incorrect revocation status results.

Denis



 Santesson a écrit :

Why do you need this at all?

 

I don't see that this extension is required in order to split OCSP responding for chunks of certs.

You can point the client to the correct responder using information in the cert today.

The responder can determine if the requested vert is within it's handled portion of certs.

 

Given that you trust the OCSP responder and the responder is honest, you will receive an appropriate response.

 

So, why the extension?

 

I can only imagine the extension being useful to detect if a responder responds outside of it's authority, but if the OCSP responder is dishonest, then you are screwed in any case.

 

/Stefan

 

 

From: Santosh Chokhani <SChokhani@cygnacom.com>
Date: Friday, September 28, 2012 4:17 PM
To: "denis.pinkas@bull.net" <denis.pinkas@bull.net>, pkix <pkix@ietf.org>
Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt

 

Denis,

 

I find the document in general acceptable.  It definitely fills a hole.

 

That said, it is effective both in general and against MITM attack if the CA recognizes that the absence of the critical extension you designed in the OCSP certificate means that the Responder is authoritative for all certificates as long as the rest of the requirements in RFC 2560 are met.

 

Note that absence of IDP means that the CRL is full and complete.  We do not have a similar statement in 2560 and this extension is fully effective only if such is the case, i.e., by omitting this extension, the CA implies that the Responder is authoritative for all certificates signed using that CA key.

 

We either need to impose this requirement, which while new, most implementations I know impose or discuss it in the Security Considerations section.

 

From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of denis.pinkas@bull.net
Sent: Tuesday, September 25, 2012 11:12 AM
To: pkix
Subject: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt

 

To the list,

The last comment from Santosh, triggered me to write a new draft proposal directly related to 2560bis.  

This proposal allows to split the workload of an OCSP service from a CA between several OCSP Responders.
This may be desirable for PKIs issuing a large number of certificates (e.g. several hundred of thousands).

Denis

==============================================================================================

A new version of I-D, draft-pinkas-2560bis-ocsp-locationcheck-00.txt
has been successfully submitted by Denis Pinkas and posted to the
IETF repository.

Filename:                 draft-pinkas-2560bis-ocsp-locationcheck
Revision:                 00
Title:                 OCSP LocationCheck certificate extension Update to OCSP
                  < draft-pinkas-2560bis-ocsp-locationcheck-00.txt >
Creation date:                  2012-09-25
WG ID:                                   Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-pinkas-2560bis-ocsp-locationcheck-00.txt
Status:          http://datatracker.ietf.org/doc/draft-pinkas-2560bis-ocsp-locationcheck
Htmlized:        http://tools.ietf.org/html/draft-pinkas-2560bis-ocsp-locationcheck-00


Abstract:

  RFC 2560 [RFC2560] allows CAs to designate one or more OCSP
  Responders for being responsible to provide the revocation status
  of the certificates they issue under a given CA key.

  This document introduces a new feature that allows allows CAs to
  split the workload between different sets of OCSP Responders in a
  way that is analogous to the way CRLs can be split between
  different sets of CRL issuers (using the cRLDistributionPoints
  extension).

  This new feature allows a CA to designate one or more OCSP
  Responders for being responsible to provide the revocation status
  for a subset of the certificates they issue under a given CA key.

  This document defines a critical extension that may only be placed
  in an OCSP certificate and the way it shall be processed by OCSP
  clients.

The IETF Secretariat

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

 

 

 


--------------030702050108090005050701-- From piyush@ditenity.com Thu Oct 11 08:08:04 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7139121F86C9 for ; Thu, 11 Oct 2012 08:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.523 X-Spam-Level: X-Spam-Status: No, score=-3.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AlCmwSqkAc52 for ; Thu, 11 Oct 2012 08:07:58 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2E421F8714 for ; Thu, 11 Oct 2012 08:07:57 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so3691937iec.31 for ; Thu, 11 Oct 2012 08:07:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language :x-gm-message-state; bh=tve0CcCB47rtYki5TTBnpxoqXoY7LXfyuOzfB66aw/8=; b=Y/1NKvE2wI7WKKFXZ9Oponbye77MmbaUCQw0VZspjZcVu3i+0F4Zpjlcwt0vPCc91W lrYmLA//vuDN1mXTJ9DKQ8MBOVUrOz3DahS24szHxt9669wuoybPgXQEtEDxaGb1/uaS YPF9VOxt+m8vusIPApNhyWPsvxEgxJYDQpcBd48G8dbumX7yhDQshzaiwAMi4nICAQoq I8APE34GaqaRGCEIKiAOlPlpM+ayJEOv4F6vvMrH/9cRE4lLiKNnyTaZpqm3zG8greTp JUY/KCX3pSVAVKLwPhUKjIA8VX8+MgNFPfXHUI5fhzrS3hksNDjx+SU4zoWhPCCP5/ne zaPw== Received: by 10.50.169.100 with SMTP id ad4mr1119299igc.50.1349968077345; Thu, 11 Oct 2012 08:07:57 -0700 (PDT) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id ch4sm14468971igb.2.2012.10.11.08.07.54 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 11 Oct 2012 08:07:56 -0700 (PDT) From: "Piyush Jain" To: "'Santosh Chokhani'" , "'Stefan Santesson'" , "'Denis Pinkas'" References: <5076BAC3.3050402@bull.net> In-Reply-To: Date: Thu, 11 Oct 2012 08:07:50 -0700 Message-ID: <039a01cda7c2$2f98f5e0$8ecae1a0$@ditenity.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_039B_01CDA787.834A4A80" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGxvTnvl0I8yxLfJgdx8fAp1PiCygF8wD9pAV4dTIOX1Su3oA== Content-Language: en-us X-Gm-Message-State: ALoCoQlQPlFJBiMMrRB4LnrFsVmFz/9WHCyKJ399jFXEcp8jKc0swS27j+VuEuYeTgGs5dn91/m9 X-Mailman-Approved-At: Thu, 11 Oct 2012 08:36:12 -0700 Cc: 'pkix' Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 15:08:04 -0000 This is a multipart message in MIME format. ------=_NextPart_000_039B_01CDA787.834A4A80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I fail to understand the benefits of this underlying assumption on which = the proposal for this extension is based. =93This proposal allows tosplit the workload of an OCSP service from a = CA between several OCSP Responders.=20 This may be desirable for PKIs issuing a large number of certificates = (e.g. several hundred of thousands).=94 =20 The proposal just cites that it may be desirable without saying what = those benefits are. I think that this approach does not help either with scalability or = security and it introduces unnecessary complexity. =20 From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Santosh Chokhani Sent: Thursday, October 11, 2012 7:26 AM To: Stefan Santesson; Denis Pinkas Cc: pkix Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt =20 Stefan, =20 It is possible that a Responder will assert good (e.g., for pre-signed responses) since RFC 2560 does not address if the CA splits the responsibility among multiple responders. In that case, MITM can get = and play a response of =93good=94 from a legitimate Responder. =20 CAs and Responders who implement this extension are protected. For = further discussion, see my comment in this thread that Denis has not addressed. =20 It is akin to IDP for partitioned CRL, but my concern is different than yours. I am concerned that unless the assumptions made by this = extension are adhered to by the CA and the Responders, there is less of a benefit. =20 From: Stefan Santesson [mailto:stefan@aaa-sec.com]=20 Sent: Thursday, October 11, 2012 9:07 AM To: Denis Pinkas Cc: Santosh Chokhani; pkix Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt =20 I still think the gain obtained by your proposal is far less than the = pain of introducing a new critical extension that needs client support. =20 I still can't see an attacker achieving anything beyond a DoS and I = can't see this scaled to a DDoS attack. Signed error or not. =20 /Stefan =20 =20 From: Denis Pinkas Date: Thursday, October 11, 2012 2:25 PM To: Stefan Santesson Cc: Santosh Chokhani , pkix Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt =20 Stefan, RFC 2560 states: "In case of errors, the OCSP Responder may return an error message. These messages are not signed".=20 So an "unauthorized" response is not signed. The text from RFC 2560 states: The response "unauthorized" is returned in cases where the client is not authorized to make this query to this server. The text from RFC 5019 states the following: As long as the OCSP infrastructure has authoritative records for a particular certificate, an OCSPResponseStatus of "successful" will be returned. When access to authoritative records for a particular certificate is not available, the responder MUST return an OCSPResponseStatus of "unauthorized". As such, this profile extends the RFC 2560 [OCSP] definition of "unauthorized" as follows: =20 The response "unauthorized" is returned in cases where the client is not authorized to make this query to this server or the server is not capable of responding authoritatively. In the absence of the proposed extension, RFC 5019 could not do better. =20 With the proposed extension, it is possible to do better and to get a = signed "unknown" status in a signed response=20 rather than an "unauthorized" error in an unsigned response, that is = harder to interpret and subject to attacks: - was there a substitution attack, since this may not be a response = from the authorized responder ? - am I using a wrong URL, since I am not sure this response comes from = the right URL ?=20 - am I missing an authorization to get the status ? Denis =20 The "unauthorized" response seems suitable to me.=20 =20 "The response "unauthorized" is returned in cases where the client is = not authorized to make this query to this server or the server is not = capable of responding authoritatively (cf. [RFC5019], Section 2.2.3)" =20 /Stefan =20 =20 =20 From: Denis Pinkas Bull Date: Thursday, October 11, 2012 7:53 AM To: Stefan Santesson Cc: Santosh Chokhani , pkix Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt =20 Stefan, As fas as I know, there are only three major status: "good", "revoked" = or "unknown". Error messages are: -- malformedRequest, -- internalError, -- tryLater, -- sigRequired, -- unauthorized. There is no response like: "the responder is not authorised to provide information about the cert". In the example, the RP gets "unknown" (with a correct signature from the OCSP responder),=20 whereas it would have received either "good" or "revoked", if there had = been no attack. Denis Sorry, Still don't get it. =20 In your example, the client receives a response that the responder is = not authorised to provide information about the cert. So a man-in-the-middle can do a DoS attack. That is not new. =20 /Stefan =20 =20 From: Denis Pinkas Bull Date: Thursday, October 11, 2012 7:31 AM To: Stefan Santesson Cc: Santosh Chokhani , pkix Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt =20 Stefan, You missed the point. Let me illustrate why using a simple scenario: OCSP Responder 1 receives delegation from CA x for the first 100.000 = issued certificates. OCSP Responder 1 has only access to the revocation status of the first 100.000 issued certificates. The first 100.000 issued certificates contain url1 to locate OCSP = Responder 1. OCSP Responder 2 receives delegation from CA x for the next 100.000 = issued certificates. OCSP Responder 2 has only access to the revocation status of the next 100.000 issued certificates. The next 100.000 issued certificates contains url2 to locate OCSP = Responder 2. A Relying Party (RP) uses url1 that is present in the target certificate = to query OCSP Responder 1. However, there is a man-in-the-middle-attack and this request in routed = to OCSP Responder 2. OCP2 responder 2 responds that it don't know the status of this = certificate. The response from OCSP Responder 2 is routed back to the RP. The RP verifies that the response is indeed correctly signed. If the man-in-the-middle attack were not done, the RP would have known = that the certificate=20 was either "revoked" or "good", since only OCSP Responder 1 knows it. Without the proposed extension, the protocol would provide incorrect revocation status results. Denis Santesson a =E9crit : Why do you need this at all? =20 I don't see that this extension is required in order to split OCSP responding for chunks of certs. You can point the client to the correct responder using information in = the cert today. The responder can determine if the requested vert is within it's handled portion of certs. =20 Given that you trust the OCSP responder and the responder is honest, you will receive an appropriate response. =20 So, why the extension? =20 I can only imagine the extension being useful to detect if a responder responds outside of it's authority, but if the OCSP responder is = dishonest, then you are screwed in any case. =20 /Stefan =20 =20 From: Santosh Chokhani Date: Friday, September 28, 2012 4:17 PM To: "denis.pinkas@bull.net" , pkix = Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt =20 Denis, =20 I find the document in general acceptable. It definitely fills a hole. =20 That said, it is effective both in general and against MITM attack if = the CA recognizes that the absence of the critical extension you designed in = the OCSP certificate means that the Responder is authoritative for all certificates as long as the rest of the requirements in RFC 2560 are = met. =20 Note that absence of IDP means that the CRL is full and complete. We do = not have a similar statement in 2560 and this extension is fully effective = only if such is the case, i.e., by omitting this extension, the CA implies = that the Responder is authoritative for all certificates signed using that CA key. =20 We either need to impose this requirement, which while new, most implementations I know impose or discuss it in the Security = Considerations section. =20 From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of denis.pinkas@bull.net Sent: Tuesday, September 25, 2012 11:12 AM To: pkix Subject: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt =20 To the list,=20 The last comment from Santosh, triggered me to write a new draft = proposal directly related to 2560bis. =20 This proposal allows to split the workload of an OCSP service from a CA between several OCSP Responders.=20 This may be desirable for PKIs issuing a large number of certificates = (e.g. several hundred of thousands).=20 Denis=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 A new version of I-D, draft-pinkas-2560bis-ocsp-locationcheck-00.txt has been successfully submitted by Denis Pinkas and posted to the IETF repository. Filename: draft-pinkas-2560bis-ocsp-locationcheck Revision: 00 Title: OCSP LocationCheck certificate extension Update = to OCSP=20 < draft-pinkas-2560bis-ocsp-locationcheck-00.txt > Creation date: 2012-09-25 WG ID: Individual Submission Number of pages: 6 URL: http://www.ietf.org/internet-drafts/draft-pinkas-2560bis-ocsp-locationche= ck- 00.txt Status: = http://datatracker.ietf.org/doc/draft-pinkas-2560bis-ocsp-locationcheck Htmlized: http://tools.ietf.org/html/draft-pinkas-2560bis-ocsp-locationcheck-00 Abstract:=20 RFC 2560 [RFC2560] allows CAs to designate one or more OCSP Responders for being responsible to provide the revocation status of the certificates they issue under a given CA key. This document introduces a new feature that allows allows CAs to split the workload between different sets of OCSP Responders in a way that is analogous to the way CRLs can be split between different sets of CRL issuers (using the cRLDistributionPoints extension). This new feature allows a CA to designate one or more OCSP Responders for being responsible to provide the revocation status for a subset of the certificates they issue under a given CA key. This document defines a critical extension that may only be placed in an OCSP certificate and the way it shall be processed by OCSP clients. The IETF Secretariat _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix=20 =20 =20 =20 ------=_NextPart_000_039B_01CDA787.834A4A80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I fail to understand the benefits of this underlying assumption on = which the proposal for this extension is based.

“This = proposal allows tosplit the workload of an OCSP service from a CA = between several OCSP Responders.
This may be = desirable for PKIs issuing a large number of certificates (e.g. several = hundred of thousands).”

 

The proposal just cites that it may be desirable without saying what = those benefits are.

I think that this approach does not help either with scalability or = security and =A0it introduces unnecessary = complexity.

 

From:= = pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of = Santosh Chokhani
Sent: Thursday, October 11, 2012 7:26 = AM
To: Stefan Santesson; Denis Pinkas
Cc: = pkix
Subject: Re: [pkix] New Version Notification for = draft-pinkas-2560bis-ocsp-locationcheck-00.txt

 

= Stefan,

=  

= It is possible that a Responder will assert good (e.g., for pre-signed = responses) since RFC 2560 does not address if the CA splits the = responsibility among multiple responders.  In that case, MITM can = get and play a response of “good” from a legitimate = Responder.

=  

= CAs and Responders who implement this extension are protected.  For = further discussion, see my comment in this thread that Denis has not = addressed.

=  

= It is akin to IDP for partitioned CRL, but my concern is different than = yours.  I am concerned that unless the assumptions made by this = extension are adhered to by the CA and the Responders, there is less of = a benefit.

=  

 

From: Denis Pinkas <denis.pinkas@bull.net>
Date: Thursday, October 11, 2012 2:25 PM
To: Stefan = Santesson <stefan@aaa-sec.com>
Cc: = Santosh Chokhani <SChokhani@cygnacom.com>, = pkix <pkix@ietf.org>
Subject: = Re: [pkix] New Version Notification for = draft-pinkas-2560bis-ocsp-locationcheck-00.txt

 

S= tefan,

RFC 2560 states:

 "In case of errors, the = OCSP Responder may return an error message.
These messages are not = signed".

So an "unauthorized" response is not = signed.

The text from RFC 2560 states:<= br>
   The response "unauthorized" is returned in = cases where the client is
   not authorized to make this = query to this server.<= br>
The text from RFC 5019 states the following:

   As long as the OCSP infrastructure has authoritative = records for a

   particular certificate, an OCSPResponseStatus of = "successful" will be

   returned.  When access to authoritative records for a = particular

   certificate is not available, the responder MUST return = an

   OCSPResponseStatus of "unauthorized".  As = such, this profile extends

   the RFC 2560 [OCSP] definition of "unauthorized" = as follows:

 

      The response "unauthorized" is = returned in cases where the client

      is not authorized to make this query to = this server or the server

      is not capable of responding = authoritatively.


In the absence of the proposed extension, RFC 5019 could not do = better.
 
With the proposed extension, it is possible to do = better and to get a signed "unknown" status in a signed = response
rather than an "unauthorized" error in an = unsigned response, that is harder to interpret and subject to = attacks:

 - was there a substitution attack, since this may = not be a response from the authorized responder ?
 - am I using = a wrong URL, since I am not sure this response comes from the right URL = ?
 - am I missing an authorization to get the status = ?

Denis

 

The "unauthorized" response seems suitable to = me. 

 

"The response "unauthorized" is returned in cases where = the client is not authorized to make this query to this server or the = server is not capable of responding authoritatively (cf. [RFC5019], = Section 2.2.3)"

 

/Stefan

 

 

 

From: Denis Pinkas Bull <denis.pinkas@bull.net>
Date: Thursday, October 11, 2012 7:53 AM
To: Stefan = Santesson <stefan@aaa-sec.com>
Cc: = Santosh Chokhani <SChokhani@cygnacom.com>, = pkix <pkix@ietf.org>
Subject: = Re: [pkix] New Version Notification for = draft-pinkas-2560bis-ocsp-locationcheck-00.txt

 

Stefan,

As = fas as I know, there are only three major status: "good", = "revoked" or "unknown".

Error messages = are:

   -- malformedRequest,
   -- = internalError,
   -- tryLater,
   -- = sigRequired,
   -- unauthorized.

There is no = response like: "the responder is not authorised to provide = information about the cert".
In the example, the RP gets = "unknown" (with a correct signature from the OCSP responder), =
whereas it would have received either "good" or = "revoked", if there had been no = attack.

Denis

Sorry, Still don't get it.

 

In your example, the client receives a response that the responder is = not authorised to provide information about the = cert.

So a man-in-the-middle can do a DoS attack. That is not = new.

 

/Stefan

 

 

From: Denis Pinkas Bull <denis.pinkas@bull.net>
Date: Thursday, October 11, 2012 7:31 AM
To: Stefan = Santesson <stefan@aaa-sec.com>
Cc: = Santosh Chokhani <SChokhani@cygnacom.com>, = pkix <pkix@ietf.org>
Subject: = Re: [pkix] New Version Notification for = draft-pinkas-2560bis-ocsp-locationcheck-00.txt

 

Stefan,

You missed the point. Let me illustrate why using a = simple scenario:

OCSP Responder 1 receives delegation from CA x = for the first 100.000 issued certificates.
OCSP Responder 1 has only = access to the revocation status of the first 100.000 issued = certificates.
The first 100.000 issued certificates contain url1 to = locate OCSP Responder 1.

OCSP Responder 2 receives delegation = from CA x for the next 100.000 issued certificates.
OCSP Responder 2 = has only access to the revocation status of the next 100.000 issued = certificates.
The next 100.000 issued certificates contains url2 to = locate OCSP Responder 2.

A Relying Party (RP) uses url1 that is = present in the target certificate to query OCSP Responder 1.
However, = there is a man-in-the-middle-attack and this request in routed to OCSP = Responder 2.
OCP2 responder 2 responds that it don't know the status = of this certificate.
The response from OCSP Responder 2 is routed = back to the RP.
The RP verifies that the response is indeed correctly = signed.

If the man-in-the-middle attack were not done, the RP = would have known that the certificate
was either "revoked" = or "good", since only OCSP Responder 1 knows = it.

Without the proposed extension, the protocol would provide = incorrect revocation status = results.

Denis



 Santesson a = =E9crit :

Why do you need this at all?

 

I don't see that this extension is required in order to split OCSP = responding for chunks of certs.

You can point the client to the correct responder using information in = the cert today.

The responder can determine if the requested vert is within it's = handled portion of certs.

 

Given that you trust the OCSP responder and the responder is honest, = you will receive an appropriate = response.

 

So, why the extension?

 

I can only imagine the extension being useful to detect if a responder = responds outside of it's authority, but if the OCSP responder is = dishonest, then you are screwed in any = case.

 

/Stefan

 

 

From: Santosh Chokhani <SChokhani@cygnacom.com>
= Date: Friday, September 28, 2012 4:17 PM
To: "denis.pinkas@bull.net" = <denis.pinkas@bull.net>, = pkix <pkix@ietf.org>
Subject: = Re: [pkix] New Version Notification for = draft-pinkas-2560bis-ocsp-locationcheck-00.txt

 

= Denis,

=  

= I find the document in general acceptable.  It definitely fills a = hole.

=  

= That said, it is effective both in general and against MITM attack if = the CA recognizes that the absence of the critical extension you = designed in the OCSP certificate means that the Responder is = authoritative for all certificates as long as the rest of the = requirements in RFC 2560 are met.

=  

= Note that absence of IDP means that the CRL is full and complete.  = We do not have a similar statement in 2560 and this extension is fully = effective only if such is the case, i.e., by omitting this extension, = the CA implies that the Responder is authoritative for all certificates = signed using that CA key.

=  

= We either need to impose this requirement, which while new, most = implementations I know impose or discuss it in the Security = Considerations section.

=  

= From:= pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] = On Behalf Of denis.pinkas@bull.net
Sen= t: Tuesday, September 25, 2012 11:12 AM
To: = pkix
Subject: [pkix] New Version Notification for = draft-pinkas-2560bis-ocsp-locationcheck-00.txt

 

T= o the list,

T= he last comment from Santosh, triggered me to write a new draft proposal = directly related to 2560bis.   =

T= his proposal allows to split the workload of an OCSP service from a CA = between several OCSP Responders. =
T= his may be desirable for PKIs issuing a large number of certificates = (e.g. several hundred of thousands). =

D= enis

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

A new version of I-D, = draft-pinkas-2560bis-ocsp-locationcheck-00.txt
has been = successfully submitted by Denis Pinkas and posted to = the
IETF repository.

Filename:     =             = draft-pinkas-2560bis-ocsp-locationcheck
Revision:   =               00
Title: =                 OCSP = LocationCheck certificate extension Update to OCSP
  =                 < = draft-pinkas-2560bis-ocsp-locationcheck-00.txt >
Creation = date:                 =  2012-09-25
WG ID:           =                     =     Individual Submission
Number of pages: = 6
URL:             = http://www.ietf.org/internet-drafts/draft-pink= as-2560bis-ocsp-locationcheck-00.txt
Status:         =  http://datatracker.ietf.org/doc/draft-pinkas-2= 560bis-ocsp-locationcheck
Htmlized:       =  http://tools.ietf.org/html/draft-pinkas-2560bi= s-ocsp-locationcheck-00


Abstract:

  RFC 2560 [RFC2560] allows CAs to = designate one or more OCSP
  Responders for being = responsible to provide the revocation status
  of the = certificates they issue under a given CA key.

  = This document introduces a new feature that allows allows CAs = to
  split the workload between different sets of OCSP = Responders in a
  way that is analogous to the way CRLs = can be split between
  different sets of CRL issuers = (using the cRLDistributionPoints
  = extension).

  This new feature allows a CA to = designate one or more OCSP
  Responders for being = responsible to provide the revocation status
  for a = subset of the certificates they issue under a given CA = key.

  This document defines a critical extension = that may only be placed
  in an OCSP certificate and = the way it shall be processed by OCSP
  = clients.

The IETF Secretariat

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

 

 

 

= ------=_NextPart_000_039B_01CDA787.834A4A80-- From denis.pinkas@bull.net Thu Oct 11 09:30:49 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B98121F8543 for ; Thu, 11 Oct 2012 09:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.554 X-Spam-Level: X-Spam-Status: No, score=-4.554 tagged_above=-999 required=5 tests=[AWL=1.694, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3t+MbUJxk7j for ; Thu, 11 Oct 2012 09:30:48 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id D95A521F8514 for ; Thu, 11 Oct 2012 09:30:47 -0700 (PDT) Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id C976D418011; Thu, 11 Oct 2012 18:30:46 +0200 (CEST) Received: from [127.0.0.1] ([129.184.39.15]) by MSGC-007.bull.fr (Lotus Domino Release 8.5.3FP1) with ESMTP id 2012101118304600-781 ; Thu, 11 Oct 2012 18:30:46 +0200 Message-ID: <5076F432.7050105@bull.net> Date: Thu, 11 Oct 2012 18:30:42 +0200 From: Denis Pinkas User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Piyush Jain References: <5076BAC3.3050402@bull.net> <039a01cda7c2$2f98f5e0$8ecae1a0$@ditenity.com> In-Reply-To: <039a01cda7c2$2f98f5e0$8ecae1a0$@ditenity.com> X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 11/10/2012 18:30:46, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 11/10/2012 18:30:46, Serialize complete at 11/10/2012 18:30:46 X-TNEFEvaluated: 1 Content-Type: multipart/alternative; boundary="------------070602050201020207080304" Cc: 'Stefan Santesson' , 'pkix' Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 16:30:49 -0000 This is a multi-part message in MIME format. --------------070602050201020207080304 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed Piyush, > I fail to understand the benefits of this underlying assumption on > which the proposal for this extension is based. > > "This proposal allows tosplit the workload of an OCSP service from a > CA between several OCSP Responders. > This may be desirable for PKIs issuing a large number of certificates > (e.g. several hundred of thousands)." > > The proposal just cites that it may be desirable without saying what > those benefits are. > The benefit is that every OCSP responder is only responsible for a fraction of the issued certificates. It is up to the CA to decide which fraction. As an example, "critical servers" may be served by a dedicated OCSP responder servicing around 1.000 servers, while "usual servers" may be served by another OCSP responder servicing around 100.000 servers. So the first URL will be less loaded than the second one. Another advantage is that the first URL will be kept unknown, unless you get a certificate from a critical server. So a denial of service attack is more difficult to construct, since you need to get a certificate from a critical server, rather than any certificate issued by the CA. Denis > I think that this approach does not help either with scalability or > security and it introduces unnecessary complexity. > > --------------070602050201020207080304 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=ISO-8859-1
Piyush,

I fail to understand the benefits of this underlying assumption on which the proposal for this extension is based.

“This proposal allows tosplit the workload of an OCSP service from a CA between several OCSP Responders.
This may be desirable for PKIs issuing a large number of certificates (e.g. several hundred of thousands).”

 

The proposal just cites that it may be desirable without saying what those benefits are.


The benefit is that every OCSP responder is only responsible for a fraction of the issued certificates.
It is up to the CA to decide which fraction.

As an example, "critical servers" may be served by a dedicated OCSP responder servicing around 1.000 servers,
while "usual servers" may be served by another OCSP responder servicing around 100.000 servers.

So the first URL will be less loaded than the second one.

Another advantage is that the first URL will be kept unknown, unless you get a certificate from a critical server.
So a denial of service attack is more difficult to construct, since you need to get a certificate from a critical server,
rather than any certificate issued by the CA.

Denis

I think that this approach does not help either with scalability or security and  it introduces unnecessary complexity.

 


--------------070602050201020207080304-- From carl@redhoundsoftware.com Thu Oct 11 10:02:02 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5FD21F8674 for ; Thu, 11 Oct 2012 10:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.834 X-Spam-Level: X-Spam-Status: No, score=-3.834 tagged_above=-999 required=5 tests=[AWL=-1.632, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dp2oIEhuaL93 for ; Thu, 11 Oct 2012 10:02:00 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 59C0321F8629 for ; Thu, 11 Oct 2012 10:02:00 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id 25so5786160qao.10 for ; Thu, 11 Oct 2012 10:01:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:x-gm-message-state; bh=Y8lubE81Hc2gtkAu7vmKh9lhkJ2Kd9ALiR9WM3opBWw=; b=WAVDxrMrkJz6xgZ6s/m073BKe1XRWsUpwAPbo9Tc+jeRnRK6INckMJfpna42WQ/G34 zxDmpyROG3BUfoz2YvvvD8RpIVMuF7O9frh+YUk1iSdoFzrVVGbIiMgtzXp+BoLDM6iJ rQkPKQm+QEP/roKXSTrd+K3uweaQSK5oNqYPSMdJdECGqbM3wg1Gj4GToaA+mDKIvaOe Q8GlI6UNoG2l5MyqD1Lgdw1iU1yivTtUwsGbAaWm+HtYausI0gWoZL3ccibcSC4GxrxW D2lyiMqqFjhNlVd3iMFinxYoCGWArbDjemAdVkP+Iuu5hdIkneA0dig3XEZquhb/9afG gYZw== Received: by 10.224.97.197 with SMTP id m5mr2798384qan.57.1349974919609; Thu, 11 Oct 2012 10:01:59 -0700 (PDT) Received: from [192.168.2.8] (pool-72-66-83-116.washdc.fios.verizon.net. [72.66.83.116]) by mx.google.com with ESMTPS id o10sm4960203qaj.14.2012.10.11.10.01.54 (version=SSLv3 cipher=OTHER); Thu, 11 Oct 2012 10:01:58 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Thu, 11 Oct 2012 13:01:49 -0400 From: Carl Wallace To: Denis Pinkas , Piyush Jain Message-ID: Thread-Topic: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt In-Reply-To: <5076F432.7050105@bull.net> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3432805316_310462" X-Gm-Message-State: ALoCoQmFHBEpzAy98mKVywNyyGPHTfSANvHtlIyEbA8BlL5nS//Wq+T6aF+HMzE5k+jWSSsMrZSx Cc: 'Stefan Santesson' , 'pkix' Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 17:02:02 -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_3432805316_310462 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable How is an OCSP responder that is fed by CRLs supposed to know which fractio= n it is responsible for? Why would you limit an OCSP responder that had direct access to a CA database? =20 You could achieve your example below by issuing the critical servers off of a different CA than usual servers and avoid updating client software. The unknown URL point is pretty thin. From: Denis Pinkas Date: Thursday, October 11, 2012 12:30 PM To: Piyush Jain Cc: 'Stefan Santesson' , 'pkix' Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt > =20 > =20 > Piyush, > =20 > =20 > =20 >> =20 >> =20 >>=20 >> I fail to understand the benefits of this underlying assumption on which= the >> proposal for this extension is based. >> =20 >> =B3This proposal allows tosplit the workload of an OCSP service from a CA >> between several OCSP Responders. >> This may be desirable for PKIs issuing a large number of certificates (= e.g. >> several hundred of thousands).=B2 >> =20 >> =20 >> =20 >> The proposal just cites that it may be desirable without saying what tho= se >> benefits are. >> =20 >> =20 >> =20 > =20 > The benefit is that every OCSP responder is only responsible for a fract= ion > of the issued certificates. > It is up to the CA to decide which fraction. > =20 > As an example, "critical servers" may be served by a dedicated OCSP resp= onder > servicing around 1.000 servers, > while "usual servers" may be served by another OCSP responder servicing > around 100.000 servers. > =20 > So the first URL will be less loaded than the second one. > =20 > Another advantage is that the first URL will be kept unknown, unless you= get > a certificate from a critical server. > So a denial of service attack is more difficult to construct, since you = need > to get a certificate from a critical server, > rather than any certificate issued by the CA. > =20 > Denis > =20 > =20 >> =20 >> =20 >>=20 >> =20 >> I think that this approach does not help either with scalability or secu= rity >> and it introduces unnecessary complexity. >> =20 >> =20 >> =20 >> =20 >> =20 > =20 > =20 > _______________________________________________ pkix mailing list > pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --B_3432805316_310462 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
How is an OCSP responder tha= t is fed by CRLs supposed to know which fraction it is responsible for? &nbs= p;

Why would you limit an OCSP responder that had d= irect access to a CA database?  

You could ach= ieve your example below by issuing the critical servers off of a different C= A than usual servers and avoid updating client software.  
The unknown URL point is pretty thin.  

<= span style=3D"font-weight:bold">From: Denis Pinkas <denis.pinkas@bull.net>
Date: Thursday, October 11, 2012 12:30 PM
To: Piyush Jain <piyush@ditenity.com>
Cc: <= /span> 'Stefan Santesson' <stefan@aaa= -sec.com>, 'pkix' <pkix@ietf.org>
Subject: Re: [pkix] New Vers= ion Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt

Piyush,

I fail to understand the benefits of this underlying assumption on which the proposal for this extension is based.

“This proposal allows tosplit the workload of an OCSP service from a CA between several OCSP Responders.
T= his may be desirable for PKIs issuing a large number of certificates (e.g. several hundred of thousands).”

 

The proposal just cites that it may be desirable without saying what those benefits are.


The benefit is that every OCSP responder is only responsible for a fraction of the issued certificates.
It is up to the CA to decide which fraction.

As an example, "critical servers" may be served by a dedicated OCSP responder servicing around 1.000 servers,
while "usual servers" may be served by another OCSP responder servicing around 100.000 servers.

So the first URL will be less loaded than the second one.

Another advantage is that the first URL will be kept unknown, unless you get a certificate from a critical server.
So a denial of service attack is more difficult to construct, since you need to get a certificate from a critical server,
rather than any certificate issued by the CA.

Denis

I think that this approach does not help either with scalability or security and  it introduces unnecessary complexity.

 


_______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/m= ailman/listinfo/pkix
--B_3432805316_310462-- From peter.sylvester@edelweb.fr Thu Oct 11 10:04:10 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38F5721F8628 for ; Thu, 11 Oct 2012 10:04:10 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0nd6rBjkvIC for ; Thu, 11 Oct 2012 10:04:09 -0700 (PDT) Received: from mx1.on-x.com (mx1.on-x.com [92.103.215.51]) by ietfa.amsl.com (Postfix) with ESMTP id A68F121F8622 for ; Thu, 11 Oct 2012 10:04:09 -0700 (PDT) Received: from mx1.on-x.com (localhost [127.0.0.1]) by mx1.on-x.com (Postfix) with ESMTP id B6E545E143 for ; Thu, 11 Oct 2012 19:03:36 +0200 (CEST) Received: from mail1.on-x.com (mail1.on-x.com [192.168.10.66]) by mx1.on-x.com (Postfix) with ESMTP id A72CA5E137 for ; Thu, 11 Oct 2012 19:03:36 +0200 (CEST) Received: from mail1.on-x.com (localhost [127.0.0.1]) by mail1.on-x.com (Postfix) with ESMTP id 75E495E210 for ; Thu, 11 Oct 2012 19:03:16 +0200 (CEST) Received: from smtps.on-x.com (imaps.on-x.com [192.168.14.31]) by mail1.on-x.com (Postfix) with ESMTP id 69C995E1D3 for ; Thu, 11 Oct 2012 19:03:16 +0200 (CEST) Received: from [192.168.0.27] (unknown [82.227.163.182]) by smtps.on-x.com (Postfix) with ESMTPSA id 017E95E0DB for ; Thu, 11 Oct 2012 19:05:22 +0200 (CEST) Message-ID: <5076FC07.1060300@edelweb.fr> Date: Thu, 11 Oct 2012 19:04:07 +0200 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: pkix@ietf.org References: <5076BAC3.3050402@bull.net> <039a01cda7c2$2f98f5e0$8ecae1a0$@ditenity.com> <5076F432.7050105@bull.net> In-Reply-To: <5076F432.7050105@bull.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 17:04:10 -0000 If a CA creates 100K or more certificates, one might consider to split the CA and with a designated ocsp responder per CA. From piyush@ditenity.com Thu Oct 11 10:10:15 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9789221F86B8 for ; Thu, 11 Oct 2012 10:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.936 X-Spam-Level: X-Spam-Status: No, score=-2.936 tagged_above=-999 required=5 tests=[AWL=0.662, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36dIB1xT1-TL for ; Thu, 11 Oct 2012 10:10:13 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1C121F86C6 for ; Thu, 11 Oct 2012 10:10:13 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so3958523iec.31 for ; Thu, 11 Oct 2012 10:10:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language :x-gm-message-state; bh=Q1c7Xa0Z/d6/F2WFzwT4QO4GvEoxGx2OzqSqMEfRIm4=; b=pqDaQAK2ii+zNjGFVNJSzz2NRT39RC0WRrBtelGBEAMaXfkdtG51BuF+kYym0yENin TCr8QX2RQTV/U3qoBHhnwWjgPCs4B+zuMh41ogpSJKqz0wdBTrAwQvWKhc/gS6m2a8jo nMGwm+6G65e+1KoIhcxv4EVR1dTGPX9jBuyhLRR42ajKsKq7jRlmMMUGcjoYgcRxUgHB S7YJXFVGLPV7qP/ertZO4mJKMz+j0O+99C6uAhBlXgVVYfD63zSxCAEohMVimVsEgVhM RGQjKiUBl/JXExc/8ARTUgDrV00yjO4bn3SidUp3FaFXcy1TTpIZP6n11vHHF8NkSutg hZAA== Received: by 10.50.213.35 with SMTP id np3mr1613510igc.22.1349975411764; Thu, 11 Oct 2012 10:10:11 -0700 (PDT) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id ce10sm14889883igb.1.2012.10.11.10.10.09 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 11 Oct 2012 10:10:10 -0700 (PDT) From: "Piyush Jain" To: "'Denis Pinkas'" References: <5076BAC3.3050402@bull.net> <039a01cda7c2$2f98f5e0$8ecae1a0$@ditenity.com> <5076F432.7050105@bull.net> In-Reply-To: <5076F432.7050105@bull.net> Date: Thu, 11 Oct 2012 10:10:05 -0700 Message-ID: <044801cda7d3$43bb5160$cb31f420$@ditenity.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0449_01CDA798.975DD8F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGxvTnvl0I8yxLfJgdx8fAp1PiCygF8wD9pAV4dTIMCgF5yeQJqBceEl634HaA= Content-Language: en-us X-Gm-Message-State: ALoCoQmTeM0lIMr7EDDuRkpbMtIoQ9pYm6ttCHFHmniRnoU5B9JOgCIahzElnubXQDqYT0Dd/UfM Cc: 'Stefan Santesson' , 'pkix' Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 17:10:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0449_01CDA798.975DD8F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Denis, Thanks for your quick response. The way I interpret it is that in you example some certificates issued by the CA are more critical than others. That an interesting idea. One outcome could be that CAs can charge a premium based on the OCSP URI that is put in your certificate. I wonder what the CPS for such a CA would look like. Don't you think that public CA vendors already have a way to do this? They don't partition OCSP responders, instead they partition CAs based on 'criticality' of the certificates that are issued by that CA. You also made a point about denial of service. Personally I'm not a fan of security through obscurity. But even if this point has some merit, your proposed extension is not needed for such a design. CAs are free to put whatever AIA extension they want in any certificate they issue. -Piyush From: Denis Pinkas [mailto:denis.pinkas@bull.net] Sent: Thursday, October 11, 2012 9:31 AM To: Piyush Jain Cc: 'Santosh Chokhani'; 'Stefan Santesson'; 'pkix' Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt Piyush, I fail to understand the benefits of this underlying assumption on which the proposal for this extension is based. "This proposal allows tosplit the workload of an OCSP service from a CA between several OCSP Responders. This may be desirable for PKIs issuing a large number of certificates (e.g. several hundred of thousands)." The proposal just cites that it may be desirable without saying what those benefits are. The benefit is that every OCSP responder is only responsible for a fraction of the issued certificates. It is up to the CA to decide which fraction. As an example, "critical servers" may be served by a dedicated OCSP responder servicing around 1.000 servers, while "usual servers" may be served by another OCSP responder servicing around 100.000 servers. So the first URL will be less loaded than the second one. Another advantage is that the first URL will be kept unknown, unless you get a certificate from a critical server. So a denial of service attack is more difficult to construct, since you need to get a certificate from a critical server, rather than any certificate issued by the CA. Denis I think that this approach does not help either with scalability or security and it introduces unnecessary complexity. ------=_NextPart_000_0449_01CDA798.975DD8F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Denis,

 

Thanks for your quick response.

 

The way I interpret it is that in you example some certificates = issued by the CA are more critical than others.

That an interesting idea. One outcome could be that CAs can charge a = premium based on the OCSP URI that is put in your certificate. I wonder = what the CPS for such a CA would look like.

 

Don’t you think that public CA vendors already have a way to do = this? They don’t partition OCSP responders, instead they partition = CAs based on ‘criticality’ of the certificates that are = issued by that CA.

 

You also made a point about denial of service. Personally I’m = not a fan of security through obscurity. But even if this point has some = merit, your proposed extension is not needed for such a design. CAs are = free to put whatever AIA extension they want in any certificate they = issue.

 

-Piyush

 

 

From: Denis Pinkas [mailto:denis.pinkas@bull.net]
Sent: = Thursday, October 11, 2012 9:31 AM
To: Piyush = Jain
Cc: 'Santosh Chokhani'; 'Stefan Santesson'; = 'pkix'
Subject: Re: [pkix] New Version Notification for = draft-pinkas-2560bis-ocsp-locationcheck-00.txt

 

Piyush,

I fail to understand the benefits of this underlying assumption on = which the proposal for this extension is based.

“This = proposal allows tosplit the workload of an OCSP service from a CA = between several OCSP Responders.
This may be = desirable for PKIs issuing a large number of certificates (e.g. several = hundred of thousands).”

 =

The proposal just cites that it may be desirable without saying what = those benefits are.


The benefit is that every OCSP responder is only = responsible for a fraction of the issued certificates.
It is up to = the CA to decide which fraction.

As an example, "critical = servers" may be served by a dedicated OCSP responder servicing = around 1.000 servers,
while "usual servers" may be served = by another OCSP responder servicing around 100.000 servers.

So = the first URL will be less loaded than the second one.

Another = advantage is that the first URL will be kept unknown, unless you get a = certificate from a critical server.
So a denial of service attack is = more difficult to construct, since you need to get a certificate from a = critical server,
rather than any certificate issued by the = CA.

Denis


I think that this approach does not help either with scalability or = security and  it introduces unnecessary = complexity.

 

 

------=_NextPart_000_0449_01CDA798.975DD8F0-- From denis.pinkas@bull.net Thu Oct 11 10:18:09 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC62121F86C3 for ; Thu, 11 Oct 2012 10:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.609 X-Spam-Level: X-Spam-Status: No, score=-4.609 tagged_above=-999 required=5 tests=[AWL=1.639, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeMyQaoONhR2 for ; Thu, 11 Oct 2012 10:18:07 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4FC21F8686 for ; Thu, 11 Oct 2012 10:18:07 -0700 (PDT) Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id B810A418042; Thu, 11 Oct 2012 19:18:06 +0200 (CEST) Received: from [127.0.0.1] ([129.184.39.15]) by MSGC-007.bull.fr (Lotus Domino Release 8.5.3FP1) with ESMTP id 2012101119180622-791 ; Thu, 11 Oct 2012 19:18:06 +0200 Message-ID: <5076FF4A.1090303@bull.net> Date: Thu, 11 Oct 2012 19:18:02 +0200 From: Denis Pinkas User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Carl Wallace References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 11/10/2012 19:18:06, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 11/10/2012 19:18:06, Serialize complete at 11/10/2012 19:18:06 X-TNEFEvaluated: 1 Content-Type: multipart/alternative; boundary="------------010001060304010008080409" Cc: 'pkix' Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 17:18:09 -0000 This is a multi-part message in MIME format. --------------010001060304010008080409 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed Carl, > How is an OCSP responder that is fed by CRLs supposed to know which > fraction it is responsible for? > > Why would you limit an OCSP responder that had direct access to a CA > database? As you have implicitly noticed, this scheme is only adequate when the OCSP responder has a direct access to the portion of the CA database for which it is responsible. I take your point: this should be better advertised. > You could achieve your example below by issuing the critical servers > off of a different CA than usual servers and avoid updating client > software. This may or may not be possible or desirable. Denis > The unknown URL point is pretty thin. > > From: Denis Pinkas > > Date: Thursday, October 11, 2012 12:30 PM > To: Piyush Jain > > Cc: 'Stefan Santesson' >, 'pkix' > > Subject: Re: [pkix] New Version Notification for > draft-pinkas-2560bis-ocsp-locationcheck-00.txt > > Piyush, > >> I fail to understand the benefits of this underlying assumption >> on which the proposal for this extension is based. >> >> "This proposal allows tosplit the workload of an OCSP service >> from a CA between several OCSP Responders. >> This may be desirable for PKIs issuing a large number of >> certificates (e.g. several hundred of thousands)." >> >> The proposal just cites that it may be desirable without saying >> what those benefits are. >> > > The benefit is that every OCSP responder is only responsible for a > fraction of the issued certificates. > It is up to the CA to decide which fraction. > > As an example, "critical servers" may be served by a dedicated > OCSP responder servicing around 1.000 servers, > while "usual servers" may be served by another OCSP responder > servicing around 100.000 servers. > > So the first URL will be less loaded than the second one. > > Another advantage is that the first URL will be kept unknown, > unless you get a certificate from a critical server. > So a denial of service attack is more difficult to construct, > since you need to get a certificate from a critical server, > rather than any certificate issued by the CA. > > Denis > >> I think that this approach does not help either with scalability >> or security and it introduces unnecessary complexity. >> >> > > _______________________________________________ pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > --------------010001060304010008080409 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=ISO-8859-1
Carl,

How is an OCSP responder that is fed by CRLs supposed to know which fraction it is responsible for?  

Why would you limit an OCSP responder that had direct access to a CA database? 
As you have implicitly noticed, this scheme is only adequate when the OCSP responder has a direct access
to the portion of the CA database for which it is responsible. I take your point: this should be better advertised.

You could achieve your example below by issuing the critical servers off of a different CA than usual servers and avoid updating client software. 

This may or may not be possible or desirable.

Denis

The unknown URL point is pretty thin.  

From: Denis Pinkas <denis.pinkas@bull.net>
Date: Thursday, October 11, 2012 12:30 PM
To: Piyush Jain <piyush@ditenity.com>
Cc: 'Stefan Santesson' <stefan@aaa-sec.com>, 'pkix' <pkix@ietf.org>
Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt

Piyush,

I fail to understand the benefits of this underlying assumption on which the proposal for this extension is based.

“This proposal allows tosplit the workload of an OCSP service from a CA between several OCSP Responders.
This may be desirable for PKIs issuing a large number of certificates (e.g. several hundred of thousands).”

 

The proposal just cites that it may be desirable without saying what those benefits are.


The benefit is that every OCSP responder is only responsible for a fraction of the issued certificates.
It is up to the CA to decide which fraction.

As an example, "critical servers" may be served by a dedicated OCSP responder servicing around 1.000 servers,
while "usual servers" may be served by another OCSP responder servicing around 100.000 servers.

So the first URL will be less loaded than the second one.

Another advantage is that the first URL will be kept unknown, unless you get a certificate from a critical server.
So a denial of service attack is more difficult to construct, since you need to get a certificate from a critical server,
rather than any certificate issued by the CA.

Denis

I think that this approach does not help either with scalability or security and  it introduces unnecessary complexity.

 


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

--------------010001060304010008080409-- From denis.pinkas@bull.net Thu Oct 11 10:25:28 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 884C121F866B for ; Thu, 11 Oct 2012 10:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.66 X-Spam-Level: X-Spam-Status: No, score=-4.66 tagged_above=-999 required=5 tests=[AWL=1.588, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRvS1c9dnNuc for ; Thu, 11 Oct 2012 10:25:26 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id AA76D21F8644 for ; Thu, 11 Oct 2012 10:25:25 -0700 (PDT) Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id E266C3180C7; Thu, 11 Oct 2012 19:25:24 +0200 (CEST) Received: from [127.0.0.1] ([129.184.39.15]) by MSGC-007.bull.fr (Lotus Domino Release 8.5.3FP1) with ESMTP id 2012101119252445-793 ; Thu, 11 Oct 2012 19:25:24 +0200 Message-ID: <50770100.2000101@bull.net> Date: Thu, 11 Oct 2012 19:25:20 +0200 From: Denis Pinkas User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Piyush Jain References: <5076BAC3.3050402@bull.net> <039a01cda7c2$2f98f5e0$8ecae1a0$@ditenity.com> <5076F432.7050105@bull.net> <044801cda7d3$43bb5160$cb31f420$@ditenity.com> In-Reply-To: <044801cda7d3$43bb5160$cb31f420$@ditenity.com> X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 11/10/2012 19:25:24, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 11/10/2012 19:25:24, Serialize complete at 11/10/2012 19:25:24 X-TNEFEvaluated: 1 Content-Type: multipart/alternative; boundary="------------090502070702040807080805" Cc: 'pkix' Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 17:25:28 -0000 This is a multi-part message in MIME format. --------------090502070702040807080805 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed Piyush, > > Denis, > > Thanks for your quick response. > > The way I interpret it is that in you example some certificates issued > by the CA are more critical than others. > > That an interesting idea. One outcome could be that CAs can charge a > premium based on the OCSP URI that is put in your certificate. I > wonder what the CPS for such a CA would look like. > > Don't you think that public CA vendors already have a way to do this? > They don't partition OCSP responders, instead they partition CAs based > on 'criticality' of the certificates that are issued by that CA. > It is a chicken and egg problem. Public CA vendors can't partition OCSP responders since the proposed extension is not defined/standardized. So the only solution is to act as you indicate. Denis > You also made a point about denial of service. Personally I'm not a > fan of security through obscurity. But even if this point has some > merit, your proposed extension is not needed for such a design. CAs > are free to put whatever AIA extension they want in any certificate > they issue. > > -Piyush > > > *From:*Denis Pinkas [mailto:denis.pinkas@bull.net] > *Sent:* Thursday, October 11, 2012 9:31 AM > *To:* Piyush Jain > *Cc:* 'Santosh Chokhani'; 'Stefan Santesson'; 'pkix' > *Subject:* Re: [pkix] New Version Notification for > draft-pinkas-2560bis-ocsp-locationcheck-00.txt > > Piyush, > > I fail to understand the benefits of this underlying assumption on > which the proposal for this extension is based. > > "This proposal allows tosplit the workload of an OCSP service from > a CA between several OCSP Responders. > This may be desirable for PKIs issuing a large number of > certificates (e.g. several hundred of thousands)." > > The proposal just cites that it may be desirable without saying > what those benefits are. > > > The benefit is that every OCSP responder is only responsible for a > fraction of the issued certificates. > It is up to the CA to decide which fraction. > > As an example, "critical servers" may be served by a dedicated OCSP > responder servicing around 1.000 servers, > while "usual servers" may be served by another OCSP responder > servicing around 100.000 servers. > > So the first URL will be less loaded than the second one. > > Another advantage is that the first URL will be kept unknown, unless > you get a certificate from a critical server. > So a denial of service attack is more difficult to construct, since > you need to get a certificate from a critical server, > rather than any certificate issued by the CA. > > Denis > > > I think that this approach does not help either with scalability or > security and it introduces unnecessary complexity. > --------------090502070702040807080805 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=ISO-8859-1
Piyush,
 

Denis,

 Thanks for your quick response.

 The way I interpret it is that in you example some certificates issued by the CA are more critical than others.

That an interesting idea. One outcome could be that CAs can charge a premium based on the OCSP URI that is put in your certificate. I wonder what the CPS for such a CA would look like.

 Don’t you think that public CA vendors already have a way to do this? They don’t partition OCSP responders, instead they partition CAs based on ‘criticality’ of the certificates that are issued by that CA.

It is a chicken and egg problem. Public CA vendors can't partition OCSP responders since the proposed extension is not defined/standardized.
So the only solution is to act as you indicate.

Denis

You also made a point about denial of service. Personally I’m not a fan of security through obscurity. But even if this point has some merit, your proposed extension is not needed for such a design. CAs are free to put whatever AIA extension they want in any certificate they issue.

 -Piyush

 

From: Denis Pinkas [mailto:denis.pinkas@bull.net]
Sent: Thursday, October 11, 2012 9:31 AM
To: Piyush Jain
Cc: 'Santosh Chokhani'; 'Stefan Santesson'; 'pkix'
Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt

 

Piyush,

I fail to understand the benefits of this underlying assumption on which the proposal for this extension is based.

“This proposal allows tosplit the workload of an OCSP service from a CA between several OCSP Responders.
This may be desirable for PKIs issuing a large number of certificates (e.g. several hundred of thousands).”

 

The proposal just cites that it may be desirable without saying what those benefits are.


The benefit is that every OCSP responder is only responsible for a fraction of the issued certificates.
It is up to the CA to decide which fraction.

As an example, "critical servers" may be served by a dedicated OCSP responder servicing around 1.000 servers,
while "usual servers" may be served by another OCSP responder servicing around 100.000 servers.

So the first URL will be less loaded than the second one.

Another advantage is that the first URL will be kept unknown, unless you get a certificate from a critical server.
So a denial of service attack is more difficult to construct, since you need to get a certificate from a critical server,
rather than any certificate issued by the CA.

Denis


I think that this approach does not help either with scalability or security and  it introduces unnecessary complexity.

 

 


--------------090502070702040807080805-- From denis.pinkas@bull.net Thu Oct 11 10:26:33 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0994321F86C1 for ; Thu, 11 Oct 2012 10:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.709 X-Spam-Level: X-Spam-Status: No, score=-4.709 tagged_above=-999 required=5 tests=[AWL=1.540, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvMYF7rBO+mO for ; Thu, 11 Oct 2012 10:26:32 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 8623221F866B for ; Thu, 11 Oct 2012 10:26:32 -0700 (PDT) Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id F29C43180C7; Thu, 11 Oct 2012 19:26:31 +0200 (CEST) Received: from [127.0.0.1] ([129.184.39.15]) by MSGC-007.bull.fr (Lotus Domino Release 8.5.3FP1) with ESMTP id 2012101119263087-795 ; Thu, 11 Oct 2012 19:26:30 +0200 Message-ID: <50770146.7060408@bull.net> Date: Thu, 11 Oct 2012 19:26:30 +0200 From: Denis Pinkas User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Peter Sylvester References: <5076BAC3.3050402@bull.net> <039a01cda7c2$2f98f5e0$8ecae1a0$@ditenity.com> <5076F432.7050105@bull.net> <5076FC07.1060300@edelweb.fr> In-Reply-To: <5076FC07.1060300@edelweb.fr> X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 11/10/2012 19:26:31, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 11/10/2012 19:26:32, Serialize complete at 11/10/2012 19:26:32 X-TNEFEvaluated: 1 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed Cc: pkix Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 17:26:33 -0000 Peter, See my response to Carl. Denis > If a CA creates 100K or more certificates, one might consider > to split the CA and with a designated ocsp responder per CA. > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From eabalea@gmail.com Thu Oct 11 10:34:48 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1156721F85C2 for ; Thu, 11 Oct 2012 10:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHlj2MWw-SIa for ; Thu, 11 Oct 2012 10:34:47 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4654521F86D0 for ; Thu, 11 Oct 2012 10:34:47 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so1649413lbo.31 for ; Thu, 11 Oct 2012 10:34:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=AGvTTHdbbhRg58sBBqHorh1XZsCU02xdEHI1/lou/Dc=; b=roaKNerKEN+SB8RfqAKDwRXYtDe+NWedHUHN3gJvglhtf6CUlV99RajUchgb0cLvVP IQO9ffcK31xwuADQ0p4JkpuHxhNT9sUa0NpA7W1RmH6GIOZ+nt7uWzBK0yVmH9O3UfYf gO3u0NTTUFg7tM0+xKMEILGCGibyBgJgwzbRFgVh7bNMdgTYXlA0IHgkZ/NA+/d26h03 39mEquqF7nDYFOAMRuD9vmjksJKTIAUOA8Rd30abYPrBPfW/nkML5D1em5ZaFTKYsulx 5frNyg9ACpA/V708qcrBCL0GJ0CNssqK6ncTTdS/Am74tr0qfaM3adl5Files7Vn2s9Z FZ1g== MIME-Version: 1.0 Received: by 10.152.123.103 with SMTP id lz7mr1403806lab.21.1349976886235; Thu, 11 Oct 2012 10:34:46 -0700 (PDT) Received: by 10.114.9.35 with HTTP; Thu, 11 Oct 2012 10:34:45 -0700 (PDT) In-Reply-To: <50770100.2000101@bull.net> References: <5076BAC3.3050402@bull.net> <039a01cda7c2$2f98f5e0$8ecae1a0$@ditenity.com> <5076F432.7050105@bull.net> <044801cda7d3$43bb5160$cb31f420$@ditenity.com> <50770100.2000101@bull.net> Date: Thu, 11 Oct 2012 19:34:45 +0200 Message-ID: From: Erwann Abalea To: Denis Pinkas Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: pkix Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 17:34:48 -0000 Bonsoir, 2012/10/11 Denis Pinkas : > Piyush, > > > Denis, > > Thanks for your quick response. > >> The way I interpret it is that in you example some certificates issued = by >> the CA are more critical than others. > >> That an interesting idea. One outcome could be that CAs can charge a pre= mium >> based on the OCSP URI that is put in your certificate. I wonder what the= CPS >> for such a CA would look like. > >> Don=E2=80=99t you think that public CA vendors already have a way to do= this? They >> don=E2=80=99t partition OCSP responders, instead they partition CAs base= d on >> =E2=80=98criticality=E2=80=99 of the certificates that are issued by tha= t CA. > > It is a chicken and egg problem. Public CA vendors can't partition OCSP > responders since the proposed extension is not defined/standardized. > So the only solution is to act as you indicate. I don't think public CAs want to partition OCSP responders. CA partitioning is quasi-free, while performant OCSP isn't. Adding OCSP partitioning will just render the whole stuff harder to use. Ongoing discussions in CABForum go toward an optional "mustStaple" extension for certificates. --=20 Erwann. From peter.sylvester@edelweb.fr Thu Oct 11 11:02:45 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C797221F8713 for ; Thu, 11 Oct 2012 11:02:45 -0700 (PDT) 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.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pl6a7YA7vL0t for ; Thu, 11 Oct 2012 11:02:45 -0700 (PDT) Received: from mx1.on-x.com (mx1.on-x.com [92.103.215.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2569E21F8587 for ; Thu, 11 Oct 2012 11:02:45 -0700 (PDT) Received: from mx1.on-x.com (localhost [127.0.0.1]) by mx1.on-x.com (Postfix) with ESMTP id B07205E143 for ; Thu, 11 Oct 2012 20:02:12 +0200 (CEST) Received: from mail1.on-x.com (mail1.on-x.com [192.168.10.66]) by mx1.on-x.com (Postfix) with ESMTP id 955055E133 for ; Thu, 11 Oct 2012 20:02:12 +0200 (CEST) Received: from mail1.on-x.com (localhost [127.0.0.1]) by mail1.on-x.com (Postfix) with ESMTP id 7DA5F5E303 for ; Thu, 11 Oct 2012 20:01:52 +0200 (CEST) Received: from smtps.on-x.com (unknown [192.168.14.34]) by mail1.on-x.com (Postfix) with ESMTP id 7176A5E08D for ; Thu, 11 Oct 2012 20:01:52 +0200 (CEST) Received: from [192.168.0.27] (unknown [82.227.163.182]) by smtps.on-x.com (Postfix) with ESMTPSA id 219735E0D8 for ; Thu, 11 Oct 2012 20:01:59 +0200 (CEST) Message-ID: <507709C3.2090200@edelweb.fr> Date: Thu, 11 Oct 2012 20:02:43 +0200 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: pkix@ietf.org References: <5076FF4A.1090303@bull.net> In-Reply-To: <5076FF4A.1090303@bull.net> Content-Type: multipart/alternative; boundary="------------070707060606030901030604" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 18:02:45 -0000 This is a multi-part message in MIME format. --------------070707060606030901030604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/11/2012 07:18 PM, Denis Pinkas wrote: > Carl, > >> You could achieve your example below by issuing the critical servers off of a different CA than >> usual servers and avoid updating client software. > > This may or may not be possible or desirable. > To me this doesn't seem very helpful. Could you provide a concrete use case where this is not possible or where this is not desirable? Erwann gave a concrete response. Peter --------------070707060606030901030604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 10/11/2012 07:18 PM, Denis Pinkas wrote:
Carl,


You could achieve your example below by issuing the critical servers off of a different CA than usual servers and avoid updating client software. 

This may or may not be possible or desirable.

To me this doesn't seem very helpful.
Could you provide a concrete use case where
this is not possible or where this is not desirable?


Erwann gave a concrete response.

Peter

--------------070707060606030901030604-- From stefan@aaa-sec.com Thu Oct 11 14:39:22 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8B561F0C3E for ; Thu, 11 Oct 2012 14:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.852 X-Spam-Level: X-Spam-Status: No, score=-100.852 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtNz8Xgu4pk0 for ; Thu, 11 Oct 2012 14:39:16 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id A7E8A1F041F for ; Thu, 11 Oct 2012 14:39:06 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id AB7702254BC7 for ; Thu, 11 Oct 2012 23:39:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id jwKZhKccGUcq for ; Thu, 11 Oct 2012 23:38:59 +0200 (CEST) Received: from s376.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id E9B372254BE0 for ; Thu, 11 Oct 2012 23:38:59 +0200 (CEST) Received: (qmail 53752 invoked from network); 11 Oct 2012 21:38:59 -0000 Received: from 81-232-51-61-no39.business.telia.com (HELO [192.168.0.111]) (stefan@fiddler.nu@[81.232.51.61]) (envelope-sender ) by s376.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 11 Oct 2012 21:38:59 -0000 User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Thu, 11 Oct 2012 23:38:58 +0200 From: Stefan Santesson To: Santosh Chokhani , Denis Pinkas Message-ID: Thread-Topic: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3432843541_5657765" Cc: pkix Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 21:39:22 -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_3432843541_5657765 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable A responder that is designed to work within the described setup will not respond good. It's hard to protect against bad implementations through protocol design. My personal view is still that this is not worth the pain. But we are in any case not allowed to take on more work in PKIX, so my opinion is not important. /Stefan From: Santosh Chokhani Date: Thursday, October 11, 2012 4:26 PM To: Stefan Santesson , Denis Pinkas Cc: pkix Subject: RE: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt > Stefan, > =20 > It is possible that a Responder will assert good (e.g., for pre-signed > responses) since RFC 2560 does not address if the CA splits the responsib= ility > among multiple responders. In that case, MITM can get and play a respons= e of > =B3good=B2 from a legitimate Responder. > =20 > CAs and Responders who implement this extension are protected. For furth= er > discussion, see my comment in this thread that Denis has not addressed. > =20 > It is akin to IDP for partitioned CRL, but my concern is different than y= ours. > I am concerned that unless the assumptions made by this extension are adh= ered > to by the CA and the Responders, there is less of a benefit. > =20 >=20 > From: Stefan Santesson [mailto:stefan@aaa-sec.com] > Sent: Thursday, October 11, 2012 9:07 AM > To: Denis Pinkas > Cc: Santosh Chokhani; pkix > Subject: Re: [pkix] New Version Notification for > draft-pinkas-2560bis-ocsp-locationcheck-00.txt > =20 >=20 > I still think the gain obtained by your proposal is far less than the pai= n of > introducing a new critical extension that needs client support. >=20 > =20 >=20 > I still can't see an attacker achieving anything beyond a DoS and I can't= see > this scaled to a DDoS attack. >=20 > Signed error or not. >=20 > =20 >=20 > /Stefan >=20 > =20 >=20 > =20 >=20 > From: Denis Pinkas > Date: Thursday, October 11, 2012 2:25 PM > To: Stefan Santesson > Cc: Santosh Chokhani , pkix > Subject: Re: [pkix] New Version Notification for > draft-pinkas-2560bis-ocsp-locationcheck-00.txt >=20 > =20 >>=20 >> Stefan, >>=20 >> RFC 2560 states: >>=20 >> "In case of errors, the OCSP Responder may return an error message. >> These messages are not signed". >>=20 >> So an "unauthorized" response is not signed. >>=20 >> The text from RFC 2560 states: >>=20 >> The response "unauthorized" is returned in cases where the client is >> not authorized to make this query to this server. >>=20 >> The text from RFC 5019 states the following: >> As long as the OCSP infrastructure has authoritative records for a >> particular certificate, an OCSPResponseStatus of "successful" will be >> returned. When access to authoritative records for a particular >> certificate is not available, the responder MUST return an >> OCSPResponseStatus of "unauthorized". As such, this profile extends >> the RFC 2560 [OCSP] definition of "unauthorized" as follows: >> =20 >> The response "unauthorized" is returned in cases where the client >> is not authorized to make this query to this server or the server >> is not capable of responding authoritatively. >>=20 >> In the absence of the proposed extension, RFC 5019 could not do better. >> =20 >> With the proposed extension, it is possible to do better and to get a si= gned >> "unknown" status in a signed response >> rather than an "unauthorized" error in an unsigned response, that is har= der >> to interpret and subject to attacks: >>=20 >> - was there a substitution attack, since this may not be a response fro= m the >> authorized responder ? >> - am I using a wrong URL, since I am not sure this response comes from = the >> right URL ?=20 >> - am I missing an authorization to get the status ? >>=20 >> Denis >>=20 >> =20 >>>=20 >>> The "unauthorized" response seems suitable to me. >>>=20 >>> =20 >>>=20 >>> "The response "unauthorized" is returned in cases where the client is n= ot >>> authorized to make this query to this server or the server is not capab= le of >>> responding authoritatively (cf. [RFC5019], Section 2.2.3)" >>>=20 >>> =20 >>>=20 >>> /Stefan >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>> From: Denis Pinkas Bull >>> Date: Thursday, October 11, 2012 7:53 AM >>> To: Stefan Santesson >>> Cc: Santosh Chokhani , pkix >>> Subject: Re: [pkix] New Version Notification for >>> draft-pinkas-2560bis-ocsp-locationcheck-00.txt >>>=20 >>> =20 >>>>=20 >>>> Stefan, >>>>=20 >>>> As fas as I know, there are only three major status: "good", "revoked"= or >>>> "unknown". >>>>=20 >>>> Error messages are: >>>>=20 >>>> -- malformedRequest, >>>> -- internalError, >>>> -- tryLater, >>>> -- sigRequired, >>>> -- unauthorized. >>>>=20 >>>> There is no response like: "the responder is not authorised to provide >>>> information about the cert". >>>> In the example, the RP gets "unknown" (with a correct signature from t= he >>>> OCSP responder), >>>> whereas it would have received either "good" or "revoked", if there ha= d >>>> been no attack. >>>>=20 >>>> Denis >>>>>=20 >>>>> Sorry, Still don't get it. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> In your example, the client receives a response that the responder is= not >>>>> authorised to provide information about the cert. >>>>>=20 >>>>> So a man-in-the-middle can do a DoS attack. That is not new. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> /Stefan >>>>>=20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> From: Denis Pinkas Bull >>>>> Date: Thursday, October 11, 2012 7:31 AM >>>>> To: Stefan Santesson >>>>> Cc: Santosh Chokhani , pkix >>>>> Subject: Re: [pkix] New Version Notification for >>>>> draft-pinkas-2560bis-ocsp-locationcheck-00.txt >>>>>=20 >>>>> =20 >>>>>>=20 >>>>>> Stefan, >>>>>>=20 >>>>>> You missed the point. Let me illustrate why using a simple scenario: >>>>>>=20 >>>>>> OCSP Responder 1 receives delegation from CA x for the first 100.000 >>>>>> issued certificates. >>>>>> OCSP Responder 1 has only access to the revocation status of the fir= st >>>>>> 100.000 issued certificates. >>>>>> The first 100.000 issued certificates contain url1 to locate OCSP >>>>>> Responder 1. >>>>>>=20 >>>>>> OCSP Responder 2 receives delegation from CA x for the next 100.000 >>>>>> issued certificates. >>>>>> OCSP Responder 2 has only access to the revocation status of the nex= t >>>>>> 100.000 issued certificates. >>>>>> The next 100.000 issued certificates contains url2 to locate OCSP >>>>>> Responder 2. >>>>>>=20 >>>>>> A Relying Party (RP) uses url1 that is present in the target certifi= cate >>>>>> to query OCSP Responder 1. >>>>>> However, there is a man-in-the-middle-attack and this request in rou= ted >>>>>> to OCSP Responder 2. >>>>>> OCP2 responder 2 responds that it don't know the status of this >>>>>> certificate. >>>>>> The response from OCSP Responder 2 is routed back to the RP. >>>>>> The RP verifies that the response is indeed correctly signed. >>>>>>=20 >>>>>> If the man-in-the-middle attack were not done, the RP would have kno= wn >>>>>> that the certificate >>>>>> was either "revoked" or "good", since only OCSP Responder 1 knows it= . >>>>>>=20 >>>>>> Without the proposed extension, the protocol would provide incorrect >>>>>> revocation status results. >>>>>>=20 >>>>>> Denis >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Santesson a =E9crit : >>>>>>>=20 >>>>>>> Why do you need this at all? >>>>>>>=20 >>>>>>> =20 >>>>>>>=20 >>>>>>> I don't see that this extension is required in order to split OCSP >>>>>>> responding for chunks of certs. >>>>>>>=20 >>>>>>> You can point the client to the correct responder using information= in >>>>>>> the cert today. >>>>>>>=20 >>>>>>> The responder can determine if the requested vert is within it's ha= ndled >>>>>>> portion of certs. >>>>>>>=20 >>>>>>> =20 >>>>>>>=20 >>>>>>> Given that you trust the OCSP responder and the responder is honest= , you >>>>>>> will receive an appropriate response. >>>>>>>=20 >>>>>>> =20 >>>>>>>=20 >>>>>>> So, why the extension? >>>>>>>=20 >>>>>>> =20 >>>>>>>=20 >>>>>>> I can only imagine the extension being useful to detect if a respon= der >>>>>>> responds outside of it's authority, but if the OCSP responder is >>>>>>> dishonest, then you are screwed in any case. >>>>>>>=20 >>>>>>> =20 >>>>>>>=20 >>>>>>> /Stefan >>>>>>>=20 >>>>>>> =20 >>>>>>>=20 >>>>>>> =20 >>>>>>>=20 >>>>>>> From: Santosh Chokhani >>>>>>> Date: Friday, September 28, 2012 4:17 PM >>>>>>> To: "denis.pinkas@bull.net" , pkix >>>>>>> >>>>>>> Subject: Re: [pkix] New Version Notification for >>>>>>> draft-pinkas-2560bis-ocsp-locationcheck-00.txt >>>>>>>=20 >>>>>>> =20 >>>>>>>=20 >>>>>>> Denis, >>>>>>> =20 >>>>>>> I find the document in general acceptable. It definitely fills a h= ole. >>>>>>> =20 >>>>>>> That said, it is effective both in general and against MITM attack = if >>>>>>> the CA recognizes that the absence of the critical extension you >>>>>>> designed in the OCSP certificate means that the Responder is >>>>>>> authoritative for all certificates as long as the rest of the >>>>>>> requirements in RFC 2560 are met. >>>>>>> =20 >>>>>>> Note that absence of IDP means that the CRL is full and complete. = We do >>>>>>> not have a similar statement in 2560 and this extension is fully >>>>>>> effective only if such is the case, i.e., by omitting this extensio= n, >>>>>>> the CA implies that the Responder is authoritative for all certific= ates >>>>>>> signed using that CA key. >>>>>>> =20 >>>>>>> We either need to impose this requirement, which while new, most >>>>>>> implementations I know impose or discuss it in the Security >>>>>>> Considerations section. >>>>>>> =20 >>>>>>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behal= f Of >>>>>>> denis.pinkas@bull.net >>>>>>> Sent: Tuesday, September 25, 2012 11:12 AM >>>>>>> To: pkix >>>>>>> Subject: [pkix] New Version Notification for >>>>>>> draft-pinkas-2560bis-ocsp-locationcheck-00.txt >>>>>>> =20 >>>>>>> To the list, >>>>>>>=20 >>>>>>> The last comment from Santosh, triggered me to write a new draft >>>>>>> proposal directly related to 2560bis. >>>>>>>=20 >>>>>>> This proposal allows to split the workload of an OCSP service from = a CA >>>>>>> between several OCSP Responders. >>>>>>> This may be desirable for PKIs issuing a large number of certificat= es >>>>>>> (e.g. several hundred of thousands). >>>>>>>=20 >>>>>>> Denis=20 >>>>>>>=20 >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>>=20 >>>>>>> A new version of I-D, draft-pinkas-2560bis-ocsp-locationcheck-00.tx= t >>>>>>> has been successfully submitted by Denis Pinkas and posted to the >>>>>>> IETF repository. >>>>>>>=20 >>>>>>> Filename: draft-pinkas-2560bis-ocsp-locationcheck >>>>>>> Revision: 00 >>>>>>> Title: OCSP LocationCheck certificate extension Upd= ate >>>>>>> to OCSP=20 >>>>>>> < draft-pinkas-2560bis-ocsp-locationcheck-00.txt = > >>>>>>> Creation date: 2012-09-25 >>>>>>> WG ID: Individual Submission >>>>>>> Number of pages: 6 >>>>>>> URL: =20 >>>>>>> http://www.ietf.org/internet-drafts/draft-pinkas-2560bis-ocsp-locat= ionch >>>>>>> eck-00.txt=20 >>>>>>> >>>>>> heck-00.txt> >>>>>>> Status: =20 >>>>>>> http://datatracker.ietf.org/doc/draft-pinkas-2560bis-ocsp-locationc= heck >>>>>>> >>>>>> >=20 >>>>>>> Htmlized: =20 >>>>>>> http://tools.ietf.org/html/draft-pinkas-2560bis-ocsp-locationcheck-= 00 >>>>>>> >>>>>>>=20 >>>>>>>=20 >>>>>>> Abstract:=20 >>>>>>>=20 >>>>>>> RFC 2560 [RFC2560] allows CAs to designate one or more OCSP >>>>>>> Responders for being responsible to provide the revocation status >>>>>>> of the certificates they issue under a given CA key. >>>>>>>=20 >>>>>>> This document introduces a new feature that allows allows CAs to >>>>>>> split the workload between different sets of OCSP Responders in a >>>>>>> way that is analogous to the way CRLs can be split between >>>>>>> different sets of CRL issuers (using the cRLDistributionPoints >>>>>>> extension). >>>>>>>=20 >>>>>>> This new feature allows a CA to designate one or more OCSP >>>>>>> Responders for being responsible to provide the revocation status >>>>>>> for a subset of the certificates they issue under a given CA key. >>>>>>>=20 >>>>>>> This document defines a critical extension that may only be place= d >>>>>>> in an OCSP certificate and the way it shall be processed by OCSP >>>>>>> clients. >>>>>>>=20 >>>>>>> The IETF Secretariat >>>>>>> _______________________________________________ pkix mailing list >>>>>>> pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix >>>>>> =20 >>>> =20 >> =20 --B_3432843541_5657765 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
A responder that is designed= to work within the described setup will not respond good.
It's ha= rd to protect against bad implementations through protocol design.

My personal view is still that this is not worth the pain.

But we are in any case not allowed to take on more w= ork in PKIX, so my opinion is not important.

/Stefa= n


From: Santosh Chokhani <SChokhani@cy= gnacom.com>
Date: Thursday,= October 11, 2012 4:26 PM
To: Stef= an Santesson <stefan@aaa-sec.com&= gt;, Denis Pinkas <denis.pinkas@bu= ll.net>
Cc: pkix <pkix@ietf.org>
Subject: RE: [pkix] New Version Notification for draft-pinkas-2= 560bis-ocsp-locationcheck-00.txt

Stefan,<= /o:p>

 

It is possible that a Responder will asser= t good (e.g., for pre-signed responses) since RFC 2560 does not address if t= he CA splits the responsibility among multiple responders.  In that cas= e, MITM can get and play a response of “good” from a legitimate = Responder.

 =

CAs and Responders who imp= lement this extension are protected.  For further discussion, see my co= mment in this thread that Denis has not addressed.

 

It is akin to IDP for partitioned CRL, but my concern is diffe= rent than yours.  I am concerned that unless the assumptions made by th= is extension are adhered to by the CA and the Responders, there is less of a= benefit.

 <= /o:p>

From: Stefan Santesson [mailto:stefan@a= aa-sec.com]
Sent: Thursday, October 11, 2012 9:07 AM
To= : Denis Pinkas
Cc: Santosh Chokhani; pkix
Subject: R= e: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationche= ck-00.txt

 

 <= /p>

I still can't see an attacker achie= ving anything beyond a DoS and I can't see this scaled to a DDoS attack.

Signed error or not.=

 

/Stefan<= /p>

 

<= div>

 

From: Denis Pinkas <denis.pinkas@bull.net>
Date: Thursd= ay, October 11, 2012 2:25 PM
To: Stefan Santesson <stefan@aaa-sec.com>
Cc: Santosh Cho= khani <SChokhani@cygnacom.com= >, pkix <pkix@ietf.org>
Su= bject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp= -locationcheck-00.txt

<= span style=3D"font-size: 10.5pt; font-family: Calibri, sans-serif; color: blac= k; "> 

Stefan,

RFC 2560 states= :

 "In case of errors, the OCSP Responder may return an error me= ssage.
These messages are not signed".

So an "unauthorized" respo= nse is not signed.

The text from RFC 2560 states:

   The response "unauthorized" is returned in cases wh= ere the client is
   not authorized to make this query to this = server.

The text from RFC 5019 states the following:

=    As long as the OCSP infrastructure has autho= ritative records for a

   particular certi= ficate, an OCSPResponseStatus of "successful" will be

   certificate is not available, = the responder MUST return an

   OCSPRespon= seStatus of "unauthorized".  As such, this profile extends=

   the RFC 2560 [OCSP] definition of "unauthorized" as= follows:

 

<= p class=3D"MsoPlainText" style=3D"margin-top:0in">  = ;    The response "unauthorized" is returned in cases where t= he client

      is not auth= orized to make this query to this server or the server


In the absence of the proposed extension, RFC = 5019 could not do better.
 
With the proposed extension, it is po= ssible to do better and to get a signed "unknown" status in a signed respons= e
rather than an "unauthorized" error in an unsigned response, that is h= arder to interpret and subject to attacks:

 - was there a substi= tution attack, since this may not be a response from the authorized responde= r ?
 - am I using a wrong URL, since I am not sure this response com= es from the right URL ?
 - am I missing an authorization to get the= status ?

Denis

 

The "unauthorized" response seems suit= able to me. 

 

"The respon= se "unauthorized" is returned in cases where the client is not authorized to= make this query to this server or the server is not capable of responding a= uthoritatively (cf. [RFC5019], Section 2.2.3)"

&nbs= p;

/Stefan

 

 

 

From: De= nis Pinkas Bull <denis.pinkas@bull= .net>
Date: Thursday, October 11, 2012 7:53 AM
To: Stefan Santesson <stefan@aaa-sec.co= m>
Cc: Santosh Chokhani <SChokhani@cygnacom.com>, pkix <pkix@ietf.org>
Subject: Re: [pkix] New Version Notific= ation for draft-pinkas-2560bis-ocsp-locationcheck-00.txt

 

<= p class=3D"MsoNormal" align=3D"left" style=3D"margin-bottom:12.0pt;text-align:left= ">Stefan,

As = fas as I know, there are only three major status: "good", "revoked" or "unkn= own".

Error messages are:

   -- malformedRequest,   -- internalError,
   -- tryLater,
  = -- sigRequired,
   -- unauthorized.

There is no respons= e like: "the responder is not authorised to provide information about the ce= rt".
In the example, the RP gets "unknown" (with a correct signature from= the OCSP responder),
whereas it would have received either= "good" or "revoked", if t= here had been no attack.

Denis

Sorry, Still don't get i= t.

 

In your example, the clien= t receives a response that the responder is not authorised to provide inform= ation about the cert.

So a man-in-the-middle can do a Do= S attack. That is not new.

 

<= /div>

/S= tefan

 

 

<= b>From: Denis Pinkas Bull <denis.pinkas@bull.net>
Date: Thursday, October = 11, 2012 7:31 AM
To: Stefan Santesson <stefan@aaa-sec.com>
Cc: Santosh Chokhani <SChokhani@cygnacom.com>, pkix &= lt;pkix@ietf.org>
Subject: R= e: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationche= ck-00.txt

 

<= blockquote style=3D"border:none;border-left:solid #B5C4DF 4.5pt;padding:0in 0i= n 0in 4.0pt;margin-left:3.75pt;margin-right:0in" id=3D"MAC_OUTLOOK_ATTRIBUTION= _BLOCKQUOTE">

Stefan,

You missed the point. Let me illustrate why u= sing a simple scenario:

OCSP Responder 1 receives delegation from CA = x for the first 100.000 issued certificates.
OCSP Responder 1 has only ac= cess to the revocation status of the first 100.000 issued certificates.
T= he first 100.000 issued certificates contain url1 to locate OCSP Responder 1= .

OCSP Responder 2 receives delegation from CA x for the next 100.000= issued certificates.
OCSP Responder 2 has only access to the revocation = status of the next 100.000 issued certificates.
The next 100.000 issued c= ertificates contains url2 to locate OCSP Responder 2.

A Relying Party= (RP) uses url1 that is present in the target certificate to query OCSP Resp= onder 1.
However, there is a man-in-the-middle-attack and this request in= routed to OCSP Responder 2.
OCP2 responder 2 responds that it don't know= the status of this certificate.
The response from OCSP Responder 2 is ro= uted back to the RP.
The RP verifies that the response is indeed correctl= y signed.

If the man-in-the-middle attack were not done, the RP would= have known that the certificate
was either "revoked" or "good", since o= nly OCSP Responder 1 knows it.

Without the proposed extension, the pr= otocol would provide incorrect revocation status results.

Denis


 Santesson a =E9crit :

Why do you need this at all?<= /o:p>

 

I don't see that this extension is= required in order to split OCSP responding for chunks of certs.<= /span>

You can point the client to the correct responder using information= in the cert today.

The responder can determine if the r= equested vert is within it's handled portion of certs.

=

<= o:p> 

Given that you trust the OCSP responder and the re= sponder is honest, you will receive an appropriate response.

<= span style=3D"font-size: 10.5pt; font-family: Calibri, sans-serif; color: blac= k; "> 

So, why the extension?

=

<= o:p> 

I can only imagine the extension being useful to d= etect if a responder responds outside of it's authority, but if the OCSP res= ponder is dishonest, then you are screwed in any case.

=

<= o:p> 

/Stefan

 

<= span style=3D"font-size: 10.5pt; font-family: Calibri, sans-serif; color: blac= k; "> 

From: Santosh Chokhani <= SChokhani@cygnacom.com>
Date: Friday, September 28, 2012 4:17 PM
To: "denis.pinkas@bull.net" <denis.pinkas@bull.net>, pkix <pkix@ietf.org>
Subject: Re: [pkix] New Version= Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt<= o:p>

 

Denis,

 

I fin= d the document in general acceptable.  It definitely fills a hole.

 

That said, it is effective both in general and agai= nst MITM attack if the CA recognizes that the absence of the critical extens= ion you designed in the OCSP certificate means that the Responder is authori= tative for all certificates as long as the rest of the requirements in RFC 2= 560 are met.

 

Note that absence of IDP means tha= t the CRL is full and complete.  We do not have a similar statement in = 2560 and this extension is fully effective only if such is the case, i.e., b= y omitting this extension, the CA implies that the Responder is authoritativ= e for all certificates signed using that CA key.

 

 

From: pkix-bounces@ietf.org [mailt= o:pkix-bounces@ietf.org] On Behalf Of denis.pinkas@bull.net
Sent: Tuesday, September 25,= 2012 11:12 AM
To: pkix
Subject: [pkix] New Version Noti= fication for draft-pinkas-2560bis-ocsp-locationcheck-00.txt

 

To the list,

The last comment from Santosh= , triggered me to write a new draft proposal directly related to 2560bis. &n= bsp;

This proposal allows = to split the workload of an OCSP service from a CA between several OCSP Resp= onders.
This may be desirable = for PKIs issuing a large number of certificates (e.g. several hundred of tho= usands).

Denis

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

A new version of I-D, draft-pinkas-2560bis-ocsp-locationcheck-00.txt
has been s= uccessfully submitted by Denis Pinkas and posted to the
= IETF repository.<= span style=3D"font-size: 10pt; font-family: 'Courier New'; color: black; ">
Filename:   =               draft-pinkas-2560bis-ocsp-l= ocationcheck
Revision:                 00
Title:  = ;               OCSP LocationCheck certif= icate extension Update to OCSP
              &nbs= p;   < draft-pinkas-2560bis-ocsp-locationcheck-00.txt >=
Creation date: &nb= sp;                2012-09-25= WG ID:   &= nbsp;                     =           Individual Submission
Number of pages: 6=
URL:    =         http://www.ietf.org/internet-draf= ts/draft-pinkas-2560bis-ocsp-locationcheck-00.txt
Status:     &n= bsp;    http://datatracker.ietf.org/doc/draft-pinkas-2560bis-oc= sp-locationcheck
Htmlized:        http://tools.ietf.o= rg/html/draft-pinkas-2560bis-ocsp-locationcheck-00
<= br>
Abstract:

  RFC 2560 [RFC2560] allows CAs to designate on= e or more OCSP
  Responders for being responsible to provide the revocation stat= us
 = of the certificates they issue under a given CA key.

  This document introd= uces a new feature that allows allows CAs to
  split the workload between differ= ent sets of OCSP Responders in a
  way that is analogous to the way CRLs can be = split between
  different sets of CRL issuers (using the cRLDistributionPoints
  ext= ension).

  This new feature allows a CA to designate one or more OCSP=   Responde= rs for being responsible to provide the revocation status
  for a subset of the = certificates they issue under a given CA key.

  This document defines a crit= ical extension that may only be placed
  in an OCSP certificate and the way it s= hall be processed by OCSP
  clients.

The IETF Secretariat

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

 

 

 

--B_3432843541_5657765-- From kent@bbn.com Thu Oct 11 14:45:33 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C890D11E8097 for ; Thu, 11 Oct 2012 14:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.484 X-Spam-Level: X-Spam-Status: No, score=-106.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCk+73FYTxfL for ; Thu, 11 Oct 2012 14:45:33 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id D74B511E80E4 for ; Thu, 11 Oct 2012 14:45:28 -0700 (PDT) Received: from dhcp89-089-176.bbn.com ([128.89.89.176]:52730) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TMQZM-0002aQ-3r for pkix@ietf.org; Thu, 11 Oct 2012 17:45:28 -0400 Message-ID: <50773DF8.3080706@bbn.com> Date: Thu, 11 Oct 2012 17:45:28 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121005 Thunderbird/16.0 MIME-Version: 1.0 To: pkix Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [pkix] 5280bis X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 21:45:33 -0000 The PKIX list has not demonstrated consensus for the CRL entry extension text I suggested, or any other, since Russ sent his message on this topic on 10/3, over a week ago. Consistent with Russ's direction, I have asked Peter Yee to remove the Section 4 text from 5280bis and publish version -10. I have begun preparation of the IESG report for the redacted version of the doc. Steve From stefan@aaa-sec.com Thu Oct 11 14:51:47 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 875761F041F for ; Thu, 11 Oct 2012 14:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.852 X-Spam-Level: X-Spam-Status: No, score=-100.852 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0QZgb5VeZJa for ; Thu, 11 Oct 2012 14:51:46 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 81E271F0C3E for ; Thu, 11 Oct 2012 14:51:46 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 9AE092254F5F for ; Thu, 11 Oct 2012 23:51:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Q2jgv6_QKOwn for ; Thu, 11 Oct 2012 23:51:45 +0200 (CEST) Received: from s331.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 297732254F54 for ; Thu, 11 Oct 2012 23:51:45 +0200 (CEST) Received: (qmail 23244 invoked from network); 11 Oct 2012 21:51:44 -0000 Received: from 81-232-51-61-no39.business.telia.com (HELO [192.168.0.111]) (stefan@fiddler.nu@[81.232.51.61]) (envelope-sender ) by s331.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 11 Oct 2012 21:51:44 -0000 User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Thu, 11 Oct 2012 23:51:43 +0200 From: Stefan Santesson To: Denis Pinkas , Santosh Chokhani Message-ID: Thread-Topic: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt In-Reply-To: <5076DBE4.9010808@bull.net> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3432844306_5699974" Cc: pkix Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 21:51:47 -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_3432844306_5699974 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Not that I really care about this, but=8A Just for the record, the below requirement is not good standards language. From: Denis Pinkas > This single extension MAY only be placed in an OCSP certificate. What you are trying to say (I assume) is that "This single extension MUST NOT be placed in any certificates other than OCSP responder certificates". "MAY only" is not a testable requirement. /Stefan --B_3432844306_5699974 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Not that I really care about= this, but…

Just for the record, the below re= quirement is not good standards language.

From: Denis Pinkas <denis.pinkas@bull.net>
This single extension MAY only be placed in an OCSP certi= ficate.


What yo= u are trying to say (I assume) is that "This single extension MUST NOT be pl= aced in any certificates other than OCSP responder certificates".
=
"MAY only" is not a testable requirement.

/Stefan
--B_3432844306_5699974-- From mrex@sap.com Thu Oct 11 19:27:33 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E22C121F847D for ; Thu, 11 Oct 2012 19:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.196 X-Spam-Level: X-Spam-Status: No, score=-10.196 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZ+7cm0nM6Ku for ; Thu, 11 Oct 2012 19:27:33 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2943721F847C for ; Thu, 11 Oct 2012 19:27:32 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q9C2RRG3010705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 12 Oct 2012 04:27:27 +0200 (MEST) In-Reply-To: To: Santosh Chokhani Date: Fri, 12 Oct 2012 04:27:27 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20121012022727.375C51A2C0@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: Stefan Santesson , pkix Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 02:27:34 -0000 Santosh Chokhani wrote: > > It is possible that a Responder will assert good > (e.g., for pre-signed responses) since RFC 2560 does not > address if the CA splits the responsibility among multiple > responders. In that case, MITM can get and play a response > of "good" from a legitimate Responder. What you're describing is not OCSP (rfc2560). In difference to CRLs, an OCSP "good" response is an affirmative response for an explicitly identified certificate. An OCSP responder can only produce "good" responses for certs for which it officially claims to be authoritative (whether the OCSP client sees a specific OCSP responder as being authorized is a completely distinct question). > > It is akin to IDP for partitioned CRL, but my concern is different > than yours. I am concerned that unless the assumptions made by this > extension are adhered to by the CA and the Responders, there is less > of a benefit. To me that seems like a bad analogy. When processing CRLs, the "good" (aka unrevoked) status is a bold conclusion drawn from the absence of a negative confirmation of revocation for an explicitly identified cert on one (or a set of) CRL(s) that is(are) alleged to be authoritative. A single or fixed URL also does not seem to be an issue for scaling. DNS round robin A/AAAA records can load-balance OCSP requests across different IP-Addresses, and NATs can load-balance OCSP requests to the same IP-Address onto different backend OCSP servers. When the OCSP signer cert is properly included in the OCSP response, then each of the backend OCSP servers can operate with its own signing key. -Martin From mrex@sap.com Thu Oct 11 19:36:50 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A964A21F852D for ; Thu, 11 Oct 2012 19:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.198 X-Spam-Level: X-Spam-Status: No, score=-10.198 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzsgDrt-73AM for ; Thu, 11 Oct 2012 19:36:50 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id E0ACF21F8514 for ; Thu, 11 Oct 2012 19:36:49 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q9C2ak7h028235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 12 Oct 2012 04:36:47 +0200 (MEST) In-Reply-To: <50765EC0.9040705@bull.net> To: Denis Pinkas Bull Date: Fri, 12 Oct 2012 04:36:46 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20121012023646.AE2F21A2C0@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: Stefan Santesson , pkix Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 02:36:50 -0000 Denis Pinkas Bull wrote: > > As fas as I know, there are only three major status: "good", "revoked" > or "unknown". > > Error messages are: > > -- malformedRequest, > -- internalError, > -- tryLater, > -- sigRequired, > -- unauthorized. > > There is no response like: "the responder is not authorised to provide > information about the cert". > In the example, the RP gets "unknown" (witha correct signature from the > OCSP responder), whereas it would have received either "good" or > "revoked", if there had been no attack. Why should a MitM try to obtain an unsigned(!!) "unauthorized" response form your second OCSP responder AT ALL? The MitM could simply make up that unsigned "unauthorized" response all by himself, and the OCSP requestor has no means to distinguish an MitM from a real unauthorized rfc2560 responder. -Martin From stefan@aaa-sec.com Fri Oct 12 02:53:48 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D67B021F845D for ; Fri, 12 Oct 2012 02:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.179 X-Spam-Level: X-Spam-Status: No, score=-100.179 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTg7HwRKS+MX for ; Fri, 12 Oct 2012 02:53:31 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 7947921F8448 for ; Fri, 12 Oct 2012 02:53:30 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 49427225A9C4 for ; Fri, 12 Oct 2012 11:50:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id FfQgS3IyuI0V for ; Fri, 12 Oct 2012 11:50:24 +0200 (CEST) Received: from s331.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 9426922114AF for ; Fri, 12 Oct 2012 11:50:24 +0200 (CEST) Received: (qmail 73499 invoked from network); 12 Oct 2012 09:50:24 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.2]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s331.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 12 Oct 2012 09:50:24 -0000 User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Fri, 12 Oct 2012 11:50:21 +0200 From: Stefan Santesson To: Denis Pinkas Message-ID: Thread-Topic: [pkix] draft-pinkas-rfc2560bis-03 In-Reply-To: <5076C4B9.70006@bull.net> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3432887424_464795" Cc: "pkix@ietf.org" Subject: Re: [pkix] draft-pinkas-rfc2560bis-03 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 09:53:49 -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_3432887424_464795 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Denis, In-line From: Denis Pinkas Date: Thursday, October 11, 2012 3:08 PM To: Stefan Santesson Cc: Santosh Chokhani , "pkix@ietf.org" Subject: Re: [pkix] draft-pinkas-rfc2560bis-03 > =20 > =20 > Stefan, > =20 > You will find detailed explanations of all the changes in the first page= s of > my draft. > You win a special prize, if you find a major change that is not indicate= d ! I have seen and read them. But they do not provide what's needed. I need to know for each change: * What is the problem you try to solve (I.e. Why is a change necessary)? * Motivate why your proposed solution is the best way forward. In order to make it to the update you need to convoke the WG on both points= . > =20 > Since the RFC was badly structured, for example, the description of the > parameters for the request and the response > was scattered all over the document, some descriptions were missing, the= n its > current format could not be kept. I disagree. The structure of 2560 is not ideal, but it is good enough. The value of having an update that is easy to compare with the original standard is greater than the benefit of changing the structure. > =20 > In my draft, each parameter is now described either with the request or = with > the response. the processing is described just after, > from a client and then from a server prospective. > =20 > Some processing of the elements were missing and the most important was = that > the processing of the response was wrong. This is valuable information. Here I would need to know (as stated above) 1= ) What is the problem? 2) Why solve it your way? Just saying that something is missing is not enough. You have to explain what negative impact this has. Something might be missing because it is not necessary. > =20 > I have added information for handling key rollover that influence the wa= y to > use the protocol. I believe this information is important, > but I would not object to move it in an annex I think on the contrary that describing key rollover is completely unnecessary. The mechanisms of key rollover is already explained in other documents. > =20 > Since we now both know that it will be possible to have a quick face to = face > meeting in London next week on Tuesday, > I propose that we both come with a printed version of the draft and then= we > can discuss the changes and the rational of each change > that is not always fully explained, since this will have overloaded the > document (which is already sufficiently heavy). I just need the list of motivations stated above. Then we can process them one by one here on the list. Having a face to face discussion is good however. /Stefan > =20 > Denis > =20 > =20 > =20 > =20 >> =20 >> Denis, >> =20 >>=20 >> =20 >> =20 >> Unfortunately, the number changes are too many to make a fast detailed r= eview >> providing suggestions on corrections to all issues. >> =20 >> I could provide examples, but that would not be a complete list. >> =20 >>=20 >> =20 >> =20 >> However, >> =20 >>=20 >> =20 >> =20 >> As the WG and AD has decided that we should start with as few changes as >> possible and only add what is necessary, I would like to reverse this. >> =20 >> Could you provide an argument for each change to the current WG draft th= at >> you think is necessary? >> =20 >>=20 >> =20 >> =20 >> /Stefan >> =20 >>=20 >> =20 >> =20 >>=20 >> =20 >> =20 >> From: Denis Pinkas Bull >> Date: Thursday, October 11, 2012 7:42 AM >> To: Stefan Santesson >> Cc: Santosh Chokhani , "pkix@ietf.org" >> >> Subject: Re: [pkix] draft-pinkas-rfc2560bis-03 >> =20 >> =20 >>=20 >> =20 >> =20 >>> =20 >>> =20 >>> =20 >>> Stefan, >>> =20 >>> Thank you for your comments. >>> =20 >>> However, your first two comments are not specific enough to know porti= ons >>> of text you would like to be removed. >>> Would you be able to be more specific ? >>> =20 >>> On your third comment, you say: The distinction between OCSP responder= , >>> OCSP server and OCSP service is >>> in this context confusing and adds nothing useful to an implementer on >>> either side of the protocol. >>> =20 >>> You are right to say that there is no need to make a difference betwee= n an >>> OCSP server and >>> an OCSP responder, and I can change this in the draft. >>> =20 >>> However, the distinction between an OCSP service supported by one or m= ore >>> OCSP responders should be maintained. >>> =20 >>> Denis >>> =20 >>> =20 >>> =20 >>>> =20 >>>> Denis, >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> Posting my major comments on this draft: >>>> =20 >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> - This is a substantial rewrite of the original standard. There has be= en a >>>> =20 >>>> WG decision to limit changes to RFC 2560 to what is necessary to resol= ve >>>> =20 >>>> previous ambiguity. In many places, the text provided in your draft ad= ds >>>> =20 >>>> confusion and adds ambiguity instead of removing them. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> - This is a protocol specification. That is, it defines the data eleme= nts >>>> =20 >>>> exchanged for the purpose of doing OCSP checks. It is NOT a system des= ign >>>> =20 >>>> specification. Processing rules are only relevant if they have a direc= t >>>> =20 >>>> impact on the bits on the wire. >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> - The distinction between OCSP responder, OCSP server and OCSP service= is >>>> =20 >>>> in this context confusing and adds nothing useful to an implementer on >>>> =20 >>>> either side of the protocol. >>>> =20 >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> /Stefan >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>> From: >>>> Date: Tuesday, September 25, 2012 5:01 PM >>>> To: Santosh Chokhani >>>> Cc: "pkix@ietf.org" >>>> Subject: [pkix] draft-pinkas-rfc2560bis-03 >>>> =20 >>>> =20 >>>>=20 >>>> =20 >>>> =20 >>>>> Santosh, >>>>> =20 >>>>> This text change has been included in draft -03 which is now availab= le at >>>>> : >>>>> =20 >>>>> http://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-03.txt >>>>> >>>>> =20 >>>>> Denis >>>>> =20 >>>>> =20 >>>>> =20 >>>>> De : Santosh Chokhani >>>>> A : "denis.pinkas@bull.net" >>>>> Cc : "pkix@ietf.org" >>>>> Date : 24/09/2012 18:21 >>>>> Objet : RE: draft-pinkas-rfc2560bis-02 >>>>> =20 >>>>>=20 >>>>>=20 >>>>> =20 >>>>> =20 >>>>> Denis, >>>>> =20 >>>>> OK except a nit (replace =B3accessLocation field from=B2 to =B3accessLocat= ion >>>>> field of=B2) >>>>> =20 >>>>> From: denis.pinkas@bull.net [mailto:denis.pinkas@bull.net >>>>> ] >>>>> Sent: Monday, September 24, 2012 2:17 AM >>>>> To: Santosh Chokhani >>>>> Cc: pkix@ietf.org >>>>> Subject: RE: draft-pinkas-rfc2560bis-02 >>>>> =20 >>>>> Santosh, >>>>> =20 >>>>> Your point is valid. Here is a proposed change to solve the issue. >>>>> =20 >>>>> OLD TEXT:=20 >>>>> =20 >>>>> For a given URI value identifying the location of an OCSP Responde= r, >>>>> the OCSP Responder SHALL only use one OCSP key pair value for a >>>>> given period of time. For example, it is acceptable for an OCSP >>>>> Responder to rekey, stop using the old key, and continue to use th= e >>>>> same URI while using the new key. >>>>> =20 >>>>> NEW TEXT:=20 >>>>> =20 >>>>> An OCSP Responder key rollover does not affect the values of the >>>>> URIs that are placed in the accessLocation field from the target >>>>> certificates. One or more OCSP Responder MAY respond to an OCSP >>>>> request addressed at a given URI picked from the accessLocation >>>>> field from a target certificate. Each OCSP Responder MAY use a >>>>> different signing key, as long as it got an OCSP certificate >>>>> appropriate for that signing key and for the target certificate. >>>>> =20 >>>>> Denis=20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> De : Santosh Chokhani >>>> > >>>>> A : "denis.pinkas@bull.net " >>>>> > >>>>> Cc : "pkix@ietf.org " >>>> > >>>>> Date : 21/09/2012 17:42 >>>>> Objet : RE: draft-pinkas-rfc2560bis-02 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> Denis,=20 >>>>> =20 >>>>> Thanks. I am ok with your changes. >>>>> =20 >>>>> One thing listed below is troubling me and I would like your and oth= ers=B9 >>>>> opinion on it. >>>>> =20 >>>>> While you have revised the text in Section 3.3.3 as I requested, it = is >>>>> overly constraining and has been troublesome from the beginning. The= text >>>>> I refer to is: =B3For a given URI value identifying the location of an = OCSP >>>>> Responder, the OCSP Responder SHALL only use one OCSP key pair value = for a >>>>> given period of time=B2. >>>>> =20 >>>>> While I can see how this assertion simplifies the sausage-making of = the >>>>> standard and the data structures you spell out, it is something these= need >>>>> not be applies in order for the OCSP to work. It is generally a bad >>>>> ideas in a standard to impose a constraint that is not necessary for >>>>> feasibility, security or interoperability reasons. >>>>> =20 >>>>> For example, one could have geographical load balancing and/or >>>>> geographicalredundancy for the URL and rather than porting the same k= ey, >>>>> have differentkeys for the Servers. In that case, the actual Server = that >>>>> got the request routed would sign the response. >>>>> =20 >>>>> Another example, is the URL and the server map to the same machine a= nd it >>>>> has multiple keys and can use any one of them. >>>>> =20 >>>>> I do agree that there needs to be some constraint that specifies tha= t the >>>>> server must be able to provide response to all the queries it is >>>>> authoritative for and meet the cryptographic binding requirement. >>>>> I think we need to work the 3.3.3 language so that the constraint is >>>>> specified such that it does not prohibit valid architectures. >>>>> =20 >>>>> From: denis.pinkas@bull.net >>>>> [mailto:denis.pinkas@bull.net ] >>>>> Sent: Friday, September 21, 2012 9:22 AM >>>>> To: Santosh Chokhani >>>>> Cc: pkix@ietf.org >>>>> Subject: draft-pinkas-rfc2560bis-02 >>>>> =20 >>>>> Santosh,=20 >>>>> =20 >>>>> Thank you for these new comments. I have one comment back and two ni= ts. >>>>> =20 >>>>> You suggested to add text at the end of STEP 2, since the current dr= aft >>>>> does not cover when the response is signed by the OCSP Responder. >>>>> Your rational is quite true. However, your propose change does not f= it >>>>> well. I have changed the text differently >>>>> =20 >>>>> Please take a look at draft -02 which has been issued today. >>>>> http://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-02.txt >>>>> >>>>> =20 >>>>> First nit :=20 >>>>> =20 >>>>> PROPOSED TEXT: >>>>> =20 >>>>> Note: The CA may need to continue issuing certificates to the OCSP >>>>> Responder using the old CA key until >>>>> all the certificates issued under the CA=B9 old key for which the OCSP >>>>> Responder is authoritative for expire. >>>>> =20 >>>>> NEW TEXT:=20 >>>>> =20 >>>>> Note: The CA may need to continue issuing certificates to the OCSP >>>>> Responder using the old CA key until >>>>> all the certificates issued under the CA=B9 old key for which the OCSP >>>>> Responder is authoritative have expired. >>>>> =20 >>>>> Second nit : >>>>> =20 >>>>> PROPOSED TEXT: >>>>> =20 >>>>> For example, it is acceptable for an OCSP Responder to rekey, stop u= sing >>>>> the old key, and continue to use >>>>> the old URI while using the new key=B2 >>>>> =20 >>>>> NEW TEXT:=20 >>>>> =20 >>>>> For example, it is acceptable for an OCSP Responder to rekey, stop u= sing >>>>> the old key, and continue to use >>>>> the same URI while using the new key. >>>>> =20 >>>>> Denis=20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> De : Santosh Chokhani >>>> > >>>>> A : "denis.pinkas@bull.net " >>>>> > >>>>> Cc : "pkix@ietf.org " >>>> > >>>>> Date : 18/09/2012 21:27 >>>>> Objet : RE: [pkix] draft-pinkas-rfc2560bis-00 >>>>>=20 >>>>> =20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> Denis,=20 >>>>> =20 >>>>> Thanks. Below are my updated recommended changes: >>>>> =20 >>>>> Section 3.2=20 >>>>> =20 >>>>> Add the following Note after the second dash: >>>>> =20 >>>>> Note: The change in accessLocation is necessary when the CA rekeys t= o >>>>> meet the following constraints imposed by this standard: 1) a >>>>> BasicOCSPResponse can only be signed using a single private key; 2) t= he >>>>> response must be signed using the same CA key that was used to sign t= he >>>>> certificate in question; and 3) the OCSP response needs to cover all = the >>>>> certificates queried in the OCSP request. >>>>> =20 >>>>> Section 3.3.2: >>>>> =20 >>>>> Add the following Note to the 3rd and the last paragraph: >>>>> =20 >>>>> Note: The CA may need to continue issuing certificates to the OCSP >>>>> Responder using the old CA key until all the certificates issued unde= r the >>>>> CA=B9 old key for which the OCSP Responder is authoritative for expire. >>>>> =20 >>>>> Section 3.3.3: >>>>> =20 >>>>> OLD TEXT:=20 >>>>> =20 >>>>> =B3For a given URI value identifying the location of an OCSP Responder= , the >>>>> OCSP Responder SHALL only use one OCSP key pair value.=B2 >>>>> =20 >>>>> NEW TEXT:=20 >>>>> =20 >>>>> =B3For a given URI value identifying the location of an OCSP Responder= , the >>>>> OCSP Responder SHALL only use one OCSP key pair value for a given per= iod >>>>> of time. For example, it is acceptable for an OCSP Responder to reke= y, >>>>> stop using the old key, and continue to use the old URI while using t= he >>>>> new key=B2 >>>>> =20 >>>>> Section 3.4: >>>>> =20 >>>>> OLD TEXT:=20 >>>>> =20 >>>>> Note: For each candidate certificate, when performing the path >>>>> validation algorithm, the OCSP client will verify that the >>>>> current time is within the validity period of the target >>>>> certificate. Thus, certificates which are outside their >>>>> validity period will not be included in the request or will >>>>> be rejected later on by the OCSP responder. >>>>> =20 >>>>> =20 >>>>> NEW TEXT:=20 >>>>> =20 >>>>> Note: For each candidate certificate, when performing the path >>>>> validation algorithm, the OCSP client SHOULD verify that the >>>>> current time is within the validity period of the target >>>>> certificate. Thus, certificates which are outside their >>>>> validity period SHOULD not be included in the request. >>>>> =20 >>>>> Section 4.3.1.3: >>>>> =20 >>>>> OLD TEXT:=20 >>>>> =20 >>>>> For each CA from which the locally trusted Responder has received a >>>>> delegation, the OCSP Responder SHALL maintain a list of entries. >>>>> =20 >>>>> =20 >>>>> NEW TEXT:=20 >>>>> =20 >>>>> For each CA for which the locally trusted Responder is authoritative= , the >>>>> OCSP Responder SHALL maintain a list of entries. >>>>> =20 >>>>> RATIONALE:=20 >>>>> =20 >>>>> The locally trusted responder need not have delegation from the CA >>>>> =20 >>>>> Section 4.3.2: >>>>> =20 >>>>> Add the following at the end of STEP 2: >>>>> =20 >>>>> check whether the response is signed using the OCSP Responder key: >>>>> =20 >>>>> If it is the case, then the revocation status of that >>>>> certificate as indicated in the certStatus field is >>>>> accepted and proceed to step 3. >>>>> =20 >>>>> If it is not the case, then the revocation status of that >>>>> certificate is "unknown" and proceed to step 3. >>>>> =20 >>>>> Rationale: Current draft does not cover when the response is signed = by >>>>> the OCSP Responder >>>>> =20 >>>>> Change S. Shokhani to S. Chokhani >>>>> =20 >>>>> =20 >>>>> From: denis.pinkas@bull.net >>>>> [mailto:denis.pinkas@bull.net ] >>>>> Sent: Monday, September 17, 2012 3:59 AM >>>>> To: Santosh Chokhani >>>>> Cc: pkix@ietf.org >>>>> Subject: RE: [pkix] draft-pinkas-rfc2560bis-00 >>>>> =20 >>>>> Santosh,=20 >>>>> =20 >>>>> Thank you for your very valuable comments. It took me "some time" to >>>>> process them. >>>>> It will take you "some time" to review them. :-) >>>>> =20 >>>>> Since the comments and the changes were numerous, I have issued a ne= w >>>>> draftwhich is available at: >>>>> http://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-01.txt >>>>> >>>>> =20 >>>>> For Santosh in particular, see my responses below in lines. >>>>> =20 >>>>> Denis,=20 >>>>> =20 >>>>> Thanks for this. My initial review indicates that this a very good = first >>>>> draft. =20 >>>>> Note that I did not review ASN.1 carefully (I assume it was copied f= rom >>>>> the existing RFC). >>>>> =20 >>>>> It was copied from the draft prepared by Stefan, but the ASN. 1 modu= le >>>>> needs to be modified >>>>> since the syntax of nonce has been omitted. >>>>> =20 >>>>> I have added: >>>>> =20 >>>>> Nonce ::=3D OCTET STRING >>>>> =20 >>>>> Since the syntax of the nocheck extension was missing, I have also a= dded: >>>>> =20 >>>>> NoCheck ::=3D NULL >>>>> =20 >>>>> In the introduction, I have also added: >>>>> =20 >>>>> o Section 4.3.2 now indicates that the value of the nocheck >>>>> extension SHALL be NULL. >>>>> =20 >>>>> The ASN.1 module that conforms to the 2002 version of ASN.1 which ma= y be >>>>> found in Section 4 >>>>> of RFC5912 has another problem, since the nocheck extension has been >>>>> omitted. >>>>> =20 >>>>> I have added: >>>>> =20 >>>>> -- Certificate Extension >>>>> =20 >>>>> ocsp-nocheck EXTENSION ::=3D { SYNTAX NULL >>>>> IDENTIFIED BY >>>>> id-pkix-ocsp-nocheck } >>>>> =20 >>>>> This means that we cannot keep the same OID for the two ASN. 1 modul= es >>>>> and thus we will need two new ones. >>>>> =20 >>>>> I have now included both syntaxes in draft -01. >>>>> =20 >>>>> In the introduction, I have also added: >>>>> =20 >>>>> o Annex B includes a new ASN.1 module using the 1988 syntax >>>>> since the syntax of nonce had been omitted. It also includes >>>>> a new ASN.1 module using the 2002 syntax since in the ASN.1 >>>>> module which may be found in Section 4 of RFC5912 the nocheck >>>>> extension had been omitted. >>>>> =20 >>>>> I do have the following comment though: >>>>> =20 >>>>> Section 2.2: When the CA is signing the response, should it not also= use >>>>> the same key to sign the response >>>>> as the certificate in question? The later part of the section indic= ates >>>>> this as a requirement. >>>>> In that case, why not make this explicit like the OCSP Responder. >>>>> =20 >>>>> You are correct: I have added: >>>>> =20 >>>>> In the former case, the CA MUST use the same key as the one that was >>>>> used to issue the target certificate. >>>>> =20 >>>>> Section 3.1.3, First paragraph, the rational for CA certificates to = have >>>>> digital signature bit set because >>>>> they sign OCSP certificates is incorrect. May be what you mean is t= hat a >>>>> CA that signs OCSP responses >>>>> needs to have digital signature bit set in its own certificate (i.e.= , the >>>>> certificate for which the CA is the subject). >>>>> =20 >>>>> Oups! The text was: >>>>> =20 >>>>> Therefore the digitalSignature bit in the keyUsage extension MUST >>>>> be set.=20 >>>>> =20 >>>>> Note 1: Since the CA issues certificates, the keyCertSign bit MUST a= lso >>>>> be set. >>>>> =20 >>>>> Note 2: If the CA supports CRLs, in particular to revoke the >>>>> certificate of the OCSP Responders, then the cRLSign bit, the >>>>> digitalSignature bit and the keyCertSig bit MUST be set. >>>>> =20 >>>>> I have changed it into: >>>>> =20 >>>>> Therefore the keyCertSign bit in the keyUsage extension MUST be set. >>>>> =20 >>>>> If the CA supports CRLs, in particular to revoke the certificate of >>>>> the OCSP Responders, then both the cRLSign bit and the keyCertSig >>>>> bit MUST be set. >>>>> =20 >>>>> Section 3.1.3, Note 2, Again there is no requirement for digital >>>>> signature bit to be set just because the CA signs >>>>> certificates and CRLs. >>>>> =20 >>>>> You are correct. See the correction proposed above. >>>>> =20 >>>>> Section 3.2: It not clear which accessLocation is being referred to = here >>>>> (cAissuers or OCSP). If this is OCSP, >>>>> the RFC is overly implementation specific. A CA can use the same OC= SP >>>>> location and sign the response with >>>>> appropriate key and include the appropriate CA certificate without h= aving >>>>> to change the OCSP pointer. >>>>> =20 >>>>> Section 3.2 addresses the case of CA that directly supports an OCSP >>>>> serviceand which performs a key rollover. >>>>> If the CA key changes, the OCSP location must change since it is onl= y >>>>> possible use a single key to sign the OCSP >>>>> responses. Nevertheless, I take your other point to be more specific >>>>> about the accessLocation. >>>>> The point is addressed later on in another comment from you. >>>>> =20 >>>>> General: The I-D does not address how the CA deals with the situatio= n >>>>> when status of multiple certificates issued by the CA, >>>>> but using different keys is requested. May be the restriction in 3.= 2 is >>>>> used to ensure that such situation does not occur. >>>>> If so, a short discussion would be helpful. >>>>> =20 >>>>> Your comment is related to section 4.3.1.1. (=B3Processing by a CA act= ing >>>>> as an OCSP responder=B2). >>>>> The case is already addressed with the following text: >>>>> =20 >>>>> For each target certificate, the OCSP responder SHALL verify whether >>>>> both the hash of the issuer's DN and the hash of the issuer public >>>>> key which are present in the request match respectively with the DN >>>>> and the hash of the public key of contained in an entry from the >>>>> list of entries maintained by this OCSP responder. >>>>> =20 >>>>> When there is no match, then the OCSP responder SHALL indicate the >>>>> "unknown" status and proceed with the next target certificate from >>>>> the OCSP request. >>>>> =20 >>>>> General: It not clear which accessLocation is being referred to in m= ost >>>>> places.=20 >>>>> It would be worth stating that it refers to OCSP in all cases unless >>>>> otherwise stated. >>>>> =20 >>>>> I have added a note after the first occurrence of the word in sectio= n >>>>> 3.1.1. >>>>> =20 >>>>> Note: accessLocation is mentioned in several places of this document= . >>>>> It refers in all cases to the accessLocation field that is presen= t >>>>> in an AIA extension field to designate the location of the OCSP >>>>> responder. In that case, the accessMethod field contains the >>>>> id-ad-ocsp OID. >>>>> =20 >>>>> Section 3.3.2 does not fully and explicitly cover the most common >>>>> implementation I have seen and that is short life certificates. >>>>> In that scenario, the CA needs to continue to issue the OCSP Respond= er >>>>> certificate using the old CA key until all the certificates >>>>> issued by the CA using the old key and for which the OCSP Responder = is >>>>> authoritative expire. >>>>> The text in 3.3.3 can form a model for this when CA rekeys and OCSP >>>>> Responder has the old keys. >>>>> =20 >>>>> The text in section 3.3.2 does not say what you say. Please be more >>>>> specific or since the text is short, provide an alternative >>>>> =20 >>>>> Section 3.3.3, the last sentence is not desirable and can cause prob= lems >>>>> with some implementations. >>>>> It is perfectly ok for a Responder to change its key independent of >>>>> certificate it is authoritative for. >>>>> Note that OCSP field in a issue certificate cannot be changed just >>>>> because the Responder rekyed, >>>>> be it routine or due to loss or compromise of Responder key. >>>>> =20 >>>>> The text in section 3.3.3 does not say what you say. Please be more >>>>> specific or since the text is short, provide an alternative. >>>>> =20 >>>>> Section 3.4, last paragraph, I would think that expiration checking = need >>>>> not be part of OCSP client. >>>>> Expiration checking should come under 5280 certificate validation. >>>>> =20 >>>>> The text was: >>>>> =20 >>>>> For each candidate certificate, the OCSP client SHALL verify that >>>>> the current time is within the validity period of the target >>>>> certificate. If this is not the case, the candidate certificate >>>>> SHALL be discarded. >>>>> =20 >>>>> I have changed it into; >>>>> =20 >>>>> Note: For each candidate certificate, when performing the path >>>>> validation algorithm, the OCSP client will verify that the >>>>> current time is within the validity period of the target >>>>> certificate. Thus, certificates which are outside their >>>>> validity period will not be included in the request or will >>>>> be rejected later on by the OCSP responder. >>>>> =20 >>>>> Section 4.1, We should dilute two CAs =B3never have the same issuerKey= Hash=B2 >>>>> to something more akin >>>>> to statistically infeasible. >>>>> =20 >>>>> The text was: >>>>> =20 >>>>> Two CAs will never, however, have the same public key unless the >>>>> CAs either explicitly decided to share their private key, or the >>>>> key of one of the CAs was compromised. >>>>> =20 >>>>> I have changed it into: >>>>> =20 >>>>> However, it is statistically infeasible that two CAs use the same >>>>> public key unless the CAs either explicitly decided to share >>>>> their private key, or the key of one of the CAs was compromised. >>>>> =20 >>>>> Titles of subsections under 4.3 could stand improvements. Responder= s >>>>> process request and produce response; >>>>> they do not process responses. Clients process responses. >>>>> =20 >>>>> The titles were: >>>>> =20 >>>>> 4.3. Response processing >>>>> 4.3.1. Response processing by OCSP servers >>>>> 4.3.1.1. Processing by a CA acting as an OCSP responder >>>>> 4.3.1.2. Processing by an OCSP Responder >>>>> 4.3.2. Response processing by an OCSP client >>>>> =20 >>>>> I have changed them into: >>>>> =20 >>>>> 4.3. Processing of requests and responses >>>>> 4.3.1. Request processing by OCSP servers >>>>> 4.3.1.1. Processing by a CA acting as an OCSP responder >>>>> 4.3.1.2. Processing by an OCSP Responder >>>>> 4.3.2. Response processing by an OCSP client >>>>> =20 >>>>> Section 4.3.1.1, The entry should contain method used to gain access= and >>>>> sign just like the text in 4.3.1.2 >>>>> as opposed to the private key. In other words, align the two texts = for >>>>> accessing and using private key >>>>> to sign OCSP responses. >>>>> =20 >>>>> Both sections have been aligned. >>>>> =20 >>>>> Section 4.3.1,1, page 18 =B3defined in entry=B2 could be misinterpreted = as >>>>> method define in request entry. >>>>> =20 >>>>> I don=B9t think that a change is necessary, since it uses the term =B3fo= r >>>>> each target certificate=B2 and the entry thus >>>>> refers to one of the entries from the tables of entries advertised a= t the >>>>> beginning of the section. >>>>> If you believe that a change is necessary, would you be able to make= a >>>>> proposal ?=20 >>>>> =20 >>>>> Section 4.3.1.2, Again the same comment, for the delegated OCSP >>>>> Responder, changing the URL >>>>> when key is changed is not required and breaks many implementations = and >>>>> hence is unacceptable. >>>>> =20 >>>>> Would you be able to be more specific, since I don=B9t see that the te= xt >>>>> states what you mean ? >>>>> =20 >>>>> Section 4.3.2, the check for thisUpdate is flawed since this value m= ay be >>>>> derived from CRL even for responses >>>>> that are not pre-generated and hence can be hours or days off depend= ing >>>>> on CRL issuance frequency, >>>>> It is better to replace it with producedAt field in the response whe= ther >>>>> it is related to current time or time in the past. >>>>> =20 >>>>> Good catch ! >>>>> =20 >>>>> The text has been changed into : >>>>> =20 >>>>> If the checking time is the current time, and if no nonce has been >>>>> used in the request, OCSP clients MUST check that the producedAt >>>>> field is within a time window that is "close enough" to the current >>>>> time.=20 >>>>> =20 >>>>> If the checking time is a time in the past, verifiers MUST check >>>>> that the producedAt field is in accordance with the verification >>>>> rules (e.g. close and/or after the date of a time-stamp token). >>>>> =20 >>>>> Section 4,3,2 is missing processing signature on the response and >>>>> processing response extension. >>>>> =20 >>>>> I don=B9t understand your request about =B3missing processing signature = on >>>>> the response=B2, since this point is addressed >>>>> under STEP 2. If you believe that a change is necessary, would you b= e >>>>> able to be more specific ? >>>>> =20 >>>>> Processing response extension is only covered for singleExtensions w= hen >>>>> the criticality flag is set and >>>>> the extension is not understood. So you are correct to request addit= ional >>>>> text to handle the other cases. >>>>> =20 >>>>> The following text has been added for the processing of >>>>> responseExtensions: >>>>> =20 >>>>> OCSP clients or verifiers SHALL check if the response contains a >>>>> critical responseExtensions. If such an extension is found and is >>>>> recognized, it MUST be processed. If such an extension is found and >>>>> is not recognized, the whole OCSP response MUST be considered as >>>>> invalid.=20 >>>>> =20 >>>>> The following text has been added for the processing of singleExtens= ions: >>>>> =20 >>>>> If checks are successful, then OCSP clients MUST process the >>>>> singleExtensions field, if it is present. >>>>> =20 >>>>> If the criticality flag is set and the extension is not understood, >>>>> then the status of the certificate shall be "unknown" and proceed to >>>>> step 3. Otherwise, proceed to step 2. >>>>> =20 >>>>> If the extension is understood, then the extension MUST be >>>>> processed. According to its content proceed either to step 2 or to >>>>> step 3.=20 >>>>> =20 >>>>> Section 5.5: Replay attack is also possible when not using pre-compu= ted >>>>> responses.=20 >>>>> =20 >>>>> I have added in new section with the following text: >>>>> =20 >>>>> 5.7. Other replay attacks >>>>> =20 >>>>> As already mentioned in section 5.5, replay attacks are possible >>>>> using precomputed responses. Replay attacks are also possible when >>>>> no nonce is being used in the OCSP request and the time window >>>>> mentioned in section 4.3.2 (STEP 1)is too large. >>>>> =20 >>>>> General: Removal of locally trusted Responder from the I-D is >>>>> unacceptable. >>>>> =20 >>>>> The intent was not to remove the =B3locally trusted Responder=B2. >>>>> Nevertheless, the current text has been improved >>>>> in several places. For example, in the introduction, I have added: >>>>> =20 >>>>> The term =B3locally trusted Responder=B2 is used to designate an OCSP >>>>> responder that is trusted using local rules. >>>>> =20 >>>>> In section 2.2, the text now states: >>>>> =20 >>>>> A response message MUST be signed either by a certificate's issuer, >>>>> by an authorized OCSP Responder or according to local rules. >>>>> =20 >>>>> In the first case, the CA MUST use the same key as the one that was >>>>> used to issue the target certificate. >>>>> =20 >>>>> In the second case, the CA MUST explicitly designate the OCSP >>>>> Responder by issuing an OCSP certificate to the OCSP Responder. >>>>> OCSP signing delegation SHALL be indicated by the inclusion of >>>>> id-kp-OCSPSigning in an extendedKeyUsage certificate extension >>>>> included in the OCSP response signer's certificate. This >>>>> certificate MUST be issued directly by the CA and under the same key >>>>> that was used to issue the target certificate. >>>>> =20 >>>>> For these two cases, systems or applications that rely on OCSP >>>>> responses MUST be capable of detecting and enforcing use of the >>>>> id-ad-ocspSigning value as described above. >>>>> =20 >>>>> In the third case, the OCSP client uses a locally trusted Responder. >>>>> The key used to sign OCSP responses may be directly trusted or be a >>>>> key contained in an OCSP certificate which is verified according to >>>>> local rules, instead of the rules detailed in this document. >>>>> =20 >>>>> In section I have changed the following text : >>>>> =20 >>>>> The OCSP certificate SHALL be signed by the CA issuing private key=20 >>>>> which corresponds to the issuing CA public key that is in this=20 >>>>> entry, unless some specific rules are agreed between the OCSP=20 >>>>> Responder and OCSP clients. In that later case, the OCSP=20 >>>>> certificate MAY be signed by a different entity. >>>>> =20 >>>>> into:=20 >>>>> =20 >>>>> The OCSP certificate SHALL be signed by the CA issuing private key=20 >>>>> which corresponds to the issuing CA public key that is in this=20 >>>>> entry, unless some specific rules are agreed between the OCSP=20 >>>>> Responder and OCSP clients. In that later case, which corresponds=20 >>>>> to the case of a locally trusted Responder, the OCSP certificate MAY= =20 >>>>> be signed by a different entity. >>>>> =20 >>>>> There is now also a completely new section: 4.3.1.3, called =B3Process= ing=20 >>>>> by a locally trusted Responder=B2. >>>>> =20 >>>>> When reviewing the text, I found that, in section 4.3.1.2, the list = only=20 >>>>> mentioned:=20 >>>>> =20 >>>>> - the method(s) used to obtain the revocation status of the=20 >>>>> certificates issued under that CA issuing public key, >>>>> =20 >>>>> In practice, an OCSP responder may not be responsible for all the=20 >>>>> certificates issued by a CA.=20 >>>>> So it also needs to know which subset of the certificates issued by = each=20 >>>>> CA it is responsible for.=20 >>>>> =20 >>>>> Thus I have changed the text into: >>>>> =20 >>>>> - the method(s) used to know for which subset of certificates=20 >>>>> issued by the CA it is responsible for,=20 >>>>> =20 >>>>> - the method(s) used to obtain the revocation status of that=20 >>>>> subset of certificates issued under that CA issuing public key,=20 >>>>> =20 >>>>> =20 >>>>> Denis=20 >>>>> =20 >>>>>> > A new Internet-Draft is available from the on-line Internet-Draft= s=20 >>>>>> > directories. >>>>>> >=20 >>>>>> > Title : X.509 Internet PublicKey Infrastructure Online= =20 >>>>>> > Certificate Status Protocol - OCSP >>>>>> > Author(s) : D. Pinkas >>>>>> > Filename : draft-pinkas-rfc2560bis >>>>>> > Pages : 41=20 >>>>>> > Date : Aug. 27, 2012=20 >>>>>> > =20 >>>>>> > This document specifies a protocol useful in determining the cu= rrent >>>>>> > status of a digital certificate without requiring CRLs. Additi= onal >>>>>> > mechanisms addressing PKIX operational requirements are specifi= ed in >>>>>> > separate documents. This document obsoletes RFC 2560 and RFC 62= 77. >>>>>> >=20 >>>>>> > A URL for this Internet-Draft is: >>>>>> > http://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-00.tx= t=20 >>>>>> = =20 >>>>>> >=20 >>>>>> > Internet-Drafts are also available by anonymous FTP at: >>>>>> > ftp://ftp.ietf.org/internet-drafts/=20 >>>>>> =20 >>>>>> >=20 >>>>>> > Below is the data which will enable a MIME compliant mail reader=20 >>>>>> > implementation to automatically retrieve the ASCII version of the= =20 >>>>>> Internet-Draft. >>>>>> >=20 >>>>>> > >>>>> >=20 >>>>>> >=20 >>>>>> > A few explanations about the content of=20 >>>>>> draft-ietf-pinkas-rfc2560bis-00.=20 >>>>>> >=20 >>>>>> > 25 changes are indicated at the beginning of the document.=20 >>>>>> > I will only mention a few of them:=20 >>>>>> >=20 >>>>>> > A - Explanations were missing to describe:=20 >>>>>> >=20 >>>>>> > - the building of a request by an OCSP client,=20 >>>>>> > - the processing of a request by an OCSP server,=20 >>>>>> > - the building of a response by an OCSP server, and=20 >>>>>> > - the processing of a response by an OCSP client.=20 >>>>>> >=20 >>>>>> > These explanations have been added.=20 >>>>>> >=20 >>>>>> > B - Explanations were missing to address CA key rollover and OCSP= =20 >>>>>> > key rollover. These explanations have been added.=20 >>>>>> >=20 >>>>>> > C - Backwards compatibility has been addressed in the=20 >>>> =20 >>> =20 >>> =20 >>> =20 >> =20 > =20 > =20 --B_3432887424_464795 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Denis,

<= div>In-line


Stefan,

You will find detailed explanations of all the changes in the first pages of my draft.
You win a special prize, if you find a major change that is not indicated !

<= div>I have seen and read them. But they do not provide what's needed.
<= div>
I need to know for each change:
  • What is the = problem you try to solve (I.e. Why is a change necessary)?
  • Motivate = why your proposed solution is the best way forward.
In order t= o make it to the update you need to convoke the WG on both points.

 
Since the RFC was badly structured, for example, the description of the parameters for the request and the response
was scattered all over the document, some descriptions were missing, then its current format could not be kept.
<= /div>

I disagree. The structure of 25= 60 is not ideal, but it is good enough.
The value of having an upd= ate that is easy to compare with the original standard is greater than the b= enefit of changing the structure.


In my draft, each parameter is now described either with the request or with the response. the processing is described just after,
from a client and then from a server prospective.

Some processing of the elements were missing and the most important was that the processing of the response was wrong.

This is valuable infor= mation. Here I would need to know (as stated above) 1) What is the problem? = 2) Why solve it your way?
Just saying that something is missing is= not enough. You have to explain what negative impact this has.
So= mething might be missing because it is not necessary.


I have added information for handling key rollover that influence the way to use the protocol. I believe this information is important,
but I would not object to move it in an annex

I think on the contrary that describin= g key rollover is completely unnecessary.
The mechanisms of key ro= llover is already explained in other documents.

=

Since we now both know that it will be possible to have a quick face to face meeting in London next week on Tuesday, 
I propose that we both come with a printed version of the draft and then we can discuss the changes and the rational of each change
that is not always fully explained, since this will have overloaded the document (which is already sufficiently heavy).

I just need the list = of motivations stated above.
Then we can process them one by one h= ere on the list.

Having a face to face discussion i= s good however.

/Stefan


Denis


=
Denis,

Unfortunately, the number changes are too many to make a fast detailed review providing suggestions on corrections to all issues.
I could provide examples, but that would not be a complete list.

However,

As the WG and AD has decided that we should start with as few changes as possible and only add what is necessary, I would like to reverse this.
Could you provide an argument for each change to the current WG draft that you think is necessary?

/Stefan


From: Denis Pinkas Bull <denis.pinkas@bull.net>
Date: Thursday, October 11, 2012 7:42 AM
To: Stefan Santesson <st= efan@aaa-sec.com>
Cc: Santosh Chokhani <SChokhani@cygnacom.com>, "pkix@ietf.= org" <pkix@ie= tf.org>
Subject: Re: [pkix] draft-pinkas-rfc2560bis-03

Stefan,

Thank you for your comments.

However, your first two comments are not specific enough to know portions of text you would like to be removed.
Would you be able to be more specific ?

On your third comment, you say: The distinction between OCSP responder, OCSP server and OCSP service is
in this context confusing and adds nothing useful to an implementer on either side of the protocol.

You are right to say that there is no need to make a difference between an OCSP server and
an OCSP responder, and I can change this in the draft.
=
However, the distinction between an OCSP service supported by one or more OCSP responders should be maintained.

Denis

Denis,

Posting my major comments on this draft:

- This is a substantial rewrite of the original standard. There has been a
WG decision to limit changes to RFC 2560 to what is necessary to resolve
previous ambiguity. In many places, the text provided in your draft adds
confusion and adds ambiguity instead of removing them.
=

- This is a protocol specification. That is, it defines the data elements
exchanged for the purpose of doing OCSP checks. It is NOT a system design
specification. Processing rules are only relevant if they have a direct
impact on the bits on the wire.

- The distinction between OCSP responder, OCSP server and OCSP service is
in this context confusing and adds nothing useful to an implementer on
either side of the protocol.

/Stefan

From: <denis.pinkas@bull.net>
Date: Tuesday, September 25, 2012 5:01 PM
To: Santosh Chokhani <SChokhani@cygnacom.com>
Cc: "pkix@ietf.org" <pkix@ietf.org>
Subject: [pkix] draft-pinkas-rfc2560bis-03

Sa= ntosh,

This text change has been included in draft -03 which is now available at :

http://www.i= etf.org/internet-drafts/draft-pinkas-rfc2560bis-03.txt

Denis



De :        Santosh Chokhani <SChokhani@cygnacom.com>
A :        "denis.pinkas@bull.net" <denis.pinkas@bull.net>
Cc&nbs= p;:        "pkix@ie= tf.org" <pkix@ietf.org>
Date :        24/09/2012 18:21
Objet :        RE: draft-pinkas-rfc2560bis-02



Denis,
 
OK except a nit (replace “accessLocation field fro= m” to “accessLocation field of”)
 
From: denis.pinkas@bull.net [mailto:denis.pinkas@bull.net]
Sent: Monday, September 24, 2012 2:17 AM
= To: Santosh Chokhani
Cc: pkix@ietf.org
Subject: RE: draft-pinkas-rfc2560bis-02<= br>  
= Santosh,

Your point is valid. Here is a proposed change to solve the issue.

OLD TEXT:

  For a given URI value identifying the location= of an OCSP Responder,
  the OCSP Responder SHALL only use one OCSP key= pair value for a
  given period of time.  For example, it is= acceptable for an OCSP
  Responder to rekey, stop using the old key, an= d continue to use the
  same URI while using the new key.

NEW TEXT:

  An OCSP Responder key rollover does not affect= the values of the
  URIs that are placed in the accessLocation fie= ld from the target
  certificates.  One or more OCSP Responder= MAY respond to an OCSP
  request addressed at a given URI picked from t= he accessLocation
  field from a target certificate.  Each OC= SP Responder MAY use a
  different signing key, as long as it got an OC= SP certificate
  appropriate for that signing key and for the target certificate.

Denis



= De :        Santosh Chokhani <SC= hokhani@cygnacom.com>
A :        "denis.pinkas@bull.net= " <denis.pinkas@bull.net>
Cc :        "= pkix@ietf.org" <pkix@ietf.org= >
Date :        21/09/2012 17:42
= Objet :        RE: draft-pinkas-rfc2560bis-02





= Denis,
=  
Thanks.  I am ok with your changes.
 
One thing listed below is troubling me and I would like your and others’ opinion on it.
 
While you have revised the text in Section 3.3.3 as I requested, it is overly constraining and has been troublesome from the beginning.  The text I= refer to is: “For a given URI value identifying= the location of an OCSP Responder, the OCSP Responder SHALL only use one OCSP key pair value for a given period of time”.
 
While I can see how this assertion simplifies the sausage-making of the standard and the data structures you spell out, it is something these need not be applies in order for the OCSP to work.   It is generally a bad ideas in a standard to impose a constraint that is not necessary for feasibility, security or interoperability reasons.
 
For example, one could have geographical load balancing and/or geographicalredundancy for the URL and rather than porting the same key, have differentkeys for the Servers.  In that case, th= e actual Server that got the request routed would sign the response.
 
Another example, is the URL and the server map to the same machine and it has multiple keys and can use any one of them.
 
I do agree that there needs to be some constraint that specifies that the server must be able to provide response to all the queries it is authoritative for and meet the cryptographic binding requirement.
I think we need to work the 3.3.3 language so that the constraint is specified such that it does not prohibit valid architectures.
 
From: den= is.pinkas@bull.net [mailto:denis.pinkas@bull.net]
Sent: Friday, September 21, 2012 9:22 AM
= To: Santosh Chokhani
Cc: pkix@ietf.org=
Subject: draft-pinkas-rfc2560bis-02
 
Santosh,

Thank you for these new comments. I have one comment back and two nits.

You suggested to add text at the end of STEP 2, since the current draft does not cover when the response is signed by the OCSP Responder.
Your rational is quite true. However, your propose change does not fit well. I have changed the text differently

Please take a look at draft -02 which has been issued today.
http://www.ietf.org/internet-drafts/draft-pi= nkas-rfc2560bis-02.txt

First nit :

PROPOSED TEXT:

Note: The CA may need to continue issuing certificates to the OCSP Responder using the old CA key until
all the certificates issued under the CA’ old k= ey for which the OCSP Responder is authoritative for expire.

NEW TEXT:

Note: The CA may need to continue issuing certificates to the OCSP Responder using the old CA key until
all the certificates issued under the CA’ old k= ey for which the OCSP Responder is authoritative = have expired.

Second nit :
=
PROPOSED TEXT:

For example, it is acceptable for an OCSP Responder to rekey, stop using the old key, and continue to use
the old URI while using the new key”

For example, it is acceptable for an OCSP Responder to rekey, stop using the old key, and continue to use
the same URI while using the new key.

Denis


=
De :        Santosh Chokhani <SC= hokhani@cygnacom.com>
A :        "denis.pinkas@bull.net= " <denis.pinkas@bull.net>
Cc :        "= pkix@ietf.org" <pkix@ietf.org= >
Date :        18/09/2012 21:27
= Objet :        RE: [pkix] draft-pinkas-rfc2560bis-00

 




=
Denis,

= Thanks.  Below are my updated recommended change= s:

Section 3.2

Add the following Note after the second dash:
Note: The change in accessLocation is necessary when the CA rekeys to meet the following constraints imposed by this standard: 1) a BasicOCSPResponse can only be signed using a single private key; 2) the response must be signed using the same CA key that was used to sign the certificate in question; and 3) the OCSP response needs to cover all the certificates queried in the OCSP request.

Section 3.3.2:

Add the following Note to the 3rd and the last paragraph:
Note: The CA may need to continue issuing certificates to the OCSP Responder using the old CA key until all the certificates issued under the CA’ old key for which the OCSP Responder is authoritative for expire.

Section 3.3.3:

OLD TEXT:

“For a= given URI value identifying the location of an OCSP Responder, the OCSP Responder SHALL only use one OCSP key pair value.”

NEW TEXT:

“For a= given URI value identifying the location of an OCSP Responder, the OCSP Responder SHALL only use one OCSP key pair value for a given period of time.  For example, it is acceptable for an OCSP Responder to rekey, stop using the old key, and continue to use the old URI while using the new key̶= 1;

Section 3.4:

OLD TEXT:

Note:  For each candidate certificate, when performing the path
     validation algorithm, the OCSP cl= ient will verify that the
     current time is within the validi= ty period of the target
     certificate.  Thus, certific= ates which are outside their
     validity period will not be inclu= ded in the request or will
     be rejected later on by the OCSP = responder.


NEW TEXT:

Note:  For each candidate certificate, when performing the path
     validation algorithm, the OCSP cl= ient SHOULD verify that the
     current time is within the validi= ty period of the target
     certificate.  Thus, certific= ates which are outside their
     validity period SHOULD not be included in the request.

Section 4.3.1.3:

OLD TEXT:

 For each CA from which the locally trusted Responder has received a
 delegation, the OCSP Responder SHALL maintain a= list of entries.


NEW TEXT:

For each CA for which the locally t= rusted Responder is authoritative, the OCS= P Responder SHALL maintain a list of entries.

RATIONALE:

The locally trusted responder need not have delegation from the CA

Section 4.3.2:

Add the following at the end of STEP 2:
check whether the response is signed using the OCSP Responder key:
            If it is the= case, then the revocation status of that
           certificate = as indicated in the certStatus field is
           accepted and= proceed to step 3.
           If it is not= the case, then the revocation status of that
           certificate = is "unknown" and proceed to step 3.

Rationale: Current draft does not cover when the response is signed by the OCSP Responder

Change S. Shokhani to S. Chokhani


From: den= is.pinkas@bull.net [mailto:denis.pinkas@bull.net]
Sent: Monday, September 17, 2012 3:59 AM
= To: Santosh Chokhani
Cc: pkix@ietf.org=
Subject: RE: [pkix] draft-pinkas-rfc2560bis-00

Santosh,

Thank you for your very valuable comments. It took me "some time" to process them.
It will take you "some time" to review them. :-)

Since the comments and the changes were numerous, I have issued a new draftwhich is available at:
http://www.ietf.org/internet-drafts/draft-pinkas-r= fc2560bis-01.txt

For Santosh in particular, see my responses below in lines.

Denis,
=
Thanks for this.  My initial review indicates th= at this a very good first draft.  
Note that I did not review ASN.1 carefully (I assume it was copied from the existing RFC).
=
It was copied from the draft prepared by Stefan, but the ASN. 1 module needs to be modified
since the syntax of nonce has been omitted.

I have added:
=
Nonce ::=3D OCTET STRING

Since the syntax of the nocheck extension was missing, I have also added:

NoCheck ::=3D NULL

In the introduction, I have also added:

   o  Section 4.3.2 now indicates that= the value of the nocheck
      extension SHALL be NULL. =

The ASN.1 module that conforms to the 2002 version of ASN.1 which may be found in Section 4
of RFC5912 has another problem, since the nocheck extension has been omitted.

I have added:
=
--  Certificate Extension

ocsp-nocheck EXTENSION ::=3D { SYNTAX NULL
              &nbs= p;                     &nb= sp; IDENTIFIED BY
              &nbs= p;                     &nb= sp; id-pkix-ocsp-nocheck }

This means that we cannot keep the same OID for the two ASN. 1 modules and thus we will need two new ones.

I have now included both syntaxes in draft -01.

In the introduction, I have also added:

   o  Annex B includes a new ASN.1 mod= ule using the 1988 syntax
      since the syntax of nonce had be= en omitted.  It also includes
      a new ASN.1 module using the 200= 2 syntax since in the ASN.1
      module which may be found in Sec= tion 4 of RFC5912 the nocheck
      extension had been omitted.

I do have the following comment though:

Section 2.2: When the CA is signing the response, should it not also use the same key to sign the response
as the certificate in question?  The later part = of the section indicates this as a requirement.   In that case, why not make this explicit like the OCSP Responder.
You are correct: I have added:

In the former case, the CA MUST use the same key as the one that was
used to issue the target certificate.

Section 3.1.3, First paragraph, the rational for CA certificates to have digital signature bit set because
they sign OCSP certificates is incorrect.  May b= e what you mean is that a CA that signs OCSP responses
needs to have digital signature bit set in its own certificate (i.e., the certificate for which the CA is the subject).

Oups! The text was:

Therefore the digitalSignature bit in the keyUsage extension MUST
be set.

Note 1: Since the CA issues certificates, the keyCertSign bit MUST also
     be set.

Note 2: If the CA supports CRLs, in particular to revoke the
     certificate of the OCSP Responder= s, then the cRLSign bit, the
     digitalSignature bit and the keyC= ertSig bit MUST be set.

I have changed it into:

Therefore the keyCertSign bit in the keyUsage extension MUST be set.

If the CA supports CRLs, in particular to revoke the certificate of
the OCSP Responders, then both the cRLSign bit and the keyCertSig
bit MUST be set.

Section 3.1.3, Note 2, Again there is no requirement for digital signature bit to be set just because the CA signs
certificates and CRLs.

You are correct. See the correction proposed above.

Section 3.2: It not clear which accessLocation is being referred to here (cAissuers or OCSP).  If this is OCSP,
the RFC is overly implementation specific.  A CA= can use the same OCSP location and sign the response with
appropriate key and include the appropriate CA certificate without having to change the OCSP pointer.

Section 3.2 addresses the case of CA that directly supports an OCSP serviceand which performs a key rollover.  
If the CA key changes, the OCSP location must change since it is only possible use a single key to sign the OCSP
responses. Nevertheless, I take your other point to be more specific about the accessLocation.
The point is addressed later on in another comment from you.

General: The I-D does not address how the CA deals with the situation when status of multiple certificates issued by the CA,
but using different keys is requested.  May be t= he restriction in 3.2 is used to ensure that such situation does not occur.  
If so, a short discussion would be helpful.

Your comment is related to section 4.3.1.1. (“Processing by a CA acting as an OCSP responder”).
The case is already addressed with the following text:

For each target certificate, the OCSP responder SHALL verify whether
both the hash of the issuer's DN and the hash of the issuer public
key which are present in the request match respectively with the DN
and the hash of the public key of contained in an entry from the
list of entries maintained by this OCSP responder.

When there is no match, then the OCSP responder SHALL indicate the
"unknown" status and proceed with the next target certificate from
the OCSP request.

General: It not clear which accessLocation is being referred to in most places.
It would be worth stating that it refers to OCSP in all cases unless otherwise stated.

I have added a note after the first occurrence of the word in section 3.1.1.

Note: accessLocation is mentioned in several places of this document.
   It refers in all cases to the accessLoca= tion field that is present
   in an AIA extension field to designate t= he location of the OCSP
   responder.  In that case, the acces= sMethod field contains the
   id-ad-ocsp OID.

Section 3.3.2 does not fully and explicitly cover the most common implementation I have seen and that is short life certificates.  
In that scenario, the CA needs to continue to issue the OCSP Responder certificate using the old CA key until all the certificates
issued by the CA using the old key and for which the OCSP Responder is authoritative expire.   The text in 3.3.3 can form a model for this when CA rekeys and OCSP Responder has the old keys.=
The text in section 3.3.2 does not say what you say. Please be more specific or since the text is short, provide an alternative

Section 3.3.3, the last sentence is not desirable and can cause problems with some implementations.
It is perfectly ok for a Responder to change its key independent of certificate it is authoritative for.  
Note that OCSP field in a issue certificate cannot be changed just because the Responder rekyed,
be it routine or due to loss or compromise of Responder key.
=
The text in section 3.3.3 does not say what you say. Please be more specific or since the text is short, provide an alternative.

Section 3.4, last paragraph, I would think that expiration checking need not be part of OCSP client.  
Expiration checking should come under 5280 certificate validation.

The text was:
=
For each candidate certificate, the OCSP client SHALL verify that
the current time is within the validity period of the target
certificate.  If this is not the case, the candidate certificate
SHALL be discarded.

I have changed it into;

Note:  For each candidate certificate, when performing the path
    validation algorithm, the OCSP client w= ill verify that the
    current time is within the validity per= iod of the target
    certificate.  Thus, certificates w= hich are outside their
    validity period will not be included in= the request or will
    be rejected later on by the OCSP respon= der.

Section 4.1, We should dilute two CAs “never ha= ve the same issuerKeyHash” to something more akin =
to statistically infeasible.

The text was:
=
   Two CAs will never, however, have the sa= me public key unless the
   CAs either explicitly decided to share t= heir private key, or the
   key of one of the CAs was compromised.

I have changed it into:

   However, it is statistically infeasible = that two CAs use the same
   public key unless the CAs either explici= tly decided to share
   their private key, or the key of one of = the CAs was compromised.

Titles of subsections under 4.3 could stand improvements.  Responders process request and produce response;
they do not process responses.  Clients process responses.

The titles were:

  4.3. Response processing
    4.3.1. Response processing by OCSP serv= ers
      4.3.1.1. Processing by a CA acti= ng as an OCSP responder
      4.3.1.2. Processing by an OCSP R= esponder
    4.3.2. Response processing by an OCSP c= lient

I have changed them into:

  4.3. Processing of requests and responses
    4.3.1. Request processing by OCSP serve= rs
      4.3.1.1. Processing by a CA acti= ng as an OCSP responder
      4.3.1.2. Processing by an OCSP R= esponder
    4.3.2. Response processing by an OCSP c= lient

Section 4.3.1.1, The entry should contain method used to gain access and sign just like the text in 4.3.1.2
as opposed to the private key.  In other words, align the two texts for accessing and using private key
to sign OCSP responses.

Both sections have been aligned.

Section 4.3.1,1, page 18 “defined in entry̶= 1; could be misinterpreted as method define in request entry.

I don’t think that a change is necessary, since= it uses the term “for each target certificate̶= 1; and the entry thus
refers to one of the entries from the tables of entries advertised at the beginning of the section.
If you believe that a change is necessary, would you be able to make a proposal ? =

Section 4.3.1.2, Again the same comment, for the delegated OCSP Responder, changing the URL
when key is changed is not required and breaks many implementations and hence is unacceptable. <= br>
Would you be able to be more specific, since I don’t see that the text states what you mean ?<= /font>

Section 4.3.2, the check for thisUpdate is flawed since this value may be derived from CRL even for responses
that are not pre-generated and hence can be hours or days off depending on CRL issuance frequency,
= It is better to replace it with producedAt field in the response whether it is related to current time or time in the past.

Good catch !

The text has been changed into :

If the checking time is the current time, and if no nonce has been
used in the request, OCSP clients MUST check that the producedAt
field is within a time window that is "close enough" to the current
time.

If the checking time is a time in the past, verifiers MUST check
that the producedAt field is in accordance with the verification
rules (e.g. close and/or after the date of a time-stamp token).

Section 4,3,2 is missing processing signature on the response and processing response extension. <= br>
I don’t understand your request about “mi= ssing processing signature on the response”, since th= is point is addressed
under STEP 2. If you believe that a change is necessary, would you be able to be more specific ?

Processing response extension is only covered for singleExtensions when the criticality flag is set and
the extension is not understood. So you are correct to request additional text to handle the other cases.

The following text has been added for the processing of responseExtensions:

OCSP clients or verifiers SHALL check if the response contains a
critical responseExtensions. If such an extension is found and is
recognized, it MUST be processed.  If such an extension is found and
is not recognized, the whole OCSP response MUST be considered as
invalid.

The following text has been added for the processing of singleExtensions:

If checks are successful, then OCSP clients MUST process the
singleExtensions field, if it is present.

If the criticality flag is set and the extension is not understood,
then the status of the certificate shall be "unknown" and proceed to
step 3.  Otherwise, proceed to step 2.

If the extension is understood, then the extension MUST be
processed.  According to its content proceed either to step 2 or to
step 3.

Section 5.5: Replay attack is also possible when not using pre-computed responses.

I have added in new section with the following text:

5.7. Other replay attacks

As already mentioned in section 5.5, replay attacks are possible
using precomputed responses.  Replay attacks are= also possible when
no nonce is being used in the OCSP request and the time window
mentioned in section 4.3.2 (STEP 1)is too large.

General: Removal of locally trusted Responder from the I-D is unacceptable.

The intent was not to remove the “locally trust= ed Responder”. Nevertheless, the current text has been improved
in several places. For example, in the introduction, I have added:

   The term “locally trusted Responde= r” is used to designate an OCSP
   responder that is trusted using local ru= les.

In section 2.2, the text now states:

A response message MUST be signed either by a certificate's issuer,
by an authorized OCSP Responder or according to local rules.

In the first case, the CA MUST use the same key as the one that was
used to issue the target certificate.

In the second case, the CA MUST explicitly designate the OCSP
Responder by issuing an OCSP certificate to the OCSP Responder.
OCSP signing delegation SHALL be indicated by the inclusion of
id-kp-OCSPSigning in an extendedKeyUsage certificate extension
included in the OCSP response signer's certificate.  This
certificate MUST be issued directly by the CA and under the same key
that was used to issue the target certificate.=

For these two cases, systems or applications that rely on OCSP
responses MUST be capable of detecting and enforcing use of the
id-ad-ocspSigning value as described above.

In the third case, the OCSP client uses a locally trusted Responder.
The key used to sign OCSP responses may be directly trusted or be a
key contained in an OCSP certificate which is verified according to
local rules, instead of the rules detailed in this document.

In section I have changed the following text :=

The OCSP certificate SHALL be signed by the CA issuing private key
which corresponds to the issuing CA public key that is in this
entry, unless some specific rules are agreed between the OCSP
Responder and OCSP clients.  In that later case,= the OCSP
certificate MAY be signed by a different entity.

into:

The OCSP certificate SHALL be signed by the CA issuing private key
which corresponds to the issuing CA public key that is in this
entry, unless some specific rules are agreed between the OCSP
Responder and OCSP clients.  In that later case,= which corresponds
to the case of a locally trusted Responder, the OCSP certificate MAY
be signed by a different entity.

There is now also a completely new section: 4.3.1.3, called “Processing by a locally truste= d Responder”.<= br>
When reviewing the text, I found that, in section 4.3.1.2, the list only mentioned:

  - the method(s) used to obtain the revocation status of the
    certificates issued under that CA issui= ng public key,

In practice, an OCSP responder may not be responsible for all the certificates issued by a CA.
So it also needs to know which subset of the certificates issued by each CA it is responsible for.

Thus I have changed the text into:

  - the method(s) used to know for which subset = of certificates
    issued by the CA it is responsible for,=

  - the method(s) used to obtain the revocation status of that
    subset of certificates issued under tha= t CA issuing public key,


Denis

> A new Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>    Title         := X.509 Internet PublicKey Infrastructure Online
>              =      Certificate Status Protocol - OCSP
>    Author(s)     : D. Pinkas=
>    Filename      : draf= t-pinkas-rfc2560bis
>    Pages         := 41
>    Date         &n= bsp;: Aug. 27, 2012
>    
>   This document specifies a protocol useful= in determining the current
>   status of a digital certificate without requiring CRLs.  Additional
>   mechanisms addressing PKIX operational requirements are specified in
>   separate documents. This document obsolet= es RFC 2560 and RFC 6277.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-p= inkas-rfc2560bis-00.txt
= >
> Internet-Drafts are also available by anonymous FTP at:
> <= u>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.
>
> <ftp://ftp.ietf.org/internet-drafts/draft-pinkas= -rfc2560bis>
>
> A few explanations about the content of draft-ietf-pinkas-rfc2560bis-00.
>
> 25 changes are indicated at the beginning of the document.
> I will only mention a few of them:
>
> A - Explanations were missing to describe:
>
>      - the building of a request = by an OCSP client,
>      - the processing of a reques= t by an OCSP server,
>      - the building of a response=  by an OCSP server, and
>      - the processing of a respon= se by an OCSP client.
>
> These explanations have been added.
>
> B - Explanations were missing to address CA key rollover and OCSP
>     key rollover. These explanations h= ave been added.
>
> C - Backwards compatibility has been addressed in the

--B_3432887424_464795-- From denis.pinkas@bull.net Fri Oct 12 07:18:41 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 845E621F8496 for ; Fri, 12 Oct 2012 07:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.753 X-Spam-Level: X-Spam-Status: No, score=-4.753 tagged_above=-999 required=5 tests=[AWL=1.495, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PA5XhXa2RU6B for ; Fri, 12 Oct 2012 07:18:40 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 6948121F8475 for ; Fri, 12 Oct 2012 07:18:40 -0700 (PDT) Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id F033C1C3F4; Fri, 12 Oct 2012 16:18:38 +0200 (CEST) Received: from [127.0.0.1] ([129.184.39.15]) by MSGC-007.bull.fr (Lotus Domino Release 8.5.3FP1) with ESMTP id 2012101216183830-918 ; Fri, 12 Oct 2012 16:18:38 +0200 Message-ID: <507826BB.8060304@bull.net> Date: Fri, 12 Oct 2012 16:18:35 +0200 From: Denis Pinkas User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Peter Sylvester References: <5076FF4A.1090303@bull.net> <507709C3.2090200@edelweb.fr> In-Reply-To: <507709C3.2090200@edelweb.fr> X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 12/10/2012 16:18:38, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 12/10/2012 16:18:38, Serialize complete at 12/10/2012 16:18:38 X-TNEFEvaluated: 1 Content-Type: multipart/alternative; boundary="------------080601000508000401030805" Cc: pkix@ietf.org Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 14:18:41 -0000 This is a multi-part message in MIME format. --------------080601000508000401030805 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed Peter, This may be costly since some PKI vendors are charging per CA, and you also need to pay for the writing of a CP, the writing of a CPS, the writing of conditions of use, the change of the CA key when it will need to be changed, etc ... This extension is optional and thus CAs shall only use it after making sure that the RPs which trust them are able to support it. Denis > On 10/11/2012 07:18 PM, Denis Pinkas wrote: >> Carl, > >> >>> You could achieve your example below by issuing the critical servers >>> off of a different CA than usual servers and avoid updating client >>> software. >> >> This may or may not be possible or desirable. >> > To me this doesn't seem very helpful. > Could you provide a concrete use case where > this is not possible or where this is not desirable? > > > Erwann gave a concrete response. > > Peter > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --------------080601000508000401030805 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=ISO-8859-1
 Peter,

This may be costly since some PKI vendors are charging per CA, and
you also need to pay for the writing of a CP, the writing of a CPS, the writing of conditions of use,
the change of the CA key when it will need to be changed, etc ...

This extension is optional and thus CAs shall only use it after making sure that the RPs which trust
them are able to support it.

Denis


On 10/11/2012 07:18 PM, Denis Pinkas wrote:
Carl,


You could achieve your example below by issuing the critical servers off of a different CA than usual servers and avoid updating client software. 

This may or may not be possible or desirable.

To me this doesn't seem very helpful.
Could you provide a concrete use case where
this is not possible or where this is not desirable?


Erwann gave a concrete response.

Peter



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


--------------080601000508000401030805-- From denis.pinkas@bull.net Fri Oct 12 07:19:02 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44BF121F8617 for ; Fri, 12 Oct 2012 07:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[AWL=1.452, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqCnTHfiYV4l for ; Fri, 12 Oct 2012 07:19:01 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 9A38821F8582 for ; Fri, 12 Oct 2012 07:19:01 -0700 (PDT) Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id 131441C320; Fri, 12 Oct 2012 16:19:01 +0200 (CEST) Received: from [127.0.0.1] ([129.184.39.15]) by MSGC-007.bull.fr (Lotus Domino Release 8.5.3FP1) with ESMTP id 2012101216190042-919 ; Fri, 12 Oct 2012 16:19:00 +0200 Message-ID: <507826D4.2070901@bull.net> Date: Fri, 12 Oct 2012 16:19:00 +0200 From: Denis Pinkas User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: mrex@sap.com References: <20121012023646.AE2F21A2C0@ld9781.wdf.sap.corp> In-Reply-To: <20121012023646.AE2F21A2C0@ld9781.wdf.sap.corp> X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 12/10/2012 16:19:00, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 12/10/2012 16:19:01, Serialize complete at 12/10/2012 16:19:01 X-TNEFEvaluated: 1 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed Cc: pkix Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 14:19:02 -0000 Martin, The point is that, when a RP gets "unknown" (with a correct signature from the OCSP responder), it sure that it is cannot be a response from MitM. Denis ================================================================= As fas as I know, there are only three major status: "good", "revoked" or "unknown". Error messages are: -- malformedRequest, -- internalError, -- tryLater, -- sigRequired, -- unauthorized. There is no response like: "the responder is not authorised to provide information about the cert". In the example, the RP gets "unknown" (witha correct signature from the OCSP responder), whereas it would have received either "good" or "revoked", if there had been no attack. ========================================================================== Why should a MitM try to obtain an unsigned(!!) "unauthorized" response form your second OCSP responder AT ALL? The MitM could simply make up that unsigned "unauthorized" response all by himself, and the OCSP requestor has no means to distinguish an MitM from a real unauthorized rfc2560 responder. -Martin From denis.pinkas@bull.net Fri Oct 12 07:21:25 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC4A621F8634 for ; Fri, 12 Oct 2012 07:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.395 X-Spam-Level: X-Spam-Status: No, score=-4.395 tagged_above=-999 required=5 tests=[AWL=0.969, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BK7Q3m6nZ-9f for ; Fri, 12 Oct 2012 07:21:14 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 9F52821F845C for ; Fri, 12 Oct 2012 07:21:13 -0700 (PDT) Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id 1424E1C329; Fri, 12 Oct 2012 16:21:13 +0200 (CEST) Received: from [127.0.0.1] ([129.184.39.15]) by MSGC-007.bull.fr (Lotus Domino Release 8.5.3FP1) with ESMTP id 2012101216211055-922 ; Fri, 12 Oct 2012 16:21:10 +0200 Message-ID: <50782754.9030601@bull.net> Date: Fri, 12 Oct 2012 16:21:08 +0200 From: Denis Pinkas User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 12/10/2012 16:21:12, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 12/10/2012 16:21:13, Serialize complete at 12/10/2012 16:21:13 Content-Type: multipart/alternative; boundary="------------030608090006080504060707" Cc: "pkix@ietf.org" Subject: Re: [pkix] draft-pinkas-rfc2560bis-03 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 14:21:26 -0000 This is a multi-part message in MIME format. --------------030608090006080504060707 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed Stefan, Let us wait until Tuesday: it is less than one and a half working days. Denis > Denis, > > In-line > > From: Denis Pinkas > > Date: Thursday, October 11, 2012 3:08 PM > To: Stefan Santesson > > Cc: Santosh Chokhani >, "pkix@ietf.org > " > > Subject: Re: [pkix] draft-pinkas-rfc2560bis-03 > > Stefan, > > You will find detailed explanations of all the changes in the > first pages of my draft. > You win a special prize, if you find a major change that is not > indicated ! > > > I have seen and read them. But they do not provide what's needed. > > I need to know for each change: > > * What is the problem you try to solve (I.e. Why is a change necessary)? > * Motivate why your proposed solution is the best way forward. > > In order to make it to the update you need to convoke the WG on both > points. > > > Since the RFC was badly structured, for example, the description > of the parameters for the request and the response > was scattered all over the document, some descriptions were > missing, then its current format could not be kept. > > > I disagree. The structure of 2560 is not ideal, but it is good enough. > The value of having an update that is easy to compare with the > original standard is greater than the benefit of changing the structure. > > > In my draft, each parameter is now described either with the > request or with the response. the processing is described just after, > from a client and then from a server prospective. > > Some processing of the elements were missing and the most > important was that the processing of the response was wrong. > > > This is valuable information. Here I would need to know (as stated > above) 1) What is the problem? 2) Why solve it your way? > Just saying that something is missing is not enough. You have to > explain what negative impact this has. > Something might be missing because it is not necessary. > > > I have added information for handling key rollover that influence > the way to use the protocol. I believe this information is important, > but I would not object to move it in an annex > > > I think on the contrary that describing key rollover is completely > unnecessary. > The mechanisms of key rollover is already explained in other documents. > > > Since we now both know that it will be possible to have a quick > face to face meeting in London next week on Tuesday, > I propose that we both come with a printed version of the draft > and then we can discuss the changes and the rational of each change > that is not always fully explained, since this will have > overloaded the document (which is already sufficiently heavy). > > > I just need the list of motivations stated above. > Then we can process them one by one here on the list. > > Having a face to face discussion is good however. > > /Stefan > > > > Denis > > >> Denis, >> >> Unfortunately, the number changes are too many to make a fast >> detailed review providing suggestions on corrections to all issues. >> I could provide examples, but that would not be a complete list. >> >> However, >> >> As the WG and AD has decided that we should start with as few >> changes as possible and only add what is necessary, I would like >> to reverse this. >> Could you provide an argument for each change to the current WG >> draft that you think is necessary? >> >> /Stefan >> >> >> From: Denis Pinkas Bull > > >> Date: Thursday, October 11, 2012 7:42 AM >> To: Stefan Santesson > >> Cc: Santosh Chokhani > >, "pkix@ietf.org >> " > >> Subject: Re: [pkix] draft-pinkas-rfc2560bis-03 >> >> Stefan, >> >> Thank you for your comments. >> >> However, your first two comments are not specific enough to >> know portions of text you would like to be removed. >> Would you be able to be more specific ? >> >> On your third comment, you say: The distinction between OCSP >> responder, OCSP server and OCSP service is >> in this context confusing and adds nothing useful to an >> implementer on either side of the protocol. >> >> You are right to say that there is no need to make a >> difference between an OCSP server and >> an OCSP responder, and I can change this in the draft. >> >> However, the distinction between an OCSP service supported by >> one or more OCSP responders should be maintained. >> >> Denis >> >>> Denis, >>> >>> Posting my major comments on this draft: >>> >>> - This is a substantial rewrite of the original standard. >>> There has been a >>> WG decision to limit changes to RFC 2560 to what is >>> necessary to resolve >>> previous ambiguity. In many places, the text provided in >>> your draft adds >>> confusion and adds ambiguity instead of removing them. >>> >>> - This is a protocol specification. That is, it defines the >>> data elements >>> exchanged for the purpose of doing OCSP checks. It is NOT a >>> system design >>> specification. Processing rules are only relevant if they >>> have a direct >>> impact on the bits on the wire. >>> >>> - The distinction between OCSP responder, OCSP server and >>> OCSP service is >>> in this context confusing and adds nothing useful to an >>> implementer on >>> either side of the protocol. >>> >>> /Stefan >>> >>> From: > >>> Date: Tuesday, September 25, 2012 5:01 PM >>> To: Santosh Chokhani >> > >>> Cc: "pkix@ietf.org " >> > >>> Subject: [pkix] draft-pinkas-rfc2560bis-03 >>> >>> Santosh, >>> >>> This text change has been included in draft -03 which is >>> now available at : >>> >>> http://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-03.txt >>> >>> Denis >>> >>> >>> >>> De : Santosh Chokhani >> > >>> A : "denis.pinkas@bull.net >>> " >> > >>> Cc : "pkix@ietf.org " >>> > >>> Date : 24/09/2012 18:21 >>> Objet : RE: draft-pinkas-rfc2560bis-02 >>> ------------------------------------------------------------------------ >>> >>> >>> >>> Denis, >>> >>> OK except a nit (replace "accessLocation field from" to >>> "accessLocation field of") >>> >>> *From:* denis.pinkas@bull.net >>> >>> [mailto:denis.pinkas@bull.net] * >>> Sent:* Monday, September 24, 2012 2:17 AM* >>> To:* Santosh Chokhani* >>> Cc:* pkix@ietf.org * >>> Subject:* RE: draft-pinkas-rfc2560bis-02 >>> >>> Santosh, >>> >>> Your point is valid. Here is a proposed change to solve >>> the issue. >>> >>> OLD TEXT: >>> >>> For a given URI value identifying the location of an >>> OCSP Responder, >>> the OCSP Responder SHALL only use one OCSP key pair >>> value for a >>> given period of time. For example, it is acceptable >>> for an OCSP >>> Responder to rekey, stop using the old key, and >>> continue to use the >>> same URI while using the new key. >>> >>> NEW TEXT: >>> >>> An OCSP Responder key rollover does not affect the >>> values of the >>> URIs that are placed in the accessLocation field from >>> the target >>> certificates. One or more OCSP Responder MAY respond >>> to an OCSP >>> request addressed at a given URI picked from the >>> accessLocation >>> field from a target certificate. Each OCSP Responder >>> MAY use a >>> different signing key, as long as it got an OCSP >>> certificate >>> appropriate for that signing key and for the target >>> certificate. >>> >>> Denis >>> >>> >>> >>> De : Santosh Chokhani <_SChokhani@cygnacom.com_ >>> > >>> A : "_denis.pinkas@bull.net_ >>> " <_denis.pinkas@bull.net_ >>> > >>> Cc : "_pkix@ietf.org_ " >>> <_pkix@ietf.org_ > >>> Date : 21/09/2012 17:42 >>> Objet : RE: draft-pinkas-rfc2560bis-02 >>> >>> ------------------------------------------------------------------------ >>> >>> >>> >>> >>> Denis, >>> >>> Thanks. I am ok with your changes. >>> >>> One thing listed below is troubling me and I would like >>> your and others' opinion on it. >>> >>> While you have revised the text in Section 3.3.3 as I >>> requested, it is overly constraining and has been >>> troublesome from the beginning. The text I refer to is: >>> "For a given URI value identifying the location of an >>> OCSP Responder, the OCSP Responder SHALL only use one >>> OCSP key pair value for a given period of time". >>> >>> While I can see how this assertion simplifies the >>> sausage-making of the standard and the data structures >>> you spell out, it is something these need not be applies >>> in order for the OCSP to work. It is generally a bad >>> ideas in a standard to impose a constraint that is not >>> necessary for feasibility, security or interoperability >>> reasons. >>> >>> For example, one could have geographical load balancing >>> and/or geographicalredundancy for the URL and rather >>> than porting the same key, have differentkeys for the >>> Servers. In that case, the actual Server that got the >>> request routed would sign the response. >>> >>> Another example, is the URL and the server map to the >>> same machine and it has multiple keys and can use any >>> one of them. >>> >>> I do agree that there needs to be some constraint that >>> specifies that the server must be able to provide >>> response to all the queries it is authoritative for and >>> meet the cryptographic binding requirement. >>> I think we need to work the 3.3.3 language so that the >>> constraint is specified such that it does not prohibit >>> valid architectures. >>> * >>> From:* _denis.pinkas@bull.net_ >>> [_mailto:denis.pinkas@bull.net_] >>> * >>> Sent:* Friday, September 21, 2012 9:22 AM* >>> To:* Santosh Chokhani* >>> Cc:* _pkix@ietf.org_ * >>> Subject:* draft-pinkas-rfc2560bis-02 >>> >>> Santosh, >>> >>> Thank you for these new comments. I have one comment >>> back and two nits. >>> >>> You suggested to add text at the end of STEP 2, since >>> the current draft does not cover when the response is >>> signed by the OCSP Responder. >>> Your rational is quite true. However, your propose >>> change does not fit well. I have changed the text >>> differently >>> >>> Please take a look at draft -02 which has been issued >>> today._ >>> __http://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-02.txt_ >>> >>> First nit : >>> >>> PROPOSED TEXT: >>> >>> Note: The CA may need to continue issuing certificates >>> to the OCSP Responder using the old CA key until >>> all the certificates issued under the CA' old key for >>> which the OCSP Responder is authoritative *for expire*. >>> >>> NEW TEXT: >>> >>> Note: The CA may need to continue issuing certificates >>> to the OCSP Responder using the old CA key until >>> all the certificates issued under the CA' old key for >>> which the OCSP Responder is authoritative *have*expire*d*. >>> >>> Second nit : >>> >>> PROPOSED TEXT: >>> >>> For example, it is acceptable for an OCSP Responder to >>> rekey, stop using the old key, and continue to use >>> the *old* URI while using the new key" >>> >>> NEW TEXT: >>> >>> For example, it is acceptable for an OCSP Responder to >>> rekey, stop using the old key, and continue to use >>> the *same* URI while using the new key. >>> >>> Denis >>> >>> >>> >>> De : Santosh Chokhani <_SChokhani@cygnacom.com_ >>> > >>> A : "_denis.pinkas@bull.net_ >>> " <_denis.pinkas@bull.net_ >>> > >>> Cc : "_pkix@ietf.org_ " >>> <_pkix@ietf.org_ > >>> Date : 18/09/2012 21:27 >>> Objet : RE: [pkix] draft-pinkas-rfc2560bis-00 >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> >>> >>> >>> Denis, >>> >>> Thanks. Below are my updated recommended changes: >>> >>> Section 3.2 >>> >>> Add the following Note after the second dash: >>> >>> Note: The change in accessLocation is necessary when the >>> CA rekeys to meet the following constraints imposed by >>> this standard: 1) a BasicOCSPResponse can only be signed >>> using a single private key; 2) the response must be >>> signed using the same CA key that was used to sign the >>> certificate in question; and 3) the OCSP response needs >>> to cover all the certificates queried in the OCSP request. >>> >>> Section 3.3.2: >>> >>> Add the following Note to the 3^rd and the last paragraph: >>> >>> Note: The CA may need to continue issuing certificates >>> to the OCSP Responder using the old CA key until all the >>> certificates issued under the CA' old key for which the >>> OCSP Responder is authoritative for expire. >>> >>> Section 3.3.3: >>> >>> OLD TEXT: >>> >>> "For a given URI value identifying the location of an >>> OCSP Responder, the OCSP Responder SHALL only use one >>> OCSP key pair value." >>> >>> NEW TEXT: >>> >>> "For a given URI value identifying the location of an >>> OCSP Responder, the OCSP Responder SHALL only use one >>> OCSP key pair value for a given period of time. For >>> example, it is acceptable for an OCSP Responder to >>> rekey, stop using the old key, and continue to use the >>> old URI while using the new key" >>> >>> Section 3.4: >>> >>> OLD TEXT: >>> >>> Note: For each candidate certificate, when performing >>> the path >>> validation algorithm, the OCSP client will verify >>> that the >>> current time is within the validity period of the >>> target >>> certificate. Thus, certificates which are outside >>> their >>> validity period will not be included in the request >>> or will >>> be rejected later on by the OCSP responder. >>> >>> >>> NEW TEXT: >>> >>> Note: For each candidate certificate, when performing >>> the path >>> validation algorithm, the OCSP client SHOULDverify >>> that the >>> current time is within the validity period of the >>> target >>> certificate. Thus, certificates which are outside >>> their >>> validity period SHOULDnot be included in the request. >>> >>> Section 4.3.1.3: >>> >>> OLD TEXT: >>> >>> For each CA from which the locally trusted Responder >>> has received a >>> delegation, the OCSP Responder SHALL maintain a list of >>> entries. >>> >>> >>> NEW TEXT: >>> >>> For each CA forwhich the locally trusted Responder is >>> authoritative, the OCSP Responder SHALL maintain a list >>> of entries. >>> >>> RATIONALE: >>> >>> The locally trusted responder need not have delegation >>> from the CA >>> >>> Section 4.3.2: >>> >>> Add the following at the end of STEP 2: >>> >>> check whether the response is signed using the OCSP >>> Responder key: >>> >>> If it is the case, then the revocation status >>> of that >>> certificate as indicated in the certStatus >>> field is >>> accepted and proceed to step 3. >>> >>> If it is not the case, then the revocation >>> status of that >>> certificate is "unknown" and proceed to step 3. >>> >>> Rationale: Current draft does not cover when the >>> response is signed by the OCSP Responder >>> >>> Change S. Shokhani to S. Chokhani >>> >>> * >>> From:* _denis.pinkas@bull.net_ >>> [_mailto:denis.pinkas@bull.net_] >>> * >>> Sent:* Monday, September 17, 2012 3:59 AM* >>> To:* Santosh Chokhani* >>> Cc:* _pkix@ietf.org_ * >>> Subject:* RE: [pkix] draft-pinkas-rfc2560bis-00 >>> >>> Santosh, >>> >>> Thank you for your very valuable comments. It took me >>> "some time" to process them. >>> It will take you "some time" to review them. :-) >>> >>> Since the comments and the changes were numerous, I have >>> issued a new draftwhich is available at:_ >>> __http://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-01.txt_ >>> >>> For Santosh in particular, see my responses below in lines. >>> >>> Denis, >>> >>> Thanks for this. My initial review indicates that this >>> a very good first draft. >>> Note that I did not review ASN.1 carefully (I assume it >>> was copied from the existing RFC). >>> >>> It was copied from the draft prepared by Stefan, but the >>> ASN. 1 module needs to be modified >>> since the syntax of nonce has been omitted. >>> >>> I have added: >>> >>> Nonce ::= OCTET STRING >>> >>> Since the syntax of the nocheck extension was missing, I >>> have also added: >>> >>> NoCheck ::= NULL >>> >>> In the introduction, I have also added: >>> >>> o Section 4.3.2 now indicates that the value of the >>> nocheck >>> extension SHALL be NULL. >>> >>> The ASN.1 module that conforms to the 2002 version of >>> ASN.1 which may be found in Section 4 >>> of RFC5912 has another problem, since the nocheck >>> extension has been omitted. >>> >>> I have added: >>> >>> -- Certificate Extension >>> >>> ocsp-nocheck EXTENSION ::= { SYNTAX NULL >>> IDENTIFIED BY >>> id-pkix-ocsp-nocheck } >>> >>> This means that we cannot keep the same OID for the two >>> ASN. 1 modules and thus we will need two new ones. >>> >>> I have now included both syntaxes in draft -01. >>> >>> In the introduction, I have also added: >>> >>> o Annex B includes a new ASN.1 module using the 1988 >>> syntax >>> since the syntax of nonce had been omitted. It >>> also includes >>> a new ASN.1 module using the 2002 syntax since in >>> the ASN.1 >>> module which may be found in Section 4 of RFC5912 >>> the nocheck >>> extension had been omitted. >>> >>> I do have the following comment though: >>> >>> Section 2.2: When the CA is signing the response, should >>> it not also use the same key to sign the response >>> as the certificate in question? The later part of the >>> section indicates this as a requirement. >>> In that case, why not make this explicit like the OCSP >>> Responder. >>> >>> You are correct: I have added: >>> >>> In the former case, the CA MUST use the same key as the >>> one that was >>> used to issue the target certificate. >>> >>> Section 3.1.3, First paragraph, the rational for CA >>> certificates to have digital signature bit set because >>> they sign OCSP certificates is incorrect. May be what >>> you mean is that a CA that signs OCSP responses >>> needs to have digital signature bit set in its own >>> certificate (i.e., the certificate for which the CA is >>> the subject). >>> >>> Oups! The text was: >>> >>> Therefore the digitalSignature bit in the keyUsage >>> extension MUST >>> be set. >>> >>> Note 1: Since the CA issues certificates, the >>> keyCertSign bit MUST also >>> be set. >>> >>> Note 2: If the CA supports CRLs, in particular to revoke >>> the >>> certificate of the OCSP Responders, then the >>> cRLSign bit, the >>> digitalSignature bit and the keyCertSig bit MUST be >>> set. >>> >>> I have changed it into: >>> >>> Therefore the keyCertSign bit in the keyUsage extension >>> MUST be set. >>> >>> If the CA supports CRLs, in particular to revoke the >>> certificate of >>> the OCSP Responders, then both the cRLSign bit and the >>> keyCertSig >>> bit MUST be set. >>> >>> Section 3.1.3, Note 2, Again there is no requirement for >>> digital signature bit to be set just because the CA signs >>> certificates and CRLs. >>> >>> You are correct. See the correction proposed above. >>> >>> Section 3.2: It not clear which accessLocation is being >>> referred to here (cAissuers or OCSP). If this is OCSP, >>> the RFC is overly implementation specific. A CA can use >>> the same OCSP location and sign the response with >>> appropriate key and include the appropriate CA >>> certificate without having to change the OCSP pointer. >>> >>> Section 3.2 addresses the case of CA that directly >>> supports an OCSP serviceand which performs a key rollover. >>> If the CA key changes, the OCSP location must change >>> since it is only possible use a single key to sign the OCSP >>> responses. Nevertheless, I take your other point to be >>> more specific about the accessLocation. >>> The point is addressed later on in another comment from you. >>> >>> General: The I-D does not address how the CA deals with >>> the situation when status of multiple certificates >>> issued by the CA, >>> but using different keys is requested. May be the >>> restriction in 3.2 is used to ensure that such situation >>> does not occur. >>> If so, a short discussion would be helpful. >>> >>> Your comment is related to section 4.3.1.1. ("Processing >>> by a CA acting as an OCSP responder"). >>> The case is already addressed with the following text: >>> >>> For each target certificate, the OCSP responder SHALL >>> verify whether >>> both the hash of the issuer's DN and the hash of the >>> issuer public >>> key which are present in the request match respectively >>> with the DN >>> and the hash of the public key of contained in an entry >>> from the >>> list of entries maintained by this OCSP responder. >>> >>> When there is no match, then the OCSP responder SHALL >>> indicate the >>> "unknown" status and proceed with the next target >>> certificate from >>> the OCSP request. >>> >>> General: It not clear which accessLocation is being >>> referred to in most places. >>> It would be worth stating that it refers to OCSP in all >>> cases unless otherwise stated. >>> >>> I have added a note after the first occurrence of the >>> word in section 3.1.1. >>> >>> Note: accessLocation is mentioned in several places of >>> this document. >>> It refers in all cases to the accessLocation field >>> that is present >>> in an AIA extension field to designate the location >>> of the OCSP >>> responder. In that case, the accessMethod field >>> contains the >>> id-ad-ocsp OID. >>> >>> Section 3.3.2 does not fully and explicitly cover the >>> most common implementation I have seen and that is short >>> life certificates. >>> In that scenario, the CA needs to continue to issue the >>> OCSP Responder certificate using the old CA key until >>> all the certificates >>> issued by the CA using the old key and for which the >>> OCSP Responder is authoritative expire. >>> The text in 3.3.3 can form a model for this when CA >>> rekeys and OCSP Responder has the old keys. >>> >>> The text in section 3.3.2 does not say what you say. >>> Please be more specific or since the text is short, >>> provide an alternative >>> >>> Section 3.3.3, the last sentence is not desirable and >>> can cause problems with some implementations. >>> It is perfectly ok for a Responder to change its key >>> independent of certificate it is authoritative for. >>> Note that OCSP field in a issue certificate cannot be >>> changed just because the Responder rekyed, >>> be it routine or due to loss or compromise of Responder key. >>> >>> The text in section 3.3.3 does not say what you say. >>> Please be more specific or since the text is short, >>> provide an alternative. >>> >>> Section 3.4, last paragraph, I would think that >>> expiration checking need not be part of OCSP client. >>> Expiration checking should come under 5280 certificate >>> validation. >>> >>> The text was: >>> >>> For each candidate certificate, the OCSP client SHALL >>> verify that >>> the current time is within the validity period of the >>> target >>> certificate. If this is not the case, the candidate >>> certificate >>> SHALL be discarded. >>> >>> I have changed it into; >>> >>> Note: For each candidate certificate, when performing >>> the path >>> validation algorithm, the OCSP client will verify >>> that the >>> current time is within the validity period of the >>> target >>> certificate. Thus, certificates which are outside >>> their >>> validity period will not be included in the request >>> or will >>> be rejected later on by the OCSP responder. >>> >>> Section 4.1, We should dilute two CAs "never have the >>> same issuerKeyHash" to something more akin >>> to statistically infeasible. >>> >>> The text was: >>> >>> Two CAs will never, however, have the same public key >>> unless the >>> CAs either explicitly decided to share their private >>> key, or the >>> key of one of the CAs was compromised. >>> >>> I have changed it into: >>> >>> However, it is statistically infeasible that two CAs >>> use the same >>> public key unless the CAs either explicitly decided >>> to share >>> their private key, or the key of one of the CAs was >>> compromised. >>> >>> Titles of subsections under 4.3 could stand >>> improvements. Responders process request and produce >>> response; >>> they do not process responses. Clients process responses. >>> >>> The titles were: >>> >>> 4.3. Response processing >>> 4.3.1. Response processing by OCSP servers >>> 4.3.1.1. Processing by a CA acting as an OCSP >>> responder >>> 4.3.1.2. Processing by an OCSP Responder >>> 4.3.2. Response processing by an OCSP client >>> >>> I have changed them into: >>> >>> 4.3. Processing of requests and responses >>> 4.3.1. Request processing by OCSP servers >>> 4.3.1.1. Processing by a CA acting as an OCSP >>> responder >>> 4.3.1.2. Processing by an OCSP Responder >>> 4.3.2. Response processing by an OCSP client >>> >>> Section 4.3.1.1, The entry should contain method used to >>> gain access and sign just like the text in 4.3.1.2 >>> as opposed to the private key. In other words, align >>> the two texts for accessing and using private key >>> to sign OCSP responses. >>> >>> Both sections have been aligned. >>> >>> Section 4.3.1,1, page 18 "defined in entry" could be >>> misinterpreted as method define in request entry. >>> >>> I don't think that a change is necessary, since it uses >>> the term "for each target certificate" and the entry thus >>> refers to one of the entries from the tables of entries >>> advertised at the beginning of the section. >>> If you believe that a change is necessary, would you be >>> able to make a proposal ? >>> >>> Section 4.3.1.2, Again the same comment, for the >>> delegated OCSP Responder, changing the URL >>> when key is changed is not required and breaks many >>> implementations and hence is unacceptable. >>> >>> Would you be able to be more specific, since I don't see >>> that the text states what you mean ? >>> >>> Section 4.3.2, the check for thisUpdate is flawed since >>> this value may be derived from CRL even for responses >>> that are not pre-generated and hence can be hours or >>> days off depending on CRL issuance frequency, >>> It is better to replace it with producedAt field in the >>> response whether it is related to current time or time >>> in the past. >>> >>> Good catch ! >>> >>> The text has been changed into : >>> >>> If the checking time is the current time, and if no >>> nonce has been >>> used in the request, OCSP clients MUST check that the >>> producedAt >>> field is within a time window that is "close enough" to >>> the current >>> time. >>> >>> If the checking time is a time in the past, verifiers >>> MUST check >>> that the producedAt field is in accordance with the >>> verification >>> rules (e.g. close and/or after the date of a time-stamp >>> token). >>> >>> Section 4,3,2 is missing processing signature on the >>> response and processing response extension. >>> >>> I don't understand your request about "missing >>> processing signature on the response", since this point >>> is addressed >>> under STEP 2. If you believe that a change is necessary, >>> would you be able to be more specific ? >>> >>> Processing response extension is only covered for >>> singleExtensions when the criticality flag is set and >>> the extension is not understood. So you are correct to >>> request additional text to handle the other cases. >>> >>> The following text has been added for the processing of >>> responseExtensions: >>> >>> OCSP clients or verifiers SHALL check if the response >>> contains a >>> critical responseExtensions. If such an extension is >>> found and is >>> recognized, it MUST be processed. If such an extension >>> is found and >>> is not recognized, the whole OCSP response MUST be >>> considered as >>> invalid. >>> >>> The following text has been added for the processing of >>> singleExtensions: >>> >>> If checks are successful, then OCSP clients MUST process >>> the >>> singleExtensions field, if it is present. >>> >>> If the criticality flag is set and the extension is not >>> understood, >>> then the status of the certificate shall be "unknown" >>> and proceed to >>> step 3. Otherwise, proceed to step 2. >>> >>> If the extension is understood, then the extension MUST be >>> processed. According to its content proceed either to >>> step 2 or to >>> step 3. >>> >>> Section 5.5: Replay attack is also possible when not >>> using pre-computed responses. >>> >>> I have added in new section with the following text: >>> >>> 5.7. Other replay attacks >>> >>> As already mentioned in section 5.5, replay attacks are >>> possible >>> using precomputed responses. Replay attacks are also >>> possible when >>> no nonce is being used in the OCSP request and the time >>> window >>> mentioned in section 4.3.2 (STEP 1)is too large. >>> >>> General: Removal of locally trusted Responder from the >>> I-D is unacceptable. >>> >>> The intent was not to remove the "locally trusted >>> Responder". Nevertheless, the current text has been improved >>> in several places. For example, in the introduction, I >>> have added: >>> >>> The term "locally trusted Responder" is used to >>> designate an OCSP >>> responder that is trusted using local rules. >>> >>> In section 2.2, the text now states: >>> >>> A response message MUST be signed either by a >>> certificate's issuer, >>> by an authorized OCSP Responder or according to local >>> rules. >>> >>> In the first case, the CA MUST use the same key as the >>> one that was >>> used to issue the target certificate. >>> >>> In the second case, the CA MUST explicitly designate the >>> OCSP >>> Responder by issuing an OCSP certificate to the OCSP >>> Responder. >>> OCSP signing delegation SHALL be indicated by the >>> inclusion of >>> id-kp-OCSPSigning in an extendedKeyUsage certificate >>> extension >>> included in the OCSP response signer's certificate. This >>> certificate MUST be issued directly by the CA and under >>> the same key >>> that was used to issue the target certificate. >>> >>> For these two cases, systems or applications that rely >>> on OCSP >>> responses MUST be capable of detecting and enforcing use >>> of the >>> id-ad-ocspSigning value as described above. >>> >>> In the third case, the OCSP client uses a locally >>> trusted Responder. >>> The key used to sign OCSP responses may be directly >>> trusted or be a >>> key contained in an OCSP certificate which is verified >>> according to >>> local rules, instead of the rules detailed in this document. >>> >>> In section I have changed the following text : >>> >>> The OCSP certificate SHALL be signed by the CA issuing >>> private key >>> which corresponds to the issuing CA public key that is >>> in this >>> entry, unless some specific rules are agreed between the >>> OCSP >>> Responder and OCSP clients. In that later case, the OCSP >>> certificate MAY be signed by a different entity. >>> >>> into: >>> >>> The OCSP certificate SHALL be signed by the CA issuing >>> private key >>> which corresponds to the issuing CA public key that is >>> in this >>> entry, unless some specific rules are agreed between the >>> OCSP >>> Responder and OCSP clients. In that later case, which >>> corresponds >>> to the case of a locally trusted Responder, the OCSP >>> certificate MAY >>> be signed by a different entity. >>> >>> There is now also a completely new section: 4.3.1.3, >>> called "Processing by a locally trusted Responder". >>> >>> When reviewing the text, I found that, in section >>> 4.3.1.2, the list only mentioned: >>> >>> - the method(s) used to obtain the revocation status >>> of the >>> certificates issued under that CA issuing public key, >>> >>> In practice, an OCSP responder may not be responsible >>> for all the certificates issued by a CA. >>> So it also needs to know which subset of the >>> certificates issued by each CA it is responsible for. >>> >>> Thus I have changed the text into: >>> >>> - the method(s) used to know for which subset of >>> certificates >>> issued by the CA it is responsible for, >>> >>> - the method(s) used to obtain the revocation status >>> of that >>> subset of certificates issued under that CA issuing >>> public key, >>> >>> >>> Denis >>> >>> > A new Internet-Draft is available from the on-line >>> Internet-Drafts >>> > directories. >>> > >>> > Title : X.509 Internet PublicKey >>> Infrastructure Online >>> > Certificate Status Protocol - OCSP >>> > Author(s) : D. Pinkas >>> > Filename : draft-pinkas-rfc2560bis >>> > Pages : 41 >>> > Date : Aug. 27, 2012 >>> > >>> > This document specifies a protocol useful in >>> determining the current >>> > status of a digital certificate without requiring >>> CRLs. Additional >>> > mechanisms addressing PKIX operational requirements >>> are specified in >>> > separate documents. This document obsoletes RFC 2560 >>> and RFC 6277. >>> > >>> > A URL for this Internet-Draft is: >>> > >>> _http://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-00.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. >>> > >>> > >>> <_ftp://ftp.ietf.org/internet-drafts/draft-pinkas-rfc2560bis_> >>> >>> > >>> > A few explanations about the content of >>> draft-ietf-pinkas-rfc2560bis-00. >>> > >>> > 25 changes are indicated at the beginning of the >>> document. >>> > I will only mention a few of them: >>> > >>> > A - Explanations were missing to describe: >>> > >>> > - the building of a request by an OCSP client, >>> > - the processing of a request by an OCSP server, >>> > - the building of a response by an OCSP server, and >>> > - the processing of a response by an OCSP client. >>> > >>> > These explanations have been added. >>> > >>> > B - Explanations were missing to address CA key >>> rollover and OCSP >>> > key rollover. These explanations have been added. >>> > >>> > C - Backwards compatibility has been addressed in the >>> > --------------030608090006080504060707 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=ISO-8859-1
Stefan,

Let us wait until Tuesday: it is less than one and a half working days.

Denis

Denis,

In-line

From: Denis Pinkas <denis.pinkas@bull.net>
Date: Thursday, October 11, 2012 3:08 PM
To: Stefan Santesson <stefan@aaa-sec.com>
Cc: Santosh Chokhani <SChokhani@cygnacom.com>, "pkix@ietf.org" <pkix@ietf.org>
Subject: Re: [pkix] draft-pinkas-rfc2560bis-03

Stefan,

You will find detailed explanations of all the changes in the first pages of my draft.
You win a special prize, if you find a major change that is not indicated !

I have seen and read them. But they do not provide what's needed.

I need to know for each change:
  • What is the problem you try to solve (I.e. Why is a change necessary)?
  • Motivate why your proposed solution is the best way forward.
In order to make it to the update you need to convoke the WG on both points.

 
Since the RFC was badly structured, for example, the description of the parameters for the request and the response
was scattered all over the document, some descriptions were missing, then its current format could not be kept.

I disagree. The structure of 2560 is not ideal, but it is good enough.
The value of having an update that is easy to compare with the original standard is greater than the benefit of changing the structure.


In my draft, each parameter is now described either with the request or with the response. the processing is described just after,
from a client and then from a server prospective.

Some processing of the elements were missing and the most important was that the processing of the response was wrong.

This is valuable information. Here I would need to know (as stated above) 1) What is the problem? 2) Why solve it your way?
Just saying that something is missing is not enough. You have to explain what negative impact this has.
Something might be missing because it is not necessary.


I have added information for handling key rollover that influence the way to use the protocol. I believe this information is important,
but I would not object to move it in an annex

I think on the contrary that describing key rollover is completely unnecessary.
The mechanisms of key rollover is already explained in other documents.


Since we now both know that it will be possible to have a quick face to face meeting in London next week on Tuesday, 
I propose that we both come with a printed version of the draft and then we can discuss the changes and the rational of each change
that is not always fully explained, since this will have overloaded the document (which is already sufficiently heavy).

I just need the list of motivations stated above.
Then we can process them one by one here on the list.

Having a face to face discussion is good however.

/Stefan



Denis


Denis,

Unfortunately, the number changes are too many to make a fast detailed review providing suggestions on corrections to all issues.
I could provide examples, but that would not be a complete list.

However,

As the WG and AD has decided that we should start with as few changes as possible and only add what is necessary, I would like to reverse this.
Could you provide an argument for each change to the current WG draft that you think is necessary?

/Stefan


From: Denis Pinkas Bull <denis.pinkas@bull.net>
Date: Thursday, October 11, 2012 7:42 AM
To: Stefan Santesson <stefan@aaa-sec.com>
Cc: Santosh Chokhani <SChokhani@cygnacom.com>, "pkix@ietf.org" <pkix@ietf.org>
Subject: Re: [pkix] draft-pinkas-rfc2560bis-03

Stefan,

Thank you for your comments.

However, your first two comments are not specific enough to know portions of text you would like to be removed.
Would you be able to be more specific ?

On your third comment, you say: The distinction between OCSP responder, OCSP server and OCSP service is
in this context confusing and adds nothing useful to an implementer on either side of the protocol.

You are right to say that there is no need to make a difference between an OCSP server and
an OCSP responder, and I can change this in the draft.

However, the distinction between an OCSP service supported by one or more OCSP responders should be maintained.

Denis

Denis,

Posting my major comments on this draft:

- This is a substantial rewrite of the original standard. There has been a
WG decision to limit changes to RFC 2560 to what is necessary to resolve
previous ambiguity. In many places, the text provided in your draft adds
confusion and adds ambiguity instead of removing them.

- This is a protocol specification. That is, it defines the data elements
exchanged for the purpose of doing OCSP checks. It is NOT a system design
specification. Processing rules are only relevant if they have a direct
impact on the bits on the wire.

- The distinction between OCSP responder, OCSP server and OCSP service is
in this context confusing and adds nothing useful to an implementer on
either side of the protocol.

/Stefan

From: <denis.pinkas@bull.net>
Date: Tuesday, September 25, 2012 5:01 PM
To: Santosh Chokhani <SChokhani@cygnacom.com>
Cc: "pkix@ietf.org" <pkix@ietf.org>
Subject: [pkix] draft-pinkas-rfc2560bis-03

Santosh,

This text change has been included in draft -03 which is now available at :

http://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-03.txt

Denis



De :        Santosh Chokhani <SChokhani@cygnacom.com>
A :        "denis.pinkas@bull.net" <denis.pinkas@bull.net>
Cc :        "pkix@ietf.org" <pkix@ietf.org>
Date :        24/09/2012 18:21
Objet :        RE: draft-pinkas-rfc2560bis-02



Denis,
 
OK except a nit (replace “accessLocation field from” to “accessLocation field of”)
 
From: denis.pinkas@bull.net [mailto:denis.pinkas@bull.net]
Sent: Monday, September 24, 2012 2:17 AM
To: Santosh Chokhani
Cc: pkix@ietf.org
Subject: RE: draft-pinkas-rfc2560bis-02
 
Santosh,

Your point is valid. Here is a proposed change to solve the issue.

OLD TEXT:

  For a given URI value identifying the location of an OCSP Responder,
  the OCSP Responder SHALL only use one OCSP key pair value for a
  given period of time.  For example, it is acceptable for an OCSP
  Responder to rekey, stop using the old key, and continue to use the
  same URI while using the new key.

NEW TEXT:

  An OCSP Responder key rollover does not affect the values of the
  URIs that are placed in the accessLocation field from the target
  certificates.  One or more OCSP Responder MAY respond to an OCSP
  request addressed at a given URI picked from the accessLocation
  field from a target certificate.  Each OCSP Responder MAY use a
  different signing key, as long as it got an OCSP certificate
  appropriate for that signing key and for the target certificate.

Denis



De :        Santosh Chokhani <SChokhani@cygnacom.com>
A :        "denis.pinkas@bull.net" <denis.pinkas@bull.net>
Cc :        "pkix@ietf.org" <pkix@ietf.org>
Date :        21/09/2012 17:42
Objet :        RE: draft-pinkas-rfc2560bis-02





Denis,
 
Thanks.  I am ok with your changes.
 
One thing listed below is troubling me and I would like your and others’ opinion on it.
 
While you have revised the text in Section 3.3.3 as I requested, it is overly constraining and has been troublesome from the beginning.  The text I refer to is: “For a given URI value identifying the location of an OCSP Responder, the OCSP Responder SHALL only use one OCSP key pair value for a given period of time”.
 
While I can see how this assertion simplifies the sausage-making of the standard and the data structures you spell out, it is something these need not be applies in order for the OCSP to work.   It is generally a bad ideas in a standard to impose a constraint that is not necessary for feasibility, security or interoperability reasons.
 
For example, one could have geographical load balancing and/or geographicalredundancy for the URL and rather than porting the same key, have differentkeys for the Servers.  In that case, the actual Server that got the request routed would sign the response.
 
Another example, is the URL and the server map to the same machine and it has multiple keys and can use any one of them.
 
I do agree that there needs to be some constraint that specifies that the server must be able to provide response to all the queries it is authoritative for and meet the cryptographic binding requirement.
I think we need to work the 3.3.3 language so that the constraint is specified such that it does not prohibit valid architectures.
 
From: denis.pinkas@bull.net [mailto:denis.pinkas@bull.net]
Sent: Friday, September 21, 2012 9:22 AM
To: Santosh Chokhani
Cc: pkix@ietf.org
Subject: draft-pinkas-rfc2560bis-02
 
Santosh,

Thank you for these new comments. I have one comment back and two nits.

You suggested to add text at the end of STEP 2, since the current draft does not cover when the response is signed by the OCSP Responder.
Your rational is quite true. However, your propose change does not fit well. I have changed the text differently

Please take a look at draft -02 which has been issued today.
http://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-02.txt

First nit :

PROPOSED TEXT:

Note: The CA may need to continue issuing certificates to the OCSP Responder using the old CA key until
all the certificates issued under the CA’ old key for which the OCSP Responder is authoritative for expire.

NEW TEXT:

Note: The CA may need to continue issuing certificates to the OCSP Responder using the old CA key until
all the certificates issued under the CA’ old key for which the OCSP Responder is authoritative have expired.

Second nit :

PROPOSED TEXT:

For example, it is acceptable for an OCSP Responder to rekey, stop using the old key, and continue to use
the old URI while using the new key”

NEW TEXT:

For example, it is acceptable for an OCSP Responder to rekey, stop using the old key, and continue to use
the same URI while using the new key.

Denis



De :        Santosh Chokhani <SChokhani@cygnacom.com>
A :        "denis.pinkas@bull.net" <denis.pinkas@bull.net>
Cc :        "pkix@ietf.org" <pkix@ietf.org>
Date :        18/09/2012 21:27
Objet :        RE: [pkix] draft-pinkas-rfc2560bis-00

 





Denis,

Thanks.  Below are my updated recommended changes:

Section 3.2

Add the following Note after the second dash:

Note: The change in accessLocation is necessary when the CA rekeys to meet the following constraints imposed by this standard: 1) a BasicOCSPResponse can only be signed using a single private key; 2) the response must be signed using the same CA key that was used to sign the certificate in question; and 3) the OCSP response needs to cover all the certificates queried in the OCSP request.

Section 3.3.2:

Add the following Note to the 3rd and the last paragraph:

Note: The CA may need to continue issuing certificates to the OCSP Responder using the old CA key until all the certificates issued under the CA’ old key for which the OCSP Responder is authoritative for expire.

Section 3.3.3:

OLD TEXT:

“For a given URI value identifying the location of an OCSP Responder, the OCSP Responder SHALL only use one OCSP key pair value.”

NEW TEXT:

“For a given URI value identifying the location of an OCSP Responder, the OCSP Responder SHALL only use one OCSP key pair value for a given period of time.  For example, it is acceptable for an OCSP Responder to rekey, stop using the old key, and continue to use the old URI while using the new key”

Section 3.4:

OLD TEXT:

Note:  For each candidate certificate, when performing the path
     validation algorithm, the OCSP client will verify that the
     current time is within the validity period of the target
     certificate.  Thus, certificates which are outside their
     validity period will not be included in the request or will
     be rejected later on by the OCSP responder.


NEW TEXT:

Note:  For each candidate certificate, when performing the path
     validation algorithm, the OCSP client SHOULD verify that the
     current time is within the validity period of the target
     certificate.  Thus, certificates which are outside their
     validity period SHOULD not be included in the request.

Section 4.3.1.3:

OLD TEXT:

 For each CA from which the locally trusted Responder has received a
 delegation, the OCSP Responder SHALL maintain a list of entries.


NEW TEXT:

For each CA for which the locally trusted Responder is authoritative, the OCSP Responder SHALL maintain a list of entries.

RATIONALE:

The locally trusted responder need not have delegation from the CA

Section 4.3.2:

Add the following at the end of STEP 2:

check whether the response is signed using the OCSP Responder key:

           If it is the case, then the revocation status of that
           certificate as indicated in the certStatus field is
           accepted and proceed to step 3.

           If it is not the case, then the revocation status of that
           certificate is "unknown" and proceed to step 3.

Rationale: Current draft does not cover when the response is signed by the OCSP Responder

Change S. Shokhani to S. Chokhani


From: denis.pinkas@bull.net [mailto:denis.pinkas@bull.net]
Sent: Monday, September 17, 2012 3:59 AM
To: Santosh Chokhani
Cc: pkix@ietf.org
Subject: RE: [pkix] draft-pinkas-rfc2560bis-00

Santosh,

Thank you for your very valuable comments. It took me "some time" to process them.
It will take you "some time" to review them. :-)

Since the comments and the changes were numerous, I have issued a new draftwhich is available at:
http://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-01.txt

For Santosh in particular, see my responses below in lines.

Denis,

Thanks for this.  My initial review indicates that this a very good first draft.  
Note that I did not review ASN.1 carefully (I assume it was copied from the existing RFC).

It was copied from the draft prepared by Stefan, but the ASN. 1 module needs to be modified
since the syntax of nonce has been omitted.

I have added:

Nonce ::= OCTET STRING

Since the syntax of the nocheck extension was missing, I have also added:

NoCheck ::= NULL

In the introduction, I have also added:

   o  Section 4.3.2 now indicates that the value of the nocheck
      extension SHALL be NULL.

The ASN.1 module that conforms to the 2002 version of ASN.1 which may be found in Section 4
of RFC5912 has another problem, since the nocheck extension has been omitted.

I have added:

--  Certificate Extension

ocsp-nocheck EXTENSION ::= { SYNTAX NULL
                                      IDENTIFIED BY
                                      id-pkix-ocsp-nocheck }

This means that we cannot keep the same OID for the two ASN. 1 modules and thus we will need two new ones.

I have now included both syntaxes in draft -01.

In the introduction, I have also added:

   o  Annex B includes a new ASN.1 module using the 1988 syntax
      since the syntax of nonce had been omitted.  It also includes
      a new ASN.1 module using the 2002 syntax since in the ASN.1
      module which may be found in Section 4 of RFC5912 the nocheck
      extension had been omitted.

I do have the following comment though:

Section 2.2: When the CA is signing the response, should it not also use the same key to sign the response
as the certificate in question?  The later part of the section indicates this as a requirement.  
In that case, why not make this explicit like the OCSP Responder.

You are correct: I have added:

In the former case, the CA MUST use the same key as the one that was
used to issue the target certificate.

Section 3.1.3, First paragraph, the rational for CA certificates to have digital signature bit set because
they sign OCSP certificates is incorrect.  May be what you mean is that a CA that signs OCSP responses
needs to have digital signature bit set in its own certificate (i.e., the certificate for which the CA is the subject).

Oups! The text was:

Therefore the digitalSignature bit in the keyUsage extension MUST
be set.

Note 1: Since the CA issues certificates, the keyCertSign bit MUST also
     be set.

Note 2: If the CA supports CRLs, in particular to revoke the
     certificate of the OCSP Responders, then the cRLSign bit, the
     digitalSignature bit and the keyCertSig bit MUST be set.

I have changed it into:

Therefore the keyCertSign bit in the keyUsage extension MUST be set.

If the CA supports CRLs, in particular to revoke the certificate of
the OCSP Responders, then both the cRLSign bit and the keyCertSig
bit MUST be set.

Section 3.1.3, Note 2, Again there is no requirement for digital signature bit to be set just because the CA signs
certificates and CRLs.

You are correct. See the correction proposed above.

Section 3.2: It not clear which accessLocation is being referred to here (cAissuers or OCSP).  If this is OCSP,
the RFC is overly implementation specific.  A CA can use the same OCSP location and sign the response with
appropriate key and include the appropriate CA certificate without having to change the OCSP pointer.

Section 3.2 addresses the case of CA that directly supports an OCSP serviceand which performs a key rollover.  
If the CA key changes, the OCSP location must change since it is only possible use a single key to sign the OCSP
responses. Nevertheless, I take your other point to be more specific about the accessLocation.
The point is addressed later on in another comment from you.

General: The I-D does not address how the CA deals with the situation when status of multiple certificates issued by the CA,
but using different keys is requested.  May be the restriction in 3.2 is used to ensure that such situation does not occur.  
If so, a short discussion would be helpful.

Your comment is related to section 4.3.1.1. (“Processing by a CA acting as an OCSP responder”).
The case is already addressed with the following text:

For each target certificate, the OCSP responder SHALL verify whether
both the hash of the issuer's DN and the hash of the issuer public
key which are present in the request match respectively with the DN
and the hash of the public key of contained in an entry from the
list of entries maintained by this OCSP responder.

When there is no match, then the OCSP responder SHALL indicate the
"unknown" status and proceed with the next target certificate from
the OCSP request.

General: It not clear which accessLocation is being referred to in most places.
It would be worth stating that it refers to OCSP in all cases unless otherwise stated.

I have added a note after the first occurrence of the word in section 3.1.1.

Note: accessLocation is mentioned in several places of this document.
   It refers in all cases to the accessLocation field that is present
   in an AIA extension field to designate the location of the OCSP
   responder.  In that case, the accessMethod field contains the
   id-ad-ocsp OID.

Section 3.3.2 does not fully and explicitly cover the most common implementation I have seen and that is short life certificates.  
In that scenario, the CA needs to continue to issue the OCSP Responder certificate using the old CA key until all the certificates
issued by the CA using the old key and for which the OCSP Responder is authoritative expire.  
The text in 3.3.3 can form a model for this when CA rekeys and OCSP Responder has the old keys.

The text in section 3.3.2 does not say what you say. Please be more specific or since the text is short, provide an alternative

Section 3.3.3, the last sentence is not desirable and can cause problems with some implementations.
It is perfectly ok for a Responder to change its key independent of certificate it is authoritative for.  
Note that OCSP field in a issue certificate cannot be changed just because the Responder rekyed,
be it routine or due to loss or compromise of Responder key.

The text in section 3.3.3 does not say what you say. Please be more specific or since the text is short, provide an alternative.

Section 3.4, last paragraph, I would think that expiration checking need not be part of OCSP client.  
Expiration checking should come under 5280 certificate validation.

The text was:

For each candidate certificate, the OCSP client SHALL verify that
the current time is within the validity period of the target
certificate.  If this is not the case, the candidate certificate
SHALL be discarded.

I have changed it into;

Note:  For each candidate certificate, when performing the path
    validation algorithm, the OCSP client will verify that the
    current time is within the validity period of the target
    certificate.  Thus, certificates which are outside their
    validity period will not be included in the request or will
    be rejected later on by the OCSP responder.

Section 4.1, We should dilute two CAs “never have the same issuerKeyHash” to something more akin
to statistically infeasible.

The text was:

   Two CAs will never, however, have the same public key unless the
   CAs either explicitly decided to share their private key, or the
   key of one of the CAs was compromised.

I have changed it into:

   However, it is statistically infeasible that two CAs use the same
   public key unless the CAs either explicitly decided to share
   their private key, or the key of one of the CAs was compromised.

Titles of subsections under 4.3 could stand improvements.  Responders process request and produce response;
they do not process responses.  Clients process responses.

The titles were:

  4.3. Response processing
    4.3.1. Response processing by OCSP servers
      4.3.1.1. Processing by a CA acting as an OCSP responder
      4.3.1.2. Processing by an OCSP Responder
    4.3.2. Response processing by an OCSP client

I have changed them into:

  4.3. Processing of requests and responses
    4.3.1. Request processing by OCSP servers
      4.3.1.1. Processing by a CA acting as an OCSP responder
      4.3.1.2. Processing by an OCSP Responder
    4.3.2. Response processing by an OCSP client

Section 4.3.1.1, The entry should contain method used to gain access and sign just like the text in 4.3.1.2
as opposed to the private key.  In other words, align the two texts for accessing and using private key
to sign OCSP responses.

Both sections have been aligned.

Section 4.3.1,1, page 18 “defined in entry” could be misinterpreted as method define in request entry.

I don’t think that a change is necessary, since it uses the term “for each target certificate” and the entry thus
refers to one of the entries from the tables of entries advertised at the beginning of the section.
If you believe that a change is necessary, would you be able to make a proposal ?

Section 4.3.1.2, Again the same comment, for the delegated OCSP Responder, changing the URL
when key is changed is not required and breaks many implementations and hence is unacceptable.

Would you be able to be more specific, since I don’t see that the text states what you mean ?

Section 4.3.2, the check for thisUpdate is flawed since this value may be derived from CRL even for responses
that are not pre-generated and hence can be hours or days off depending on CRL issuance frequency,
It is better to replace it with producedAt field in the response whether it is related to current time or time in the past.

Good catch !

The text has been changed into :

If the checking time is the current time, and if no nonce has been
used in the request, OCSP clients MUST check that the producedAt
field is within a time window that is "close enough" to the current
time.

If the checking time is a time in the past, verifiers MUST check
that the producedAt field is in accordance with the verification
rules (e.g. close and/or after the date of a time-stamp token).

Section 4,3,2 is missing processing signature on the response and processing response extension.

I don’t understand your request about “missing processing signature on the response”, since this point is addressed
under STEP 2. If you believe that a change is necessary, would you be able to be more specific ?

Processing response extension is only covered for singleExtensions when the criticality flag is set and
the extension is not understood. So you are correct to request additional text to handle the other cases.

The following text has been added for the processing of responseExtensions:

OCSP clients or verifiers SHALL check if the response contains a
critical responseExtensions. If such an extension is found and is
recognized, it MUST be processed.  If such an extension is found and
is not recognized, the whole OCSP response MUST be considered as
invalid.

The following text has been added for the processing of singleExtensions:

If checks are successful, then OCSP clients MUST process the
singleExtensions field, if it is present.

If the criticality flag is set and the extension is not understood,
then the status of the certificate shall be "unknown" and proceed to
step 3.  Otherwise, proceed to step 2.

If the extension is understood, then the extension MUST be
processed.  According to its content proceed either to step 2 or to
step 3.

Section 5.5: Replay attack is also possible when not using pre-computed responses.

I have added in new section with the following text:

5.7. Other replay attacks

As already mentioned in section 5.5, replay attacks are possible
using precomputed responses.  Replay attacks are also possible when
no nonce is being used in the OCSP request and the time window
mentioned in section 4.3.2 (STEP 1)is too large.

General: Removal of locally trusted Responder from the I-D is unacceptable.

The intent was not to remove the “locally trusted Responder”. Nevertheless, the current text has been improved
in several places. For example, in the introduction, I have added:

   The term “locally trusted Responder” is used to designate an OCSP
   responder that is trusted using local rules.

In section 2.2, the text now states:

A response message MUST be signed either by a certificate's issuer,
by an authorized OCSP Responder or according to local rules.

In the first case, the CA MUST use the same key as the one that was
used to issue the target certificate.

In the second case, the CA MUST explicitly designate the OCSP
Responder by issuing an OCSP certificate to the OCSP Responder.
OCSP signing delegation SHALL be indicated by the inclusion of
id-kp-OCSPSigning in an extendedKeyUsage certificate extension
included in the OCSP response signer's certificate.  This
certificate MUST be issued directly by the CA and under the same key
that was used to issue the target certificate.

For these two cases, systems or applications that rely on OCSP
responses MUST be capable of detecting and enforcing use of the
id-ad-ocspSigning value as described above.

In the third case, the OCSP client uses a locally trusted Responder.
The key used to sign OCSP responses may be directly trusted or be a
key contained in an OCSP certificate which is verified according to
local rules, instead of the rules detailed in this document.

In section I have changed the following text :

The OCSP certificate SHALL be signed by the CA issuing private key
which corresponds to the issuing CA public key that is in this
entry, unless some specific rules are agreed between the OCSP
Responder and OCSP clients.  In that later case, the OCSP
certificate MAY be signed by a different entity.

into:

The OCSP certificate SHALL be signed by the CA issuing private key
which corresponds to the issuing CA public key that is in this
entry, unless some specific rules are agreed between the OCSP
Responder and OCSP clients.  In that later case, which corresponds
to the case of a locally trusted Responder, the OCSP certificate MAY
be signed by a different entity.

There is now also a completely new section: 4.3.1.3, called “Processing by a locally trusted Responder”.

When reviewing the text, I found that, in section 4.3.1.2, the list only mentioned:

  - the method(s) used to obtain the revocation status of the
    certificates issued under that CA issuing public key,

In practice, an OCSP responder may not be responsible for all the certificates issued by a CA.
So it also needs to know which subset of the certificates issued by each CA it is responsible for.

Thus I have changed the text into:

  - the method(s) used to know for which subset of certificates
    issued by the CA it is responsible for,

  - the method(s) used to obtain the revocation status of that
    subset of certificates issued under that CA issuing public key,


Denis

> A new Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>    Title         : X.509 Internet PublicKey Infrastructure Online
>                    Certificate Status Protocol - OCSP
>    Author(s)     : D. Pinkas
>    Filename      : draft-pinkas-rfc2560bis
>    Pages         : 41
>    Date          : Aug. 27, 2012
>    
>   This document specifies a protocol useful in determining the current
>   status of a digital certificate without requiring CRLs.  Additional
>   mechanisms addressing PKIX operational requirements are specified in
>   separate documents. This document obsoletes RFC 2560 and RFC 6277.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-pinkas-rfc2560bis-00.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.
>
> <ftp://ftp.ietf.org/internet-drafts/draft-pinkas-rfc2560bis>
>
> A few explanations about the content of draft-ietf-pinkas-rfc2560bis-00.
>
> 25 changes are indicated at the beginning of the document.
> I will only mention a few of them:
>
> A - Explanations were missing to describe:
>
>      - the building of a request by an OCSP client,
>      - the processing of a request by an OCSP server,
>      - the building of a response  by an OCSP server, and
>      - the processing of a response by an OCSP client.
>
> These explanations have been added.
>
> B - Explanations were missing to address CA key rollover and OCSP
>     key rollover. These explanations have been added.
>
> C - Backwards compatibility has been addressed in the


--------------030608090006080504060707-- From peter.sylvester@edelweb.fr Fri Oct 12 07:43:11 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C9B21F8645 for ; Fri, 12 Oct 2012 07:43:11 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1F4ZIa8RVFe for ; Fri, 12 Oct 2012 07:43:10 -0700 (PDT) Received: from mx1.on-x.com (mx1.on-x.com [92.103.215.51]) by ietfa.amsl.com (Postfix) with ESMTP id 532AE21F8554 for ; Fri, 12 Oct 2012 07:43:10 -0700 (PDT) Received: from mx1.on-x.com (localhost [127.0.0.1]) by mx1.on-x.com (Postfix) with ESMTP id DDC795E146; Fri, 12 Oct 2012 16:42:33 +0200 (CEST) Received: from mail1.on-x.com (mail1.on-x.com [192.168.10.66]) by mx1.on-x.com (Postfix) with ESMTP id C4A945E133; Fri, 12 Oct 2012 16:42:33 +0200 (CEST) Received: from mail1.on-x.com (localhost [127.0.0.1]) by mail1.on-x.com (Postfix) with ESMTP id 5C3DC5E33C; Fri, 12 Oct 2012 16:42:15 +0200 (CEST) Received: from smtps.on-x.com (imaps.on-x.com [192.168.14.31]) by mail1.on-x.com (Postfix) with ESMTP id 46E365E2A8; Fri, 12 Oct 2012 16:42:15 +0200 (CEST) Received: from [192.168.18.180] (unknown [192.168.18.180]) by smtps.on-x.com (Postfix) with ESMTPSA id DF6745E043; Fri, 12 Oct 2012 16:44:23 +0200 (CEST) Message-ID: <50782C88.1010806@edelweb.fr> Date: Fri, 12 Oct 2012 16:43:20 +0200 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Denis Pinkas References: <5076FF4A.1090303@bull.net> <507709C3.2090200@edelweb.fr> <507826BB.8060304@bull.net> In-Reply-To: <507826BB.8060304@bull.net> Content-Type: multipart/alternative; boundary="------------080904050405080607000003" X-AV-Checked: ClamAV using ClamSMTP Cc: pkix@ietf.org Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 14:43:11 -0000 This is a multi-part message in MIME format. --------------080904050405080607000003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/12/2012 04:18 PM, Denis Pinkas wrote: > Peter, > > This may be costly since some PKI vendors are charging per CA, and > you also need to pay for the writing of a CP, the writing of a CPS, > the writing of conditions of use, > the change of the CA key when it will need to be changed, etc ... "Maybe". I think it is more efficient to convince vendors to change their policy than to play play cat and mice with them. Other vendors might sell as a function of the number of Issued certificates. Tell me the vendor, I'l might charge you two days of consulting. The CP/CPS are the same if this is just another incarnation of the same CA for performance reasons. If you have different rules depending on whatever thing, I am not sure that you would put this all together into one CP/CPS. N.B. CP/CPS is not a good distrinction between two documents. > > This extension is optional and thus CAs shall only use it after making > sure that the RPs which trust > them are able to support it. Doesn't sound very realistic to me. BTW: What is the difference to use a subjectAltName with the URI of the access location? No new extension. Peter --------------080904050405080607000003 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 10/12/2012 04:18 PM, Denis Pinkas wrote:
 Peter,

This may be costly since some PKI vendors are charging per CA, and
you also need to pay for the writing of a CP, the writing of a CPS, the writing of conditions of use,
the change of the CA key when it will need to be changed, etc ...

"Maybe". I think it is more efficient to convince vendors to change their policy
than to play play cat and mice with them.
Other vendors might sell as a function of the number of Issued certificates.
Tell me the vendor, I'l might charge you two days of consulting.

The CP/CPS are the same if this is just another incarnation of the same CA for
performance reasons.
If you have different rules depending on whatever thing, I am not sure
that you would put this all together into one CP/CPS.
N.B. CP/CPS is not a good distrinction between two documents.


This extension is optional and thus CAs shall only use it after making sure that the RPs which trust
them are able to support it.
Doesn't sound very realistic to me.

BTW: What is the difference to use a subjectAltName with the URI of the access location?
No new extension.
 
Peter
--------------080904050405080607000003-- From pritikin@cisco.com Fri Oct 12 12:22:20 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE0321F86E2 for ; Fri, 12 Oct 2012 12:22:20 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HM4KiM2YelZ6 for ; Fri, 12 Oct 2012 12:22:19 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 8928D21F86DD for ; Fri, 12 Oct 2012 12:22:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1116; q=dns/txt; s=iport; t=1350069739; x=1351279339; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=rT+gNX6bAaQkgtZnsmu8SB95fvYLYHGW5woJhB3r23Y=; b=OXrZS1RB/YTSwRddxL050DkIYiRqSwPFOm/lzr6VfpmYPJVh7ksSnG/n 3f3ej2MFGpnP0tCtLQa+RWl0uy7JLVm/9ubZvN9i8UJHHakC3wyWEXCYe lw4t29rp2BXWtvBe/3290Dxo0278HpIQdUfxVDZtqkk9dqP4v+qbLSmi/ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAxteFCtJV2Z/2dsb2JhbABFv2aBCIIgAQEBAwEBAQEPASc0BgUFCwIBCCIUECcLJQIEDgUIGodcBguaf59+BItSFIVJYAOkMoFrgm2BWj0 X-IronPort-AV: E=Sophos;i="4.80,577,1344211200"; d="scan'208";a="131090353" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 12 Oct 2012 19:22:19 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9CJMJNh024848 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Oct 2012 19:22:19 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.215]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.001; Fri, 12 Oct 2012 14:22:18 -0500 From: "Max Pritikin (pritikin)" To: Stefan Santesson Thread-Topic: [pkix] Request for agenda items Thread-Index: AQHNpz8tIBngmlZh8EmKhiX8UeVa55e2YxwA Date: Fri, 12 Oct 2012 19:22:18 +0000 Message-ID: <53EA47528D6ACF4486AA152F92C2B69825BFFA@xmb-rcd-x03.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.0.189] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19266.000 x-tm-as-result: No--42.326700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" Subject: Re: [pkix] Request for agenda items X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 19:22:20 -0000 Stefan,=20 We're working to close outstanding comments on the EST draft and will be pu= blishing our update soon. Its probably appropriate for us to provide a stat= us update and solicit any final comments as the draft heads toward the fina= l stages of the process. Please reserver some time on the schedule for that= .=20 Thanks, - max On Oct 10, 2012, at 5:29 PM, Stefan Santesson wrote: > All, >=20 > PKIX has been rescheduled in Atlanta for a 1 hour session on Thursday aft= ernoon. > This because the AD has limited the meeting to focus on finalising adopte= d documents before WG closure. >=20 > This means that we will not accept any presentations that is a request fo= r new work. >=20 > Presentations not focusing on current work will only be accepted if we ha= ve time over and if its inclusion in the meeting can be motivated. >=20 >=20 > Please send me any requests for agenda items ASAP. >=20 > /Stefan > =20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From housley@vigilsec.com Fri Oct 12 12:32:17 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A91821F8743 for ; Fri, 12 Oct 2012 12:32:17 -0700 (PDT) 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.198, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rLG4H6X2-mn for ; Fri, 12 Oct 2012 12:32:17 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id E17FF21F8624 for ; Fri, 12 Oct 2012 12:32:16 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id DD05C9A4004; Fri, 12 Oct 2012 15:32:23 -0400 (EDT) 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 V0LuqkU1Rk80; Fri, 12 Oct 2012 15:31:59 -0400 (EDT) Received: from [192.168.2.100] (pool-96-255-37-162.washdc.fios.verizon.net [96.255.37.162]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 8CCE19A4001; Fri, 12 Oct 2012 15:32:22 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <53EA47528D6ACF4486AA152F92C2B69825BFFA@xmb-rcd-x03.cisco.com> Date: Fri, 12 Oct 2012 15:32:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53EA47528D6ACF4486AA152F92C2B69825BFFA@xmb-rcd-x03.cisco.com> To: Max Pritikin (pritikin) X-Mailer: Apple Mail (2.1085) Cc: Stefan Santesson , "pkix@ietf.org" Subject: Re: [pkix] Request for agenda items X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 19:32:17 -0000 If this next draft will (hopefully) resolve the outstanding comments, I = would like to push for WG Last Call. That way, the face-to-face time in = Atlanta can be used to resolve any issues that surface during the WG = Last Call. Russ On Oct 12, 2012, at 3:22 PM, Max Pritikin (pritikin) wrote: > Stefan,=20 >=20 > We're working to close outstanding comments on the EST draft and will = be publishing our update soon. Its probably appropriate for us to = provide a status update and solicit any final comments as the draft = heads toward the final stages of the process. Please reserver some time = on the schedule for that.=20 >=20 > Thanks, >=20 > - max >=20 > On Oct 10, 2012, at 5:29 PM, Stefan Santesson = wrote: >=20 >> All, >>=20 >> PKIX has been rescheduled in Atlanta for a 1 hour session on Thursday = afternoon. >> This because the AD has limited the meeting to focus on finalising = adopted documents before WG closure. >>=20 >> This means that we will not accept any presentations that is a = request for new work. >>=20 >> Presentations not focusing on current work will only be accepted if = we have time over and if its inclusion in the meeting can be motivated. >>=20 >>=20 >> Please send me any requests for agenda items ASAP. >>=20 >> /Stefan >>=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 mrex@sap.com Fri Oct 12 16:24:35 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCF4C21F86B3 for ; Fri, 12 Oct 2012 16:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.2 X-Spam-Level: X-Spam-Status: No, score=-10.2 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwxX8XD84My7 for ; Fri, 12 Oct 2012 16:24:35 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id E8F1C21F86D0 for ; Fri, 12 Oct 2012 16:24:34 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q9CNOWGl008038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 13 Oct 2012 01:24:32 +0200 (MEST) In-Reply-To: <507826D4.2070901@bull.net> To: Denis Pinkas Date: Sat, 13 Oct 2012 01:24:31 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20121012232431.CA0A61A2C5@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: pkix Subject: Re: [pkix] New Version Notification for draft-pinkas-2560bis-ocsp-locationcheck-00.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 23:24:35 -0000 Denis Pinkas wrote: > > The point is that, when a RP gets "unknown" (with a correct signature > from the OCSP responder), it sure that it is cannot be a response from MitM. But that is completely useless information. The objective of OCSP/rfc2560 is not doing isolated OCSP for its own merits or fun. It is a means to an end: a possible method to check the revocation status of a certificate. When trying OCSP to perform a revocation check for a certificate it doesn't really matter how the operation fails, whether the DNS lookup of the hostname on the OCSP URL fails with NXDOMAIN or NODATA, whether the connect fails with "ICMP no route to host", the "administratively firewalled" ICMP, a connection timeout or connection failure (TCP RST), whether the response is an rfc2560 error message does not make any difference. All of these are fully equivalent useless answers to determine the status of a certificate. Doing digital signatures on anything will have exactly zero impact on the uselessness for the purpose of determining the status of the certificate. If the CA would operate a feature-enhanced OCSP server itself, that is capable of returned signed errors, and if the EE cert contained an extension that indicates this feature for the CA's own OCSP server, what would that mean for RPs that have local (plain-rfc2560) OCSP responders configured? -Martin > > ================================================================= > > As fas as I know, there are only three major status: "good", "revoked" > or "unknown". > > Error messages are: > > -- malformedRequest, > -- internalError, > -- tryLater, > -- sigRequired, > -- unauthorized. > > There is no response like: "the responder is not authorised to provide > information about the cert". > In the example, the RP gets "unknown" (witha correct signature from the > OCSP responder), whereas it would have received either "good" or > "revoked", if there had been no attack. > > ========================================================================== > > Why should a MitM try to obtain an unsigned(!!) "unauthorized" response > form your second OCSP responder AT ALL? The MitM could simply make up > that unsigned "unauthorized" response all by himself, and the OCSP > requestor has no means to distinguish an MitM from a real unauthorized > rfc2560 responder. > > > -Martin > > > > From stefan@aaa-sec.com Sun Oct 14 04:04:16 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF2D21F8491 for ; Sun, 14 Oct 2012 04:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.551 X-Spam-Level: X-Spam-Status: No, score=-101.551 tagged_above=-999 required=5 tests=[AWL=0.699, BAYES_00=-2.599, HELO_EQ_SE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWUzfcUeThzJ for ; Sun, 14 Oct 2012 04:04:16 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 0210D21F842E for ; Sun, 14 Oct 2012 04:04:15 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 87229223B9F9 for ; Sun, 14 Oct 2012 13:04:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id fuTKDJufqJNp for ; Sun, 14 Oct 2012 13:04:13 +0200 (CEST) Received: from s376.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 3EE2222142B2 for ; Sun, 14 Oct 2012 13:04:13 +0200 (CEST) Received: (qmail 37372 invoked from network); 14 Oct 2012 11:04:13 -0000 Received: from 81-232-51-61-no39.business.telia.com (HELO [192.168.0.108]) (stefan@fiddler.nu@[81.232.51.61]) (envelope-sender ) by s376.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 14 Oct 2012 11:04:13 -0000 User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Sun, 14 Oct 2012 13:04:16 +0200 From: Stefan Santesson To: "Max Pritikin (pritikin)" Message-ID: Thread-Topic: [pkix] Request for agenda items In-Reply-To: <53EA47528D6ACF4486AA152F92C2B69825BFFA@xmb-rcd-x03.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] Request for agenda items X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 11:04:16 -0000 Hi Max, I'll put you up for the agenda. How long time do you want? /Stefan On 10/12/12 9:22 PM, "Max Pritikin (pritikin)" wrote: >Stefan, > >We're working to close outstanding comments on the EST draft and will be >publishing our update soon. Its probably appropriate for us to provide a >status update and solicit any final comments as the draft heads toward >the final stages of the process. Please reserver some time on the >schedule for that. > >Thanks, > >- max > >On Oct 10, 2012, at 5:29 PM, Stefan Santesson wrote: > >> All, >> >> PKIX has been rescheduled in Atlanta for a 1 hour session on Thursday >>afternoon. >> This because the AD has limited the meeting to focus on finalising >>adopted documents before WG closure. >> >> This means that we will not accept any presentations that is a request >>for new work. >> >> Presentations not focusing on current work will only be accepted if we >>have time over and if its inclusion in the meeting can be motivated. >> >> >> Please send me any requests for agenda items ASAP. >> >> /Stefan >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > From stefan@aaa-sec.com Sun Oct 14 04:08:33 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 830C921F8459 for ; Sun, 14 Oct 2012 04:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.783 X-Spam-Level: X-Spam-Status: No, score=-101.783 tagged_above=-999 required=5 tests=[AWL=0.466, BAYES_00=-2.599, HELO_EQ_SE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNIpbssoaJH6 for ; Sun, 14 Oct 2012 04:08:33 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id E2DFE21F8433 for ; Sun, 14 Oct 2012 04:08:32 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id B4CDC2279856 for ; Sun, 14 Oct 2012 13:07:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id PGuwNPpomVmh for ; Sun, 14 Oct 2012 13:07:36 +0200 (CEST) Received: from s326.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 6A8842279855 for ; Sun, 14 Oct 2012 13:07:36 +0200 (CEST) Received: (qmail 92146 invoked from network); 14 Oct 2012 11:07:36 -0000 Received: from 81-232-51-61-no39.business.telia.com (HELO [192.168.0.108]) (stefan@fiddler.nu@[81.232.51.61]) (envelope-sender ) by s326.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 14 Oct 2012 11:07:36 -0000 User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Sun, 14 Oct 2012 13:07:39 +0200 From: Stefan Santesson To: Russ Housley , "Max Pritikin (pritikin)" Message-ID: Thread-Topic: [pkix] Request for agenda items In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "pkix@ietf.org" Subject: Re: [pkix] Request for agenda items X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 11:08:33 -0000 I think that is a good call. Max, do you think the next draft is WGLC ready, and when will it be submitted. If it's ready, I will initiate a WGLC once published. /Stefan On 10/12/12 9:32 PM, "Russ Housley" wrote: >If this next draft will (hopefully) resolve the outstanding comments, I >would like to push for WG Last Call. That way, the face-to-face time in >Atlanta can be used to resolve any issues that surface during the WG Last >Call. > >Russ > > >On Oct 12, 2012, at 3:22 PM, Max Pritikin (pritikin) wrote: > >> Stefan, >> >> We're working to close outstanding comments on the EST draft and will >>be publishing our update soon. Its probably appropriate for us to >>provide a status update and solicit any final comments as the draft >>heads toward the final stages of the process. Please reserver some time >>on the schedule for that. >> >> Thanks, >> >> - max >> >> On Oct 10, 2012, at 5:29 PM, Stefan Santesson >>wrote: >> >>> All, >>> >>> PKIX has been rescheduled in Atlanta for a 1 hour session on Thursday >>>afternoon. >>> This because the AD has limited the meeting to focus on finalising >>>adopted documents before WG closure. >>> >>> This means that we will not accept any presentations that is a request >>>for new work. >>> >>> Presentations not focusing on current work will only be accepted if we >>>have time over and if its inclusion in the meeting can be motivated. >>> >>> >>> Please send me any requests for agenda items ASAP. >>> >>> /Stefan >>> >>> _______________________________________________ >>> 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 internet-drafts@ietf.org Sun Oct 14 16:24:16 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F40BA21F84EA; Sun, 14 Oct 2012 16:24:15 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EA9jWB71xlMS; Sun, 14 Oct 2012 16:24:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5595221F8480; Sun, 14 Oct 2012 16:24:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121014232415.11613.42694.idtracker@ietfa.amsl.com> Date: Sun, 14 Oct 2012 16:24:15 -0700 Cc: pkix@ietf.org Subject: [pkix] I-D Action: draft-ietf-pkix-rfc2560bis-06.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 23:24:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Public-Key Infrastructure (X.509) Working= Group of the IETF. Title : X.509 Internet Public Key Infrastructure Online Certific= ate Status Protocol - OCSP Author(s) : Stefan Santesson Michael Myers Rich Ankney Ambarish Malpani Slava Galperin Carlisle Adams Filename : draft-ietf-pkix-rfc2560bis-06.txt Pages : 38 Date : 2012-10-14 Abstract: This document specifies a protocol useful in determining the current status of a digital certificate without requiring CRLs. Additional mechanisms addressing PKIX operational requirements are specified in separate documents. This document obsoletes RFC 2560 and RFC 6277. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pkix-rfc2560bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pkix-rfc2560bis-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pkix-rfc2560bis-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From stefan@aaa-sec.com Sun Oct 14 16:49:36 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0717F21F844C for ; Sun, 14 Oct 2012 16:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, HELO_EQ_SE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrA+UlGfw+r3 for ; Sun, 14 Oct 2012 16:49:35 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1EB21F8447 for ; Sun, 14 Oct 2012 16:49:34 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id D0DD222459E8 for ; Mon, 15 Oct 2012 01:49:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id y9M04-ktUM69 for ; Mon, 15 Oct 2012 01:49:31 +0200 (CEST) Received: from s328.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 7E5A82242CB4 for ; Mon, 15 Oct 2012 01:49:31 +0200 (CEST) Received: (qmail 51270 invoked from network); 14 Oct 2012 23:49:31 -0000 Received: from 81-232-51-61-no39.business.telia.com (HELO [192.168.0.108]) (stefan@fiddler.nu@[81.232.51.61]) (envelope-sender ) by s328.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 14 Oct 2012 23:49:31 -0000 User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Mon, 15 Oct 2012 01:49:29 +0200 From: Stefan Santesson To: Message-ID: Thread-Topic: New draft-ietf-pkix-rfc2560bis-06 In-Reply-To: <20120807195800.D89DF1A12E@ld9781.wdf.sap.corp> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 23:49:36 -0000 All, I have just posted an update of rfc2560bis (OCSP update) after carefully reviewing all comments on the list. Some notes about the update: - Added the previous OCSP editors with updated affiliations. - Added some calcifications on ResponderID as suggested by Simon Josefsson. - Updated the clarifications on Authorized responders. The requirements have not changed. I just tried to improve the text. - Updated a clarification on the "revoked" state to be the preferred response if a certificate is known by the responder to never have been issued. - Some minor editorial nits. Regarding backwards compatibility I mean that none of the clarifications changes RFC 2560. On Authorized responders it has always been the case that a responder certificate issued with the same key as was used to issue the certificate being checked for revocation, represents a valid Authorized responder. There has never been an explicit requirement to support key rollover and key rollover support has never been in the "spirit" of the original standard as it clearly attempted to provide direct cryptographic binding between the responder and the CA. On the "revoked" state, the old spec did not even consider the case of a certificate being requested where the OCSP responder knows that the certificate was never issued. It is clearly counterproductive to respond good when a certificate is known to be bad. A responder must pick one response and picking "revoked" breaks nothing, but has the desired effect, that is, to prevent the certificate from being accepted. The current text makes clear that there is no mechanism in the current standard by which a client can know how a responder will respond to a request for a not issued certificate. It simply recommend a known to be bad certificate to result in "revoked" in order to prevent damage as far as possible. It also opens for definition of new extensions through which such knowledge could be obtained. The current updates also clearly opens a path for the CAB forum efforts to define a suitable solution for server certificates. I have not, even thug suggested, added any requirements on what clients should do with the checked cert as a result of a particular response. I don't believe such requirements are suitable as it is policy and not protocol. We have no right to demand that all systems MUST reject any certificate for any reason as they may have a local policy that overrules the OCSP response. This protocol only provides information about the cert status, it does not mandate validation policy. I have not included any of the substantial changes i the Pinkas draft. I want to wait for a list of motivation for each change before including any of them. So there changed may be up for debate before this draft is ready for WGLC. /Stefan From internet-drafts@ietf.org Sun Oct 14 19:34:25 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9581521F851A; Sun, 14 Oct 2012 19:34:25 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 188fiDhTq8do; Sun, 14 Oct 2012 19:34:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2634D21F853E; Sun, 14 Oct 2012 19:34:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121015023425.27492.34330.idtracker@ietfa.amsl.com> Date: Sun, 14 Oct 2012 19:34:25 -0700 Cc: pkix@ietf.org Subject: [pkix] I-D Action: draft-ietf-pkix-rfc5280-clarifications-10.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 02:34:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Public-Key Infrastructure (X.509) Working= Group of the IETF. Title : Updates to the Internet X.509 Public Key Infrastructure = Certificate and Certificate Revocation List (CRL) Profile Author(s) : Peter E. Yee Filename : draft-ietf-pkix-rfc5280-clarifications-10.txt Pages : 7 Date : 2012-10-14 Abstract: This document updates RFC 5280, the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. This document changes the set of acceptable encoding methods for the explicitText field of the user notice policy qualifier and clarifies the rules for converting internationalized domain name labels to ASCII. This document also provides some clarifications on the use of self-signed certificates, trust anchors, and some updated security considerations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pkix-rfc5280-clarifications There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pkix-rfc5280-clarifications-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pkix-rfc5280-clarifications-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From peter@akayla.com Sun Oct 14 19:36:54 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D97921F8568 for ; Sun, 14 Oct 2012 19:36:54 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OuJLrxP8pyoG for ; Sun, 14 Oct 2012 19:36:53 -0700 (PDT) Received: from p3plsmtpa06-02.prod.phx3.secureserver.net (p3plsmtpa06-02.prod.phx3.secureserver.net [173.201.192.103]) by ietfa.amsl.com (Postfix) with ESMTP id 811EC21F8559 for ; Sun, 14 Oct 2012 19:36:53 -0700 (PDT) Received: from spectre ([173.8.184.78]) by p3plsmtpa06-02.prod.phx3.secureserver.net with id BEcs1k0031huGat01Ecso0; Sun, 14 Oct 2012 19:36:52 -0700 From: "Peter Yee" To: "'Stephen Kent'" , "'pkix'" References: <50773DF8.3080706@bbn.com> In-Reply-To: <50773DF8.3080706@bbn.com> Date: Sun, 14 Oct 2012 19:36:53 -0700 Message-ID: <029801cdaa7d$f024a620$d06df260$@akayla.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHKouA5QdjEgGVEMH0B8smZdMSCvpe/tcNA Content-Language: en-us Subject: Re: [pkix] 5280bis X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 02:36:54 -0000 Version -10 has been uploaded and the sole change (outside of the name/dates) is the removal of the contentious text. Please let me know if there are any other changes that need to be made. I'm hoping we're sufficiently controversy free so that we can move the document forward. Thanks. -Peter -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Stephen Kent Sent: Thursday, October 11, 2012 2:45 PM To: pkix Subject: [pkix] 5280bis The PKIX list has not demonstrated consensus for the CRL entry extension text I suggested, or any other, since Russ sent his message on this topic on 10/3, over a week ago. Consistent with Russ's direction, I have asked Peter Yee to remove the Section 4 text from 5280bis and publish version -10. I have begun preparation of the IESG report for the redacted version of the doc. Steve _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From turners@ieca.com Tue Oct 16 16:29:26 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFF91F0CA9 for ; Tue, 16 Oct 2012 16:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.349 X-Spam-Level: X-Spam-Status: No, score=-102.349 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oq5e0vxE5OwX for ; Tue, 16 Oct 2012 16:29:25 -0700 (PDT) Received: from gateway12.websitewelcome.com (gateway12.websitewelcome.com [69.56.144.7]) by ietfa.amsl.com (Postfix) with ESMTP id 76AF41F0423 for ; Tue, 16 Oct 2012 16:29:25 -0700 (PDT) Received: by gateway12.websitewelcome.com (Postfix, from userid 5007) id 85BA6EFA9A73C; Tue, 16 Oct 2012 18:29:29 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway12.websitewelcome.com (Postfix) with ESMTP id 78906EFA9A71C for ; Tue, 16 Oct 2012 18:29:29 -0500 (CDT) Received: from [96.241.97.104] (port=65066 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TOGZg-0005PE-QK for pkix@ietf.org; Tue, 16 Oct 2012 18:29:24 -0500 Message-ID: <507DEDD4.5070409@ieca.com> Date: Tue, 16 Oct 2012 19:29:24 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: pkix@ietf.org References: <20121015023425.27492.34330.idtracker@ietfa.amsl.com> In-Reply-To: <20121015023425.27492.34330.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [96.241.97.104]:65066 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: Re: [pkix] I-D Action: draft-ietf-pkix-rfc5280-clarifications-10.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 23:29:26 -0000 So that nobody is surprised: I've placed this draft on the 10/25 IESG telechat. The -08 version and the -10 version are technically identical. -08 went through IETF LC so I'm not planning on issuing another IETF LC for -10. spt On 10/14/12 10:34 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. > > Title : Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile > Author(s) : Peter E. Yee > Filename : draft-ietf-pkix-rfc5280-clarifications-10.txt > Pages : 7 > Date : 2012-10-14 > > Abstract: > This document updates RFC 5280, the Internet X.509 Public Key > Infrastructure Certificate and Certificate Revocation List (CRL) > Profile. This document changes the set of acceptable encoding > methods for the explicitText field of the user notice policy > qualifier and clarifies the rules for converting internationalized > domain name labels to ASCII. This document also provides some > clarifications on the use of self-signed certificates, trust anchors, > and some updated security considerations. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-pkix-rfc5280-clarifications > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-pkix-rfc5280-clarifications-10 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-pkix-rfc5280-clarifications-10 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From hallam@gmail.com Thu Oct 18 08:26:56 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D12121F882E for ; Thu, 18 Oct 2012 08:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.93 X-Spam-Level: X-Spam-Status: No, score=-3.93 tagged_above=-999 required=5 tests=[AWL=-0.332, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvnXgwjb3ae0 for ; Thu, 18 Oct 2012 08:26:55 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 664B321F8829 for ; Thu, 18 Oct 2012 08:26:55 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so10536863oag.31 for ; Thu, 18 Oct 2012 08:26:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jDcThP9n2mpSdIFm22infYwtDUHXVuzoyJxHEymixCE=; b=w6IXbZ3nhFSUtSEuI5akGxOkKo28t1A3gO4/AafJ6Q0W2sH9ZOSTTQjRRSo2RScRvj kjlhalKXSStcPSJEx4Tr9PvFQdYkN0YITL63cM+vgsiBRhxUpLVkt8PW2GJukyBCYMM8 nJDDGPqzvD6GqG8mK9H0C+ln69i0bKu2xEuQ0tp05F93zUOHi2ijld8MpCrF/Wfe137P phL9D4x3gKfEsS5ibvFJEw5GC3ssPoXprCQYTzj7YL3czReo9errKGRpbWIS+YI2+aoN YD2Kv+dvhlchrmGOJlc1z1OJm3iTqNTQymKRtI5Pk+gN+dLBFywaQ2VfRZixIsmsRqjK RgvQ== MIME-Version: 1.0 Received: by 10.60.172.177 with SMTP id bd17mr2624622oec.101.1350574013162; Thu, 18 Oct 2012 08:26:53 -0700 (PDT) Received: by 10.76.27.103 with HTTP; Thu, 18 Oct 2012 08:26:52 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E114FD99FC60@WSMSG3153V.srv.dir.telstra.com> References: <20121007023227.19777.9236.idtracker@ietfa.amsl.com> <255B9BB34FB7D647A506DC292726F6E114FD99FC60@WSMSG3153V.srv.dir.telstra.com> Date: Thu, 18 Oct 2012 11:26:52 -0400 Message-ID: From: Phillip Hallam-Baker To: "Manger, James H" Content-Type: multipart/alternative; boundary=bcaec54ee5784c265404cc570454 Cc: "pkix@ietf.org" Subject: Re: [pkix] I-D Action: draft-ietf-pkix-caa-14.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 15:26:56 -0000 --bcaec54ee5784c265404cc570454 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Sun, Oct 7, 2012 at 9:27 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > Comments on draft-ietf-pkix-caa-14 > > > 3. The CAA RR type > and tags are listed, but not . > Fixed > > 5.2. CAA issue Property: ABNF typos > is missing a ']'; > has extraneous '/'; > would be better just in , not also in ; > includes so is ambiguous. > > WRONG: > Property =3D space [domain] space [";" space * (parameter space) > parameter =3D / space tag "=3D" value > value =3D *VCHAR | DQUOTE *(%x20-21 / %x23-7E) DQUOTE > > RIGHT: > Property =3D space [domain] space [";" *(space parameter) space] > parameter =3D tag "=3D" value > value =3D *VCHAR > > Adding a quoting mechanism for allows only one extra character > SPACE. It's not worth it. A quoting mechanism would also interact awkward= ly > with the (under-specified) presentation format > Fixed > > 5.1.1. Canonical Presentation Format > The 'Value' part of a CAA record is specified as a "sequence of octets". > The presentation format is specified as "the US-ASCII text Encoding of th= e > value field". I=92m not sure where that "text Encoding" is defined, perha= ps > RFC1035 "Domain Implementation and Specification" section 5.1. Master Fil= es > Format. Does it say always-wrap-in-double-quotes? > No, it says that the quotes are optional unless there is a space in the field: http://www.ietf.org/rfc/rfc1035.txt is expressed in one or two ways: as a contiguous set of characters without interior spaces, or as a string beginning with a " and ending with a ". Inside a " delimited string any character can occur, except for a " itself, which must be quoted using \ (back slash). Is the <character-string> encoding of the value field as specified in section 5.1. > 8.1. Normative References > RFC1034 and RFC1035 appear twice: once as themselves; then again as STD13 > This is intentional. STD13 is not simply the concatenation of RFC1034 and 1035, it tracks the current status of the standard. The reference to STD13 is made in the definitions because that is the standard. The references to 1035 are made in the context of describing the peculiar bit numbering convention and the specific description of the zone file. In these cases it seems better to follow the convention of choosing one specific edition of the document rather than the standard. --=20 Website: http://hallambaker.com/ --bcaec54ee5784c265404cc570454 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Sun, Oct 7, 2012 at 9:27 PM, Manger, = James H <James.H.Manger@team.telstra.com> wrot= e:
Comments on draft-ietf-pkix-caa-14


3. The CAA RR type
<issue> and <iodef> tags are listed, but not <issuewild>.=

Fixed
=A0

5.2. CAA issue Property: ABNF typos
=A0 <Property> is missing a ']';
=A0 <parameter> has extraneous '/';
=A0 <space> would be better just in <Property>, not also in <= ;parameter>;
=A0 <VCHAR> includes <DQUOTE> so <value> is ambiguous.
WRONG:
=A0 Property =3D space [domain] space [";" space * (parameter spa= ce)
=A0 parameter =3D =A0/ space tag "=3D" value
=A0 value =3D *VCHAR | DQUOTE *(%x20-21 / %x23-7E) DQUOTE

RIGHT:
=A0 Property =3D space [domain] space [";" *(space parameter) spa= ce]
=A0 parameter =3D tag "=3D" value
=A0 value =3D *VCHAR

Adding a quoting mechanism for <value> allows only one extra characte= r SPACE. It's not worth it. A quoting mechanism would also interact awk= wardly with the (under-specified) presentation format

Fixed

=A0

5.1.1. Canonical Presentation Format
The 'Value' part of a CAA record is specified as a "sequence o= f octets". The presentation format is specified as "the US-ASCII = text Encoding of the value field". I=92m not sure where that "tex= t Encoding" is defined, perhaps RFC1035 "Domain Implementation an= d Specification" section 5.1. Master Files Format. Does it say always-= wrap-in-double-quotes?

No, it says that the quotes are optional u= nless there is a space in the field:

http://www.ietf.org/rfc/rfc1035.txt<= /div> 
<character=
-string> is expressed in one or two ways: as a contiguous set
of characters without interior spaces, or as a string beginning with a &quo=
t;
and ending with a ".  Inside a " delimited string any character c=
an
occur, except for a " itself, which must be quoted using \ (back slash=
).

=A0 =A0 =A0 =A0 =A0 =A0 =A0 <t ha= ngText=3D"Value:">
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I= s the &lt;character-string&gt; encoding of the value field as speci= fied in=A0
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <xref target=3D"RFC1035"/= > section 5.1.
=A0
8.1. Normative References
RFC1034 and RFC1035 appear twice: once as themselves; then again as STD13

This is intentional.

STD13 is not simply the concatenation of RFC1034 and 1035, it tracks = the current status of the standard. The reference to STD13 is made in the d= efinitions because that is the standard.

The references to 1035 are made in the context of descr= ibing the peculiar bit numbering convention and the specific description of= the zone file. In these cases it seems better to follow the convention of = choosing one specific edition of the document rather than the standard.


--
Website: http://hallambaker.com/

--bcaec54ee5784c265404cc570454-- From internet-drafts@ietf.org Thu Oct 18 16:26:36 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C81D21F85BB; Thu, 18 Oct 2012 16:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHPSOHroUQyg; Thu, 18 Oct 2012 16:26:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC7B21F85BF; Thu, 18 Oct 2012 16:26:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121018232636.21608.12142.idtracker@ietfa.amsl.com> Date: Thu, 18 Oct 2012 16:26:36 -0700 Cc: pkix@ietf.org Subject: [pkix] I-D Action: draft-ietf-pkix-caa-15.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 23:26:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Public-Key Infrastructure (X.509) Working= Group of the IETF. Title : DNS Certification Authority Authorization (CAA) Resource= Record Author(s) : Phillip Hallam-Baker Rob Stradling Filename : draft-ietf-pkix-caa-15.txt Pages : 18 Date : 2012-10-18 Abstract: The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain. CAA resource records allow a public Certification Authority to implement additional controls to reduce the risk of unintended certificate mis-issue. This document defines the syntax of the CAA record and rules for processing CAA records by certificate issuers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pkix-caa There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pkix-caa-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pkix-caa-15 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From stefan@aaa-sec.com Fri Oct 19 02:22:52 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 161EE21F8684 for ; Fri, 19 Oct 2012 02:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.97 X-Spam-Level: X-Spam-Status: No, score=-101.97 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, HELO_EQ_SE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UmIu2swdWeuf for ; Fri, 19 Oct 2012 02:22:51 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 7469521F8668 for ; Fri, 19 Oct 2012 02:22:50 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 8197422BB90B for ; Fri, 19 Oct 2012 11:22:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hu8vxgH2yCZL for ; Fri, 19 Oct 2012 11:22:47 +0200 (CEST) Received: from s376.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id E398B22BC590 for ; Fri, 19 Oct 2012 11:21:28 +0200 (CEST) Received: (qmail 93615 invoked from network); 19 Oct 2012 09:21:28 -0000 Received: from 81-232-51-61-no39.business.telia.com (HELO [192.168.0.108]) (stefan@fiddler.nu@[81.232.51.61]) (envelope-sender ) by s376.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 19 Oct 2012 09:21:28 -0000 User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Fri, 19 Oct 2012 11:21:26 +0200 From: Stefan Santesson To: Peter Yee , 'Stephen Kent' , 'pkix' Message-ID: Thread-Topic: [pkix] 5280bis In-Reply-To: <029801cdaa7d$f024a620$d06df260$@akayla.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [pkix] 5280bis X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 09:22:52 -0000 This is too late for the poll, but a question came to my mind this week after an ETSI meeting, so I will just post it. The current text requires me to reject a CRL as source of revocation information if ANY entry includes an unrecognised extension. So thinking as an implementer, I just wander how this works in practice. Consider I have a 100 MB CRL. I then have to go through each entry and determine if any of them have an unrecognised extension before I use it. Just going to the entry of interest is not enough, since another entry may have an unrecognised extension. Is this how implementations work today? /Stefan On 10/15/12 4:36 AM, "Peter Yee" wrote: >Version -10 has been uploaded and the sole change (outside of the >name/dates) is the removal of the contentious text. Please let me know if >there are any other changes that need to be made. I'm hoping we're >sufficiently controversy free so that we can move the document forward. > >Thanks. > -Peter > >-----Original Message----- >From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >Stephen Kent >Sent: Thursday, October 11, 2012 2:45 PM >To: pkix >Subject: [pkix] 5280bis > >The PKIX list has not demonstrated consensus for the CRL entry extension >text I suggested, or any other, since Russ sent his message on this topic >on >10/3, over a week ago. > >Consistent with Russ's direction, I have asked Peter Yee to remove the >Section 4 text from 5280bis and publish version -10. > >I have begun preparation of the IESG report for the redacted version of >the >doc. > >Steve >_______________________________________________ >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 prvs=063967d583=rybar@nbusr.sk Fri Oct 19 04:07:51 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAABA21F868D for ; Fri, 19 Oct 2012 04:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.694 X-Spam-Level: X-Spam-Status: No, score=-0.694 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrQpNlq3+See for ; Fri, 19 Oct 2012 04:07:51 -0700 (PDT) Received: from mail.nbusr.sk (mail.nbusr.sk [84.245.65.227]) by ietfa.amsl.com (Postfix) with ESMTP id BBEC821F861E for ; Fri, 19 Oct 2012 04:07:50 -0700 (PDT) Message-Id: <201210191107.q9JB7m62045167@mail.nbusr.sk> From: "Peter Rybar" To: "'Stefan Santesson'" , pkix@ietf.org Date: Fri, 19 Oct 2012 13:07:40 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: Thread-Index: Ac2qZpjE3oQRVEnhQPqpiFLAJmN0cwDePJyg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-NAI-Spam-Flag: NO X-NAI-Spam-Level: *** X-NAI-Spam-Threshold: 6 X-NAI-Spam-Score: 3.5 X-NAI-Spam-Version: 2.2.0.9309 : core <4375> : streams <841242> : uri <1247039> Cc: 'Peter Rybar' Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 11:07:51 -0000 Stefan, I have a question about the present OCSP RFC and at the end of the mail = about the new situation which will happen according to your new = proposal. The presence of the positive statement in OCSP response is important for = electronic signature validations, especially for an expired certificate. = Positive statement is the hash value of a certificate whose status is = provided in OCSP response. =20 Electronic signature validation is usually about the signatures created = in the past and validated now, when the certificate is expired. When the certificate expires then revocation is usually removed from CRL = and the revoked certificate can be provided as "good" in OCSP response.=20 Is it acceptable? I think not. According to your new draft there is not defined a value of = revocationTime. RFC must also define the value of revocationTime when the certificate = which was never issued is as "revoked". http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pkix-rfc2560bis-06 Have you also covered the situation when the certificate is expired, = REMOVED FROM CRL and will be provided as revoked with incorrect = revocationTime e.g. with the value before or after the revocationTime = which was present in the removed record from CRL? Because according to sentence in your draft ""revoked" - This state = SHOULD also be returned if the responder knows that the requested = certificate has never been issued." the following situation can happen: = when certificate is removed from CRL after expiration and CA/OCSP = responder is responsible for this certificate but have not record about = expired certificate and for that reason it is identified as "never been = issued". ... revoked [1] IMPLICIT RevokedInfo, ... RevokedInfo ::=3D SEQUENCE { revocationTime GeneralizedTime, revocationReason [0] EXPLICIT CRLReason OPTIONAL } As you have mentioned in the mail: "On the "revoked" state, the old spec did not even consider the case of = a certificate being requested where the OCSP responder knows that the = certificate was never issued." "It simply recommend a known to be bad certificate to result in "revoked" in order to prevent damage as far as possible. It also = opens for definition of new extensions through which such knowledge could be obtained." Peter Rybar National Security Authority Information Security and Electronic Signature Department Budatinska 30, 850 07 Bratislava 57, Slovak Republic e-mail: peter.rybar@nbusr.sk e-mail: peterryb@gmail.com -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of = Stefan Santesson Sent: Monday, October 15, 2012 1:49 AM To: pkix@ietf.org Subject: [pkix] New draft-ietf-pkix-rfc2560bis-06 All, I have just posted an update of rfc2560bis (OCSP update) after carefully reviewing all comments on the list. Some notes about the update: - Added the previous OCSP editors with updated affiliations. - Added some calcifications on ResponderID as suggested by Simon = Josefsson. - Updated the clarifications on Authorized responders. The requirements have not changed. I just tried to improve the text. - Updated a clarification on the "revoked" state to be the preferred response if a certificate is known by the responder to never have been issued. - Some minor editorial nits. Regarding backwards compatibility I mean that none of the clarifications changes RFC 2560. On Authorized responders it has always been the case that a responder certificate issued with the same key as was used to issue the = certificate being checked for revocation, represents a valid Authorized responder. There has never been an explicit requirement to support key rollover and key rollover support has never been in the "spirit" of the original standard as it clearly attempted to provide direct cryptographic binding between the responder and the CA. On the "revoked" state, the old spec did not even consider the case of a certificate being requested where the OCSP responder knows that the certificate was never issued. It is clearly counterproductive to respond good when a certificate is known to be bad. A responder must pick one response and picking "revoked" breaks nothing, but has the desired = effect, that is, to prevent the certificate from being accepted. The current = text makes clear that there is no mechanism in the current standard by which = a client can know how a responder will respond to a request for a not = issued certificate. It simply recommend a known to be bad certificate to result in "revoked" in order to prevent damage as far as possible. It also = opens for definition of new extensions through which such knowledge could be obtained. The current updates also clearly opens a path for the CAB forum efforts = to define a suitable solution for server certificates. I have not, even thug suggested, added any requirements on what clients should do with the checked cert as a result of a particular response. I don't believe such requirements are suitable as it is policy and not protocol. We have no right to demand that all systems MUST reject any certificate for any reason as they may have a local policy that = overrules the OCSP response. This protocol only provides information about the = cert status, it does not mandate validation policy. I have not included any of the substantial changes i the Pinkas draft. I want to wait for a list of motivation for each change before including = any of them. So there changed may be up for debate before this draft is = ready for WGLC. /Stefan _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From simon@tardell.se Fri Oct 19 04:57:01 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B3F21F8630 for ; Fri, 19 Oct 2012 04:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8T01uBd-WMx for ; Fri, 19 Oct 2012 04:57:00 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id C538321F8594 for ; Fri, 19 Oct 2012 04:56:59 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so290675lam.31 for ; Fri, 19 Oct 2012 04:56:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=6gdZQEL40jLi6j5iwaSXxCADeAAUduuEvPeDAY+CXAo=; b=O+TxWbsaFA6bozoZEC1QVcDSb3fORvMxHCjcYrEZQCDzoGQKSjlIDtA11fwvkl1AZl BFV6Pype8Vi/giu5z2n+bAknzWTAWITnEfDcLqNRgtqafsgU/qL9Up+SWM8lm4VX7VwR 4lU8LrL9VGJ5qphQjg8GDtilSImmN0XM9/5HEx/sE0WKMsSWGbJaPRDfwMvUGJEvu8L5 0uHE44ANNK7Pb15P0LF7lXlxaiBSx08UlDHsQX+YT+FNfAamUQPc81/sMOn3z2/Mnheb V8UmwmOZHTm8f9DG43w59nmdKCeuDeM0+cqh/NlLvtgFAldajiouS1U446sHgbUMA0rJ /YrA== MIME-Version: 1.0 Received: by 10.152.108.66 with SMTP id hi2mr1003791lab.11.1350647818192; Fri, 19 Oct 2012 04:56:58 -0700 (PDT) Received: by 10.112.151.71 with HTTP; Fri, 19 Oct 2012 04:56:58 -0700 (PDT) In-Reply-To: <201210191107.q9JB7m62045167@mail.nbusr.sk> References: <201210191107.q9JB7m62045167@mail.nbusr.sk> Date: Fri, 19 Oct 2012 13:56:58 +0200 Message-ID: From: Simon Tardell To: Peter Rybar Content-Type: multipart/alternative; boundary=bcaec54eecc86b866904cc683317 X-Gm-Message-State: ALoCoQmY6MxU/jTKuBwx9yWjbfSgq9tWRSU1P/xwy9zIAf2LCtAw/j09lnArIMIxERdXpX++dsGf Cc: Peter Rybar , Stefan Santesson , pkix@ietf.org Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 11:57:01 -0000 --bcaec54eecc86b866904cc683317 Content-Type: text/plain; charset=ISO-8859-1 It seems to me that if you remove information about the revocation status for expired certificates you can't be expected to be able to answer the question of whether it was ever issued. Or put in reverse: If you keep track of all certificates ever issued, then it is reasonable to assume that you keep track of all revocations of the same. Also: "Electronic signature validation is usually about the signatures created in the past and validated now, when the certificate is expired." Well, yes, sort of. You can only be sure to validate a signature at the moment of production. At any later point in time the signature key may be compromised, or the algorithms involved may have become to weak. (In which case the time of revocation in the OCSP response is worth nothing to you). The risk increases as time passes. And of course, the revocation information may not be kept around after the expiry of the certificate. That's why you should validate signatures as soon as possible. If you need to ascertain that a signature was valid at a later time, you have to trust your system that it performed the validation at the time it first received the signature. That trust must be established through some kind of mix of policies and technical measures (such as timestamping). Simon Tardell, Technology Nexus. On Fri, Oct 19, 2012 at 1:07 PM, Peter Rybar wrote: > Stefan, > > I have a question about the present OCSP RFC and at the end of the mail > about the new situation which will happen according to your new proposal. > > The presence of the positive statement in OCSP response is important for > electronic signature validations, especially for an expired certificate. > Positive statement is the hash value of a certificate whose status is > provided in OCSP response. > > Electronic signature validation is usually about the signatures created in > the past and validated now, when the certificate is expired. > > When the certificate expires then revocation is usually removed from CRL > and the revoked certificate can be provided as "good" in OCSP response. > Is it acceptable? I think not. > > According to your new draft there is not defined a value of revocationTime. > RFC must also define the value of revocationTime when the certificate > which was never issued is as "revoked". > http://www.ietf.org/rfcdiff?url2=draft-ietf-pkix-rfc2560bis-06 > > Have you also covered the situation when the certificate is expired, > REMOVED FROM CRL and will be provided as revoked with incorrect > revocationTime e.g. with the value before or after the revocationTime which > was present in the removed record from CRL? > Because according to sentence in your draft ""revoked" - This state SHOULD > also be returned if the responder knows that the requested certificate has > never been issued." the following situation can happen: when certificate is > removed from CRL after expiration and CA/OCSP responder is responsible for > this certificate but have not record about expired certificate and for that > reason it is identified as "never been issued". > > ... > revoked [1] IMPLICIT RevokedInfo, > ... > > RevokedInfo ::= SEQUENCE { > revocationTime GeneralizedTime, > revocationReason [0] EXPLICIT CRLReason OPTIONAL } > > As you have mentioned in the mail: > "On the "revoked" state, the old spec did not even consider the case of a > certificate being requested where the OCSP responder knows that the > certificate was never issued." > "It simply recommend a known to be bad certificate to result > in "revoked" in order to prevent damage as far as possible. It also opens > for definition of new extensions through which such knowledge could be > obtained." > > Peter Rybar > National Security Authority > Information Security and Electronic Signature Department > Budatinska 30, 850 07 Bratislava 57, Slovak Republic > e-mail: peter.rybar@nbusr.sk > e-mail: peterryb@gmail.com > > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > Stefan Santesson > Sent: Monday, October 15, 2012 1:49 AM > To: pkix@ietf.org > Subject: [pkix] New draft-ietf-pkix-rfc2560bis-06 > > All, > > I have just posted an update of rfc2560bis (OCSP update) after carefully > reviewing all comments on the list. > > Some notes about the update: > > - Added the previous OCSP editors with updated affiliations. > - Added some calcifications on ResponderID as suggested by Simon Josefsson. > - Updated the clarifications on Authorized responders. The requirements > have not changed. I just tried to improve the text. > - Updated a clarification on the "revoked" state to be the preferred > response if a certificate is known by the responder to never have been > issued. > - Some minor editorial nits. > > > Regarding backwards compatibility I mean that none of the clarifications > changes RFC 2560. > > On Authorized responders it has always been the case that a responder > certificate issued with the same key as was used to issue the certificate > being checked for revocation, represents a valid Authorized responder. > There has never been an explicit requirement to support key rollover and > key rollover support has never been in the "spirit" of the original > standard as it clearly attempted to provide direct cryptographic binding > between the responder and the CA. > > On the "revoked" state, the old spec did not even consider the case of a > certificate being requested where the OCSP responder knows that the > certificate was never issued. It is clearly counterproductive to respond > good when a certificate is known to be bad. A responder must pick one > response and picking "revoked" breaks nothing, but has the desired effect, > that is, to prevent the certificate from being accepted. The current text > makes clear that there is no mechanism in the current standard by which a > client can know how a responder will respond to a request for a not issued > certificate. It simply recommend a known to be bad certificate to result > in "revoked" in order to prevent damage as far as possible. It also opens > for definition of new extensions through which such knowledge could be > obtained. > > The current updates also clearly opens a path for the CAB forum efforts to > define a suitable solution for server certificates. > > I have not, even thug suggested, added any requirements on what clients > should do with the checked cert as a result of a particular response. I > don't believe such requirements are suitable as it is policy and not > protocol. We have no right to demand that all systems MUST reject any > certificate for any reason as they may have a local policy that overrules > the OCSP response. This protocol only provides information about the cert > status, it does not mandate validation policy. > > I have not included any of the substantial changes i the Pinkas draft. I > want to wait for a list of motivation for each change before including any > of them. So there changed may be up for debate before this draft is ready > for WGLC. > > /Stefan > > > > _______________________________________________ > 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 > --bcaec54eecc86b866904cc683317 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It seems to me that if you remove information about the revocation status f= or expired certificates you can't be expected to be able to answer the = question of whether it was ever issued. Or put in reverse: If you keep trac= k of all certificates ever issued, then it is reasonable to assume that you= keep track of all revocations of the same.

Also: "Electronic signature validation is usually about the signat= ures created in the past and validated now, when the certificate is expired= ."

Well, yes, sort of. You can only be sure to validate a signa= ture at the moment of production. At any later point in time the signature = key may be compromised, or the algorithms involved may have become to weak.= (In which case the time of revocation in the OCSP response is worth nothin= g to you). The risk increases as time passes. And of course, the revocation= information may not be kept around after the expiry of the certificate.=A0=

That's why you should validate signatures as soon as pos= sible.=A0

If you need to ascertain that a signatur= e was valid at a later time, you have to trust your system that it performe= d the validation at the time it first received the signature. That trust mu= st be established through some kind of mix of policies and technical measur= es (such as timestamping).

Simon Tardell,=A0
Technology Nexus.

On Fri, Oct 19, 2012 at 1:07 PM, Peter Rybar <= ;rybar@nbusr.sk>= wrote:
Stefan,

I have a question about the present OCSP RFC and at the end of the mail abo= ut the new situation which will happen according to your new proposal.

The presence of the positive statement in OCSP response is important for el= ectronic signature validations, especially for an expired certificate. Posi= tive statement is the hash value of a certificate whose status is provided = in OCSP response.

Electronic signature validation is usually about the signatures created in = the past and validated now, when the certificate is expired.

When the certificate expires then revocation is usually removed from CRL an= d the revoked certificate can be provided as "good" in OCSP respo= nse.
Is it acceptable? I think not.

According to your new draft there is not defined a value of revocationTime.=
RFC must also define the value of revocationTime when the certificate which= was never issued is as "revoked".
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pkix-rfc2= 560bis-06

Have you also covered the situation when the certificate is expired, REMOVE= D FROM CRL and will be provided as revoked with incorrect revocationTime e.= g. with the value before or after the revocationTime which was present in t= he removed record from CRL?
Because according to sentence in your draft ""revoked" - Thi= s state SHOULD also be returned if the responder knows that the requested c= ertificate has never been issued." the following situation can happen:= when certificate is removed from CRL after expiration and CA/OCSP responde= r is responsible for this certificate but have not record about expired cer= tificate and for that reason it is identified as "never been issued&qu= ot;.

...
revoked =A0 =A0 [1] =A0 =A0 IMPLICIT RevokedInfo,
...

=A0 =A0RevokedInfo ::=3D SEQUENCE {
=A0 =A0 =A0 =A0revocationTime =A0 =A0 =A0 =A0 =A0 =A0 =A0GeneralizedTime, =A0 =A0 =A0 =A0revocationReason =A0 =A0[0] =A0 =A0 EXPLICIT CRLReason OPTIO= NAL }

As you have mentioned in the mail:
"On the "revoked" state, the old sp= ec did not even consider the case of a certificate being requested where th= e OCSP responder knows that the certificate was never issued."
"It simply recommend a known to be bad = certificate to result
in "revoked" in order to prevent damage as far as possible. It al= so opens
for definition of new extensions through which such knowledge could be
obtained."

Peter Rybar
National Security Authority
Information Security and Electronic Signature Department
Budatinska 30, 850 07 Bratislava 57, Slovak Republic
e-mail: peter.rybar@nbusr.sk e-mail: peterryb@gmail.com

-----Original Message-----
From: pkix-bounces@ietf.org [m= ailto:pkix-bounces@ietf.org] O= n Behalf Of Stefan Santesson
Sent: Monday, October 15, 2012 1:49 AM
To: pkix@ietf.org
Subject: [pkix] New draft-ietf-pkix-rfc2560bis-06

All,

I have just posted an update of rfc2560bis (OCSP update) after carefully reviewing all comments on the list.

Some notes about the update:

- Added the previous OCSP editors with updated affiliations.
- Added some calcifications on ResponderID as suggested by Simon Josefsson.=
- Updated the clarifications on Authorized responders. The requirements
have not changed. I just tried to improve the text.
- Updated a clarification on the "revoked" state to be the prefer= red
response if a certificate is known by the responder to never have been
issued.
- Some minor editorial nits.


Regarding backwards compatibility I mean that none of the clarifications changes RFC 2560.

On Authorized responders it has always been the case that a responder
certificate issued with the same key as was used to issue the certificate being checked for revocation, represents a valid Authorized responder.
There has never been an explicit requirement to support key rollover and key rollover support has never been in the "spirit" of the origin= al
standard as it clearly attempted to provide direct cryptographic binding between the responder and the CA.

On the "revoked" state, the old spec did not even consider the ca= se of a
certificate being requested where the OCSP responder knows that the
certificate was never issued. It is clearly counterproductive to respond good when a certificate is known to be bad. A responder must pick one
response and picking "revoked" breaks nothing, but has the desire= d effect,
that is, to prevent the certificate from being accepted. The current text makes clear that there is no mechanism in the current standard by which a client can know how a responder will respond to a request for a not issued<= br> certificate. It simply recommend a known to be bad certificate to result in "revoked" in order to prevent damage as far as possible. It al= so opens
for definition of new extensions through which such knowledge could be
obtained.

The current updates also clearly opens a path for the CAB forum efforts to<= br> define a suitable solution for server certificates.

I have not, even thug suggested, added any requirements on what clients
should do with the checked cert as a result of a particular response. I
don't believe such requirements are suitable as it is policy and not protocol. We have no right to demand that all systems MUST reject any
certificate for any reason as they may have a local policy that overrules the OCSP response. This protocol only provides information about the cert status, it does not mandate validation policy.

I have not included any of the substantial changes i the Pinkas draft. I want to wait for a list of motivation for each change before including any<= br> of them. So there changed may be up for debate before this draft is ready for WGLC.

/Stefan



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

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

--bcaec54eecc86b866904cc683317-- From carl@redhoundsoftware.com Fri Oct 19 05:31:15 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61AC521F8641 for ; Fri, 19 Oct 2012 05:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.543 X-Spam-Level: X-Spam-Status: No, score=-3.543 tagged_above=-999 required=5 tests=[AWL=-1.341, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxg+3nmzk36g for ; Fri, 19 Oct 2012 05:31:14 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C375E21F8480 for ; Fri, 19 Oct 2012 05:31:13 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so466863vcb.31 for ; Fri, 19 Oct 2012 05:31:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:x-gm-message-state; bh=5aFSy0FoxRkZjdH0zfny4F8rhWyjGXLgiTBDyOS9OMM=; b=hbWJvr1vgjhtL+bhyB8NvQpdVCDn5xUX+IxnjAtwH6vXukRd+9dPCHcWa0RkbWu91B IlxH/xZyPnnzwfpQUvdU/G0QSKpUGEs9Qk8uMAU/8vR79btarFHWObBi/X5YWiboVIoU 36SJw82uUl/0RfGpkgRSGdT1YCeNU2fo3mPBQKUXjvyb/mrSy2NyOqs8G7DZglWgGnUf lZ+JI2X5Jcgst3WtQnxQVgO8kz+oodrchAZ5nnC26p8QGasGliWm5TGOYZgJpgr58Y/C Gyzwl4eWEt/llhNu9+Z9TP5GnkS2FZuIOzC6hYodbGFlvaqY3LJ75d9yQvYco+xjWPfX uupg== Received: by 10.221.0.78 with SMTP id nl14mr1324716vcb.21.1350649873067; Fri, 19 Oct 2012 05:31:13 -0700 (PDT) Received: from [192.168.2.8] (pool-72-66-83-116.washdc.fios.verizon.net. [72.66.83.116]) by mx.google.com with ESMTPS id ct5sm1431615vdb.6.2012.10.19.05.31.08 (version=SSLv3 cipher=OTHER); Fri, 19 Oct 2012 05:31:12 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Fri, 19 Oct 2012 08:31:05 -0400 From: Carl Wallace To: Simon Tardell , Peter Rybar Message-ID: Thread-Topic: [pkix] New draft-ietf-pkix-rfc2560bis-06 In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3433480270_5188817" X-Gm-Message-State: ALoCoQk86JHNZUF98LJZjHa+M3/5li/r2FgVdK7sR7ZeCoKhAzW9qwrohLml2xgDv8+5X7y9wb24 Cc: Peter Rybar , Stefan Santesson , pkix@ietf.org Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 12:31:15 -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_3433480270_5188817 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit From: Simon Tardell Date: Friday, October 19, 2012 7:56 AM To: Peter Rybar Cc: Peter Rybar , Stefan Santesson , Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 > It seems to me that if you remove information about the revocation status for > expired certificates you can't be expected to be able to answer the question > of whether it was ever issued. Or put in reverse: If you keep track of all > certificates ever issued, then it is reasonable to assume that you keep track > of all revocations of the same. > > Also: "Electronic signature validation is usually about the signatures created > in the past and validated now, when the certificate is expired." > > Well, yes, sort of. You can only be sure to validate a signature at the moment > of production. What if the signature key was compromised at the moment of production but is not yet on a revocation list? > At any later point in time the signature key may be compromised, or the > algorithms involved may have become to weak. (In which case the time of > revocation in the OCSP response is worth nothing to you). The risk increases > as time passes. And of course, the revocation information may not be kept > around after the expiry of the certificate. > > That's why you should validate signatures as soon as possible. For these archival purposes wouldn't it be better to have the final revocation list before removed due to expiry? In any case, you'd need verification information collected after some grace period following moment of production. > > If you need to ascertain that a signature was valid at a later time, you have > to trust your system that it performed the validation at the time it first > received the signature. That trust must be established through some kind of > mix of policies and technical measures (such as timestamping). In the dark corner just beyond the dark corner that is SCVP, there's a spec (RFC 5276) that defines a binding of evidence records to artifacts that can be returned via SCVP. This provides for timestamping. > > > Simon Tardell, > Technology Nexus. > > On Fri, Oct 19, 2012 at 1:07 PM, Peter Rybar wrote: >> Stefan, >> >> I have a question about the present OCSP RFC and at the end of the mail about >> the new situation which will happen according to your new proposal. >> >> The presence of the positive statement in OCSP response is important for >> electronic signature validations, especially for an expired certificate. >> Positive statement is the hash value of a certificate whose status is >> provided in OCSP response. >> >> Electronic signature validation is usually about the signatures created in >> the past and validated now, when the certificate is expired. >> >> When the certificate expires then revocation is usually removed from CRL and >> the revoked certificate can be provided as "good" in OCSP response. >> Is it acceptable? I think not. >> >> According to your new draft there is not defined a value of revocationTime. >> RFC must also define the value of revocationTime when the certificate which >> was never issued is as "revoked". >> http://www.ietf.org/rfcdiff?url2=draft-ietf-pkix-rfc2560bis-06 >> >> Have you also covered the situation when the certificate is expired, REMOVED >> FROM CRL and will be provided as revoked with incorrect revocationTime e.g. >> with the value before or after the revocationTime which was present in the >> removed record from CRL? >> Because according to sentence in your draft ""revoked" - This state SHOULD >> also be returned if the responder knows that the requested certificate has >> never been issued." the following situation can happen: when certificate is >> removed from CRL after expiration and CA/OCSP responder is responsible for >> this certificate but have not record about expired certificate and for that >> reason it is identified as "never been issued". >> >> ... >> revoked [1] IMPLICIT RevokedInfo, >> ... >> >> RevokedInfo ::= SEQUENCE { >> revocationTime GeneralizedTime, >> revocationReason [0] EXPLICIT CRLReason OPTIONAL } >> >> As you have mentioned in the mail: >> "On the "revoked" state, the old spec did not even consider the case of a >> certificate being requested where the OCSP responder knows that the >> certificate was never issued." >> "It simply recommend a known to be bad certificate to result >> in "revoked" in order to prevent damage as far as possible. It also opens >> for definition of new extensions through which such knowledge could be >> obtained." >> >> Peter Rybar >> National Security Authority >> Information Security and Electronic Signature Department >> Budatinska 30, 850 07 Bratislava 57, Slovak Republic >> e-mail: peter.rybar@nbusr.sk >> e-mail: peterryb@gmail.com >> >> -----Original Message----- >> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >> Stefan Santesson >> Sent: Monday, October 15, 2012 1:49 AM >> To: pkix@ietf.org >> Subject: [pkix] New draft-ietf-pkix-rfc2560bis-06 >> >> All, >> >> I have just posted an update of rfc2560bis (OCSP update) after carefully >> reviewing all comments on the list. >> >> Some notes about the update: >> >> - Added the previous OCSP editors with updated affiliations. >> - Added some calcifications on ResponderID as suggested by Simon Josefsson. >> - Updated the clarifications on Authorized responders. The requirements >> have not changed. I just tried to improve the text. >> - Updated a clarification on the "revoked" state to be the preferred >> response if a certificate is known by the responder to never have been >> issued. >> - Some minor editorial nits. >> >> >> Regarding backwards compatibility I mean that none of the clarifications >> changes RFC 2560. >> >> On Authorized responders it has always been the case that a responder >> certificate issued with the same key as was used to issue the certificate >> being checked for revocation, represents a valid Authorized responder. >> There has never been an explicit requirement to support key rollover and >> key rollover support has never been in the "spirit" of the original >> standard as it clearly attempted to provide direct cryptographic binding >> between the responder and the CA. >> >> On the "revoked" state, the old spec did not even consider the case of a >> certificate being requested where the OCSP responder knows that the >> certificate was never issued. It is clearly counterproductive to respond >> good when a certificate is known to be bad. A responder must pick one >> response and picking "revoked" breaks nothing, but has the desired effect, >> that is, to prevent the certificate from being accepted. The current text >> makes clear that there is no mechanism in the current standard by which a >> client can know how a responder will respond to a request for a not issued >> certificate. It simply recommend a known to be bad certificate to result >> in "revoked" in order to prevent damage as far as possible. It also opens >> for definition of new extensions through which such knowledge could be >> obtained. >> >> The current updates also clearly opens a path for the CAB forum efforts to >> define a suitable solution for server certificates. >> >> I have not, even thug suggested, added any requirements on what clients >> should do with the checked cert as a result of a particular response. I >> don't believe such requirements are suitable as it is policy and not >> protocol. We have no right to demand that all systems MUST reject any >> certificate for any reason as they may have a local policy that overrules >> the OCSP response. This protocol only provides information about the cert >> status, it does not mandate validation policy. >> >> I have not included any of the substantial changes i the Pinkas draft. I >> want to wait for a list of motivation for each change before including any >> of them. So there changed may be up for debate before this draft is ready >> for WGLC. >> >> /Stefan >> >> >> >> _______________________________________________ >> 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 > > _______________________________________________ pkix mailing list > pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --B_3433480270_5188817 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable

From: Simon Tardell <= simon@tardell.se>
Date: Fri= day, October 19, 2012 7:56 AM
To: = Peter Rybar <rybar@nbusr.sk>
Cc: Peter Rybar <peterryb@gmail.com>, Stefan Santesson <stefan@aaa-sec.com>, <pkix@ietf.org>
Subject= : Re: [pkix] New draft-ietf-pkix-rfc2560bis-06

It seems to me that if you= remove information about the revocation status for expired certificates you= can't be expected to be able to answer the question of whether it was ever = issued. Or put in reverse: If you keep track of all certificates ever issued= , then it is reasonable to assume that you keep track of all revocations of = the same.

Also: "Electronic signature validation is usually about the= signatures created in the past and validated now, when the certificate is e= xpired."

Well, yes, sort of. You can only be sure to validate a signa= ture at the moment of production.

Wh= at if the signature key was compromised at the moment of production but is n= ot yet on a revocation list?

At any later point in ti= me the signature key may be compromised, or the algorithms involved may have= become to weak. (In which case the time of revocation in the OCSP response = is worth nothing to you). The risk increases as time passes. And of course, = the revocation information may not be kept around after the expiry of the ce= rtificate. 

That's why you should validate signature= s as soon as possible. 

Fo= r these archival purposes wouldn't it be better to have the final revocation= list before removed due to expiry?  In any case, you'd need verificati= on information collected after some grace period following moment of product= ion.


If you need to ascertain tha= t a signature was valid at a later time, you have to trust your system that = it performed the validation at the time it first received the signature. Tha= t trust must be established through some kind of mix of policies and technic= al measures (such as timestamping).

=
In the dark corner just beyond the dark corner that is SCVP, there's a = spec (RFC 5276) that defines a binding of evidence records to artifacts that= can be returned via SCVP.  This provides for timestamping.  



Simon Tardell, 
Technology Ne= xus.

On Fri, Oct 19, 2012 at 1:07 PM, Peter = Rybar <ry= bar@nbusr.sk> wrote:
Stefan,
<= br> I have a question about the present OCSP RFC and at the end of the mail abo= ut the new situation which will happen according to your new proposal.
The presence of the positive statement in OCSP response is important for el= ectronic signature validations, especially for an expired certificate. Posit= ive statement is the hash value of a certificate whose status is provided in= OCSP response.

Electronic signature validation is usually about the signatures created in = the past and validated now, when the certificate is expired.

When the certificate expires then revocation is usually removed from CRL an= d the revoked certificate can be provided as "good" in OCSP response.
Is it acceptable? I think not.

According to your new draft there is not defined a value of revocationTime.=
RFC must also define the value of revocationTime when the certificate which= was never issued is as "revoked".
http://www.ietf.org/rfcdi= ff?url2=3Ddraft-ietf-pkix-rfc2560bis-06

Have you also covered the situation when the certificate is expired, REMOVE= D FROM CRL and will be provided as revoked with incorrect revocationTime e.g= . with the value before or after the revocationTime which was present in the= removed record from CRL?
Because according to sentence in your draft ""revoked" - This state SHOULD = also be returned if the responder knows that the requested certificate has n= ever been issued." the following situation can happen: when certificate is r= emoved from CRL after expiration and CA/OCSP responder is responsible for th= is certificate but have not record about expired certificate and for that re= ason it is identified as "never been issued".

...
revoked     [1]     IMPLICIT RevokedInfo,
...

   RevokedInfo ::=3D SEQUENCE {
       revocationTime          = ;    GeneralizedTime,
       revocationReason    [0]     = EXPLICIT CRLReason OPTIONAL }

As you have mentioned in the mail:
"On the "revok= ed" state, the old spec did not even consider the case of a certificate bein= g requested where the OCSP responder knows that the certificate was never is= sued."
"It simply recommend a known to be ba= d certificate to result
in "revoked" in order to prevent damage as far as possible. It also opens for definition of new extensions through which such knowledge could be
obtained."

Peter Ry= bar
National Security Authority
Information Security and Electronic Signature Department
Budatinska 30, 850 07 Bratislava 57, Slovak Republic
e-mail: peter.rybar@nbusr.sk
e-mail: peterryb@gmail.com

-----Original Message-----
From: pkix-bounces@ietf.org [mai= lto:pkix-bounces@ietf.org] On Beh= alf Of Stefan Santesson
Sent: Monday, October 15, 2012 1:49 AM
To: pkix@ietf.org
Subject: [pkix] New draft-ietf-pkix-rfc2560bis-06

All,

I have just posted an update of rfc2560bis (OCSP update) after carefully reviewing all comments on the list.

Some notes about the update:

- Added the previous OCSP editors with updated affiliations.
- Added some calcifications on ResponderID as suggested by Simon Josefsson.=
- Updated the clarifications on Authorized responders. The requirements
= have not changed. I just tried to improve the text.
- Updated a clarification on the "revoked" state to be the preferred
response if a certificate is known by the responder to never have been
issued.
- Some minor editorial nits.


Regarding backwards compatibility I mean that none of the clarifications changes RFC 2560.

On Authorized responders it has always been the case that a responder
certificate issued with the same key as was used to issue the certificate being checked for revocation, represents a valid Authorized responder.
There has never been an explicit requirement to support key rollover and key rollover support has never been in the "spirit" of the original
standard as it clearly attempted to provide direct cryptographic binding between the responder and the CA.

On the "revoked" state, the old spec did not even consider the case of a certificate being requested where the OCSP responder knows that the
certificate was never issued. It is clearly counterproductive to respond good when a certificate is known to be bad. A responder must pick one
response and picking "revoked" breaks nothing, but has the desired effect,<= br> that is, to prevent the certificate from being accepted. The current text makes clear that there is no mechanism in the current standard by which a client can know how a responder will respond to a request for a not issued<= br> certificate. It simply recommend a known to be bad certificate to result in "revoked" in order to prevent damage as far as possible. It also opens for definition of new extensions through which such knowledge could be
obtained.

The current updates also clearly opens a path for the CAB forum efforts to<= br> define a suitable solution for server certificates.

I have not, even thug suggested, added any requirements on what clients
= should do with the checked cert as a result of a particular response. I
= don't believe such requirements are suitable as it is policy and not
protocol. We have no right to demand that all systems MUST reject any
certificate for any reason as they may have a local policy that overrules the OCSP response. This protocol only provides information about the cert status, it does not mandate validation policy.

I have not included any of the substantial changes i the Pinkas draft. I want to wait for a list of motivation for each change before including any<= br> of them. So there changed may be up for debate before this draft is ready for WGLC.

/Stefan



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

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

=
_______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/m= ailman/listinfo/pkix
--B_3433480270_5188817-- From denis.pinkas@bull.net Fri Oct 19 06:08:55 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC1121F8584 for ; Fri, 19 Oct 2012 06:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.899 X-Spam-Level: X-Spam-Status: No, score=-4.899 tagged_above=-999 required=5 tests=[AWL=1.349, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EwHjpG8Io9DH for ; Fri, 19 Oct 2012 06:08:53 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id C169021F8594 for ; Fri, 19 Oct 2012 06:08:52 -0700 (PDT) Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id 6F07B1C309 for ; Fri, 19 Oct 2012 15:08:51 +0200 (CEST) Received: from [127.0.0.1] ([129.184.39.15]) by MSGC-007.bull.fr (Lotus Domino Release 8.5.3FP1) with ESMTP id 2012101915084985-998 ; Fri, 19 Oct 2012 15:08:49 +0200 Message-ID: <508150DD.6010608@bull.net> Date: Fri, 19 Oct 2012 15:08:45 +0200 From: Denis Pinkas User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: pkix@ietf.org References: <201210191107.q9JB7m62045167@mail.nbusr.sk> In-Reply-To: X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 19/10/2012 15:08:50, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 19/10/2012 15:08:51, Serialize complete at 19/10/2012 15:08:51 X-TNEFEvaluated: 1 Content-Type: multipart/alternative; boundary="------------000408070209050406090902" Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 13:08:55 -0000 This is a multi-part message in MIME format. --------------000408070209050406090902 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed Peter and Simon, There are two different topics covered by these two emails: 1 - verification of an OCSP response that was issued in the past, and 2 - status of a certificate that was never was never issued. 1) Verification of an OCSP response that was issued in the past RFC 2560 ,nor the draft from Stefan, does not address verification in the past. This topic are addressed in details in: draft-pinkas-rfc2560bis-03. Hereafter are only a few extracts. Page 5: oSection 4.3 addresses the verification of an OCSP response both at the current time and at a time in the past. Page 21: 4.3.2. Response processing by an OCSP client OCSP responses can be verified at the current time by an OCSP client when receiving a response, whereas old responses can be verified at a time in the past by a verifier.The algorithm below addresses both cases. Prior to processing a basic response, OCSP clients MUST determine the checking time, which may be either the current time or a time in the past. Page 22: If the certificate status from the single certificate response is either "good" or "revoked", OCSP clients or verifiers SHALL check that the checking time is within the validity period of the target certificate. (...) If the checking time is a time in the past, verifiers MUST check that the producedAt field is in accordance with the verification rules (e.g. close and/or after the date of a time-stamp token). In addition, if the nextUpdate field is present, OCSP clients MUST check that the time which is indicated is greater than the checking time, otherwise the single response MUST be discarded. 2) Status of a certificate that was never was never issued There is a strong agreement that, if the OCSP responder has access to the database of issued certificates, the revocation status shall never be "good". The only question is whether the returned revocation status shall be "revoked" or "unknown": - with "revoked", the RP will not accept the certificate and will stop the processing. - with "unknown", the RP will not accept the certificate, but may attempt to access other sources of information. However IMO, "unknown" is more appropriate, since if the proposed non criticalcertinfo extension is used, (see draft-pinkas-2560bis-certinfo-00)"unkown" make more sense (how would you revoke a certificate that was never issued ???) and the extension provides more details to RPs that are able to process it. The case that Peter mentioned, i.e. "certificate removed from CRL after expiration" does not exist, ... unless the Archive Cutoff extension is supported. Denis > It seems to me that if you remove information about the revocation > status for expired certificates you can't be expected to be able to > answer the question of whether it was ever issued. Or put in reverse: > If you keep track of all certificates ever issued, then it is > reasonable to assume that you keep track of all revocations of the same. > > Also: "Electronic signature validation is usually about the signatures > created in the past and validated now, when the certificate is expired." > > Well, yes, sort of. You can only be sure to validate a signature at > the moment of production. At any later point in time the signature key > may be compromised, or the algorithms involved may have become to > weak. (In which case the time of revocation in the OCSP response is > worth nothing to you). The risk increases as time passes. And of > course, the revocation information may not be kept around after the > expiry of the certificate. > > That's why you should validate signatures as soon as possible. > > If you need to ascertain that a signature was valid at a later time, > you have to trust your system that it performed the validation at the > time it first received the signature. That trust must be established > through some kind of mix of policies and technical measures (such as > timestamping). > > Simon Tardell, > Technology Nexus. > > On Fri, Oct 19, 2012 at 1:07 PM, Peter Rybar > wrote: > > Stefan, > > I have a question about the present OCSP RFC and at the end of the > mail about the new situation which will happen according to your > new proposal. > > The presence of the positive statement in OCSP response is > important for electronic signature validations, especially for an > expired certificate. Positive statement is the hash value of a > certificate whose status is provided in OCSP response. > > Electronic signature validation is usually about the signatures > created in the past and validated now, when the certificate is > expired. > > When the certificate expires then revocation is usually removed > from CRL and the revoked certificate can be provided as "good" in > OCSP response. > Is it acceptable? I think not. > > According to your new draft there is not defined a value of > revocationTime. > RFC must also define the value of revocationTime when the > certificate which was never issued is as "revoked". > http://www.ietf.org/rfcdiff?url2=draft-ietf-pkix-rfc2560bis-06 > > Have you also covered the situation when the certificate is > expired, REMOVED FROM CRL and will be provided as revoked with > incorrect revocationTime e.g. with the value before or after the > revocationTime which was present in the removed record from CRL? > Because according to sentence in your draft ""revoked" - This > state SHOULD also be returned if the responder knows that the > requested certificate has never been issued." the following > situation can happen: when certificate is removed from CRL after > expiration and CA/OCSP responder is responsible for this > certificate but have not record about expired certificate and for > that reason it is identified as "never been issued". > > ... > revoked [1] IMPLICIT RevokedInfo, > ... > > RevokedInfo ::= SEQUENCE { > revocationTime GeneralizedTime, > revocationReason [0] EXPLICIT CRLReason OPTIONAL } > > As you have mentioned in the mail: > "On the "revoked" state, the old spec did not even consider the > case of a certificate being requested where the OCSP responder > knows that the certificate was never issued." > "It simply recommend a known to be bad certificate to result > in "revoked" in order to prevent damage as far as possible. It > also opens > for definition of new extensions through which such knowledge could be > obtained." > > Peter Rybar > National Security Authority > Information Security and Electronic Signature Department > Budatinska 30, 850 07 Bratislava 57, Slovak Republic > e-mail: peter.rybar@nbusr.sk > e-mail: peterryb@gmail.com > > -----Original Message----- > From: pkix-bounces@ietf.org > [mailto:pkix-bounces@ietf.org ] On > Behalf Of Stefan Santesson > Sent: Monday, October 15, 2012 1:49 AM > To: pkix@ietf.org > Subject: [pkix] New draft-ietf-pkix-rfc2560bis-06 > > All, > > I have just posted an update of rfc2560bis (OCSP update) after > carefully > reviewing all comments on the list. > > Some notes about the update: > > - Added the previous OCSP editors with updated affiliations. > - Added some calcifications on ResponderID as suggested by Simon > Josefsson. > - Updated the clarifications on Authorized responders. The > requirements > have not changed. I just tried to improve the text. > - Updated a clarification on the "revoked" state to be the preferred > response if a certificate is known by the responder to never have been > issued. > - Some minor editorial nits. > > > Regarding backwards compatibility I mean that none of the > clarifications > changes RFC 2560. > > On Authorized responders it has always been the case that a responder > certificate issued with the same key as was used to issue the > certificate > being checked for revocation, represents a valid Authorized responder. > There has never been an explicit requirement to support key > rollover and > key rollover support has never been in the "spirit" of the original > standard as it clearly attempted to provide direct cryptographic > binding > between the responder and the CA. > > On the "revoked" state, the old spec did not even consider the > case of a > certificate being requested where the OCSP responder knows that the > certificate was never issued. It is clearly counterproductive to > respond > good when a certificate is known to be bad. A responder must pick one > response and picking "revoked" breaks nothing, but has the desired > effect, > that is, to prevent the certificate from being accepted. The > current text > makes clear that there is no mechanism in the current standard by > which a > client can know how a responder will respond to a request for a > not issued > certificate. It simply recommend a known to be bad certificate to > result > in "revoked" in order to prevent damage as far as possible. It > also opens > for definition of new extensions through which such knowledge could be > obtained. > > The current updates also clearly opens a path for the CAB forum > efforts to > define a suitable solution for server certificates. > > I have not, even thug suggested, added any requirements on what > clients > should do with the checked cert as a result of a particular > response. I > don't believe such requirements are suitable as it is policy and not > protocol. We have no right to demand that all systems MUST reject any > certificate for any reason as they may have a local policy that > overrules > the OCSP response. This protocol only provides information about > the cert > status, it does not mandate validation policy. > > I have not included any of the substantial changes i the Pinkas > draft. I > want to wait for a list of motivation for each change before > including any > of them. So there changed may be up for debate before this draft > is ready > for WGLC. > > /Stefan > > > > _______________________________________________ > 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 > > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --------------000408070209050406090902 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=ISO-8859-1
Peter and Simon,

There are two different topics covered by these two emails:

   1 - verification of an OCSP response that was issued in the past, and
   2 - status of a certificate that was never was never issued. 


1) Verification of an OCSP response that was issued in the past

RFC 2560 ,nor the draft from Stefan, does not address verification in the past.
This topic are addressed in details in: draft-pinkas-rfc2560bis-03.
Hereafter are only a few extracts.

 

Page 5:

 

      o  Section 4.3 addresses the verification of an OCSP response

         both at the current time and at a time in the past.

 

Page 21:

 

4.3.2. Response processing by an OCSP client

 

   OCSP responses can be verified at the current time by an OCSP client

   when receiving a response, whereas old responses can be verified at

   a time in the past by a verifier.  The algorithm below addresses

   both cases.

 

   Prior to processing a basic response, OCSP clients MUST determine

   the checking time, which may be either the current time or a time

   in the past.

 

Page 22:

 

   If the certificate status from the single certificate response is

   either "good" or "revoked", OCSP clients or verifiers SHALL check

   that the checking time is within the validity period of the target

   certificate. 

 

(...)

 

   If the checking time is a time in the past, verifiers MUST check

   that the producedAt field is in accordance with the verification

   rules (e.g. close and/or after the date of a time-stamp token).

 

   In addition, if the nextUpdate field is present, OCSP clients MUST

   check that the time which is indicated is greater than the checking

   time, otherwise the single response MUST be discarded.



2) Status of a certificate that was never was never issued


 There is a strong agreement that, if the OCSP responder has access to the database
 of issued certificates, the revocation status shall never be "good". The only question
 is whether the returned revocation status shall be "revoked" or "unknown":

   - with "revoked", the RP will not accept the certificate and will stop the processing.

   - with "unknown", the RP will not accept the certificate, but may attempt to access other sources of information.


 However IMO, "unknown" is more appropriate, since if the proposed non critical certinfo extension is used,
 (see draft-pinkas-2560bis-certinfo-00) "unkown" make more sense (how would you revoke a certificate that was
 never issued ???) and the extension provides more details to RPs that are able to process it.

The case that Peter mentioned, i.e. "certificate removed from CRL after expiration" does not exist, ... unless
the Archive Cutoff extension is supported.

 

Denis


It seems to me that if you remove information about the revocation status for expired certificates you can't be expected to be able to answer the question of whether it was ever issued. Or put in reverse: If you keep track of all certificates ever issued, then it is reasonable to assume that you keep track of all revocations of the same.

Also: "Electronic signature validation is usually about the signatures created in the past and validated now, when the certificate is expired."

Well, yes, sort of. You can only be sure to validate a signature at the moment of production. At any later point in time the signature key may be compromised, or the algorithms involved may have become to weak. (In which case the time of revocation in the OCSP response is worth nothing to you). The risk increases as time passes. And of course, the revocation information may not be kept around after the expiry of the certificate. 

That's why you should validate signatures as soon as possible. 

If you need to ascertain that a signature was valid at a later time, you have to trust your system that it performed the validation at the time it first received the signature. That trust must be established through some kind of mix of policies and technical measures (such as timestamping).

Simon Tardell, 
Technology Nexus.

On Fri, Oct 19, 2012 at 1:07 PM, Peter Rybar <rybar@nbusr.sk> wrote:
Stefan,

I have a question about the present OCSP RFC and at the end of the mail about the new situation which will happen according to your new proposal.

The presence of the positive statement in OCSP response is important for electronic signature validations, especially for an expired certificate. Positive statement is the hash value of a certificate whose status is provided in OCSP response.

Electronic signature validation is usually about the signatures created in the past and validated now, when the certificate is expired.

When the certificate expires then revocation is usually removed from CRL and the revoked certificate can be provided as "good" in OCSP response.
Is it acceptable? I think not.

According to your new draft there is not defined a value of revocationTime.
RFC must also define the value of revocationTime when the certificate which was never issued is as "revoked".
http://www.ietf.org/rfcdiff?url2=draft-ietf-pkix-rfc2560bis-06

Have you also covered the situation when the certificate is expired, REMOVED FROM CRL and will be provided as revoked with incorrect revocationTime e.g. with the value before or after the revocationTime which was present in the removed record from CRL?
Because according to sentence in your draft ""revoked" - This state SHOULD also be returned if the responder knows that the requested certificate has never been issued." the following situation can happen: when certificate is removed from CRL after expiration and CA/OCSP responder is responsible for this certificate but have not record about expired certificate and for that reason it is identified as "never been issued".

...
revoked     [1]     IMPLICIT RevokedInfo,
...

   RevokedInfo ::= SEQUENCE {
       revocationTime              GeneralizedTime,
       revocationReason    [0]     EXPLICIT CRLReason OPTIONAL }

As you have mentioned in the mail:
"On the "revoked" state, the old spec did not even consider the case of a certificate being requested where the OCSP responder knows that the certificate was never issued."
"It simply recommend a known to be bad certificate to result
in "revoked" in order to prevent damage as far as possible. It also opens
for definition of new extensions through which such knowledge could be
obtained."

Peter Rybar
National Security Authority
Information Security and Electronic Signature Department
Budatinska 30, 850 07 Bratislava 57, Slovak Republic
e-mail: peter.rybar@nbusr.sk
e-mail: peterryb@gmail.com

-----Original Message-----
From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Stefan Santesson
Sent: Monday, October 15, 2012 1:49 AM
To: pkix@ietf.org
Subject: [pkix] New draft-ietf-pkix-rfc2560bis-06

All,

I have just posted an update of rfc2560bis (OCSP update) after carefully
reviewing all comments on the list.

Some notes about the update:

- Added the previous OCSP editors with updated affiliations.
- Added some calcifications on ResponderID as suggested by Simon Josefsson.
- Updated the clarifications on Authorized responders. The requirements
have not changed. I just tried to improve the text.
- Updated a clarification on the "revoked" state to be the preferred
response if a certificate is known by the responder to never have been
issued.
- Some minor editorial nits.


Regarding backwards compatibility I mean that none of the clarifications
changes RFC 2560.

On Authorized responders it has always been the case that a responder
certificate issued with the same key as was used to issue the certificate
being checked for revocation, represents a valid Authorized responder.
There has never been an explicit requirement to support key rollover and
key rollover support has never been in the "spirit" of the original
standard as it clearly attempted to provide direct cryptographic binding
between the responder and the CA.

On the "revoked" state, the old spec did not even consider the case of a
certificate being requested where the OCSP responder knows that the
certificate was never issued. It is clearly counterproductive to respond
good when a certificate is known to be bad. A responder must pick one
response and picking "revoked" breaks nothing, but has the desired effect,
that is, to prevent the certificate from being accepted. The current text
makes clear that there is no mechanism in the current standard by which a
client can know how a responder will respond to a request for a not issued
certificate. It simply recommend a known to be bad certificate to result
in "revoked" in order to prevent damage as far as possible. It also opens
for definition of new extensions through which such knowledge could be
obtained.

The current updates also clearly opens a path for the CAB forum efforts to
define a suitable solution for server certificates.

I have not, even thug suggested, added any requirements on what clients
should do with the checked cert as a result of a particular response. I
don't believe such requirements are suitable as it is policy and not
protocol. We have no right to demand that all systems MUST reject any
certificate for any reason as they may have a local policy that overrules
the OCSP response. This protocol only provides information about the cert
status, it does not mandate validation policy.

I have not included any of the substantial changes i the Pinkas draft. I
want to wait for a list of motivation for each change before including any
of them. So there changed may be up for debate before this draft is ready
for WGLC.

/Stefan



_______________________________________________
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



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

--------------000408070209050406090902-- From prvs=063967d583=rybar@nbusr.sk Fri Oct 19 06:12:22 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 157F021F859E for ; Fri, 19 Oct 2012 06:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.694 X-Spam-Level: X-Spam-Status: No, score=-0.694 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id td5u6yLVF5KP for ; Fri, 19 Oct 2012 06:12:20 -0700 (PDT) Received: from mail.nbusr.sk (mail.nbusr.sk [84.245.65.227]) by ietfa.amsl.com (Postfix) with ESMTP id 04E3221F8585 for ; Fri, 19 Oct 2012 06:12:19 -0700 (PDT) Message-Id: <201210191312.q9JDCHtT046173@mail.nbusr.sk> From: "Peter Rybar" To: "'Carl Wallace'" , "'Simon Tardell'" Date: Fri, 19 Oct 2012 15:12:13 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01CDAE0C.1ED9E750" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: Thread-Index: Ac2t9aKWTP1HJY+oSA+RIAmWWBLMvAAAlrAw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-NAI-Spam-Flag: NO X-NAI-Spam-Level: ** X-NAI-Spam-Threshold: 6 X-NAI-Spam-Score: 2.5 X-NAI-Spam-Version: 2.2.0.9309 : core <4375> : streams <841288> : uri <1247132> Cc: 'Peter Rybar' , 'Stefan Santesson' , pkix@ietf.org Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 13:12:22 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_000F_01CDAE0C.1ED9E750 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Well, yes, sort of. You can only be sure to validate a signature at the = moment of production.=20 =20 What if the signature key was compromised at the moment of production = but is not yet on a revocation list? [PR] According to clause 2.4 - thisUpdate: The time at which the = status being indicated is known to be correct It means when signature time-stamp time is X then any OCSP responses = with thisUpdate time X+y are sufficient to validate because the status = is correct.=20 Y is in the interval <0, producedAt - X> =20 At any later point in time the signature key may be compromised, or the = algorithms involved may have become to weak. (In which case the time of = revocation in the OCSP response is worth nothing to you). The risk = increases as time passes. And of course, the revocation information may = not be kept around after the expiry of the certificate.=20 =20 That's why you should validate signatures as soon as possible.=20 =20 For these archival purposes wouldn't it be better to have the final = revocation list before removed due to expiry? In any case, you'd need = verification information collected after some grace period following = moment of production. [PR] Grace period is not a fixed value of the time interval.=20 Grace period is changeable because the first OCSP response with = thisUpdate time value > than time of signature time-stamp contains = correct status. =20 =20 If you need to ascertain that a signature was valid at a later time, you = have to trust your system that it performed the validation at the time = it first received the signature. That trust must be established through = some kind of mix of policies and technical measures (such as = timestamping). =20 In the dark corner just beyond the dark corner that is SCVP, there's a = spec (RFC 5276) that defines a binding of evidence records to artifacts = that can be returned via SCVP. This provides for timestamping. =20 [PR] The validation is simplified when OCSP response with positive = statement as a hash value of requested certificate is used. Positive statement is evidence that OCSP know the status of certificate = and also protect the integrity of certificate with a new more secure = hash algorithm. =20 Peter Rybar =20 Simon Tardell,=20 Technology Nexus. On Fri, Oct 19, 2012 at 1:07 PM, Peter Rybar wrote: Stefan, I have a question about the present OCSP RFC and at the end of the mail = about the new situation which will happen according to your new = proposal. The presence of the positive statement in OCSP response is important for = electronic signature validations, especially for an expired certificate. = Positive statement is the hash value of a certificate whose status is = provided in OCSP response. Electronic signature validation is usually about the signatures created = in the past and validated now, when the certificate is expired. When the certificate expires then revocation is usually removed from CRL = and the revoked certificate can be provided as "good" in OCSP response. Is it acceptable? I think not. According to your new draft there is not defined a value of = revocationTime. RFC must also define the value of revocationTime when the certificate = which was never issued is as "revoked". http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pkix-rfc2560bis-06 Have you also covered the situation when the certificate is expired, = REMOVED FROM CRL and will be provided as revoked with incorrect = revocationTime e.g. with the value before or after the revocationTime = which was present in the removed record from CRL? Because according to sentence in your draft ""revoked" - This state = SHOULD also be returned if the responder knows that the requested = certificate has never been issued." the following situation can happen: = when certificate is removed from CRL after expiration and CA/OCSP = responder is responsible for this certificate but have not record about = expired certificate and for that reason it is identified as "never been = issued". ... revoked [1] IMPLICIT RevokedInfo, ... RevokedInfo ::=3D SEQUENCE { revocationTime GeneralizedTime, revocationReason [0] EXPLICIT CRLReason OPTIONAL } As you have mentioned in the mail: "On the "revoked" state, the old spec did not even consider the case of = a certificate being requested where the OCSP responder knows that the = certificate was never issued." "It simply recommend a known to be bad certificate to result in "revoked" in order to prevent damage as far as possible. It also = opens for definition of new extensions through which such knowledge could be obtained." Peter Rybar National Security Authority Information Security and Electronic Signature Department Budatinska 30, 850 07 Bratislava 57, Slovak Republic e-mail: peter.rybar@nbusr.sk e-mail: peterryb@gmail.com -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of = Stefan Santesson Sent: Monday, October 15, 2012 1:49 AM To: pkix@ietf.org Subject: [pkix] New draft-ietf-pkix-rfc2560bis-06 All, I have just posted an update of rfc2560bis (OCSP update) after carefully reviewing all comments on the list. Some notes about the update: - Added the previous OCSP editors with updated affiliations. - Added some calcifications on ResponderID as suggested by Simon = Josefsson. - Updated the clarifications on Authorized responders. The requirements have not changed. I just tried to improve the text. - Updated a clarification on the "revoked" state to be the preferred response if a certificate is known by the responder to never have been issued. - Some minor editorial nits. Regarding backwards compatibility I mean that none of the clarifications changes RFC 2560. On Authorized responders it has always been the case that a responder certificate issued with the same key as was used to issue the = certificate being checked for revocation, represents a valid Authorized responder. There has never been an explicit requirement to support key rollover and key rollover support has never been in the "spirit" of the original standard as it clearly attempted to provide direct cryptographic binding between the responder and the CA. On the "revoked" state, the old spec did not even consider the case of a certificate being requested where the OCSP responder knows that the certificate was never issued. It is clearly counterproductive to respond good when a certificate is known to be bad. A responder must pick one response and picking "revoked" breaks nothing, but has the desired = effect, that is, to prevent the certificate from being accepted. The current = text makes clear that there is no mechanism in the current standard by which = a client can know how a responder will respond to a request for a not = issued certificate. It simply recommend a known to be bad certificate to result in "revoked" in order to prevent damage as far as possible. It also = opens for definition of new extensions through which such knowledge could be obtained. The current updates also clearly opens a path for the CAB forum efforts = to define a suitable solution for server certificates. I have not, even thug suggested, added any requirements on what clients should do with the checked cert as a result of a particular response. I don't believe such requirements are suitable as it is policy and not protocol. We have no right to demand that all systems MUST reject any certificate for any reason as they may have a local policy that = overrules the OCSP response. This protocol only provides information about the = cert status, it does not mandate validation policy. I have not included any of the substantial changes i the Pinkas draft. I want to wait for a list of motivation for each change before including = any of them. So there changed may be up for debate before this draft is = ready for WGLC. /Stefan _______________________________________________ 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 =20 _______________________________________________ pkix mailing list = pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix=20 ------=_NextPart_000_000F_01CDAE0C.1ED9E750 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Well, yes, = sort of. You can only be sure to validate a signature at the moment of = production.

 

What if the = signature key was compromised at the moment of production but is not yet on a = revocation list?

[PR] According = to clause 2.4 =C2=A0-=C2=A0 thisUpdate: The time at which the status being = indicated is known to be correct

It means when = signature time-stamp time is X then any OCSP responses with thisUpdate time X+y = are sufficient to validate because the status is correct.

Y is in the = interval <0, producedAt - X>

 

At any later point in time the signature key = may be compromised, or the algorithms involved may have become to weak. (In = which case the time of revocation in the OCSP response is worth nothing to you). = The risk increases as time passes. And of course, the revocation information may = not be kept around after the expiry of the = certificate. 

 

That's why = you should validate signatures as soon as = possible. 

 

For these = archival purposes wouldn't it be better to have the final revocation list before = removed due to expiry?  In any case, you'd need verification information = collected after some grace period following moment of = production.

[PR] Grace = period is not a fixed value of the time interval.

Grace period is = changeable because the first OCSP response with thisUpdate time value > than = time of signature time-stamp contains correct status.

 

 

If you need = to ascertain that a signature was valid at a later time, you have to trust = your system that it performed the validation at the time it first received = the signature. That trust must be established through some kind of mix of = policies and technical measures (such as = timestamping).

 

In the dark = corner just beyond the dark corner that is SCVP, there's a spec (RFC 5276) that defines a binding of evidence records to artifacts that can be returned = via SCVP.  This provides for timestamping. =  

[PR] The = validation is simplified when OCSP response with positive statement as a hash value of requested certificate is used.

Positive = statement is evidence that OCSP know the status of certificate and also protect the integrity of certificate with a new more secure hash = algorithm.

 

Peter = Rybar

 =



Simon Tardell, 

Technology Nexus.

On Fri, Oct = 19, 2012 at 1:07 PM, Peter = Rybar <rybar@nbusr.sk> wrote:

Stefan,

I have a question about the present OCSP RFC and at the end of the mail = about the new situation which will happen according to your new proposal.

The presence of the positive statement in OCSP response is important for electronic signature validations, especially for an expired certificate. = Positive statement is the hash value of a certificate whose status is provided in = OCSP response.

Electronic signature validation is usually about the signatures created = in the past and validated now, when the certificate is expired.

When the certificate expires then revocation is usually removed from CRL = and the revoked certificate can be provided as "good" in OCSP = response.
Is it acceptable? I think not.

According to your new draft there is not defined a value of = revocationTime.
RFC must also define the value of revocationTime when the certificate = which was never issued is as "revoked".
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pkix-rfc2= 560bis-06

Have you also covered the situation when the certificate is expired, = REMOVED FROM CRL and will be provided as revoked with incorrect revocationTime = e.g. with the value before or after the revocationTime which was present in = the removed record from CRL?
Because according to sentence in your draft ""revoked" - = This state SHOULD also be returned if the responder knows that the requested certificate has never been issued." the following situation can = happen: when certificate is removed from CRL after expiration and CA/OCSP = responder is responsible for this certificate but have not record about expired = certificate and for that reason it is identified as "never been = issued".

...
revoked     [1]     IMPLICIT RevokedInfo,
...

   RevokedInfo ::=3D SEQUENCE {
       revocationTime         =      GeneralizedTime,
       revocationReason    [0]   =   EXPLICIT CRLReason OPTIONAL }

As you have mentioned in the mail:

"On the "revoked" state, the old spec did not even consider the case = of a certificate being requested where the OCSP responder knows that the = certificate was never issued."

"It simply recommend a known to be bad certificate to = result
in "revoked" in order to prevent damage as far as possible. It = also opens
for definition of new extensions through which such knowledge could = be
obtained."

Peter = Rybar
National Security Authority
Information Security and Electronic Signature = Department
Budatinska 30, 850 07 Bratislava 57, Slovak Republic
e-mail: peter.rybar@nbusr.sk
e-mail: peterryb@gmail.com


-----Original Message-----
From: pkix-bounces@ietf.org = [mailto:pkix-bounces@ietf.org] On = Behalf Of Stefan Santesson
Sent: Monday, October 15, 2012 1:49 AM
To: pkix@ietf.org
Subject: [pkix] New draft-ietf-pkix-rfc2560bis-06

All,

I have just posted an update of rfc2560bis (OCSP update) after = carefully
reviewing all comments on the list.

Some notes about the update:

- Added the previous OCSP editors with updated affiliations.
- Added some calcifications on ResponderID as suggested by Simon = Josefsson.
- Updated the clarifications on Authorized responders. The = requirements
have not changed. I just tried to improve the text.
- Updated a clarification on the "revoked" state to be the = preferred
response if a certificate is known by the responder to never have = been
issued.
- Some minor editorial nits.


Regarding backwards compatibility I mean that none of the = clarifications
changes RFC 2560.

On Authorized responders it has always been the case that a = responder
certificate issued with the same key as was used to issue the = certificate
being checked for revocation, represents a valid Authorized = responder.
There has never been an explicit requirement to support key rollover = and
key rollover support has never been in the "spirit" of the = original
standard as it clearly attempted to provide direct cryptographic = binding
between the responder and the CA.

On the "revoked" state, the old spec did not even consider the = case of a
certificate being requested where the OCSP responder knows that the
certificate was never issued. It is clearly counterproductive to = respond
good when a certificate is known to be bad. A responder must pick = one
response and picking "revoked" breaks nothing, but has the = desired effect,
that is, to prevent the certificate from being accepted. The current = text
makes clear that there is no mechanism in the current standard by which = a
client can know how a responder will respond to a request for a not = issued
certificate. It simply recommend a known to be bad certificate to = result
in "revoked" in order to prevent damage as far as possible. It = also opens
for definition of new extensions through which such knowledge could = be
obtained.

The current updates also clearly opens a path for the CAB forum efforts = to
define a suitable solution for server certificates.

I have not, even thug suggested, added any requirements on what = clients
should do with the checked cert as a result of a particular response. = I
don't believe such requirements are suitable as it is policy and not
protocol. We have no right to demand that all systems MUST reject = any
certificate for any reason as they may have a local policy that = overrules
the OCSP response. This protocol only provides information about the = cert
status, it does not mandate validation policy.

I have not included any of the substantial changes i the Pinkas draft. = I
want to wait for a list of motivation for each change before including = any
of them. So there changed may be up for debate before this draft is = ready
for WGLC.

/Stefan



_______________________________________________
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

 

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

------=_NextPart_000_000F_01CDAE0C.1ED9E750-- From stefan@aaa-sec.com Fri Oct 19 07:26:49 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79A3721F85A4 for ; Fri, 19 Oct 2012 07:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.318 X-Spam-Level: X-Spam-Status: No, score=-101.318 tagged_above=-999 required=5 tests=[AWL=-0.466, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bB1nm8Lm9dVL for ; Fri, 19 Oct 2012 07:26:48 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 6A12521F86EC for ; Fri, 19 Oct 2012 07:26:46 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 9B8C222BE3CA for ; Fri, 19 Oct 2012 16:25:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id RkucLqRx2W6C for ; Fri, 19 Oct 2012 16:25:09 +0200 (CEST) Received: from s326.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id CC77122BE1BC for ; Fri, 19 Oct 2012 16:24:33 +0200 (CEST) Received: (qmail 76673 invoked from network); 19 Oct 2012 14:24:33 -0000 Received: from 81-232-51-61-no39.business.telia.com (HELO [192.168.0.108]) (stefan@fiddler.nu@[81.232.51.61]) (envelope-sender ) by s326.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 19 Oct 2012 14:24:33 -0000 User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Fri, 19 Oct 2012 16:24:31 +0200 From: Stefan Santesson To: Peter Rybar , 'Carl Wallace' , 'Simon Tardell' Message-ID: Thread-Topic: [pkix] New draft-ietf-pkix-rfc2560bis-06 In-Reply-To: <201210191312.q9JDCHnw046175@mail.nbusr.sk> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3433508675_5906481" Cc: 'Peter Rybar' , pkix@ietf.org Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 14:26:49 -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_3433508675_5906481 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Peter, An OCSP responder is by default a service providing information about current certificates. The default response you get from an OCSP responder is "good" unless the cert is known to be bad or not a cert the responder can provide status for. If you need it to respond about old certificates, and as a client know that the responder does this in a way that suits your needs, you will need to add an extension. Such extension will not be part of the rfc256bis effort. Is there any text in the current draft that you think is unclear on this? /Stefan From: Peter Rybar Date: Friday, October 19, 2012 3:12 PM To: 'Carl Wallace' , 'Simon Tardell' Cc: 'Peter Rybar' , Stefan Santesson , Subject: RE: [pkix] New draft-ietf-pkix-rfc2560bis-06 >> Well, yes, sort of. You can only be sure to validate a signature at the >> moment of production. > > > > What if the signature key was compromised at the moment of production but is > not yet on a revocation list? > [PR] According to clause 2.4 - thisUpdate: The time at which the status > being indicated is known to be correct > It means when signature time-stamp time is X then any OCSP responses with > thisUpdate time X+y are sufficient to validate because the status is correct. > Y is in the interval <0, producedAt - X> > > >> At any later point in time the signature key may be compromised, or the >> algorithms involved may have become to weak. (In which case the time of >> revocation in the OCSP response is worth nothing to you). The risk increases >> as time passes. And of course, the revocation information may not be kept >> around after the expiry of the certificate. >> >> >> >> That's why you should validate signatures as soon as possible. > > > > For these archival purposes wouldn't it be better to have the final revocation > list before removed due to expiry? In any case, you'd need verification > information collected after some grace period following moment of production. > > [PR] Grace period is not a fixed value of the time interval. > Grace period is changeable because the first OCSP response with thisUpdate > time value > than time of signature time-stamp contains correct status. > >> >> >> >> If you need to ascertain that a signature was valid at a later time, you have >> to trust your system that it performed the validation at the time it first >> received the signature. That trust must be established through some kind of >> mix of policies and technical measures (such as timestamping). > > > > In the dark corner just beyond the dark corner that is SCVP, there's a spec > (RFC 5276) that defines a binding of evidence records to artifacts that can be > returned via SCVP. This provides for timestamping. > [PR] The validation is simplified when OCSP response with positive statement > as a hash value of requested certificate is used. > Positive statement is evidence that OCSP know the status of certificate and > also protect the integrity of certificate with a new more secure hash > algorithm. > > > Peter Rybar > >> >> >> >> Simon Tardell, >> >> Technology Nexus. >> >> On Fri, Oct 19, 2012 at 1:07 PM, Peter Rybar wrote: >> Stefan, >> >> I have a question about the present OCSP RFC and at the end of the mail about >> the new situation which will happen according to your new proposal. >> >> The presence of the positive statement in OCSP response is important for >> electronic signature validations, especially for an expired certificate. >> Positive statement is the hash value of a certificate whose status is >> provided in OCSP response. >> >> Electronic signature validation is usually about the signatures created in >> the past and validated now, when the certificate is expired. >> >> When the certificate expires then revocation is usually removed from CRL and >> the revoked certificate can be provided as "good" in OCSP response. >> Is it acceptable? I think not. >> >> According to your new draft there is not defined a value of revocationTime. >> RFC must also define the value of revocationTime when the certificate which >> was never issued is as "revoked". >> http://www.ietf.org/rfcdiff?url2=draft-ietf-pkix-rfc2560bis-06 >> >> Have you also covered the situation when the certificate is expired, REMOVED >> FROM CRL and will be provided as revoked with incorrect revocationTime e.g. >> with the value before or after the revocationTime which was present in the >> removed record from CRL? >> Because according to sentence in your draft ""revoked" - This state SHOULD >> also be returned if the responder knows that the requested certificate has >> never been issued." the following situation can happen: when certificate is >> removed from CRL after expiration and CA/OCSP responder is responsible for >> this certificate but have not record about expired certificate and for that >> reason it is identified as "never been issued". >> >> ... >> revoked [1] IMPLICIT RevokedInfo, >> ... >> >> RevokedInfo ::= SEQUENCE { >> revocationTime GeneralizedTime, >> revocationReason [0] EXPLICIT CRLReason OPTIONAL } >> >> As you have mentioned in the mail: >> >> "On the "revoked" state, the old spec did not even consider the case of a >> certificate being requested where the OCSP responder knows that the >> certificate was never issued." >> >> "It simply recommend a known to be bad certificate to result >> in "revoked" in order to prevent damage as far as possible. It also opens >> for definition of new extensions through which such knowledge could be >> obtained." >> Peter Rybar >> National Security Authority >> Information Security and Electronic Signature Department >> Budatinska 30, 850 07 Bratislava 57, Slovak Republic >> e-mail: peter.rybar@nbusr.sk >> e-mail: peterryb@gmail.com >> >> >> -----Original Message----- >> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >> Stefan Santesson >> Sent: Monday, October 15, 2012 1:49 AM >> To: pkix@ietf.org >> Subject: [pkix] New draft-ietf-pkix-rfc2560bis-06 >> >> All, >> >> I have just posted an update of rfc2560bis (OCSP update) after carefully >> reviewing all comments on the list. >> >> Some notes about the update: >> >> - Added the previous OCSP editors with updated affiliations. >> - Added some calcifications on ResponderID as suggested by Simon Josefsson. >> - Updated the clarifications on Authorized responders. The requirements >> have not changed. I just tried to improve the text. >> - Updated a clarification on the "revoked" state to be the preferred >> response if a certificate is known by the responder to never have been >> issued. >> - Some minor editorial nits. >> >> >> Regarding backwards compatibility I mean that none of the clarifications >> changes RFC 2560. >> >> On Authorized responders it has always been the case that a responder >> certificate issued with the same key as was used to issue the certificate >> being checked for revocation, represents a valid Authorized responder. >> There has never been an explicit requirement to support key rollover and >> key rollover support has never been in the "spirit" of the original >> standard as it clearly attempted to provide direct cryptographic binding >> between the responder and the CA. >> >> On the "revoked" state, the old spec did not even consider the case of a >> certificate being requested where the OCSP responder knows that the >> certificate was never issued. It is clearly counterproductive to respond >> good when a certificate is known to be bad. A responder must pick one >> response and picking "revoked" breaks nothing, but has the desired effect, >> that is, to prevent the certificate from being accepted. The current text >> makes clear that there is no mechanism in the current standard by which a >> client can know how a responder will respond to a request for a not issued >> certificate. It simply recommend a known to be bad certificate to result >> in "revoked" in order to prevent damage as far as possible. It also opens >> for definition of new extensions through which such knowledge could be >> obtained. >> >> The current updates also clearly opens a path for the CAB forum efforts to >> define a suitable solution for server certificates. >> >> I have not, even thug suggested, added any requirements on what clients >> should do with the checked cert as a result of a particular response. I >> don't believe such requirements are suitable as it is policy and not >> protocol. We have no right to demand that all systems MUST reject any >> certificate for any reason as they may have a local policy that overrules >> the OCSP response. This protocol only provides information about the cert >> status, it does not mandate validation policy. >> >> I have not included any of the substantial changes i the Pinkas draft. I >> want to wait for a list of motivation for each change before including any >> of them. So there changed may be up for debate before this draft is ready >> for WGLC. >> >> /Stefan >> >> >> >> _______________________________________________ >> 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 >> >> _______________________________________________ pkix mailing list >> pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --B_3433508675_5906481 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Peter,

<= div>An OCSP responder is by default a service providing information about cu= rrent certificates.
The default response you get from an OCSP resp= onder is "good" unless the cert is known to be bad or not a cert the respond= er can provide status for.

If you need it to respon= d about old certificates, and as a client know that the responder does this = in a way that suits your needs, you will need to add an extension.
Such extension will not be part of the rfc256bis effort.

Is there any text in the current draft that you think is unclear on t= his?

/Stefan


From: Peter Rybar <rybar@nbusr.sk>
Date: Friday, October 19, 2012 3:12 PM
To:= 'Carl Wallace' <carl@= redhoundsoftware.com>, 'Simon Tardell' <simon@tardell.se>
Cc: 'Peter Rybar' <peterryb@gmail.com<= /a>>, Stefan Santesson <stefan@aaa= -sec.com>, <pkix@ietf.org>Subject: RE: [pkix] New draft-ietf-= pkix-rfc2560bis-06

Well, yes, sort of. You can only be sure to validate a signature at the moment of production. <= o:p>

 

=

What i= f the signature key was compromised at the moment of production but is not yet on a revocat= ion list?

[PR] According to clause 2.4  -  thisUpdate: The time at which the status being indicated = is known to be correct

It means when signature time-stamp time is X then any OCSP responses with thisUpdate time X+y are s= ufficient to validate because the status is correct.

Y is in the interval= <0, producedAt - X>

 

At any later point in time the signature key may be compromised, or the algorithms involved may have become to weak. (In which = case the time of revocation in the OCSP response is worth nothing to you). The r= isk increases as time passes. And of course, the revocation information may not= be kept around after the expiry of the certificate. 

 

= That's why you should validate signatures as soon as possible. 

=

 

For these archival purposes wouldn't it be better to have the final revocation list before rem= oved due to expiry?  In any case, you'd need verification information colle= cted after some grace period following moment of production.

[PR] Grace period is= not a fixed value of the time interval.

Grace period is changeable because the first OCSP response with thisUpdate time value > than time o= f signature time-stamp contains correct status.

 

 

If you need t= o ascertain that a signature was valid at a later time, you have to trust you= r system that it performed the validation at the time it first received the signature. That trust must be established through some kind of mix of polic= ies and technical measures (such as timestamping).

=

 

In the dark corner just beyond the dark corner that is SCVP, there's a spec (RFC 5276) that defines a binding of evidence records to artifacts that can be returned via= SCVP.  This provides for timestamping.  =

[PR] The vali= dation is simplified when OCSP response with positive statement as a hash value of requested certificate is used.

Positive statement is evidence that OCSP know the status of certificate and also protect the integrity of certificate with a new more secure hash algorithm.<= /span>

 

Peter Rybar

 


=
Simon Tardell, 

Technology Nexus.

On Fri, Oct 19, 2012 at 1:07 PM, Peter Rybar <rybar@nbusr.sk> wrote:

Stefan,

I have a question about the present OCSP RFC and at the end of the mail abo= ut the new situation which will happen according to your new proposal.

= The presence of the positive statement in OCSP response is important for electronic signature validations, especially for an expired certificate. Po= sitive statement is the hash value of a certificate whose status is provided in OC= SP response.

Electronic signature validation is usually about the signatures created in = the past and validated now, when the certificate is expired.

When the certificate expires then revocation is usually removed from CRL an= d the revoked certificate can be provided as "good" in OCSP response.
Is it acceptable? I think not.

According to your new draft there is not defined a value of revocationTime.=
RFC must also define the value of revocationTime when the certificate which= was never issued is as "revoked".
http://www.ietf.org/rfcdiff?u= rl2=3Ddraft-ietf-pkix-rfc2560bis-06

Have you also covered the situation when the certificate is expired, REMOVE= D FROM CRL and will be provided as revoked with incorrect revocationTime e.g.= with the value before or after the revocationTime which was present in the removed record from CRL?
Because according to sentence in your draft ""revoked" - This state SHOULD also be returned if the responder knows that the requested certificate has never been issued." the following situation can happen: when certificate is removed from CRL after expiration and CA/OCSP responder= is responsible for this certificate but have not record about expired certific= ate and for that reason it is identified as "never been issued".

...
revoked     [1]     IMPLICIT RevokedInfo,
...

   RevokedInfo ::=3D SEQUENCE {
       revocationTime          = ;    GeneralizedTime,
       revocationReason    [0]     EXPLICIT CRLReason OPTIONAL }

As you have mentioned in the mail:

"On the "revoked" state, the old spec did not even consider the case of a certificate being requested where the OCSP responder knows that the certifi= cate was never issued."

"It simply recommend a known to be bad certificate to result in "revoked" in order to prevent damage as far as possible. It also opens
for definition of new extensions through which such knowledge could be
obtained."

Peter Rybar
National Securi= ty Authority
Information Security and Electro= nic Signature Department
Budatinska 30, 850 0= 7 Bratislava 57, Slovak Republic
e-mail: peter.rybar@nbu= sr.sk
e-mail: peterryb@gmail.com


-----Original Message-----
From: pkix-bounces@ietf.org [mai= lto:pkix-bounces@ietf.org] On Beh= alf Of Stefan Santesson
Sent: Monday, October 15, 2012 1:49 AM
To: pkix@ietf.org
Subject: [pkix] New draft-ietf-pkix-rfc2560bis-06

All,

I have just posted an update of rfc2560bis (OCSP update) after carefully reviewing all comments on the list.

Some notes about the update:

- Added the previous OCSP editors with updated affiliations.
- Added some calcifications on ResponderID as suggested by Simon Josefsson.=
- Updated the clarifications on Authorized responders. The requirements
= have not changed. I just tried to improve the text.
- Updated a clarification on the "revoked" state to be the preferred
response if a certificate is known by the responder to never have been
issued.
- Some minor editorial nits.


Regarding backwards compatibility I mean that none of the clarifications changes RFC 2560.

On Authorized responders it has always been the case that a responder
certificate issued with the same key as was used to issue the certificate being checked for revocation, represents a valid Authorized responder.
There has never been an explicit requirement to support key rollover and key rollover support has never been in the "spirit" of the original
standard as it clearly attempted to provide direct cryptographic binding between the responder and the CA.

On the "revoked" state, the old spec did not even consider the case of a
certificate being requested where the OCSP responder knows that the
certificate was never issued. It is clearly counterproductive to respond good when a certificate is known to be bad. A responder must pick one
response and picking "revoked" breaks nothing, but has the desired effect,
that is, to prevent the certificate from being accepted. The current text makes clear that there is no mechanism in the current standard by which a client can know how a responder will respond to a request for a not issued<= br> certificate. It simply recommend a known to be bad certificate to result in "revoked" in order to prevent damage as far as possible. It also opens
for definition of new extensions through which such knowledge could be
obtained.

The current updates also clearly opens a path for the CAB forum efforts to<= br> define a suitable solution for server certificates.

I have not, even thug suggested, added any requirements on what clients
= should do with the checked cert as a result of a particular response. I
= don't believe such requirements are suitable as it is policy and not
protocol. We have no right to demand that all systems MUST reject any
certificate for any reason as they may have a local policy that overrules the OCSP response. This protocol only provides information about the cert status, it does not mandate validation policy.

I have not included any of the substantial changes i the Pinkas draft. I want to wait for a list of motivation for each change before including any<= br> of them. So there changed may be up for debate before this draft is ready for WGLC.

/Stefan



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

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

 

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

--B_3433508675_5906481-- From piyush@ditenity.com Fri Oct 19 08:05:14 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80DB821F85E7 for ; Fri, 19 Oct 2012 08:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.031 X-Spam-Level: X-Spam-Status: No, score=-3.031 tagged_above=-999 required=5 tests=[AWL=0.568, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gj9K4yyS18HR for ; Fri, 19 Oct 2012 08:05:13 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 91EC421F84B3 for ; Fri, 19 Oct 2012 08:05:13 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id o25so463355iad.31 for ; Fri, 19 Oct 2012 08:05:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language:x-gm-message-state; bh=1LFWkyRezoEqNKqJ2Rr2zH42vW3JlMLCD509aSHge1Y=; b=QyxGwVSFUeNT4G9qIMUOaHYh0SY7mBxdwdtDFVAmhF9KV+rjgGDVq8L9dqwIQotO12 nMlXXHEsdpmQGKvcNZyyqybLzOi+9aiR3zSQjjMs54eYjvesH0IkYm4IgvzxWzAJXxKA 9vsF0J9S/BVKcfbTlXbMl8dKZvBTNeNlvjMKHw7YDQD8iNnsSxz1yQ+c6Dvygkmzna4T mvf+kYrLKeZ6K3DLopUA1l17JcKhBuKew/4Az47xP8bkD2c8Fm/NtbKSY203XYo9kVvi T07K/BEFUqwFcc4T3VrUSXS31ujoNKCGYDchJqtEKD2BYepBlBI9Ro7KlN6LI025A7T6 ZZRg== Received: by 10.50.214.66 with SMTP id ny2mr1647404igc.21.1350659112908; Fri, 19 Oct 2012 08:05:12 -0700 (PDT) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id u4sm1583361igw.6.2012.10.19.08.05.10 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 19 Oct 2012 08:05:11 -0700 (PDT) From: "Piyush Jain" To: "'Stefan Santesson'" , "'Peter Yee'" , "'Stephen Kent'" , "'pkix'" References: <029801cdaa7d$f024a620$d06df260$@akayla.com> In-Reply-To: Date: Fri, 19 Oct 2012 08:04:56 -0700 Message-ID: <05a101cdae0b$1b7702b0$52650810$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGWk8Pv5cL/UrX4AzBeyewPR0WznZgu6bGw Content-Language: en-us X-Gm-Message-State: ALoCoQmJCr+jgFNU/IskFUEkAL1asEGrlgQLE4e446tkMnDdwOfYK62NtIlyu7BhJKZcl6h/nVbe Subject: Re: [pkix] 5280bis X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 15:05:14 -0000 The few implementations that I've worked do not check for critical entry extension unless/until - There is a CRL extension that says that CRL entry extension (IDP with indirect CRL bit on) may impact the whole CRL. In this case the CRL is just rejected. I have not seen a single implementation supporting indirect CRLs. - A CRL entry matches the certificate in question. At that point the CRL entry is scanned for unknown critical extensions. If there are any, the certificate is considered unknown. So in a way these implementations are not compliant with 5280, but it does not seem to matter there are no CA deployments out there that create CRLs with critical CRL entry extensions. Just to give you a perspective, these implementations are deployed not only at some of the biggest enterprises (PKI size) but also at a few public CAs. -Piyush > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > Stefan Santesson > Sent: Friday, October 19, 2012 2:21 AM > To: Peter Yee; 'Stephen Kent'; 'pkix' > Subject: Re: [pkix] 5280bis > > This is too late for the poll, but a question came to my mind this week after > an ETSI meeting, so I will just post it. > > The current text requires me to reject a CRL as source of revocation > information if ANY entry includes an unrecognised extension. > So thinking as an implementer, I just wander how this works in practice. > > Consider I have a 100 MB CRL. > I then have to go through each entry and determine if any of them have an > unrecognised extension before I use it. > Just going to the entry of interest is not enough, since another entry may > have an unrecognised extension. > > Is this how implementations work today? > > /Stefan > > > > > > On 10/15/12 4:36 AM, "Peter Yee" wrote: > > >Version -10 has been uploaded and the sole change (outside of the > >name/dates) is the removal of the contentious text. Please let me know > >if there are any other changes that need to be made. I'm hoping we're > >sufficiently controversy free so that we can move the document forward. > > > >Thanks. > > -Peter > > > >-----Original Message----- > >From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > >Stephen Kent > >Sent: Thursday, October 11, 2012 2:45 PM > >To: pkix > >Subject: [pkix] 5280bis > > > >The PKIX list has not demonstrated consensus for the CRL entry > >extension text I suggested, or any other, since Russ sent his message > >on this topic on 10/3, over a week ago. > > > >Consistent with Russ's direction, I have asked Peter Yee to remove the > >Section 4 text from 5280bis and publish version -10. > > > >I have begun preparation of the IESG report for the redacted version of > >the doc. > > > >Steve > >_______________________________________________ > >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 > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From iesg-secretary@ietf.org Fri Oct 19 08:28:00 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC0C721F8487; Fri, 19 Oct 2012 08:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gYFQvmutbUM; Fri, 19 Oct 2012 08:28:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7943921F845C; Fri, 19 Oct 2012 08:28:00 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121019152800.17968.8544.idtracker@ietfa.amsl.com> Date: Fri, 19 Oct 2012 08:28:00 -0700 Cc: pkix@ietf.org Subject: [pkix] Last Call: (DNS Certification Authority Authorization (CAA) Resource Record) to Proposed Standard X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 15:28:01 -0000 The IESG has received a request from the Public-Key Infrastructure (X.509) WG (pkix) to consider the following document: - 'DNS Certification Authority Authorization (CAA) Resource Record' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-11-02. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain. CAA resource records allow a public Certification Authority to implement additional controls to reduce the risk of unintended certificate mis-issue. This document defines the syntax of the CAA record and rules for processing CAA records by certificate issuers. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pkix-caa/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pkix-caa/ballot/ No IPR declarations have been submitted directly on this I-D. From stefan@aaa-sec.com Fri Oct 19 08:28:46 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A60D21F87B1 for ; Fri, 19 Oct 2012 08:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.95 X-Spam-Level: X-Spam-Status: No, score=-101.95 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, HELO_EQ_SE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTj6N-jD9H6p for ; Fri, 19 Oct 2012 08:28:46 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 93FC221F8479 for ; Fri, 19 Oct 2012 08:28:45 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 7EE4022BE49C for ; Fri, 19 Oct 2012 17:28:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id XpTTGGaaI5t2 for ; Fri, 19 Oct 2012 17:28:10 +0200 (CEST) Received: from s331.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 136C322BDFFF for ; Fri, 19 Oct 2012 17:28:10 +0200 (CEST) Received: (qmail 6091 invoked from network); 19 Oct 2012 15:28:09 -0000 Received: from 81-232-51-61-no39.business.telia.com (HELO [192.168.0.108]) (stefan@fiddler.nu@[81.232.51.61]) (envelope-sender ) by s331.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 19 Oct 2012 15:28:09 -0000 User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Fri, 19 Oct 2012 17:28:09 +0200 From: Stefan Santesson To: Piyush Jain , 'Peter Yee' , 'Stephen Kent' , 'pkix' Message-ID: Thread-Topic: [pkix] 5280bis In-Reply-To: <05a101cdae0b$1b7702b0$52650810$@ditenity.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [pkix] 5280bis X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 15:28:46 -0000 I suspect that you are right. In particular on the point that I don't think any of this matters in real implementations. But it reinforces my impression that the current text in RFC 5280 simply represents bad engineering. That is, information that effects the processing of the complete CRL, should not be hidden in a CRL entry. It's begging for problems and will most probably never be correctly implemented. So personally I regret that the corrected paragraph was removed. It represented a lot cleaner software design. /Stefan On 10/19/12 5:04 PM, "Piyush Jain" wrote: >The few implementations that I've worked do not check for critical entry >extension unless/until >- There is a CRL extension that says that CRL entry extension (IDP with >indirect CRL bit on) may impact the whole CRL. In this case the CRL is >just >rejected. I have not seen a single implementation supporting indirect >CRLs. >- A CRL entry matches the certificate in question. At that point the CRL >entry is scanned for unknown critical extensions. If there are any, the >certificate is considered unknown. >So in a way these implementations are not compliant with 5280, but it does >not seem to matter there are no CA deployments out there that create CRLs >with critical CRL entry extensions. > >Just to give you a perspective, these implementations are deployed not >only >at some of the biggest enterprises (PKI size) but also at a few public >CAs. > >-Piyush > >> -----Original Message----- >> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >> Stefan Santesson >> Sent: Friday, October 19, 2012 2:21 AM >> To: Peter Yee; 'Stephen Kent'; 'pkix' >> Subject: Re: [pkix] 5280bis >> >> This is too late for the poll, but a question came to my mind this week >after >> an ETSI meeting, so I will just post it. >> >> The current text requires me to reject a CRL as source of revocation >> information if ANY entry includes an unrecognised extension. >> So thinking as an implementer, I just wander how this works in practice. >> >> Consider I have a 100 MB CRL. >> I then have to go through each entry and determine if any of them have >>an >> unrecognised extension before I use it. >> Just going to the entry of interest is not enough, since another entry >>may >> have an unrecognised extension. >> >> Is this how implementations work today? >> >> /Stefan >> >> >> >> >> >> On 10/15/12 4:36 AM, "Peter Yee" wrote: >> >> >Version -10 has been uploaded and the sole change (outside of the >> >name/dates) is the removal of the contentious text. Please let me know >> >if there are any other changes that need to be made. I'm hoping we're >> >sufficiently controversy free so that we can move the document forward. >> > >> >Thanks. >> > -Peter >> > >> >-----Original Message----- >> >From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >> >Stephen Kent >> >Sent: Thursday, October 11, 2012 2:45 PM >> >To: pkix >> >Subject: [pkix] 5280bis >> > >> >The PKIX list has not demonstrated consensus for the CRL entry >> >extension text I suggested, or any other, since Russ sent his message >> >on this topic on 10/3, over a week ago. >> > >> >Consistent with Russ's direction, I have asked Peter Yee to remove the >> >Section 4 text from 5280bis and publish version -10. >> > >> >I have begun preparation of the IESG report for the redacted version of >> >the doc. >> > >> >Steve >> >_______________________________________________ >> >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 >> >> >> _______________________________________________ >> 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 piyush@ditenity.com Fri Oct 19 10:34:42 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1309E21F870C for ; Fri, 19 Oct 2012 10:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.102 X-Spam-Level: X-Spam-Status: No, score=-3.102 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMklpukROjVo for ; Fri, 19 Oct 2012 10:34:35 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 97C2821F8741 for ; Fri, 19 Oct 2012 10:34:35 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id o25so594066iad.31 for ; Fri, 19 Oct 2012 10:34:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language :x-gm-message-state; bh=/ir2L2WUJYoK2GqgtFXLLh9kLrDuSavmBu2mrQecctU=; b=l0L80xTCHWg/7pmQFGikf8yo8W9p3XYzwS1L1UoZ5C/QNvkoHM2SMl+tqnPyCVMVOW pkAHkz8v86h8y/Aht7N1b2ZKX43vosSmT7K/IM73bLscxNSci7/GJMuZk2vS9gRPJ/ZR Bg88BuirimlduLFAFzWLW6a62JTtb2PtDBzyGD/98Ct9mE2bVEWPB92Ksh5uE+47L24J TBYBH+k+m3tbWuS+IutM5FVresGUoyZoDUD4pT8RxI3ZIdtLNZEdHsybhy5yYxgOupve 7zLA+du/+9dJQQLMfMYwh1Io+MvP8JDBr3yOHQVphqZaWh4/8WL/CfDp/YX/xdELptlp +GGw== Received: by 10.50.42.231 with SMTP id r7mr9374645igl.60.1350668074798; Fri, 19 Oct 2012 10:34:34 -0700 (PDT) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id rd10sm6797340igb.1.2012.10.19.10.34.31 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 19 Oct 2012 10:34:33 -0700 (PDT) From: "Piyush Jain" To: "'Stefan Santesson'" , "'Peter Rybar'" , "'Carl Wallace'" , "'Simon Tardell'" References: <201210191312.q9JDCHnw046175@mail.nbusr.sk> In-Reply-To: Date: Fri, 19 Oct 2012 10:34:16 -0700 Message-ID: <05df01cdae1f$f8737db0$e95a7910$@ditenity.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_05E0_01CDADE5.4C19AEC0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQK0nKe03xqVXp3V9Hu1fpQ9zPVxo5Xy+Muw Content-Language: en-us X-Gm-Message-State: ALoCoQlxu8WO6dD0HrQqVRsmbk+Er6Gl+AftsVEOBqo8vSg/7hFCjF/8iEdpTQyvwgpfpgr+pTdC Cc: 'Peter Rybar' , pkix@ietf.org Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 17:34:42 -0000 This is a multipart message in MIME format. ------=_NextPart_000_05E0_01CDADE5.4C19AEC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Stefan, I think some of you interpretations below are twisted to accommodate the new provisions for providing revoked responses for unissued certificates. Providing responses for expired certificates is within the scope of 2560 using archive cutoff extension. The original authors of 2560 can correct me if I'm wrong, but it is my understanding that a response from OCSP responder is not supposed to indicate if a certificate is good or bad but to indicate if a certificate is revoked or unrevoked by the issuing authority. The fact that certificate is issued by the CA is checked by the RP by verifying the signature on the certificate. This draft introduces the concept of returning revoked responses for unissued certificates. There are many unintended consequences of this approach - Revocation statuses become non-deterministic based on who you are asking (A responder with access to CA database vs. one without vs. checking status off a CRL). If I'm archiving a signed document with the relevant artifacts to determine the validity status of the document, this becomes a huge problem. Note that a revoked status implies that certificate was good between the time of its issuance and that of its revocation. Any document that is signed within that period should still be considered valid. - It would confuse an implementer about what "non-issued" means. The fact that the CA signed the certificate implies it was issued. If a certificate is issued fraudulently, based on its security practices, it is up to the CA to either revoke the issued certificate, or ask its issuing authority to revoke its own certificate. -Piyush From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Stefan Santesson Sent: Friday, October 19, 2012 7:25 AM To: Peter Rybar; 'Carl Wallace'; 'Simon Tardell' Cc: 'Peter Rybar'; pkix@ietf.org Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Peter, An OCSP responder is by default a service providing information about current certificates. The default response you get from an OCSP responder is "good" unless the cert is known to be bad or not a cert the responder can provide status for. If you need it to respond about old certificates, and as a client know that the responder does this in a way that suits your needs, you will need to add an extension. Such extension will not be part of the rfc256bis effort. Is there any text in the current draft that you think is unclear on this? /Stefan From: Peter Rybar Date: Friday, October 19, 2012 3:12 PM To: 'Carl Wallace' , 'Simon Tardell' Cc: 'Peter Rybar' , Stefan Santesson , Subject: RE: [pkix] New draft-ietf-pkix-rfc2560bis-06 Well, yes, sort of. You can only be sure to validate a signature at the moment of production. What if the signature key was compromised at the moment of production but is not yet on a revocation list? [PR] According to clause 2.4 - thisUpdate: The time at which the status being indicated is known to be correct It means when signature time-stamp time is X then any OCSP responses with thisUpdate time X+y are sufficient to validate because the status is correct. Y is in the interval <0, producedAt - X> At any later point in time the signature key may be compromised, or the algorithms involved may have become to weak. (In which case the time of revocation in the OCSP response is worth nothing to you). The risk increases as time passes. And of course, the revocation information may not be kept around after the expiry of the certificate. That's why you should validate signatures as soon as possible. For these archival purposes wouldn't it be better to have the final revocation list before removed due to expiry? In any case, you'd need verification information collected after some grace period following moment of production. [PR] Grace period is not a fixed value of the time interval. Grace period is changeable because the first OCSP response with thisUpdate time value > than time of signature time-stamp contains correct status. If you need to ascertain that a signature was valid at a later time, you have to trust your system that it performed the validation at the time it first received the signature. That trust must be established through some kind of mix of policies and technical measures (such as timestamping). In the dark corner just beyond the dark corner that is SCVP, there's a spec (RFC 5276) that defines a binding of evidence records to artifacts that can be returned viaSCVP. This provides for timestamping. [PR] The validation is simplified when OCSP response with positive statement as a hash value of requested certificate is used. Positive statement is evidence that OCSP know the status of certificate and also protect the integrity of certificate with a new more secure hash algorithm. Peter Rybar Simon Tardell, Technology Nexus. On Fri, Oct 19, 2012 at 1:07 PM, Peter Rybar wrote: Stefan, I have a question about the present OCSP RFC and at the end of the mail about the new situation which will happen according to your new proposal. The presence of the positive statement in OCSP response is important for electronic signature validations, especially for an expired certificate. Positive statement is the hash value of a certificate whose status is provided in OCSP response. Electronic signature validation is usually about the signatures created in the past and validated now, when the certificate is expired. When the certificate expires then revocation is usually removed from CRL and the revoked certificate can be provided as "good" in OCSP response. Is it acceptable? I think not. According to your new draft there is not defined a value of revocationTime. RFC must also define the value of revocationTime when the certificate which was never issued is as "revoked". http://www.ietf.org/rfcdiff?url2=draft-ietf-pkix-rfc2560bis-06 Have you also covered the situation when the certificate is expired, REMOVED FROM CRL and will be provided as revoked with incorrect revocationTime e.g.with the value before or after the revocationTime which was present in the removed record from CRL? Because according to sentence in your draft ""revoked" - This state SHOULD also be returned if the responder knows that the requested certificate has never been issued." the following situation can happen: when certificate is removed from CRL after expiration and CA/OCSP responder is responsible for this certificate but have not record about expired certificate and for that reason it is identified as "never been issued". ... revoked [1] IMPLICIT RevokedInfo, ... RevokedInfo ::= SEQUENCE { revocationTime GeneralizedTime, revocationReason [0] EXPLICIT CRLReason OPTIONAL } As you have mentioned in the mail: "On the "revoked" state, the old spec did not even consider the case of a certificate being requested where the OCSP responder knows that the certificate was never issued." "It simply recommend a known to be bad certificate to result in "revoked" in order to prevent damage as far as possible. It also opens for definition of new extensions through which such knowledge could be obtained." Peter Rybar National Security Authority Information Security and Electronic Signature Department Budatinska 30, 850 07 Bratislava 57, Slovak Republic e-mail: peter.rybar@nbusr.sk e-mail: peterryb@gmail.com -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Stefan Santesson Sent: Monday, October 15, 2012 1:49 AM To: pkix@ietf.org Subject: [pkix] New draft-ietf-pkix-rfc2560bis-06 All, I have just posted an update of rfc2560bis (OCSP update) after carefully reviewing all comments on the list. Some notes about the update: - Added the previous OCSP editors with updated affiliations. - Added some calcifications on ResponderID as suggested by Simon Josefsson. - Updated the clarifications on Authorized responders. The requirements have not changed. I just tried to improve the text. - Updated a clarification on the "revoked" state to be the preferred response if a certificate is known by the responder to never have been issued. - Some minor editorial nits. Regarding backwards compatibility I mean that none of the clarifications changes RFC 2560. On Authorized responders it has always been the case that a responder certificate issued with the same key as was used to issue the certificate being checked for revocation, represents a valid Authorized responder. There has never been an explicit requirement to support key rollover and key rollover support has never been in the "spirit" of the original standard as it clearly attempted to provide direct cryptographic binding between the responder and the CA. On the "revoked" state, the old spec did not even consider the case of a certificate being requested where the OCSP responder knows that the certificate was never issued. It is clearly counterproductive to respond good when a certificate is known to be bad. A responder must pick one response and picking "revoked" breaks nothing, but has the desired effect, that is, to prevent the certificate from being accepted. The current text makes clear that there is no mechanism in the current standard by which a client can know how a responder will respond to a request for a not issued certificate. It simply recommend a known to be bad certificate to result in "revoked" in order to prevent damage as far as possible. It also opens for definition of new extensions through which such knowledge could be obtained. The current updates also clearly opens a path for the CAB forum efforts to define a suitable solution for server certificates. I have not, even thug suggested, added any requirements on what clients should do with the checked cert as a result of a particular response. I don't believe such requirements are suitable as it is policy and not protocol. We have no right to demand that all systems MUST reject any certificate for any reason as they may have a local policy that overrules the OCSP response. This protocol only provides information about the cert status, it does not mandate validation policy. I have not included any of the substantial changes i the Pinkas draft. I want to wait for a list of motivation for each change before including any of them. So there changed may be up for debate before this draft is ready for WGLC. /Stefan _______________________________________________ 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 _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix ------=_NextPart_000_05E0_01CDADE5.4C19AEC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stefan,

 

I think some of you interpretations below are twisted to accommodate = the new provisions for providing revoked responses for unissued = certificates.

Providing responses for expired certificates is within the scope of = 2560 using archive cutoff extension.

 

The original authors of 2560 can correct me if I’m wrong, but = it is my understanding that a response from OCSP responder is not = supposed to indicate if a certificate is good or bad but to indicate if = a certificate is revoked or unrevoked by the issuing authority. The fact = that certificate is issued by the CA is checked by the RP by verifying = the signature on the certificate.

 

This draft introduces the concept of returning revoked responses for = unissued certificates. There are many unintended consequences of this = approach

-          = Revocation statuses become non-deterministic based on who you are = asking (A responder with access to CA database vs. one without vs. = checking status off a CRL). If I’m archiving a signed document = with the relevant artifacts to determine the validity status of the = document, this becomes a huge problem. Note that a revoked status = implies that certificate was good between the time of its issuance and = that of its revocation. Any document that is signed within that period = should still be considered valid.

-          = It would confuse an implementer about what “non-issued” = means. The fact that the CA signed the certificate implies it was = issued. If a certificate is issued fraudulently, based on its security = practices, it is up to the CA to either revoke the issued certificate, = or ask its issuing authority to revoke its own = certificate.

 

-Piyush

 

 

 

 

From:= = pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of = Stefan Santesson
Sent: Friday, October 19, 2012 7:25 = AM
To: Peter Rybar; 'Carl Wallace'; 'Simon = Tardell'
Cc: 'Peter Rybar'; pkix@ietf.org
Subject: = Re: [pkix] New = draft-ietf-pkix-rfc2560bis-06

 

Peter,

 

An OCSP responder is by default a service providing information about = current certificates.

The default response you get from an OCSP responder is "good" = unless the cert is known to be bad or not a cert the responder can = provide status for.

 

If you need it to respond about old certificates, and as a client know = that the responder does this in a way that suits your needs, you will = need to add an extension.

Such extension will not be part of the rfc256bis = effort.

 

Is there any text in the current draft that you think is unclear on = this?

 

/Stefan

 

 

From: Peter Rybar <rybar@nbusr.sk>
Date: = Friday, October 19, 2012 3:12 PM
To: 'Carl Wallace' <carl@redhoundsoftware.com&g= t;, 'Simon Tardell' <simon@tardell.se>
Cc: = 'Peter Rybar' <peterryb@gmail.com>, Stefan = Santesson <stefan@aaa-sec.com>, <pkix@ietf.org>
Subject: = RE: [pkix] New = draft-ietf-pkix-rfc2560bis-06

 

Well, yes, sort of. You can only be sure to validate a signature at the = moment of production.

 

What if the signature key was compromised at the moment of production = but is not yet on a revocation list?

[P= R] According to clause 2.4  -  thisUpdate: The time at which = the status being indicated is known to be correct

It= means when signature time-stamp time is X then any OCSP responses with = thisUpdate time X+y are sufficient to validate because the status is = correct.

Y = is in the interval <0, producedAt - X>

 

At any later point in time the signature key may be compromised, or the = algorithms involved may have become to weak. (In which case the time of = revocation in the OCSP response is worth nothing to you). The risk = increases as time passes. And of course, the revocation information may = not be kept around after the expiry of the = certificate. 

 

That's why you should validate signatures as soon as = possible. 

 

For these archival purposes wouldn't it be better to have the final = revocation list before removed due to expiry?  In any case, you'd = need verification information collected after some grace period = following moment of production.

[P= R] Grace period is not a fixed value of the time interval.

Gr= ace period is changeable because the first OCSP response with thisUpdate = time value > than time of signature time-stamp contains correct = status.

 

 

If you need to ascertain that a signature was valid at a later time, = you have to trust your system that it performed the validation at the = time it first received the signature. That trust must be established = through some kind of mix of policies and technical measures (such as = timestamping).

 

In the dark corner just beyond the dark corner that is SCVP, there's a = spec (RFC 5276) that defines a binding of evidence records to artifacts = that can be returned viaSCVP.  This provides for timestamping. =  

[P= R] The validation is simplified when OCSP response with positive = statement as a hash value of requested certificate is used.

Po= sitive statement is evidence that OCSP know the status of certificate = and also protect the integrity of certificate with a new more secure = hash algorithm.

=  

Pe= ter Rybar

&n= bsp;



Simon Tardell, 

Technology Nexus.

On Fri, Oct 19, 2012 at 1:07 PM, Peter Rybar <rybar@nbusr.sk> = wrote:

Stefan,

I have a question about the present OCSP RFC and at the = end of the mail about the new situation which will happen according to = your new proposal.

The presence of the positive statement in OCSP = response is important for electronic signature validations, especially = for an expired certificate. Positive statement is the hash value of a = certificate whose status is provided in OCSP response.

Electronic = signature validation is usually about the signatures created in the past = and validated now, when the certificate is expired.

When the = certificate expires then revocation is usually removed from CRL and the = revoked certificate can be provided as "good" in OCSP = response.
Is it acceptable? I think not.

According to your new = draft there is not defined a value of revocationTime.
RFC must also = define the value of revocationTime when the certificate which was never = issued is as "revoked".
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pkix-rfc2= 560bis-06

Have you also covered the situation when the = certificate is expired, REMOVED FROM CRL and will be provided as revoked = with incorrect revocationTime e.g.with the value before or after the = revocationTime which was present in the removed record from = CRL?
Because according to sentence in your draft = ""revoked" - This state SHOULD also be returned if the = responder knows that the requested certificate has never been = issued." the following situation can happen: when certificate is = removed from CRL after expiration and CA/OCSP responder is responsible = for this certificate but have not record about expired certificate and = for that reason it is identified as "never been = issued".

...
revoked     [1]     = IMPLICIT RevokedInfo,
...

   RevokedInfo ::=3D = SEQUENCE {
       revocationTime     =          GeneralizedTime,
    =    revocationReason    [0]     EXPLICIT = CRLReason OPTIONAL }

As you have mentioned in the = mail:

"On the "revoked" state, the old spec did not even = consider the case of a certificate being requested where the OCSP = responder knows that the certificate was never issued."

"It simply recommend a known to be bad certificate to result
in = "revoked" in order to prevent damage as far as possible. It = also opens
for definition of new extensions through which such = knowledge could be
obtained."

Peter Rybar
National Security Authority
Information Security and Electronic Signature = Department
Budatinska 30, 850 07 = Bratislava 57, Slovak Republic
e-mail: peter.rybar@nbusr.sk
<= span class=3Dhoenzb>e-mail: peterryb@gmail.com


-----Original Message-----
From: pkix-bounces@ietf.org = [mailto:pkix-bounces@ietf.org] On = Behalf Of Stefan Santesson
Sent: Monday, October 15, 2012 1:49 = AM
To: pkix@ietf.org
Subject: = [pkix] New draft-ietf-pkix-rfc2560bis-06

All,

I have just = posted an update of rfc2560bis (OCSP update) after = carefully
reviewing all comments on the list.

Some notes about = the update:

- Added the previous OCSP editors with updated = affiliations.
- Added some calcifications on ResponderID as suggested = by Simon Josefsson.
- Updated the clarifications on Authorized = responders. The requirements
have not changed. I just tried to = improve the text.
- Updated a clarification on the = "revoked" state to be the preferred
response if a = certificate is known by the responder to never have been
issued.
- = Some minor editorial nits.


Regarding backwards compatibility = I mean that none of the clarifications
changes RFC 2560.

On = Authorized responders it has always been the case that a = responder
certificate issued with the same key as was used to issue = the certificate
being checked for revocation, represents a valid = Authorized responder.
There has never been an explicit requirement to = support key rollover and
key rollover support has never been in the = "spirit" of the original
standard as it clearly attempted = to provide direct cryptographic binding
between the responder and the = CA.

On the "revoked" state, the old spec did not even = consider the case of a
certificate being requested where the OCSP = responder knows that the
certificate was never issued. It is clearly = counterproductive to respond
good when a certificate is known to be = bad. A responder must pick one
response and picking = "revoked" breaks nothing, but has the desired effect,
that = is, to prevent the certificate from being accepted. The current = text
makes clear that there is no mechanism in the current standard = by which a
client can know how a responder will respond to a request = for a not issued
certificate. It simply recommend a known to be bad = certificate to result
in "revoked" in order to prevent = damage as far as possible. It also opens
for definition of new = extensions through which such knowledge could be
obtained.

The = current updates also clearly opens a path for the CAB forum efforts = to
define a suitable solution for server certificates.

I have = not, even thug suggested, added any requirements on what = clients
should do with the checked cert as a result of a particular = response. I
don't believe such requirements are suitable as it is = policy and not
protocol. We have no right to demand that all systems = MUST reject any
certificate for any reason as they may have a local = policy that overrules
the OCSP response. This protocol only provides = information about the cert
status, it does not mandate validation = policy.

I have not included any of the substantial changes i the = Pinkas draft. I
want to wait for a list of motivation for each change = before including any
of them. So there changed may be up for debate = before this draft is ready
for = WGLC.

/Stefan



_____________________________________= __________
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

 

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

------=_NextPart_000_05E0_01CDADE5.4C19AEC0-- From david.cooper@nist.gov Fri Oct 19 11:32:59 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C60B521F87A6 for ; Fri, 19 Oct 2012 11:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.141 X-Spam-Level: X-Spam-Status: No, score=-5.141 tagged_above=-999 required=5 tests=[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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJW74x03zHkL for ; Fri, 19 Oct 2012 11:32:59 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id BDD6621F85ED for ; Fri, 19 Oct 2012 11:32:58 -0700 (PDT) Received: from WSGHUB2.xchange.nist.gov (129.6.16.197) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.379.0; Fri, 19 Oct 2012 14:32:48 -0400 Received: from smtp.nist.gov (129.6.16.226) by smtp-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.1.421.2; Fri, 19 Oct 2012 14:29:45 -0400 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 q9JIWv2q028147 for ; Fri, 19 Oct 2012 14:32:57 -0400 Message-ID: <50819CD9.5070606@nist.gov> Date: Fri, 19 Oct 2012 14:32:57 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120829 Thunderbird/15.0 MIME-Version: 1.0 To: "pkix@ietf.org" References: <201210191107.q9JB7m62045167@mail.nbusr.sk> In-Reply-To: <201210191107.q9JB7m62045167@mail.nbusr.sk> Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 18:32:59 -0000
On 10/19/2012 07:07 AM, Peter Rybar wrote:
Because according to sentence in your draft ""revoked" - This state SHOULD also be returned if the responder knows that the requested certificate has never been issued." the following situation can happen: when certificate is removed from CRL after expiration and CA/OCSP responder is responsible for this certificate but have not record about expired certificate and for that reason it is identified as "never been issued".

Peter,

There seems to be disagreement on this, but I think that the situation described above needs to be prohibited.  If a responder is going to use "revoked" as a response for a certificate that has never been issued, then it must remember every certificate that has ever been issued, even ones that have been revoked.  Technically, this is what the text requires, since it only permits the "revoked" response in two cases (1) the certificate has been revoked and (2) the responder knows that the certificate has never been issued.  Providing a response of "revoked" for an expired certificate that was never revoked would be incorrect.

Some may argue that as long as the response does not include an archive cutoff extension, it doesn't matter if the response indicates a status of "revoked" even if the certificate was issued and was not revoked.  However, RFC 2560 only says that OCSP servers that provide status information about revoked certificates SHOULD include the archive cutoff extension.  So, an RFC 2560-compliant responser that maintains information about expired certificates could provide a response of "revoked" for an expired certificate without including the archive cutoff extension, and a client should be able to take the response to mean that the certificate was revoked.  If the situation you describe were allowed, then a client could receive a response of "revoked" for an expired certificate that had not been revoked.  While clients could be designed to treat the response status for an expired certificate as meaningless unless the archive cutoff extension is present, that would be a non-backward compatible change from the current specification.

Dave

From yngve@opera.com Fri Oct 19 11:36:57 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EAF521F87A6 for ; Fri, 19 Oct 2012 11:36:57 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWmvkbrjtBvD for ; Fri, 19 Oct 2012 11:36:56 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2A69021F85B0 for ; Fri, 19 Oct 2012 11:36:55 -0700 (PDT) Received: from acorna.invalid.invalid (pat-tdc.opera.com [213.236.208.22]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q9JIasQw002790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 19 Oct 2012 18:36:54 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: pkix@ietf.org References: Date: Fri, 19 Oct 2012 20:37:08 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen (Developer Opera Software ASA)" Organization: Opera Software AS Message-ID: In-Reply-To: User-Agent: Opera Mail/11.64 (Win32) Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 18:36:57 -0000 On Mon, 15 Oct 2012 01:49:29 +0200, Stefan Santesson wrote: > - Updated a clarification on the "revoked" state to be the preferred > response if a certificate is known by the responder to never have been > issued. Very good. Thank you. -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 96 90 41 51 Fax: +47 23 69 24 01 ******************************************************************** From david.cooper@nist.gov Fri Oct 19 11:41:34 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E3F21F87BF for ; Fri, 19 Oct 2012 11:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.141 X-Spam-Level: X-Spam-Status: No, score=-5.141 tagged_above=-999 required=5 tests=[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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHioLFLhMPZx for ; Fri, 19 Oct 2012 11:41:34 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id DAFAA21F869C for ; Fri, 19 Oct 2012 11:41:33 -0700 (PDT) Received: from WSGHUB2.xchange.nist.gov (129.6.42.35) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.379.0; Fri, 19 Oct 2012 14:40:51 -0400 Received: from smtp.nist.gov (129.6.16.226) by smtp-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.1.421.2; Fri, 19 Oct 2012 14:37:59 -0400 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 q9JIfBr1023310 for ; Fri, 19 Oct 2012 14:41:11 -0400 Message-ID: <50819EC7.7050405@nist.gov> Date: Fri, 19 Oct 2012 14:41:11 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120829 Thunderbird/15.0 MIME-Version: 1.0 To: "pkix@ietf.org" References: <201210191107.q9JB7m62045167@mail.nbusr.sk> <50819CD9.5070606@nist.gov> In-Reply-To: <50819CD9.5070606@nist.gov> Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 18:41:34 -0000
In the second sentence I meant to say "even ones that have expired."

On 10/19/2012 02:32 PM, David A. Cooper wrote:
On 10/19/2012 07:07 AM, Peter Rybar wrote:
Because according to sentence in your draft ""revoked" - This state SHOULD also be returned if the responder knows that the requested certificate has never been issued." the following situation can happen: when certificate is removed from CRL after expiration and CA/OCSP responder is responsible for this certificate but have not record about expired certificate and for that reason it is identified as "never been issued".

Peter,

There seems to be disagreement on this, but I think that the situation described above needs to be prohibited.  If a responder is going to use "revoked" as a response for a certificate that has never been issued, then it must remember every certificate that has ever been issued, even ones that have been revoked.  Technically, this is what the text requires, since it only permits the "revoked" response in two cases (1) the certificate has been revoked and (2) the responder knows that the certificate has never been issued.  Providing a response of "revoked" for an expired certificate that was never revoked would be incorrect.

Some may argue that as long as the response does not include an archive cutoff extension, it doesn't matter if the response indicates a status of "revoked" even if the certificate was issued and was not revoked.  However, RFC 2560 only says that OCSP servers that provide status information about revoked certificates SHOULD include the archive cutoff extension.  So, an RFC 2560-compliant responser that maintains information about expired certificates could provide a response of "revoked" for an expired certificate without including the archive cutoff extension, and a client should be able to take the response to mean that the certificate was revoked.  If the situation you describe were allowed, then a client could receive a response of "revoked" for an expired certificate that had not been revoked.  While clients could be designed to treat the response status for an expired certificate as meaningless unless the archive cutoff extension is present, that would be a non-backward compatible change from the current specification.

Dave


From hallam@gmail.com Fri Oct 19 18:08:32 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4DB321F84BA; Fri, 19 Oct 2012 18:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.923 X-Spam-Level: X-Spam-Status: No, score=-3.923 tagged_above=-999 required=5 tests=[AWL=-0.325, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YBN6mimEwSP4; Fri, 19 Oct 2012 18:08:28 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B823621F8464; Fri, 19 Oct 2012 18:08:28 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so1174962obq.31 for ; Fri, 19 Oct 2012 18:08:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=U9A+VHln0SE9UP4Gk5unxDEe1GhVgZxjdICBZ6m9xRM=; b=uTN5k0KLizoRVuV9+xY8RqcRhakFi+t+z07zf8feDsvPe7EC2FgmKXoeVufMd9b26b NoUL+u3MdqryUkceqRk7/oRwpCPwE50l0vI2Be5mTc+zensnXaBMk5Sjn1xAtbSOplzP 9AkqYkdXdoYxLfKmcAeSlyAbz6u0FMHV3qbMIFyL65YQZHrIlyB40sKQMjHrMNWVn2Tu XdjxVTTIkdpnodzsOm7C0uW/GwtBmwyLSTLWhNZ9YW7PLTc40m1AOLiCP2bcNFE7u44a 3numL4nT75Pa0IO+qJN9A+T74jzxMjef5e05qXEQ70k9XBJ7u/pZbtCcuNJIw43FseQu otHQ== MIME-Version: 1.0 Received: by 10.182.145.35 with SMTP id sr3mr1845874obb.98.1350695308228; Fri, 19 Oct 2012 18:08:28 -0700 (PDT) Received: by 10.76.27.103 with HTTP; Fri, 19 Oct 2012 18:08:28 -0700 (PDT) Date: Fri, 19 Oct 2012 21:08:28 -0400 Message-ID: From: Phillip Hallam-Baker To: pkix@ietf.org, tls@ietf.org Content-Type: multipart/alternative; boundary=f46d044630780bf9b904cc734225 Subject: [pkix] TLS Security Policy Draft Update X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 01:08:32 -0000 --f46d044630780bf9b904cc734225 Content-Type: text/plain; charset=ISO-8859-1 http://www.ietf.org/id/draft-hallambaker-tlssecuritypolicy-02.txt I am not proposing this as a PKIX WG item as the plan is to close the group. It may be of interest to PKIX and TLS members however. This is a slight generalization of the 'MUST STAPLE' certificate and CSR extension. Specifically the specification permits two types of security policy to be specified in an X.509v3 cert. * Minimum TLS Version * 'Must Staple OCSP token' The design is slightly more general so that it can co-exist with TLS extensions that are similar to OCSP token stapling. For example Certificate Transparency info. The big advantage to using this is that it allows a client to check revocation status and to immediately fail if the OCSP token is not provided as it should be. At present most clients will only fail if they see an invalid OCSP token, if the token is not returned, they consider it valid. To do otherwise opens the client to a DoS attack bu DDoS-ing the OCSP servers. Note that the TLS protocol handshake provides protection against most forms of downgrade attack and most importantly cipher suite downgrade (for later versions at least). So it is not necessary to wire them into the cert. In fact the only statements that should be wired into the cert are statements that the server knows that it can ensure compliance with. -- Website: http://hallambaker.com/ --f46d044630780bf9b904cc734225 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I am not proposing this as a PKIX WG item as the pla= n is to close the group. It may be of interest to PKIX and TLS members howe= ver.

This is a slight generalization of the 'MUST STAPLE'= certificate and CSR extension. Specifically the specification permits two = types of security policy to be specified in an X.509v3 cert.

* Minimum TLS Version
* 'Must Staple OCSP toke= n'

The design is slightly more general so that= it can co-exist with TLS extensions that are similar to OCSP token staplin= g. For example Certificate Transparency info.


The big advantage to using this is that = it allows a client to check revocation status and to immediately fail if th= e OCSP token is not provided as it should be. At present most clients will = only fail if they see an invalid OCSP token, if the token is not returned, = they consider it valid. To do otherwise opens the client to a DoS attack bu= DDoS-ing the OCSP servers.

Note that the TLS protocol handshake provides protectio= n against most forms of downgrade attack and most importantly cipher suite = downgrade (for later versions at least). So it is not necessary to wire the= m into the cert. In fact the only statements that should be wired into the = cert are statements that the server knows that it can ensure compliance wit= h.=A0

 --f46d044630780bf9b904cc734225-- From stefan@aaa-sec.com Fri Oct 19 19:23:16 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6819821F8551 for ; Fri, 19 Oct 2012 19:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.289 X-Spam-Level: X-Spam-Status: No, score=-101.289 tagged_above=-999 required=5 tests=[AWL=-0.437, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ti-N92akm+Cy for ; Fri, 19 Oct 2012 19:23:11 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 71C2B21F8841 for ; Fri, 19 Oct 2012 19:23:09 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 4C22D22BFDAB for ; Sat, 20 Oct 2012 04:23:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dy71ABpuKjxX for ; Sat, 20 Oct 2012 04:23:02 +0200 (CEST) Received: from s326.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 6C9FB22BFDC7 for ; Sat, 20 Oct 2012 04:22:57 +0200 (CEST) Received: (qmail 68602 invoked from network); 20 Oct 2012 02:22:57 -0000 Received: from 81-232-51-61-no39.business.telia.com (HELO [192.168.0.108]) (stefan@fiddler.nu@[81.232.51.61]) (envelope-sender ) by s326.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 20 Oct 2012 02:22:57 -0000 User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Sat, 20 Oct 2012 04:22:51 +0200 From: Stefan Santesson To: Piyush Jain , 'Peter Rybar' , 'Carl Wallace' , 'Simon Tardell' Message-ID: Thread-Topic: [pkix] New draft-ietf-pkix-rfc2560bis-06 In-Reply-To: <05df01cdae1f$f8737db0$e95a7910$@ditenity.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3433551777_8219742" Cc: 'Peter Rybar' , pkix@ietf.org Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 02:23:16 -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_3433551777_8219742 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable I'm sorry. I fail to the any of the problems you raise. If you receive a request for a certificate that you know has never been issued, and you choose to reply revoked, what problems can you cause? What in your mind is a more appropriate response? It does not make OCSP more non-deterministic. If you ask status for an issued cert from a non-broken CA, nothing is non-deterministic. If you ask for status for a non-issued certificate, or a bad certificate from a broken CA, then the result is by default non-deteministic and has always been. However, choosing a revoked response may save the relying party, at best, but can hurt no-one What is your problem on the practical ground. /Stefan From: Piyush Jain Date: Friday, October 19, 2012 7:34 PM To: Stefan Santesson , 'Peter Rybar' , 'Carl Wallace' , 'Simon Tardell' Cc: 'Peter Rybar' , Subject: RE: [pkix] New draft-ietf-pkix-rfc2560bis-06 > Stefan, > =20 > I think some of you interpretations below are twisted to accommodate the = new > provisions for providing revoked responses for unissued certificates. > Providing responses for expired certificates is within the scope of 2560 = using > archive cutoff extension. > =20 > The original authors of 2560 can correct me if I=B9m wrong, but it is my > understanding that a response from OCSP responder is not supposed to indi= cate > if a certificate is good or bad but to indicate if a certificate is revok= ed or > unrevoked by the issuing authority. The fact that certificate is issued b= y the > CA is checked by the RP by verifying the signature on the certificate. > =20 > This draft introduces the concept of returning revoked responses for unis= sued > certificates. There are many unintended consequences of this approach > - Revocation statuses become non-deterministic based on who you = are > asking (A responder with access to CA database vs. one without vs. checki= ng > status off a CRL). If I=B9m archiving a signed document with the relevant > artifacts to determine the validity status of the document, this becomes = a > huge problem. Note that a revoked status implies that certificate was goo= d > between the time of its issuance and that of its revocation. Any document= that > is signed within that period should still be considered valid. >=20 > - It would confuse an implementer about what =B3non-issued=B2 means.= The > fact that the CA signed the certificate implies it was issued. If a > certificate is issued fraudulently, based on its security practices, it i= s up > to the CA to either revoke the issued certificate, or ask its issuing > authority to revoke its own certificate. >=20 > =20 > -Piyush > =20 > =20 > =20 > =20 >=20 > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of S= tefan > Santesson > Sent: Friday, October 19, 2012 7:25 AM > To: Peter Rybar; 'Carl Wallace'; 'Simon Tardell' > Cc: 'Peter Rybar'; pkix@ietf.org > Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 > =20 >=20 > Peter, >=20 > =20 >=20 > An OCSP responder is by default a service providing information about cur= rent > certificates. >=20 > The default response you get from an OCSP responder is "good" unless the = cert > is known to be bad or not a cert the responder can provide status for. >=20 > =20 >=20 > If you need it to respond about old certificates, and as a client know th= at > the responder does this in a way that suits your needs, you will need to = add > an extension. >=20 > Such extension will not be part of the rfc256bis effort. >=20 > =20 >=20 > Is there any text in the current draft that you think is unclear on this? >=20 > =20 >=20 > /Stefan >=20 > =20 >=20 > =20 >=20 > From: Peter Rybar > Date: Friday, October 19, 2012 3:12 PM > To: 'Carl Wallace' , 'Simon Tardell' > > Cc: 'Peter Rybar' , Stefan Santesson , > > Subject: RE: [pkix] New draft-ietf-pkix-rfc2560bis-06 >=20 > =20 >>=20 >>> Well, yes, sort of. You can only be sure to validate a signature at the >>> moment of production. >>=20 >> =20 >>=20 >> What if the signature key was compromised at the moment of production bu= t is >> not yet on a revocation list? >> [PR] According to clause 2.4 - thisUpdate: The time at which the statu= s >> being indicated is known to be correct >> It means when signature time-stamp time is X then any OCSP responses wit= h >> thisUpdate time X+y are sufficient to validate because the status is cor= rect. >> Y is in the interval <0, producedAt - X> >>=20 >> =20 >>> At any later point in time the signature key may be compromised, or the >>> algorithms involved may have become to weak. (In which case the time of >>> revocation in the OCSP response is worth nothing to you). The risk incr= eases >>> as time passes. And of course, the revocation information may not be ke= pt >>> around after the expiry of the certificate. >>>=20 >>> =20 >>>=20 >>> That's why you should validate signatures as soon as possible. >>=20 >> =20 >>=20 >> For these archival purposes wouldn't it be better to have the final >> revocation list before removed due to expiry? In any case, you'd need >> verification information collected after some grace period following mom= ent >> of production. >>=20 >> [PR] Grace period is not a fixed value of the time interval. >> Grace period is changeable because the first OCSP response with thisUpda= te >> time value > than time of signature time-stamp contains correct status. >> =20 >>>=20 >>> =20 >>>=20 >>> If you need to ascertain that a signature was valid at a later time, yo= u >>> have to trust your system that it performed the validation at the time = it >>> first received the signature. That trust must be established through so= me >>> kind of mix of policies and technical measures (such as timestamping). >>=20 >> =20 >>=20 >> In the dark corner just beyond the dark corner that is SCVP, there's a s= pec >> (RFC 5276) that defines a binding of evidence records to artifacts that = can >> be returned viaSCVP. This provides for timestamping. >> [PR] The validation is simplified when OCSP response with positive state= ment >> as a hash value of requested certificate is used. >> Positive statement is evidence that OCSP know the status of certificate = and >> also protect the integrity of certificate with a new more secure hash >> algorithm. >>=20 >> =20 >> Peter Rybar >> =20 >>>=20 >>>=20 >>>=20 >>> Simon Tardell,=20 >>>=20 >>> Technology Nexus. >>>=20 >>> On Fri, Oct 19, 2012 at 1:07 PM, Peter Rybar wrote: >>> Stefan, >>>=20 >>> I have a question about the present OCSP RFC and at the end of the mail >>> about the new situation which will happen according to your new proposa= l. >>>=20 >>> The presence of the positive statement in OCSP response is important fo= r >>> electronic signature validations, especially for an expired certificate= . >>> Positive statement is the hash value of a certificate whose status is >>> provided in OCSP response. >>>=20 >>> Electronic signature validation is usually about the signatures created= in >>> the past and validated now, when the certificate is expired. >>>=20 >>> When the certificate expires then revocation is usually removed from CR= L and >>> the revoked certificate can be provided as "good" in OCSP response. >>> Is it acceptable? I think not. >>>=20 >>> According to your new draft there is not defined a value of revocationT= ime. >>> RFC must also define the value of revocationTime when the certificate w= hich >>> was never issued is as "revoked". >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pkix-rfc2560bis-06 >>>=20 >>> Have you also covered the situation when the certificate is expired, RE= MOVED >>> FROM CRL and will be provided as revoked with incorrect revocationTime >>> e.g.with the value before or after the revocationTime which was present= in >>> the removed record from CRL? >>> Because according to sentence in your draft ""revoked" - This state SHO= ULD >>> also be returned if the responder knows that the requested certificate = has >>> never been issued." the following situation can happen: when certificat= e is >>> removed from CRL after expiration and CA/OCSP responder is responsible = for >>> this certificate but have not record about expired certificate and for = that >>> reason it is identified as "never been issued". >>>=20 >>> ... >>> revoked [1] IMPLICIT RevokedInfo, >>> ... >>>=20 >>> RevokedInfo ::=3D SEQUENCE { >>> revocationTime GeneralizedTime, >>> revocationReason [0] EXPLICIT CRLReason OPTIONAL } >>>=20 >>> As you have mentioned in the mail: >>>=20 >>> "On the "revoked" state, the old spec did not even consider the case of= a >>> certificate being requested where the OCSP responder knows that the >>> certificate was never issued." >>>=20 >>> "It simply recommend a known to be bad certificate to result >>> in "revoked" in order to prevent damage as far as possible. It also ope= ns >>> for definition of new extensions through which such knowledge could be >>> obtained." >>> Peter Rybar >>> National Security Authority >>> Information Security and Electronic Signature Department >>> Budatinska 30, 850 07 Bratislava 57, Slovak Republic >>> e-mail: peter.rybar@nbusr.sk >>> e-mail: peterryb@gmail.com >>>=20 >>>=20 >>> -----Original Message----- >>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >>> Stefan Santesson >>> Sent: Monday, October 15, 2012 1:49 AM >>> To: pkix@ietf.org >>> Subject: [pkix] New draft-ietf-pkix-rfc2560bis-06 >>>=20 >>> All, >>>=20 >>> I have just posted an update of rfc2560bis (OCSP update) after carefull= y >>> reviewing all comments on the list. >>>=20 >>> Some notes about the update: >>>=20 >>> - Added the previous OCSP editors with updated affiliations. >>> - Added some calcifications on ResponderID as suggested by Simon Josefs= son. >>> - Updated the clarifications on Authorized responders. The requirements >>> have not changed. I just tried to improve the text. >>> - Updated a clarification on the "revoked" state to be the preferred >>> response if a certificate is known by the responder to never have been >>> issued. >>> - Some minor editorial nits. >>>=20 >>>=20 >>> Regarding backwards compatibility I mean that none of the clarification= s >>> changes RFC 2560. >>>=20 >>> On Authorized responders it has always been the case that a responder >>> certificate issued with the same key as was used to issue the certifica= te >>> being checked for revocation, represents a valid Authorized responder. >>> There has never been an explicit requirement to support key rollover an= d >>> key rollover support has never been in the "spirit" of the original >>> standard as it clearly attempted to provide direct cryptographic bindin= g >>> between the responder and the CA. >>>=20 >>> On the "revoked" state, the old spec did not even consider the case of = a >>> certificate being requested where the OCSP responder knows that the >>> certificate was never issued. It is clearly counterproductive to respon= d >>> good when a certificate is known to be bad. A responder must pick one >>> response and picking "revoked" breaks nothing, but has the desired effe= ct, >>> that is, to prevent the certificate from being accepted. The current te= xt >>> makes clear that there is no mechanism in the current standard by which= a >>> client can know how a responder will respond to a request for a not iss= ued >>> certificate. It simply recommend a known to be bad certificate to resul= t >>> in "revoked" in order to prevent damage as far as possible. It also ope= ns >>> for definition of new extensions through which such knowledge could be >>> obtained. >>>=20 >>> The current updates also clearly opens a path for the CAB forum efforts= to >>> define a suitable solution for server certificates. >>>=20 >>> I have not, even thug suggested, added any requirements on what clients >>> should do with the checked cert as a result of a particular response. I >>> don't believe such requirements are suitable as it is policy and not >>> protocol. We have no right to demand that all systems MUST reject any >>> certificate for any reason as they may have a local policy that overrul= es >>> the OCSP response. This protocol only provides information about the ce= rt >>> status, it does not mandate validation policy. >>>=20 >>> I have not included any of the substantial changes i the Pinkas draft. = I >>> want to wait for a list of motivation for each change before including = any >>> of them. So there changed may be up for debate before this draft is rea= dy >>> for WGLC. >>>=20 >>> /Stefan >>>=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 --B_3433551777_8219742 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
I'm sorry. I fail to the any= of the problems you raise.

If you receive a reques= t for a certificate that you know has never been issued, and you choose to r= eply revoked, what problems can you cause?
What in your mind is a = more appropriate response?

It does not make OCSP mo= re non-deterministic. If you ask status for an issued cert from a non-broken= CA, nothing is non-deterministic.
If you ask for status for a non= -issued certificate, or a bad certificate from a broken CA, then the result = is by default non-deteministic and has always been. However, choosing a revo= ked response may save the relying party, at best, but can hurt no-one
<= div>
What is your problem on the practical ground.
<= br>
/Stefan

From: = Piyush Jain <piyush@ditenity= .com>
Date: Friday, October= 19, 2012 7:34 PM
To: Stefan Sante= sson <stefan@aaa-sec.com>, 'Pe= ter Rybar' <rybar@nbusr.sk>, 'Carl= Wallace' <carl@redhoundsoftwa= re.com>, 'Simon Tardell' <simon@= tardell.se>
Cc: 'Peter Ryba= r' <peterryb@gmail.com>, <<= a href=3D"mailto:pkix@ietf.org">pkix@ietf.org>
Subject: RE: [pkix] New draft-ietf-pkix-rfc2560bis-06
<= /div>

<= meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">

Stefan,=

 

I think some of you interpretations= below are twisted to accommodate the new provisions for providing revoked r= esponses for unissued certificates.

Providing responses for expired certificates is within the = scope of 2560 using archive cutoff extension.

 

= The original authors of 2560 can correct me if I’m wron= g, but it is my understanding that a response from OCSP responder is not sup= posed to indicate if a certificate is good or bad but to indicate if a certi= ficate is revoked or unrevoked by the issuing authority. The fact that certi= ficate is issued by the CA is checked by the RP by verifying the signature o= n the certificate.

=  

This draft i= ntroduces the concept of returning revoked responses for unissued certificat= es. There are many unintended consequences of this approach

-          = Revocation statuses become non-determini= stic based on who you are asking (A responder with access to CA database vs.= one without vs. checking status off a CRL). If I’m archiving a signed= document with the relevant artifacts to determine the validity status of th= e document, this becomes a huge problem. Note that a revoked status implies = that certificate was good between the time of its issuance and that of its r= evocation. Any document that is signed within that period should still be co= nsidered valid.

-      &= nbsp;   It would= confuse an implementer about what “non-issued” means. The fact = that the CA signed the certificate implies it was issued. If a certificate i= s issued fraudulently, based on its security practices, it is up to the CA t= o either revoke the issued certificate, or ask its issuing authority to revo= ke its own certificate.

 

-Piyush=

 <= /span>

 

 

 

pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On= Behalf Of Stefan Santesson
Sent: Friday, October 19, 2012 7:2= 5 AM
To: Peter Rybar; 'Carl Wallace'; 'Simon Tardell'
Cc: 'Peter Rybar'; pkix@ietf.org
Subj= ect: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06

<= /div>

 

Peter,

<= o:p> 

An OCSP res= ponder is by default a service providing information about current certifica= tes.

The default = response you get from an OCSP responder is "good" unless the cert is known t= o be bad or not a cert the responder can provide status for.

 

If you need it to respond about old certif= icates, and as a client know that the responder does this in a way that suit= s your needs, you will need to add an extension.

=

Such extension will not be part of the rfc25= 6bis effort.

 

Is there any t= ext in the current draft that you think is unclear on this?

 

/Stefan

 

 

<= b>From: Peter Rybar <r= ybar@nbusr.sk>
Date: Friday, October 19, 2012 3:12 PM
To: 'Carl Wallace' <carl@= redhoundsoftware.com>, 'Simon Tardell' <simon@tardell.se>
Cc: 'Peter Rybar' <peterryb@gmail.com>, Stefan Santesson <stefan@aaa-sec.com>, <pkix@ietf.org>
Subject: RE: [pkix] New= draft-ietf-pkix-rfc2560bis-06

 

Well, yes, sort of. You can only be sure t= o validate a signature at the moment of production.

 

What if the signature key was com= promised at the moment of production but is not yet on a revocation list?

[PR] According to clause 2.4  -  thisUpdate: The time at w= hich the status being indicated is known to be correct

It means wh= en signature time-stamp time is X then any OCSP responses with thisUpdate ti= me X+y are sufficient to validate because the status is correct.

<= span style=3D"font-size: 10pt; font-family: Arial, sans-serif; color: navy; ">= Y is in the interval <0, producedAt - X>

&nb= sp;

= At any later point in time the signature key may be compromised, or the algo= rithms involved may have become to weak. (In which case the time of revocati= on in the OCSP response is worth nothing to you). The risk increases as time= passes. And of course, the revocation information may not be kept around af= ter the expiry of the certificate. 

 

That's why you should validate signatures as soon as possi= ble. 

<= /div>

 

For these archival purposes wouldn't it be better to have the final r= evocation list before removed due to expiry?  In any case, you'd need v= erification information collected after some grace period following moment o= f production.

[PR] Grace period is not a fixed value of= the time interval.

Grace period is changeable because the first = OCSP response with thisUpdate time value > than time of signature time-st= amp contains correct status.=

 

 

If you need to ascertain that a signature was valid at a later time= , you have to trust your system that it performed the validation at the time= it first received the signature. That trust must be established through som= e kind of mix of policies and technical measures (such as timestamping).

 

In the = dark corner just beyond the dark corner that is SCVP, there's a spec (RFC 52= 76) that defines a binding of evidence records to artifacts that can be retu= rned viaSCVP.  This provides for timestamping.  

[PR] Th= e validation is simplified when OCSP response with positive statement as a h= ash value of requested certificate is used.

Positive statement is = evidence that OCSP know the status of certificate and also protect the integ= rity of certificate with a new more secure hash algorithm.

 <= /p>

Peter Rybar

 



Simon Tardell= , 

Technology Ne= xus.

On Fri, Oct 19, 2012 at 1:07 PM, Peter Rybar <rybar@nbusr.sk> wrote:<= /span>

Stefan,

I have a question about the present OCSP RFC a= nd at the end of the mail about the new situation which will happen accordin= g to your new proposal.

The presence of the positive statement in OCS= P response is important for electronic signature validations, especially for= an expired certificate. Positive statement is the hash value of a certifica= te whose status is provided in OCSP response.

Electronic signature va= lidation is usually about the signatures created in the past and validated n= ow, when the certificate is expired.

When the certificate expires the= n revocation is usually removed from CRL and the revoked certificate can be = provided as "good" in OCSP response.
Is it acceptable? I think not.
According to your new draft there is not defined a value of revocationTime= .
RFC must also define the value of revocationTime when the certificate w= hich was never issued is as "revoked".
http://www.ietf.org/r= fcdiff?url2=3Ddraft-ietf-pkix-rfc2560bis-06

Have you also covered t= he situation when the certificate is expired, REMOVED FROM CRL and will be p= rovided as revoked with incorrect revocationTime e.g.with the value before o= r after the revocationTime which was present in the removed record from CRL?=
Because according to sentence in your draft ""revoked" - This state SHOU= LD also be returned if the responder knows that the requested certificate ha= s never been issued." the following situation can happen: when certificate i= s removed from CRL after expiration and CA/OCSP responder is responsible for= this certificate but have not record about expired certificate and for that= reason it is identified as "never been issued".

...
revoked  = ;   [1]     IMPLICIT RevokedInfo,
...

   = RevokedInfo ::=3D SEQUENCE {
       revocationTime &nbs= p;            GeneralizedTime,
   = ;    revocationReason    [0]     EXPLICIT CRLR= eason OPTIONAL }

As you have mentioned in the mail:

in "revok= ed" in order to prevent damage as far as possible. It also opens
for defi= nition of new extensions through which such knowledge could be
obtained."=

Peter Rybar
National Security Authority=
Information Security and Electronic Signatur= e Department
Budatinska 30, 850 07 Bratislava= 57, Slovak Republic
e-mail: peter.rybar@nbusr.sk
e-mail: peterryb@gmail.com<= /span>


-----Original Message-----
From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Stefan Sant= esson
Sent: Monday, October 15, 2012 1:49 AM
To: pkix@ietf.org
Subject: [pkix] New draft-ietf-pkix-rfc2560bi= s-06

All,

I have just posted an update of rfc2560bis (OCSP upd= ate) after carefully
reviewing all comments on the list.

Some note= s about the update:

- Added the previous OCSP editors with updated af= filiations.
- Added some calcifications on ResponderID as suggested by Si= mon Josefsson.
- Updated the clarifications on Authorized responders. The= requirements
have not changed. I just tried to improve the text.
- Up= dated a clarification on the "revoked" state to be the preferred
response= if a certificate is known by the responder to never have been
issued.- Some minor editorial nits.


Regarding backwards compatibility I= mean that none of the clarifications
changes RFC 2560.

On Authori= zed responders it has always been the case that a responder
certificate i= ssued with the same key as was used to issue the certificate
being checke= d for revocation, represents a valid Authorized responder.
There has neve= r been an explicit requirement to support key rollover and
key rollover s= upport has never been in the "spirit" of the original
standard as it clea= rly attempted to provide direct cryptographic binding
between the respond= er and the CA.

On the "revoked" state, the old spec did not even cons= ider the case of a
certificate being requested where the OCSP responder k= nows that the
certificate was never issued. It is clearly counterproducti= ve to respond
good when a certificate is known to be bad. A responder mus= t pick one
response and picking "revoked" breaks nothing, but has the des= ired effect,
that is, to prevent the certificate from being accepted. The= current text
makes clear that there is no mechanism in the current stand= ard by which a
client can know how a responder will respond to a request = for a not issued
certificate. It simply recommend a known to be bad certi= ficate to result
in "revoked" in order to prevent damage as far as possib= le. It also opens
for definition of new extensions through which such kno= wledge could be
obtained.

The current updates also clearly opens a= path for the CAB forum efforts to
define a suitable solution for server = certificates.

I have not, even thug suggested, added any requirements= on what clients
should do with the checked cert as a result of a particu= lar response. I
don't believe such requirements are suitable as it is pol= icy and not
protocol. We have no right to demand that all systems MUST re= ject any
certificate for any reason as they may have a local policy that = overrules
the OCSP response. This protocol only provides information abou= t the cert
status, it does not mandate validation policy.

I have n= ot included any of the substantial changes i the Pinkas draft. I
want to = wait for a list of motivation for each change before including any
of the= m. So there changed may be up for debate before this draft is ready
for W= GLC.

/Stefan



_________________________________________= ______
pkix mailing list
pkix@ietf.org<= /a>
= https://www.ietf.org/mailman/listinfo/pkix

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

 

_________________________= ______________________ pkix mailing list pkix= @ietf.org https://w= ww.ietf.org/mailman/listinfo/pkix

= --B_3433551777_8219742-- From piyush@ditenity.com Sat Oct 20 08:49:12 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3100921F8467 for ; Sat, 20 Oct 2012 08:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.157 X-Spam-Level: X-Spam-Status: No, score=-3.157 tagged_above=-999 required=5 tests=[AWL=0.441, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6E-h3bt8kVUe for ; Sat, 20 Oct 2012 08:49:04 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id CA77621F8442 for ; Sat, 20 Oct 2012 08:49:03 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id o25so1245881iad.31 for ; Sat, 20 Oct 2012 08:49:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language :x-gm-message-state; bh=7sl7A04GpZgjs4E1iOYzrPPHIqoi/ByFXmrnB4BlARQ=; b=GEJ2z+lQuXfuOE5hvoTK0AHxxjAVcE1x6b4xPmaRVuz2GEXnQErrrwiZTgu7dqB8Si V7ciLaL32THqrKTVlkiYKjF1dMGgYf1AM6g+7tQ0fgMm4LLf0c5ZJfIxjwTDqE0QsyKV WjAprWRYttS8tbRJafeFRVqiLdHAyZgHyQdeIezNRdCiUOXN2oTCj0FPwVIe2Y2vk31a xaP31OwZeevGm7GuO2Lwf0CvdyGIXq1B516s7+XAvFTOxNqIiRsXCnGqYKKqnJl4XxLr AGrsWJbK6dgZXzcGSV61n7oRGqJ0wDfD9jeIbMUGtDkxUNC6KYLB5pcV8CxBSS+maWD3 /ifA== Received: by 10.50.160.166 with SMTP id xl6mr11842867igb.74.1350748142818; Sat, 20 Oct 2012 08:49:02 -0700 (PDT) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id a10sm4167255igd.1.2012.10.20.08.48.58 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 20 Oct 2012 08:49:01 -0700 (PDT) From: "Piyush Jain" To: "'Stefan Santesson'" , "'Peter Rybar'" , "'Carl Wallace'" , "'Simon Tardell'" References: <05df01cdae1f$f8737db0$e95a7910$@ditenity.com> In-Reply-To: Date: Sat, 20 Oct 2012 08:48:44 -0700 Message-ID: <076201cdaeda$64800ef0$2d802cd0$@ditenity.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0763_01CDAE9F.B82C3370" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJhWGyE4803XvdlOMFj/MmNXkH/tpaa7emQ Content-Language: en-us X-Gm-Message-State: ALoCoQmBrxUcmYzl5gWnhBN6N8Zqt3GKI2tllkZI1gklNid2ghOW/FG5wjp9HJ0Rho5kNqmn4We8 Cc: 'Peter Rybar' , pkix@ietf.org Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 15:49:12 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0763_01CDAE9F.B82C3370 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Please see inline From: Stefan Santesson [mailto:stefan@aaa-sec.com] Sent: Friday, October 19, 2012 7:23 PM To: Piyush Jain; 'Peter Rybar'; 'Carl Wallace'; 'Simon Tardell' Cc: 'Peter Rybar'; pkix@ietf.org Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 I'm sorry. I fail to the any of the problems you raise. If you receive a request for a certificate that you know has never been issued, and you choose to reply revoked, what problems can you cause? [Piyush] It depends on how you define "never been issued", which btw becomes unclear after introduction of the new text. There are two interpretations 1) Certificate is not signed by the CA or 2) Certificate is not present in the database of issued certificates that CA maintains. One unintended consequence of first interpretation will be that RPs would stop performing signature checks if their responder/CA publicizes that it returns revoked for "non-issued" certificates. If the interpretation is 2, then this scenario is not possible unless the CA is compromised. What in your mind is a more appropriate response? [Piyush] I would say the appropriate response is good (if the certificate is not marked as revoked), because that is what the RP will see if it consults a CRL or a responder detached from the CA. Revoked for "not issued" adds no value because the only case in which an RP would send a query for a "non-issued" certificate is when the CA is compromised. It does not make OCSP more non-deterministic. If you ask status for an issued cert from a non-broken CA, nothing is non-deterministic. [Piyush] It does not make OCSP non-deterministic but it makes revocation checking non-deterministic. The goal of OCSP is to address operational limitations of CRLs, not functional limitations. The fact that you'll get different answers from two sources, both of which are authorized by the same CA makes revocation checking non deterministic. If you ask for status for a non-issued certificate, or a bad certificate from a broken CA, then the result is by default non-deteministic and has always been. However, choosing a revoked response may save the relying party, at best, but can hurt no-one [Piyush] I agree that a revoke response does not hurt anyone. But the point is that it provides a false sense of additional security to the RP without providing any. As an RP, I won't trust what my responder says if the authority that certified it is compromised. What is your problem on the practical ground. [Piyush] Let's say that we still need to address this scenario and revoked is the appropriate response. In that case - The text needs to be explicit about the revocation time in this situation. Revoked implies good until a certain date and this distinction is important for long term archiving applications. For unissued certificate the revocation time should probably be set to -infinity. - It needs to call out that in this particular scenario it is addressing a functional limitation of CRLs (ability to detect CA compromise) not an operational limitation. - I think we need additional text in security considerations to indicate that RP is communicating with a responder certified by a compromised CA in this scenario. /Stefan From: Piyush Jain Date: Friday, October 19, 2012 7:34 PM To: Stefan Santesson , 'Peter Rybar' , 'Carl Wallace' , 'Simon Tardell' Cc: 'Peter Rybar' , Subject: RE: [pkix] New draft-ietf-pkix-rfc2560bis-06 Stefan, I think some of you interpretations below are twisted to accommodate the new provisions for providing revoked responses for unissued certificates. Providing responses for expired certificates is within the scope of 2560 using archive cutoff extension. The original authors of 2560 can correct me if I'm wrong, but it is my understanding that a response from OCSP responder is not supposed to indicate if a certificate is good or bad but to indicate if a certificate is revoked or unrevoked by the issuing authority. The fact that certificate is issued by the CA is checked by the RP by verifying the signature on the certificate. This draft introduces the concept of returning revoked responses for unissued certificates. There are many unintended consequences of this approach - Revocation statuses become non-deterministic based on who you are asking (A responder with access to CA database vs. one without vs. checking status off a CRL). If I'm archiving a signed document with the relevant artifacts to determine the validity status of the document, this becomes a huge problem. Note that a revoked status implies that certificate was good between the time of its issuance and that of its revocation. Any document that is signed within that period should still be considered valid. - It would confuse an implementer about what "non-issued" means. The fact that the CA signed the certificate implies it was issued. If a certificate is issued fraudulently, based on its security practices, it is up to the CA to either revoke the issued certificate, or ask its issuing authority to revoke its own certificate. -Piyush From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Stefan Santesson Sent: Friday, October 19, 2012 7:25 AM To: Peter Rybar; 'Carl Wallace'; 'Simon Tardell' Cc: 'Peter Rybar'; pkix@ietf.org Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Peter, An OCSP responder is by default a service providing information about current certificates. The default response you get from an OCSP responder is "good" unless the cert is known to be bad or not a cert the responder can provide status for. If you need it to respond about old certificates, and as a client know that the responder does this in a way that suits your needs, you will need to add an extension. Such extension will not be part of the rfc256bis effort. Is there any text in the current draft that you think is unclear on this? /Stefan From: Peter Rybar Date: Friday, October 19, 2012 3:12 PM To: 'Carl Wallace' , 'Simon Tardell' Cc: 'Peter Rybar' , Stefan Santesson , Subject: RE: [pkix] New draft-ietf-pkix-rfc2560bis-06 Well, yes, sort of. You can only be sure to validate a signature at the moment of production. What if the signature key was compromised at the moment of production but is not yet on a revocation list? [PR] According to clause 2.4 - thisUpdate: The time at which the status being indicated is known to be correct It means when signature time-stamp time is X then any OCSP responses with thisUpdate time X+y are sufficient to validate because the status is correct. Y is in the interval <0, producedAt - X> At any later point in time the signature key may be compromised, or the algorithms involved may have become to weak. (In which case the time of revocation in the OCSP response is worth nothing to you). The risk increases as time passes. And of course, the revocation information may not be kept around after the expiry of the certificate. That's why you should validate signatures as soon as possible. For these archival purposes wouldn't it be better to have the final revocation list before removed due to expiry? In any case, you'd need verification information collected after some grace period following moment of production. [PR] Grace period is not a fixed value of the time interval. Grace period is changeable because the first OCSP response with thisUpdate time value > than time of signature time-stamp contains correct status. If you need to ascertain that a signature was valid at a later time, you have to trust your system that it performed the validation at the time it first received the signature. That trust must be established through some kind of mix of policies and technical measures (such as timestamping). In the dark corner just beyond the dark corner that is SCVP, there's a spec (RFC 5276) that defines a binding of evidence records to artifacts that can be returned viaSCVP. This provides for timestamping. [PR] The validation is simplified when OCSP response with positive statement as a hash value of requested certificate is used. Positive statement is evidence that OCSP know the status of certificate and also protect the integrity of certificate with a new more secure hash algorithm. Peter Rybar Simon Tardell, Technology Nexus. On Fri, Oct 19, 2012 at 1:07 PM, Peter Rybar wrote: Stefan, I have a question about the present OCSP RFC and at the end of the mail about the new situation which will happen according to your new proposal. The presence of the positive statement in OCSP response is important for electronic signature validations, especially for an expired certificate. Positive statement is the hash value of a certificate whose status is provided in OCSP response. Electronic signature validation is usually about the signatures created in the past and validated now, when the certificate is expired. When the certificate expires then revocation is usually removed from CRL and the revoked certificate can be provided as "good" in OCSP response. Is it acceptable? I think not. According to your new draft there is not defined a value of revocationTime. RFC must also define the value of revocationTime when the certificate which was never issued is as "revoked". http://www.ietf.org/rfcdiff?url2=draft-ietf-pkix-rfc2560bis-06 Have you also covered the situation when the certificate is expired, REMOVED FROM CRL and will be provided as revoked with incorrect revocationTime e.g.with the value before or after the revocationTime which was present in the removed record from CRL? Because according to sentence in your draft ""revoked" - This state SHOULD also be returned if the responder knows that the requested certificate has never been issued." the following situation can happen: when certificate is removed from CRL after expiration and CA/OCSP responder is responsible for this certificate but have not record about expired certificate and for that reason it is identified as "never been issued". ... revoked [1] IMPLICIT RevokedInfo, ... RevokedInfo ::= SEQUENCE { revocationTime GeneralizedTime, revocationReason [0] EXPLICIT CRLReason OPTIONAL } As you have mentioned in the mail: "On the "revoked" state, the old spec did not even consider the case of a certificate being requested where the OCSP responder knows that the certificate was never issued." "It simply recommend a known to be bad certificate to result in "revoked" in order to prevent damage as far as possible. It also opens for definition of new extensions through which such knowledge could be obtained." Peter Rybar National Security Authority Information Security and Electronic Signature Department Budatinska 30, 850 07 Bratislava 57, Slovak Republic e-mail: peter.rybar@nbusr.sk e-mail: peterryb@gmail.com -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Stefan Santesson Sent: Monday, October 15, 2012 1:49 AM To: pkix@ietf.org Subject: [pkix] New draft-ietf-pkix-rfc2560bis-06 All, I have just posted an update of rfc2560bis (OCSP update) after carefully reviewing all comments on the list. Some notes about the update: - Added the previous OCSP editors with updated affiliations. - Added some calcifications on ResponderID as suggested by Simon Josefsson. - Updated the clarifications on Authorized responders. The requirements have not changed. I just tried to improve the text. - Updated a clarification on the "revoked" state to be the preferred response if a certificate is known by the responder to never have been issued. - Some minor editorial nits. Regarding backwards compatibility I mean that none of the clarifications changes RFC 2560. On Authorized responders it has always been the case that a responder certificate issued with the same key as was used to issue the certificate being checked for revocation, represents a valid Authorized responder. There has never been an explicit requirement to support key rollover and key rollover support has never been in the "spirit" of the original standard as it clearly attempted to provide direct cryptographic binding between the responder and the CA. On the "revoked" state, the old spec did not even consider the case of a certificate being requested where the OCSP responder knows that the certificate was never issued. It is clearly counterproductive to respond good when a certificate is known to be bad. A responder must pick one response and picking "revoked" breaks nothing, but has the desired effect, that is, to prevent the certificate from being accepted. The current text makes clear that there is no mechanism in the current standard by which a client can know how a responder will respond to a request for a not issued certificate. It simply recommend a known to be bad certificate to result in "revoked" in order to prevent damage as far as possible. It also opens for definition of new extensions through which such knowledge could be obtained. The current updates also clearly opens a path for the CAB forum efforts to define a suitable solution for server certificates. I have not, even thug suggested, added any requirements on what clients should do with the checked cert as a result of a particular response. I don't believe such requirements are suitable as it is policy and not protocol. We have no right to demand that all systems MUST reject any certificate for any reason as they may have a local policy that overrules the OCSP response. This protocol only provides information about the cert status, it does not mandate validation policy. I have not included any of the substantial changes i the Pinkas draft. I want to wait for a list of motivation for each change before including any of them. So there changed may be up for debate before this draft is ready for WGLC. /Stefan _______________________________________________ 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 _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix ------=_NextPart_000_0763_01CDAE9F.B82C3370 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please see inline

 

From:= = Stefan Santesson [mailto:stefan@aaa-sec.com]
Sent: Friday, = October 19, 2012 7:23 PM
To: Piyush Jain; 'Peter Rybar'; 'Carl = Wallace'; 'Simon Tardell'
Cc: 'Peter Rybar'; = pkix@ietf.org
Subject: Re: [pkix] New = draft-ietf-pkix-rfc2560bis-06

 

I'm sorry. I fail to the any of the problems you = raise.

 

If you receive a request for a certificate that you know has never been = issued, and you choose to reply revoked, what problems can you = cause?

[Piyush] It depends on how you define “never been = issued”, which btw becomes unclear after introduction of the new = text. There are two interpretations

1)      = Certificate is not signed by the CA = or

2)      = Certificate is not present in the database of issued certificates = that CA maintains.

One unintended consequence of first interpretation will be that RPs = would stop performing signature checks if their responder/CA publicizes = that it returns revoked for “non-issued” = certificates.

If the interpretation is 2, then this scenario is not possible unless = the CA is compromised.

 

What in your mind is a more appropriate = response?

[Piyush] I would say the appropriate response is good (if the = certificate is not marked as revoked), because that is what the RP will = see if it consults a CRL or a responder detached from the CA. =

Revoked for “not issued” adds no value because the only = case in which an RP would send a query for a “non-issued” = certificate is when the CA is compromised.

 

It does not make OCSP more non-deterministic. If you ask status for an = issued cert from a non-broken CA, nothing is = non-deterministic.

[Piyush] It does not make OCSP non-deterministic but it makes = revocation checking non-deterministic. The goal of OCSP is to address = operational limitations of CRLs, not functional limitations.  The = fact that you’ll get different answers from two sources, both of = which are authorized by the same CA makes revocation checking non = deterministic.

 

If you ask for status for a non-issued certificate, or a bad = certificate from a broken CA, then the result is by default = non-deteministic and has always been. However, choosing a revoked = response may save the relying party, at best, but can hurt = no-one

[Piyush] I agree that a revoke response does not hurt anyone. But the = point is that it provides a false sense of additional security to the RP = without providing any. As an RP, I won’t trust what my responder = says if the authority that certified it is = compromised.

 

What is your problem on the practical = ground.

[Piyush]  Let’s say that we still need to address this scenario and = revoked is the appropriate response. In that = case

-          = The text needs to be explicit about the revocation time in this = situation. Revoked implies good until a certain date and this = distinction is important for long term archiving applications. For = unissued certificate the revocation time should probably be set to = –infinity.

-          = It needs to call out that in this particular scenario it is = addressing a functional limitation of CRLs (ability to detect CA = compromise) not an operational limitation.

-          = I think we need additional text in security considerations to = indicate that RP is communicating with a responder certified by a = compromised CA in this scenario.

 

 

/Stefan

 

From: Piyush Jain <piyush@ditenity.com>
Dat= e: Friday, October 19, 2012 7:34 PM
To: Stefan Santesson = <stefan@aaa-sec.com>, = 'Peter Rybar' <rybar@nbusr.sk>, 'Carl Wallace' = <carl@redhoundsoftware.com&g= t;, 'Simon Tardell' <simon@tardell.se>
Cc: = 'Peter Rybar' <peterryb@gmail.com>, <pkix@ietf.org>
Subject: = RE: [pkix] New = draft-ietf-pkix-rfc2560bis-06

 

Stefan,

 

I think some of you interpretations below are twisted to accommodate = the new provisions for providing revoked responses for unissued = certificates.

Providing responses for expired certificates is within the scope of = 2560 using archive cutoff extension.

 

The original authors of 2560 can correct me if I’m wrong, but = it is my understanding that a response from OCSP responder is not = supposed to indicate if a certificate is good or bad but to indicate if = a certificate is revoked or unrevoked by the issuing authority. The fact = that certificate is issued by the CA is checked by the RP by verifying = the signature on the certificate.

 

This draft introduces the concept of returning revoked responses for = unissued certificates. There are many unintended consequences of this = approach

-          = Revocation statuses become non-deterministic based on who you are = asking (A responder with access to CA database vs. one without vs. = checking status off a CRL). If I’m archiving a signed document = with the relevant artifacts to determine the validity status of the = document, this becomes a huge problem. Note that a revoked status = implies that certificate was good between the time of its issuance and = that of its revocation. Any document that is signed within that period = should still be considered valid.

-          = It would confuse an implementer about what “non-issued” = means. The fact that the CA signed the certificate implies it was = issued. If a certificate is issued fraudulently, based on its security = practices, it is up to the CA to either revoke the issued certificate, = or ask its issuing authority to revoke its own certificate.

 

-Piyush

 

 

 

 

= From:= pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] = On Behalf Of Stefan Santesson
Sent: Friday, October 19, = 2012 7:25 AM
To: Peter Rybar; 'Carl Wallace'; 'Simon = Tardell'
Cc: 'Peter Rybar'; pkix@ietf.org
Subject: Re: = [pkix] New draft-ietf-pkix-rfc2560bis-06

 

Peter,

 

An OCSP responder is by default a service providing information about = current certificates.

The default response you get from an OCSP responder is "good" = unless the cert is known to be bad or not a cert the responder can = provide status for.

 

If you need it to respond about old certificates, and as a client know = that the responder does this in a way that suits your needs, you will = need to add an extension.

Such extension will not be part of the rfc256bis effort.

 

Is there any text in the current draft that you think is unclear on = this?

 

/Stefan

 

 

From: Peter Rybar <rybar@nbusr.sk>
Date: = Friday, October 19, 2012 3:12 PM
To: 'Carl Wallace' <carl@redhoundsoftware.com&g= t;, 'Simon Tardell' <simon@tardell.se>
Cc: = 'Peter Rybar' <peterryb@gmail.com>, Stefan = Santesson <stefan@aaa-sec.com>, <pkix@ietf.org>
Subject: = RE: [pkix] New draft-ietf-pkix-rfc2560bis-06

 

Well, yes, sort of. You can only be sure to validate a signature at the = moment of production.

 

What if the signature key was compromised at the moment of production = but is not yet on a revocation list?

[P= R] According to clause 2.4  -  thisUpdate: The time at which = the status being indicated is known to be correct

It= means when signature time-stamp time is X then any OCSP responses with = thisUpdate time X+y are sufficient to validate because the status is = correct.

Y = is in the interval <0, producedAt - X>

 

At any later point in time the signature key may be compromised, or the = algorithms involved may have become to weak. (In which case the time of = revocation in the OCSP response is worth nothing to you). The risk = increases as time passes. And of course, the revocation information may = not be kept around after the expiry of the = certificate. 

 

That's why you should validate signatures as soon as = possible. 

 

For these archival purposes wouldn't it be better to have the final = revocation list before removed due to expiry?  In any case, you'd = need verification information collected after some grace period = following moment of production.

[P= R] Grace period is not a fixed value of the time interval.

Gr= ace period is changeable because the first OCSP response with thisUpdate = time value > than time of signature time-stamp contains correct = status.

 

 

If you need to ascertain that a signature was valid at a later time, = you have to trust your system that it performed the validation at the = time it first received the signature. That trust must be established = through some kind of mix of policies and technical measures (such as = timestamping).

 

In the dark corner just beyond the dark corner that is SCVP, there's a = spec (RFC 5276) that defines a binding of evidence records to artifacts = that can be returned viaSCVP.  This provides for timestamping. =  

[P= R] The validation is simplified when OCSP response with positive = statement as a hash value of requested certificate is used.

Po= sitive statement is evidence that OCSP know the status of certificate = and also protect the integrity of certificate with a new more secure = hash algorithm.

=  

Pe= ter Rybar

&n= bsp;



Simon Tardell, 

Technology Nexus.

On Fri, Oct 19, 2012 at 1:07 PM, Peter Rybar <rybar@nbusr.sk> = wrote:

Stefan,

I have a question about the present OCSP RFC and at the = end of the mail about the new situation which will happen according to = your new proposal.

The presence of the positive statement in OCSP = response is important for electronic signature validations, especially = for an expired certificate. Positive statement is the hash value of a = certificate whose status is provided in OCSP response.

Electronic = signature validation is usually about the signatures created in the past = and validated now, when the certificate is expired.

When the = certificate expires then revocation is usually removed from CRL and the = revoked certificate can be provided as "good" in OCSP = response.
Is it acceptable? I think not.

According to your new = draft there is not defined a value of revocationTime.
RFC must also = define the value of revocationTime when the certificate which was never = issued is as "revoked".
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pkix-rfc2= 560bis-06

Have you also covered the situation when the = certificate is expired, REMOVED FROM CRL and will be provided as revoked = with incorrect revocationTime e.g.with the value before or after the = revocationTime which was present in the removed record from = CRL?
Because according to sentence in your draft = ""revoked" - This state SHOULD also be returned if the = responder knows that the requested certificate has never been = issued." the following situation can happen: when certificate is = removed from CRL after expiration and CA/OCSP responder is responsible = for this certificate but have not record about expired certificate and = for that reason it is identified as "never been = issued".

...
revoked     [1]     = IMPLICIT RevokedInfo,
...

   RevokedInfo ::=3D = SEQUENCE {
       revocationTime     =          GeneralizedTime,
    =    revocationReason    [0]     EXPLICIT = CRLReason OPTIONAL }

As you have mentioned in the = mail:

"On the "revoked" state, the old spec did not even = consider the case of a certificate being requested where the OCSP = responder knows that the certificate was never issued."

"It simply recommend a known to be bad certificate to result
in = "revoked" in order to prevent damage as far as possible. It = also opens
for definition of new extensions through which such = knowledge could be
obtained."

Peter Rybar
National Security Authority
Information Security and Electronic Signature = Department
Budatinska 30, 850 07 = Bratislava 57, Slovak Republic
e-mail: peter.rybar@nbusr.sk
<= span class=3Dhoenzb>e-mail: peterryb@gmail.com


-----Original Message-----
From: pkix-bounces@ietf.org = [mailto:pkix-bounces@ietf.org] On = Behalf Of Stefan Santesson
Sent: Monday, October 15, 2012 1:49 = AM
To: pkix@ietf.org
Subject: = [pkix] New draft-ietf-pkix-rfc2560bis-06

All,

I have just = posted an update of rfc2560bis (OCSP update) after = carefully
reviewing all comments on the list.

Some notes about = the update:

- Added the previous OCSP editors with updated = affiliations.
- Added some calcifications on ResponderID as suggested = by Simon Josefsson.
- Updated the clarifications on Authorized = responders. The requirements
have not changed. I just tried to = improve the text.
- Updated a clarification on the = "revoked" state to be the preferred
response if a = certificate is known by the responder to never have been
issued.
- = Some minor editorial nits.


Regarding backwards compatibility = I mean that none of the clarifications
changes RFC 2560.

On = Authorized responders it has always been the case that a = responder
certificate issued with the same key as was used to issue = the certificate
being checked for revocation, represents a valid = Authorized responder.
There has never been an explicit requirement to = support key rollover and
key rollover support has never been in the = "spirit" of the original
standard as it clearly attempted = to provide direct cryptographic binding
between the responder and the = CA.

On the "revoked" state, the old spec did not even = consider the case of a
certificate being requested where the OCSP = responder knows that the
certificate was never issued. It is clearly = counterproductive to respond
good when a certificate is known to be = bad. A responder must pick one
response and picking = "revoked" breaks nothing, but has the desired effect,
that = is, to prevent the certificate from being accepted. The current = text
makes clear that there is no mechanism in the current standard = by which a
client can know how a responder will respond to a request = for a not issued
certificate. It simply recommend a known to be bad = certificate to result
in "revoked" in order to prevent = damage as far as possible. It also opens
for definition of new = extensions through which such knowledge could be
obtained.

The = current updates also clearly opens a path for the CAB forum efforts = to
define a suitable solution for server certificates.

I have = not, even thug suggested, added any requirements on what = clients
should do with the checked cert as a result of a particular = response. I
don't believe such requirements are suitable as it is = policy and not
protocol. We have no right to demand that all systems = MUST reject any
certificate for any reason as they may have a local = policy that overrules
the OCSP response. This protocol only provides = information about the cert
status, it does not mandate validation = policy.

I have not included any of the substantial changes i the = Pinkas draft. I
want to wait for a list of motivation for each change = before including any
of them. So there changed may be up for debate = before this draft is ready
for = WGLC.

/Stefan



_____________________________________= __________
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

 

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

------=_NextPart_000_0763_01CDAE9F.B82C3370-- From stefan@aaa-sec.com Sun Oct 21 08:53:18 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2694A21F8984 for ; Sun, 21 Oct 2012 08:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.24 X-Spam-Level: X-Spam-Status: No, score=-101.24 tagged_above=-999 required=5 tests=[AWL=-0.388, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eaegd0lv1c8i for ; Sun, 21 Oct 2012 08:53:10 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id E54CC21F8928 for ; Sun, 21 Oct 2012 08:53:09 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 5C33A3908 for ; Sun, 21 Oct 2012 17:53:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id s9ZMbcVGhTVq for ; Sun, 21 Oct 2012 17:52:54 +0200 (CEST) Received: from s326.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 473B03AEB for ; Sun, 21 Oct 2012 17:52:22 +0200 (CEST) Received: (qmail 67751 invoked from network); 21 Oct 2012 15:52:19 -0000 Received: from 81-232-51-61-no39.business.telia.com (HELO [192.168.0.109]) (stefan@fiddler.nu@[81.232.51.61]) (envelope-sender ) by s326.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 21 Oct 2012 15:52:19 -0000 User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Sun, 21 Oct 2012 17:52:10 +0200 From: Stefan Santesson To: Piyush Jain , 'Peter Rybar' , 'Carl Wallace' , 'Simon Tardell' Message-ID: Thread-Topic: [pkix] New draft-ietf-pkix-rfc2560bis-06 In-Reply-To: <076201cdaeda$64800ef0$2d802cd0$@ditenity.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3433686739_12675366" Cc: 'Peter Rybar' , pkix@ietf.org Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 15:53:18 -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_3433686739_12675366 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable I don't think the "not issued" is unclear. The possibility to send a revoked reply only applies then the responder "knows" that the requested certificate has never been issued. How the responder knows this is totally irrelevant, but unless the responde= r knows this, it can't choose this option and has to reply "good". It does not make revocation checking non-deterministric. "good" still means what is declared in the standard (The cert is not known to be revoked, but it may never have been issued). "revoked" still have a deterministic meaning, that is, don't trust this cert. The old exact semantics was "the cert IS revoked". The new semantic i= s "the cert is revoked or possibly might never been issued" The new response semantic of revoked is backwards compatible and not less deterministic than the good, response. So, I still don't see any practical problems here. /Stefan From: Piyush Jain Date: Saturday, October 20, 2012 5:48 PM To: Stefan Santesson , 'Peter Rybar' , 'Carl Wallace' , 'Simon Tardell' Cc: 'Peter Rybar' , Subject: RE: [pkix] New draft-ietf-pkix-rfc2560bis-06 > Please see inline > =20 >=20 > From: Stefan Santesson [mailto:stefan@aaa-sec.com] > Sent: Friday, October 19, 2012 7:23 PM > To: Piyush Jain; 'Peter Rybar'; 'Carl Wallace'; 'Simon Tardell' > Cc: 'Peter Rybar'; pkix@ietf.org > Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 > =20 >=20 > I'm sorry. I fail to the any of the problems you raise. >=20 > =20 >=20 > If you receive a request for a certificate that you know has never been > issued, and you choose to reply revoked, what problems can you cause? >=20 > [Piyush] It depends on how you define =B3never been issued=B2, which btw beco= mes > unclear after introduction of the new text. There are two interpretations > 1) Certificate is not signed by the CA or >=20 > 2) Certificate is not present in the database of issued certificates= that > CA maintains. >=20 > One unintended consequence of first interpretation will be that RPs would= stop > performing signature checks if their responder/CA publicizes that it retu= rns > revoked for =B3non-issued=B2 certificates. > If the interpretation is 2, then this scenario is not possible unless the= CA > is compromised. > =20 > What in your mind is a more appropriate response? > [Piyush] I would say the appropriate response is good (if the certificate= is > not marked as revoked), because that is what the RP will see if it consul= ts a > CRL or a responder detached from the CA. > Revoked for =B3not issued=B2 adds no value because the only case in which an = RP > would send a query for a =B3non-issued=B2 certificate is when the CA is > compromised. >=20 > =20 >=20 > It does not make OCSP more non-deterministic. If you ask status for an is= sued > cert from a non-broken CA, nothing is non-deterministic. > [Piyush] It does not make OCSP non-deterministic but it makes revocation > checking non-deterministic. The goal of OCSP is to address operational > limitations of CRLs, not functional limitations. The fact that you=B9ll ge= t > different answers from two sources, both of which are authorized by the s= ame > CA makes revocation checking non deterministic. > =20 >=20 > If you ask for status for a non-issued certificate, or a bad certificate = from > a broken CA, then the result is by default non-deteministic and has alway= s > been. However, choosing a revoked response may save the relying party, at > best, but can hurt no-one > [Piyush] I agree that a revoke response does not hurt anyone. But the poi= nt is > that it provides a false sense of additional security to the RP without > providing any. As an RP, I won=B9t trust what my responder says if the auth= ority > that certified it is compromised. > =20 >=20 > What is your problem on the practical ground. >=20 > [Piyush] Let=B9s say that we still need to address this scenario and revok= ed is > the appropriate response. In that case > - The text needs to be explicit about the revocation time in thi= s > situation. Revoked implies good until a certain date and this distinction= is > important for long term archiving applications. For unissued certificate = the > revocation time should probably be set to =ADinfinity. >=20 > - It needs to call out that in this particular scenario it is > addressing a functional limitation of CRLs (ability to detect CA compromi= se) > not an operational limitation. >=20 > - I think we need additional text in security considerations to > indicate that RP is communicating with a responder certified by a comprom= ised > CA in this scenario. >=20 > =20 > =20 >=20 > /Stefan >=20 > =20 >=20 > From: Piyush Jain > Date: Friday, October 19, 2012 7:34 PM > To: Stefan Santesson , 'Peter Rybar' = , > 'Carl Wallace' , 'Simon Tardell' > Cc: 'Peter Rybar' , > Subject: RE: [pkix] New draft-ietf-pkix-rfc2560bis-06 >=20 > =20 >>=20 >> Stefan, >> =20 >> I think some of you interpretations below are twisted to accommodate the= new >> provisions for providing revoked responses for unissued certificates. >> Providing responses for expired certificates is within the scope of 2560 >> using archive cutoff extension. >> =20 >> The original authors of 2560 can correct me if I=B9m wrong, but it is my >> understanding that a response from OCSP responder is not supposed to ind= icate >> if a certificate is good or bad but to indicate if a certificate is revo= ked >> or unrevoked by the issuing authority. The fact that certificate is issu= ed by >> the CA is checked by the RP by verifying the signature on the certificat= e. >> =20 >> This draft introduces the concept of returning revoked responses for uni= ssued >> certificates. There are many unintended consequences of this approach >> - Revocation statuses become non-deterministic based on who you= are >> asking (A responder with access to CA database vs. one without vs. check= ing >> status off a CRL). If I=B9m archiving a signed document with the relevant >> artifacts to determine the validity status of the document, this becomes= a >> huge problem. Note that a revoked status implies that certificate was go= od >> between the time of its issuance and that of its revocation. Any documen= t >> that is signed within that period should still be considered valid. >>=20 >> - It would confuse an implementer about what =B3non-issued=B2 means= . The >> fact that the CA signed the certificate implies it was issued. If a >> certificate is issued fraudulently, based on its security practices, it = is up >> to the CA to either revoke the issued certificate, or ask its issuing >> authority to revoke its own certificate. >>=20 >> =20 >> -Piyush >> =20 >> =20 >> =20 >> =20 >>=20 >> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >> Stefan Santesson >> Sent: Friday, October 19, 2012 7:25 AM >> To: Peter Rybar; 'Carl Wallace'; 'Simon Tardell' >> Cc: 'Peter Rybar'; pkix@ietf.org >> Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 >> =20 >>=20 >> Peter, >>=20 >> =20 >>=20 >> An OCSP responder is by default a service providing information about cu= rrent >> certificates. >>=20 >> The default response you get from an OCSP responder is "good" unless the= cert >> is known to be bad or not a cert the responder can provide status for. >>=20 >> =20 >>=20 >> If you need it to respond about old certificates, and as a client know t= hat >> the responder does this in a way that suits your needs, you will need to= add >> an extension. >>=20 >> Such extension will not be part of the rfc256bis effort. >>=20 >> =20 >>=20 >> Is there any text in the current draft that you think is unclear on this= ? >>=20 >> =20 >>=20 >> /Stefan >>=20 >> =20 >>=20 >> =20 >>=20 >> From: Peter Rybar >> Date: Friday, October 19, 2012 3:12 PM >> To: 'Carl Wallace' , 'Simon Tardell' >> >> Cc: 'Peter Rybar' , Stefan Santesson >> , >> Subject: RE: [pkix] New draft-ietf-pkix-rfc2560bis-06 >>=20 >> =20 >>>=20 >>>> Well, yes, sort of. You can only be sure to validate a signature at th= e >>>> moment of production. >>>=20 >>> =20 >>>=20 >>> What if the signature key was compromised at the moment of production b= ut is >>> not yet on a revocation list? >>> [PR] According to clause 2.4 - thisUpdate: The time at which the stat= us >>> being indicated is known to be correct >>> It means when signature time-stamp time is X then any OCSP responses wi= th >>> thisUpdate time X+y are sufficient to validate because the status is >>> correct.=20 >>> Y is in the interval <0, producedAt - X> >>>=20 >>> =20 >>>> At any later point in time the signature key may be compromised, or th= e >>>> algorithms involved may have become to weak. (In which case the time o= f >>>> revocation in the OCSP response is worth nothing to you). The risk >>>> increases as time passes. And of course, the revocation information ma= y not >>>> be kept around after the expiry of the certificate. >>>>=20 >>>> =20 >>>>=20 >>>> That's why you should validate signatures as soon as possible. >>>=20 >>> =20 >>>=20 >>> For these archival purposes wouldn't it be better to have the final >>> revocation list before removed due to expiry? In any case, you'd need >>> verification information collected after some grace period following mo= ment >>> of production. >>>=20 >>> [PR] Grace period is not a fixed value of the time interval. >>> Grace period is changeable because the first OCSP response with thisUpd= ate >>> time value > than time of signature time-stamp contains correct status. >>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> If you need to ascertain that a signature was valid at a later time, y= ou >>>> have to trust your system that it performed the validation at the time= it >>>> first received the signature. That trust must be established through s= ome >>>> kind of mix of policies and technical measures (such as timestamping). >>>=20 >>> =20 >>>=20 >>> In the dark corner just beyond the dark corner that is SCVP, there's a = spec >>> (RFC 5276) that defines a binding of evidence records to artifacts that= can >>> be returned viaSCVP. This provides for timestamping. >>> [PR] The validation is simplified when OCSP response with positive stat= ement >>> as a hash value of requested certificate is used. >>> Positive statement is evidence that OCSP know the status of certificate= and >>> also protect the integrity of certificate with a new more secure hash >>> algorithm. >>>=20 >>> =20 >>> Peter Rybar >>> =20 >>>>=20 >>>>=20 >>>>=20 >>>> Simon Tardell, >>>>=20 >>>> Technology Nexus. >>>>=20 >>>> On Fri, Oct 19, 2012 at 1:07 PM, Peter Rybar wrote: >>>> Stefan, >>>>=20 >>>> I have a question about the present OCSP RFC and at the end of the mai= l >>>> about the new situation which will happen according to your new propos= al. >>>>=20 >>>> The presence of the positive statement in OCSP response is important f= or >>>> electronic signature validations, especially for an expired certificat= e. >>>> Positive statement is the hash value of a certificate whose status is >>>> provided in OCSP response. >>>>=20 >>>> Electronic signature validation is usually about the signatures create= d in >>>> the past and validated now, when the certificate is expired. >>>>=20 >>>> When the certificate expires then revocation is usually removed from C= RL >>>> and the revoked certificate can be provided as "good" in OCSP response= . >>>> Is it acceptable? I think not. >>>>=20 >>>> According to your new draft there is not defined a value of revocation= Time. >>>> RFC must also define the value of revocationTime when the certificate = which >>>> was never issued is as "revoked". >>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pkix-rfc2560bis-06 >>>>=20 >>>> Have you also covered the situation when the certificate is expired, >>>> REMOVED FROM CRL and will be provided as revoked with incorrect >>>> revocationTime e.g.with the value before or after the revocationTime w= hich >>>> was present in the removed record from CRL? >>>> Because according to sentence in your draft ""revoked" - This state SH= OULD >>>> also be returned if the responder knows that the requested certificate= has >>>> never been issued." the following situation can happen: when certifica= te is >>>> removed from CRL after expiration and CA/OCSP responder is responsible= for >>>> this certificate but have not record about expired certificate and for= that >>>> reason it is identified as "never been issued". >>>>=20 >>>> ... >>>> revoked [1] IMPLICIT RevokedInfo, >>>> ... >>>>=20 >>>> RevokedInfo ::=3D SEQUENCE { >>>> revocationTime GeneralizedTime, >>>> revocationReason [0] EXPLICIT CRLReason OPTIONAL } >>>>=20 >>>> As you have mentioned in the mail: >>>>=20 >>>> "On the "revoked" state, the old spec did not even consider the case o= f a >>>> certificate being requested where the OCSP responder knows that the >>>> certificate was never issued." >>>>=20 >>>> "It simply recommend a known to be bad certificate to result >>>> in "revoked" in order to prevent damage as far as possible. It also op= ens >>>> for definition of new extensions through which such knowledge could be >>>> obtained." >>>> Peter Rybar >>>> National Security Authority >>>> Information Security and Electronic Signature Department >>>> Budatinska 30, 850 07 Bratislava 57, Slovak Republic >>>> e-mail: peter.rybar@nbusr.sk >>>> e-mail: peterryb@gmail.com >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf O= f >>>> Stefan Santesson >>>> Sent: Monday, October 15, 2012 1:49 AM >>>> To: pkix@ietf.org >>>> Subject: [pkix] New draft-ietf-pkix-rfc2560bis-06 >>>>=20 >>>> All, >>>>=20 >>>> I have just posted an update of rfc2560bis (OCSP update) after careful= ly >>>> reviewing all comments on the list. >>>>=20 >>>> Some notes about the update: >>>>=20 >>>> - Added the previous OCSP editors with updated affiliations. >>>> - Added some calcifications on ResponderID as suggested by Simon Josef= sson. >>>> - Updated the clarifications on Authorized responders. The requirement= s >>>> have not changed. I just tried to improve the text. >>>> - Updated a clarification on the "revoked" state to be the preferred >>>> response if a certificate is known by the responder to never have been >>>> issued. >>>> - Some minor editorial nits. >>>>=20 >>>>=20 >>>> Regarding backwards compatibility I mean that none of the clarificatio= ns >>>> changes RFC 2560. >>>>=20 >>>> On Authorized responders it has always been the case that a responder >>>> certificate issued with the same key as was used to issue the certific= ate >>>> being checked for revocation, represents a valid Authorized responder. >>>> There has never been an explicit requirement to support key rollover a= nd >>>> key rollover support has never been in the "spirit" of the original >>>> standard as it clearly attempted to provide direct cryptographic bindi= ng >>>> between the responder and the CA. >>>>=20 >>>> On the "revoked" state, the old spec did not even consider the case of= a >>>> certificate being requested where the OCSP responder knows that the >>>> certificate was never issued. It is clearly counterproductive to respo= nd >>>> good when a certificate is known to be bad. A responder must pick one >>>> response and picking "revoked" breaks nothing, but has the desired eff= ect, >>>> that is, to prevent the certificate from being accepted. The current t= ext >>>> makes clear that there is no mechanism in the current standard by whic= h a >>>> client can know how a responder will respond to a request for a not is= sued >>>> certificate. It simply recommend a known to be bad certificate to resu= lt >>>> in "revoked" in order to prevent damage as far as possible. It also op= ens >>>> for definition of new extensions through which such knowledge could be >>>> obtained. >>>>=20 >>>> The current updates also clearly opens a path for the CAB forum effort= s to >>>> define a suitable solution for server certificates. >>>>=20 >>>> I have not, even thug suggested, added any requirements on what client= s >>>> should do with the checked cert as a result of a particular response. = I >>>> don't believe such requirements are suitable as it is policy and not >>>> protocol. We have no right to demand that all systems MUST reject any >>>> certificate for any reason as they may have a local policy that overru= les >>>> the OCSP response. This protocol only provides information about the c= ert >>>> status, it does not mandate validation policy. >>>>=20 >>>> I have not included any of the substantial changes i the Pinkas draft.= I >>>> want to wait for a list of motivation for each change before including= any >>>> of them. So there changed may be up for debate before this draft is re= ady >>>> for WGLC. >>>>=20 >>>> /Stefan >>>>=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 --B_3433686739_12675366 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
I don't think the "not issue= d" is unclear.

The possibility to send a revoked re= ply only applies then the responder "knows" that the requested certificate h= as never been issued.
How the responder knows this is totally irre= levant, but unless the responder knows this, it can't choose this option and= has to reply "good".

It does not make revocation c= hecking non-deterministric. 
"good" still means what is decla= red in the standard (The cert is not known to be revoked, but it may never h= ave been issued).
"revoked" still have a deterministic meaning, th= at is, don't trust this cert. The old exact semantics was "the cert IS revok= ed". The new semantic is "the cert is revoked or possibly might never been i= ssued"

The new response semantic of revoked is back= wards compatible and not less deterministic than the good, response.

So, I still don't see any practical problems here.

/Stefan


From: Piyush Jain <piyush@ditenity.com>
Date: Saturday, October 20, 2012 5:48 PM
To:= Stefan Santesson <stefan@aaa= -sec.com>, 'Peter Rybar' <rybar@nb= usr.sk>, 'Carl Wallace' <carl@redhoundsoftware.com>, 'Simon Tardell' <simon@tardell.se>
Cc= : 'Peter Rybar' <peterryb@gma= il.com>, <pkix@ietf.org>
= Subject: RE: [pkix] New draft-ietf-pk= ix-rfc2560bis-06

Please see i= nline

 

From: Stefan Santesson [mailto:stefan@aaa-sec.com]
Sent: F= riday, October 19, 2012 7:23 PM
To: Piyush Jain; 'Peter Rybar'; 'C= arl Wallace'; 'Simon Tardell'
Cc: 'Peter Rybar'; pkix@ietf.org
Subject: Re: [pkix] New draft-ietf= -pkix-rfc2560bis-06

 

I'm sorry. I fail to the = any of the problems you raise.

 

If you receive a request for a certificate that you know has never been = issued, and you choose to reply revoked, what problems can you cause?

[Piyush]= It depends on how you define “never been issued”, which btw bec= omes unclear after introduction of the new text. There are two interpretatio= ns

1)      Certificate is n= ot signed by the CA or

2)  &nb= sp;   Certificate is not present in the database of issued certificates that C= A maintains.

One unintended consequence of first interpretation will be that RPs = would stop performing signature checks if their responder/CA publicizes that= it returns revoked for “non-issued” certificates.

If the interpretat= ion is 2, then this scenario is not possible unless the CA is compromised.

 = ;

What in your mind is a more app= ropriate response?

[Piyush] I would say the appropriate response is good (if the certific= ate is not marked as revoked), because that is what the RP will see if it co= nsults a CRL or a responder detached from the CA. =

Revoked for “not issued&= #8221; adds no value because the only case in which an RP would send a query= for a “non-issued” certificate is when the CA is compromised.

 

[Piyush] It does not make OC= SP non-deterministic but it makes revocation checking non-deterministic. The= goal of OCSP is to address operational limitations of CRLs, not functional = limitations.  The fact that you’ll get different answers from two= sources, both of which are authorized by the same CA makes revocation check= ing non deterministic.

 

= [Piyush] I agree that a revoke response does not hurt anyone.= But the point is that it provides a false sense of additional security to t= he RP without providing any. As an RP, I won’t trust what my responder= says if the authority that certified it is compromised.

 

What is your problem on the practical gr= ound.

[Piyush]  Let’s say that we= still need to address this scenario and revoked is the appropriate response= . In that case

-      &n= bsp;   The tex= t needs to be explicit about the revocation time in this situation. Revoked = implies good until a certain date and this distinction is important for long= term archiving applications. For unissued certificate the revocation time s= hould probably be set to –infinity.

-  = ;        It needs to call out that in this particular scenario it= is addressing a functional limitation of CRLs (ability to detect CA comprom= ise) not an operational limitation.

-   = ;       I think we need additional text in security considerations to = indicate that RP is communicating with a responder certified by a compromise= d CA in this scenario.

 

 

/Stefan

 

From: Piyush Jai= n <piyush@ditenity.com>
Date: Friday, October 19, 2012 7:34 PM
To: Stefan Santesson &= lt;stefan@aaa-sec.com>, 'Peter Ry= bar' <rybar@nbusr.sk>, 'Carl Walla= ce' <carl@redhoundsoftware.com= >, 'Simon Tardell' <simon@tardel= l.se>
Cc: 'Peter Rybar' <peterryb@gmail.com>, <pkix@iet= f.org>
Subject: RE: [pkix] New draft-ietf-pkix-rfc2560bis-0= 6

 

 <= /span>

I think some of you interpreta= tions below are twisted to accommodate the new provisions for providing revo= ked responses for unissued certificates.

Providing responses f= or expired certificates is within the scope of 2560 using archive cutoff ext= ension.

 

The original authors of 2560 can = correct me if I’m wrong, but it is my understanding that a response fr= om OCSP responder is not supposed to indicate if a certificate is good or ba= d but to indicate if a certificate is revoked or unrevoked by the issuing au= thority. The fact that certificate is issued by the CA is checked by the RP = by verifying the signature on the certificate.

 

This draft introduces the concept of returning revoked responses for u= nissued certificates. There are many unintended consequences of this approac= h

-      &= nbsp;   Revocati= on statuses become non-deterministic based on who you are asking (A responde= r with access to CA database vs. one without vs. checking status off a CRL).= If I’m archiving a signed document with the relevant artifacts to det= ermine the validity status of the document, this becomes a huge problem. Not= e that a revoked status implies that certificate was good between the time o= f its issuance and that of its revocation. Any document that is signed withi= n that period should still be considered valid.

-          It would confuse an implementer about = what “non-issued” means. The fact that the CA signed the certifi= cate implies it was issued. If a certificate is issued fraudulently, based o= n its security practices, it is up to the CA to either revoke the issued cer= tificate, or ask its issuing authority to revoke its own certificate.=

 

-Piyush

 

&nbs= p;

 

 

From: pkix-bounces@ietf.org [<= a href=3D"mailto:pkix-bounces@ietf.org">mailto:pkix-bounces@ietf.org] O= n Behalf Of Stefan Santesson
Sent: Friday, October 19, 2012 7:= 25 AM
To: Peter Rybar; 'Carl Wallace'; 'Simon Tardell'
Cc: 'Peter Rybar'; pkix@ietf.org
Sub= ject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06

 

= Peter,

 

An OCSP responder is by defaul= t a service providing information about current certificates.

 

=

If you need it to respond about old ce= rtificates, and as a client know that the responder does this in a way that = suits your needs, you will need to add an extension.

Such ex= tension will not be part of the rfc256bis effort.

 

Is there any text in the current draft that you think is unclea= r on this?

=

 

/Stefan

&n= bsp;

 

From: Peter Ryb= ar <rybar@nbusr.sk>
Date: Friday, October 19, 2012 3:12 PM
To: 'Carl Wallace' <carl@redhoundsoftware.com>, 'Simon= Tardell' <simon@tardell.se>
= Cc: 'Peter Rybar' <peterryb@gm= ail.com>, Stefan Santesson <st= efan@aaa-sec.com>, <pkix@ietf.org>
Subject: RE: [pkix] New draft-ietf-pkix-rfc2560bis-06

 

Well, yes, sort of. You can only be sure to validat= e a signature at the moment of production. =

At = any later point in time the signature key may be compromised, or the algorit= hms involved may have become to weak. (In which case the time of revocation = in the OCSP response is worth nothing to you). The risk increases as time pa= sses. And of course, the revocation information may not be kept around after= the expiry of the certificate. <= /o:p>

 

That'= s why you should validate signatures as soon as possible. 

=

In the dark corner just beyond the dark corn= er that is SCVP, there's a spec (RFC 5276) that defines a binding of evidenc= e records to artifacts that can be returned viaSCVP.  This provides for= timestamping.  

=

[PR] The validation is simplified when OCSP response w= ith positive statement as a hash value of requested certificate is used.

Pos= itive statement is evidence that OCSP know the status of certificate and als= o protect the integrity of certificate with a new more secure hash algorithm= .

 

Peter Rybar

 <= o:p>



Simon Tardell, 

Technology Nexus.

On Fri, Oct 19, = 2012 at 1:07 PM, Peter Rybar <rybar@nbusr.sk> wrote:

Stefan,

I have a question abo= ut the present OCSP RFC and at the end of the mail about the new situation w= hich will happen according to your new proposal.

The presence of the = positive statement in OCSP response is important for electronic signature va= lidations, especially for an expired certificate. Positive statement is the = hash value of a certificate whose status is provided in OCSP response.
Electronic signature validation is usually about the signatures created in= the past and validated now, when the certificate is expired.

When th= e certificate expires then revocation is usually removed from CRL and the re= voked certificate can be provided as "good" in OCSP response.
Is it accep= table? I think not.

According to your new draft there is not defined = a value of revocationTime.
RFC must also define the value of revocationTi= me when the certificate which was never issued is as "revoked".
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pkix-rfc2560bis-06
Have you also covered the situation when the certificate is expired, REMOV= ED FROM CRL and will be provided as revoked with incorrect revocationTime e.= g.with the value before or after the revocationTime which was present in the= removed record from CRL?
Because according to sentence in your draft ""r= evoked" - This state SHOULD also be returned if the responder knows that the= requested certificate has never been issued." the following situation can h= appen: when certificate is removed from CRL after expiration and CA/OCSP res= ponder is responsible for this certificate but have not record about expired= certificate and for that reason it is identified as "never been issued".
...
revoked     [1]     IMPLICIT RevokedInfo,...

   RevokedInfo ::=3D SEQUENCE {
      =  revocationTime              General= izedTime,
       revocationReason    [0] &n= bsp;   EXPLICIT CRLReason OPTIONAL }

As you have mentioned in th= e mail:

"On the "revoked" state, the old spec did not even conside= r the case of a certificate being requested where the OCSP responder knows t= hat the certificate was never issued."=

"It simply recommend a known to be bad certificate to result
in "= revoked" in order to prevent damage as far as possible. It also opens
for= definition of new extensions through which such knowledge could be
obtai= ned."

Peter Rybar=
National Security Authority
Information Security and Electronic Signature Dep= artment
Budatinska 30, 850 07 Bratislava 57, = Slovak Republic
e-mail: peter.rybar@nbusr.sk
e-m= ail: peterryb@gmail.com


-----Original Message-----
From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Stefan Santesson
Sent: = Monday, October 15, 2012 1:49 AM
To: pkix@= ietf.org
Subject: [pkix] New draft-ietf-pkix-rfc2560bis-06

All= ,

I have just posted an update of rfc2560bis (OCSP update) after care= fully
reviewing all comments on the list.

Some notes about the upd= ate:

- Added the previous OCSP editors with updated affiliations.
= - Added some calcifications on ResponderID as suggested by Simon Josefsson.<= br>- Updated the clarifications on Authorized responders. The requirementshave not changed. I just tried to improve the text.
- Updated a clarifi= cation on the "revoked" state to be the preferred
response if a certifica= te is known by the responder to never have been
issued.
- Some minor e= ditorial nits.


Regarding backwards compatibility I mean that none= of the clarifications
changes RFC 2560.

On Authorized responders = it has always been the case that a responder
certificate issued with the = same key as was used to issue the certificate
being checked for revocatio= n, represents a valid Authorized responder.
There has never been an expli= cit requirement to support key rollover and
key rollover support has neve= r been in the "spirit" of the original
standard as it clearly attempted t= o provide direct cryptographic binding
between the responder and the CA.<= br>
On the "revoked" state, the old spec did not even consider the case o= f a
certificate being requested where the OCSP responder knows that thecertificate was never issued. It is clearly counterproductive to respondgood when a certificate is known to be bad. A responder must pick one
r= esponse and picking "revoked" breaks nothing, but has the desired effect,that is, to prevent the certificate from being accepted. The current textmakes clear that there is no mechanism in the current standard by which a<= br>client can know how a responder will respond to a request for a not issue= d
certificate. It simply recommend a known to be bad certificate to resul= t
in "revoked" in order to prevent damage as far as possible. It also ope= ns
for definition of new extensions through which such knowledge could be=
obtained.

The current updates also clearly opens a path for the C= AB forum efforts to
define a suitable solution for server certificates.
I have not, even thug suggested, added any requirements on what client= s
should do with the checked cert as a result of a particular response. I=
don't believe such requirements are suitable as it is policy and not
= protocol. We have no right to demand that all systems MUST reject any
cer= tificate for any reason as they may have a local policy that overrules
th= e OCSP response. This protocol only provides information about the cert
s= tatus, it does not mandate validation policy.

I have not included any= of the substantial changes i the Pinkas draft. I
want to wait for a list= of motivation for each change before including any
of them. So there cha= nged may be up for debate before this draft is ready
for WGLC.

/St= efan



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

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

&n= bsp;

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

=
--B_3433686739_12675366-- From piyush@ditenity.com Sun Oct 21 10:43:07 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B318321F89D3 for ; Sun, 21 Oct 2012 10:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.201 X-Spam-Level: X-Spam-Status: No, score=-3.201 tagged_above=-999 required=5 tests=[AWL=0.397, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPL8ihxC2Web for ; Sun, 21 Oct 2012 10:42:55 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7ECEA21F89BE for ; Sun, 21 Oct 2012 10:42:55 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so3188818iec.31 for ; Sun, 21 Oct 2012 10:42:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language :x-gm-message-state; bh=D7kKdHVc3BK0m6NTDunvjgQdrI0Cv8SOA+358ZflKbc=; b=Qh49aF0CRC8V/H4MqBTh/ihEp0DihSLLpmiY7WEL5W4UbxfobP7QqIpD5hBKNl7xB6 eQvuGUvQPyZk858xLXfuRGdXP9EclUlT/F4UzoZiZbwN2M90cY0Y25B0CGNq4HM4Rb95 PerYCXSzwJTX0cNTsoQzminTpV5G5fMqrYPX2ShurKeIXEk9j+WAxbHLBktsqB9vDdFQ JUzN1OeeZf5ySHPbGH8Og2WIbqDA0mNiGHTDGKdlZgytn8UI8J/SubR9HHzdbNRQHtMq N1WDyidtAzrKBOnrmdpZ0PL9V7oX3fdMWLLw5zRAVJbOiteqmDeMfemjUpCELw+8LpOq 2NKQ== Received: by 10.50.106.227 with SMTP id gx3mr14223066igb.10.1350841374679; Sun, 21 Oct 2012 10:42:54 -0700 (PDT) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id gz10sm6690346igc.9.2012.10.21.10.42.51 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 21 Oct 2012 10:42:53 -0700 (PDT) From: "Piyush Jain" To: "'Stefan Santesson'" , "'Peter Rybar'" , "'Carl Wallace'" , "'Simon Tardell'" References: <076201cdaeda$64800ef0$2d802cd0$@ditenity.com> In-Reply-To: Date: Sun, 21 Oct 2012 10:42:50 -0700 Message-ID: <006401cdafb3$7f073d00$7d15b700$@ditenity.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0065_01CDAF78.D2B3D6B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJdyN4G6QKd3iYBTDkFfnTlIpwYQ5ajxIeA Content-Language: en-us X-Gm-Message-State: ALoCoQnJlGZKaRQAFe5oq154KY47Cc2UGepFQiRBUb+dIE4ydW4oihEGuisq/JerG2ROivM3YsLq Cc: 'Peter Rybar' , pkix@ietf.org Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 17:43:07 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0065_01CDAF78.D2B3D6B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit So what is "not-issued" - not signed by the CA or not present in CA database? It is unclear to folks who have been using signature verification as a way to check issuance. Isn't it a fair conclusion that I do not need to perform signature checks if the responder can check issuance for me? You said that the possibility to send revoked reply only applies when the responder 'knows' that requested certificate has never been issued. Please note that the responder will encounter this kind of request only in two situations. First in which the RP sends a request for a certificate without checking the signature and second in which the responder itself is compromised by virtue of its issuing authority being compromised. In either case what the responder responds with does not matter. I've no problem with your proposal to respond with 'revoked' in this situation. I've fundamental problem with the introduction of 'non-issued' concept in OCSP, which seems to provide additional security in this exceptional scenario without actually providing any. It'll be very helpful if I can see at least one practical scenario where this additional text would add value. -Piyush From: Stefan Santesson [mailto:stefan@aaa-sec.com] Sent: Sunday, October 21, 2012 8:52 AM To: Piyush Jain; 'Peter Rybar'; 'Carl Wallace'; 'Simon Tardell' Cc: 'Peter Rybar'; pkix@ietf.org Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 I don't think the "not issued" is unclear. The possibility to send a revoked reply only applies then the responder "knows" that the requested certificate has never been issued. How the responder knows this is totally irrelevant, but unless the responder knows this, it can't choose this option and has to reply "good". It does not make revocation checking non-deterministric. "good" still means what is declared in the standard (The cert is not known to be revoked, but it may never have been issued). "revoked" still have a deterministic meaning, that is, don't trust this cert. The old exact semantics was "the cert IS revoked". The new semantic is "the cert is revoked or possibly might never been issued" The new response semantic of revoked is backwards compatible and not less deterministic than the good, response. So, I still don't see any practical problems here. /Stefan From: Piyush Jain Date: Saturday, October 20, 2012 5:48 PM To: Stefan Santesson , 'Peter Rybar' , 'Carl Wallace' , 'Simon Tardell' Cc: 'Peter Rybar' , Subject: RE: [pkix] New draft-ietf-pkix-rfc2560bis-06 Please see inline From: Stefan Santesson [mailto:stefan@aaa-sec.com] Sent: Friday, October 19, 2012 7:23 PM To: Piyush Jain; 'Peter Rybar'; 'Carl Wallace'; 'Simon Tardell' Cc: 'Peter Rybar'; pkix@ietf.org Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 I'm sorry. I fail to the any of the problems you raise. If you receive a request for a certificate that you know has never been issued, and you choose to reply revoked, what problems can you cause? [Piyush] It depends on how you define "never been issued", which btw becomes unclear after introduction of the new text. There are two interpretations 1) Certificate is not signed by the CA or 2) Certificate is not present in the database of issued certificates that CA maintains. One unintended consequence of first interpretation will be that RPs would stop performing signature checks if their responder/CA publicizes that it returns revoked for "non-issued" certificates. If the interpretation is 2, then this scenario is not possible unless the CA is compromised. What in your mind is a more appropriate response? [Piyush] I would say the appropriate response is good (if the certificate is not marked as revoked), because that is what the RP will see if it consults a CRL or a responder detached from the CA. Revoked for "not issued" adds no value because the only case in which an RP would send a query for a "non-issued" certificate is when the CA is compromised. It does not make OCSP more non-deterministic. If you ask status for an issued cert from a non-broken CA, nothing is non-deterministic. [Piyush] It does not make OCSP non-deterministic but it makes revocation checking non-deterministic. The goal of OCSP is to address operational limitations of CRLs, not functional limitations. The fact that you'll get different answers from two sources, both of which are authorized by the same CA makes revocation checking non deterministic. If you ask for status for a non-issued certificate, or a bad certificate from a broken CA, then the result is by default non-deteministic and has always been. However, choosing a revoked response may save the relying party, at best, but can hurt no-one [Piyush] I agree that a revoke response does not hurt anyone. But the point is that it provides a false sense of additional security to the RP without providing any. As an RP, I won't trust what my responder says if the authority that certified it is compromised. What is your problem on the practical ground. [Piyush] Let's say that we still need to address this scenario and revoked is the appropriate response. In that case - The text needs to be explicit about the revocation time in this situation. Revoked implies good until a certain date and this distinction is important for long term archiving applications. For unissued certificate the revocation time should probably be set to -infinity. - It needs to call out that in this particular scenario it is addressing a functional limitation of CRLs (ability to detect CA compromise) not an operational limitation. - I think we need additional text in security considerations to indicate that RP is communicating with a responder certified by a compromised CA in this scenario. /Stefan From: Piyush Jain Date: Friday, October 19, 2012 7:34 PM To: Stefan Santesson , 'Peter Rybar' , 'Carl Wallace' , 'Simon Tardell' Cc: 'Peter Rybar' , Subject: RE: [pkix] New draft-ietf-pkix-rfc2560bis-06 Stefan, I think some of you interpretations below are twisted to accommodate the new provisions for providing revoked responses for unissued certificates. Providing responses for expired certificates is within the scope of 2560 using archive cutoff extension. The original authors of 2560 can correct me if I'm wrong, but it is my understanding that a response from OCSP responder is not supposed to indicate if a certificate is good or bad but to indicate if a certificate is revoked or unrevoked by the issuing authority. The fact that certificate is issued by the CA is checked by the RP by verifying the signature on the certificate. This draft introduces the concept of returning revoked responses for unissued certificates. There are many unintended consequences of this approach - Revocation statuses become non-deterministic based on who you are asking (A responder with access to CA database vs. one without vs. checking status off a CRL). If I'm archiving a signed document with the relevant artifacts to determine the validity status of the document, this becomes a huge problem. Note that a revoked status implies that certificate was good between the time of its issuance and that of its revocation. Any document that is signed within that period should still be considered valid. - It would confuse an implementer about what "non-issued" means. The fact that the CA signed the certificate implies it was issued. If a certificate is issued fraudulently, based on its security practices, it is up to the CA to either revoke the issued certificate, or ask its issuing authority to revoke its own certificate. -Piyush From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Stefan Santesson Sent: Friday, October 19, 2012 7:25 AM To: Peter Rybar; 'Carl Wallace'; 'Simon Tardell' Cc: 'Peter Rybar'; pkix@ietf.org Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Peter, An OCSP responder is by default a service providing information about current certificates. The default response you get from an OCSP responder is "good" unless the cert is known to be bad or not a cert the responder can provide status for. If you need it to respond about old certificates, and as a client know that the responder does this in a way that suits your needs, you will need to add an extension. Such extension will not be part of the rfc256bis effort. Is there any text in the current draft that you think is unclear on this? /Stefan From: Peter Rybar Date: Friday, October 19, 2012 3:12 PM To: 'Carl Wallace' , 'Simon Tardell' Cc: 'Peter Rybar' , Stefan Santesson , Subject: RE: [pkix] New draft-ietf-pkix-rfc2560bis-06 Well, yes, sort of. You can only be sure to validate a signature at the moment of production. What if the signature key was compromised at the moment of production but is not yet on a revocation list? [PR] According to clause 2.4 - thisUpdate: The time at which the status being indicated is known to be correct It means when signature time-stamp time is X then any OCSP responses with thisUpdate time X+y are sufficient to validate because the status is correct. Y is in the interval <0, producedAt - X> At any later point in time the signature key may be compromised, or the algorithms involved may have become to weak. (In which case the time of revocation in the OCSP response is worth nothing to you). The risk increases as time passes. And of course, the revocation information may not be kept around after the expiry of the certificate. That's why you should validate signatures as soon as possible. For these archival purposes wouldn't it be better to have the final revocation list before removed due to expiry? In any case, you'd need verification information collected after some grace period following moment of production. [PR] Grace period is not a fixed value of the time interval. Grace period is changeable because the first OCSP response with thisUpdate time value > than time of signature time-stamp contains correct status. If you need to ascertain that a signature was valid at a later time, you have to trust your system that it performed the validation at the time it first received the signature. That trust must be established through some kind of mix of policies and technical measures (such as timestamping). In the dark corner just beyond the dark corner that is SCVP, there's a spec (RFC 5276) that defines a binding of evidence records to artifacts that can be returned viaSCVP. This provides for timestamping. [PR] The validation is simplified when OCSP response with positive statement as a hash value of requested certificate is used. Positive statement is evidence that OCSP know the status of certificate and also protect the integrity of certificate with a new more secure hash algorithm. Peter Rybar Simon Tardell, Technology Nexus. On Fri, Oct 19, 2012 at 1:07 PM, Peter Rybar wrote: Stefan, I have a question about the present OCSP RFC and at the end of the mail about the new situation which will happen according to your new proposal. The presence of the positive statement in OCSP response is important for electronic signature validations, especially for an expired certificate. Positive statement is the hash value of a certificate whose status is provided in OCSP response. Electronic signature validation is usually about the signatures created in the past and validated now, when the certificate is expired. When the certificate expires then revocation is usually removed from CRL and the revoked certificate can be provided as "good" in OCSP response. Is it acceptable? I think not. According to your new draft there is not defined a value of revocationTime. RFC must also define the value of revocationTime when the certificate which was never issued is as "revoked". http://www.ietf.org/rfcdiff?url2=draft-ietf-pkix-rfc2560bis-06 Have you also covered the situation when the certificate is expired, REMOVED FROM CRL and will be provided as revoked with incorrect revocationTime e.g.with the value before or after the revocationTime which was present in the removed record from CRL? Because according to sentence in your draft ""revoked" - This state SHOULD also be returned if the responder knows that the requested certificate has never been issued." the following situation can happen: when certificate is removed from CRL after expiration and CA/OCSP responder is responsible for this certificate but have not record about expired certificate and for that reason it is identified as "never been issued". ... revoked [1] IMPLICIT RevokedInfo, ... RevokedInfo ::= SEQUENCE { revocationTime GeneralizedTime, revocationReason [0] EXPLICIT CRLReason OPTIONAL } As you have mentioned in the mail: "On the "revoked" state, the old spec did not even consider the case of a certificate being requested where the OCSP responder knows that the certificate was never issued." "It simply recommend a known to be bad certificate to result in "revoked" in order to prevent damage as far as possible. It also opens for definition of new extensions through which such knowledge could be obtained." Peter Rybar National Security Authority Information Security and Electronic Signature Department Budatinska 30, 850 07 Bratislava 57, Slovak Republic e-mail: peter.rybar@nbusr.sk e-mail: peterryb@gmail.com -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Stefan Santesson Sent: Monday, October 15, 2012 1:49 AM To: pkix@ietf.org Subject: [pkix] New draft-ietf-pkix-rfc2560bis-06 All, I have just posted an update of rfc2560bis (OCSP update) after carefully reviewing all comments on the list. Some notes about the update: - Added the previous OCSP editors with updated affiliations. - Added some calcifications on ResponderID as suggested by Simon Josefsson. - Updated the clarifications on Authorized responders. The requirements have not changed. I just tried to improve the text. - Updated a clarification on the "revoked" state to be the preferred response if a certificate is known by the responder to never have been issued. - Some minor editorial nits. Regarding backwards compatibility I mean that none of the clarifications changes RFC 2560. On Authorized responders it has always been the case that a responder certificate issued with the same key as was used to issue the certificate being checked for revocation, represents a valid Authorized responder. There has never been an explicit requirement to support key rollover and key rollover support has never been in the "spirit" of the original standard as it clearly attempted to provide direct cryptographic binding between the responder and the CA. On the "revoked" state, the old spec did not even consider the case of a certificate being requested where the OCSP responder knows that the certificate was never issued. It is clearly counterproductive to respond good when a certificate is known to be bad. A responder must pick one response and picking "revoked" breaks nothing, but has the desired effect, that is, to prevent the certificate from being accepted. The current text makes clear that there is no mechanism in the current standard by which a client can know how a responder will respond to a request for a not issued certificate. It simply recommend a known to be bad certificate to result in "revoked" in order to prevent damage as far as possible. It also opens for definition of new extensions through which such knowledge could be obtained. The current updates also clearly opens a path for the CAB forum efforts to define a suitable solution for server certificates. I have not, even thug suggested, added any requirements on what clients should do with the checked cert as a result of a particular response. I don't believe such requirements are suitable as it is policy and not protocol. We have no right to demand that all systems MUST reject any certificate for any reason as they may have a local policy that overrules the OCSP response. This protocol only provides information about the cert status, it does not mandate validation policy. I have not included any of the substantial changes i the Pinkas draft. I want to wait for a list of motivation for each change before including any of them. So there changed may be up for debate before this draft is ready for WGLC. /Stefan _______________________________________________ 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 _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix ------=_NextPart_000_0065_01CDAF78.D2B3D6B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

So what is “not-issued” - not signed by the CA or not = present in CA database?

It is unclear to folks who have been using signature verification as = a way to check issuance. Isn’t it a fair conclusion that I do not = need to perform signature checks if the responder can check issuance for = me?

 

You said that the possibility to send revoked reply only applies when = the responder ’knows’ that requested certificate has never = been issued.

Please note that the responder will encounter this kind of request = only in two situations. First in which the RP sends a request for a = certificate without checking the signature and second in which the = responder itself is compromised by virtue of its issuing authority being = compromised. In either case what the responder responds with does not = matter.

 

I’ve no problem with your proposal to respond with = ‘revoked’ in this situation.

I’ve fundamental problem with the introduction of = ‘non-issued’ concept in OCSP, which seems to provide = additional security in this exceptional scenario without actually = providing any.

 

It’ll be very helpful if I can see at least one practical = scenario where this additional text would add = value.

 

-Piyush

From:= = Stefan Santesson [mailto:stefan@aaa-sec.com]
Sent: Sunday, = October 21, 2012 8:52 AM
To: Piyush Jain; 'Peter Rybar'; 'Carl = Wallace'; 'Simon Tardell'
Cc: 'Peter Rybar'; = pkix@ietf.org
Subject: Re: [pkix] New = draft-ietf-pkix-rfc2560bis-06

 

I don't think the "not issued" is = unclear.

 

The possibility to send a revoked reply only applies then the responder = "knows" that the requested certificate has never been = issued.

How the responder knows this is totally irrelevant, but unless the = responder knows this, it can't choose this option and has to reply = "good".

 

It does not make revocation checking = non-deterministric. 

"good" still means what is declared in the standard (The cert = is not known to be revoked, but it may never have been = issued).

"revoked" still have a deterministic meaning, that is, don't = trust this cert. The old exact semantics was "the cert IS = revoked". The new semantic is "the cert is revoked or possibly = might never been issued"

 

The new response semantic of revoked is backwards compatible and not = less deterministic than the good, = response.

 

So, I still don't see any practical problems = here.

 

/Stefan

 

 

From: Piyush Jain <piyush@ditenity.com>
Dat= e: Saturday, October 20, 2012 5:48 PM
To: Stefan Santesson = <stefan@aaa-sec.com>, = 'Peter Rybar' <rybar@nbusr.sk>, 'Carl Wallace' = <carl@redhoundsoftware.com&g= t;, 'Simon Tardell' <simon@tardell.se>
Cc: = 'Peter Rybar' <peterryb@gmail.com>, <pkix@ietf.org>
Subject: = RE: [pkix] New = draft-ietf-pkix-rfc2560bis-06

 

Please see inline

 

= From:= Stefan Santesson [mailto:stefan@aaa-sec.com] =
Sent: Friday, October 19, 2012 7:23 PM
To: Piyush = Jain; 'Peter Rybar'; 'Carl Wallace'; 'Simon Tardell'
Cc: = 'Peter Rybar'; pkix@ietf.org
Subject: Re: = [pkix] New draft-ietf-pkix-rfc2560bis-06

 

I'm sorry. I fail to the any of the problems you raise.

 

If you receive a request for a certificate that you know has never been = issued, and you choose to reply revoked, what problems can you = cause?

[Piyush] It depends on how you define “never been = issued”, which btw becomes unclear after introduction of the new = text. There are two interpretations

1)      = Certificate is not signed by the CA or

2)      = Certificate is not present in the database of issued certificates = that CA maintains.

One unintended consequence of first interpretation will be that RPs = would stop performing signature checks if their responder/CA publicizes = that it returns revoked for “non-issued” = certificates.

If the interpretation is 2, then this scenario is not possible unless = the CA is compromised.

 

What in your mind is a more appropriate response?

[Piyush] I would say the appropriate response is good (if the = certificate is not marked as revoked), because that is what the RP will = see if it consults a CRL or a responder detached from the CA. =

Revoked for “not issued” adds no value because the only = case in which an RP would send a query for a “non-issued” = certificate is when the CA is compromised.

 

It does not make OCSP more non-deterministic. If you ask status for an = issued cert from a non-broken CA, nothing is = non-deterministic.

[Piyush] It does not make OCSP non-deterministic but it makes = revocation checking non-deterministic. The goal of OCSP is to address = operational limitations of CRLs, not functional limitations.  The = fact that you’ll get different answers from two sources, both of = which are authorized by the same CA makes revocation checking non = deterministic.

 

If you ask for status for a non-issued certificate, or a bad = certificate from a broken CA, then the result is by default = non-deteministic and has always been. However, choosing a revoked = response may save the relying party, at best, but can hurt = no-one

[Piyush] I agree that a revoke response does not hurt anyone. But the = point is that it provides a false sense of additional security to the RP = without providing any. As an RP, I won’t trust what my responder = says if the authority that certified it is = compromised.

 

What is your problem on the practical ground.

[Piyush]  Let’s say that we still need to address this scenario and = revoked is the appropriate response. In that case

-          = The text needs to be explicit about the revocation time in this = situation. Revoked implies good until a certain date and this = distinction is important for long term archiving applications. For = unissued certificate the revocation time should probably be set to = –infinity.

-          = It needs to call out that in this particular scenario it is = addressing a functional limitation of CRLs (ability to detect CA = compromise) not an operational limitation.

-          = I think we need additional text in security considerations to = indicate that RP is communicating with a responder certified by a = compromised CA in this scenario.

 

 

/Stefan

 

From: Piyush Jain <piyush@ditenity.com>
Dat= e: Friday, October 19, 2012 7:34 PM
To: Stefan Santesson = <stefan@aaa-sec.com>, = 'Peter Rybar' <rybar@nbusr.sk>, 'Carl Wallace' = <carl@redhoundsoftware.com&g= t;, 'Simon Tardell' <simon@tardell.se>
Cc: = 'Peter Rybar' <peterryb@gmail.com>, <pkix@ietf.org>
Subject: = RE: [pkix] New draft-ietf-pkix-rfc2560bis-06

 

Stefan,

 

I think some of you interpretations below are twisted to accommodate = the new provisions for providing revoked responses for unissued = certificates.

Providing responses for expired certificates is within the scope of = 2560 using archive cutoff extension.

 

The original authors of 2560 can correct me if I’m wrong, but = it is my understanding that a response from OCSP responder is not = supposed to indicate if a certificate is good or bad but to indicate if = a certificate is revoked or unrevoked by the issuing authority. The fact = that certificate is issued by the CA is checked by the RP by verifying = the signature on the certificate.

 

This draft introduces the concept of returning revoked responses for = unissued certificates. There are many unintended consequences of this = approach

-          = Revocation statuses become non-deterministic based on who you are = asking (A responder with access to CA database vs. one without vs. = checking status off a CRL). If I’m archiving a signed document = with the relevant artifacts to determine the validity status of the = document, this becomes a huge problem. Note that a revoked status = implies that certificate was good between the time of its issuance and = that of its revocation. Any document that is signed within that period = should still be considered valid.

-          = It would confuse an implementer about what “non-issued” = means. The fact that the CA signed the certificate implies it was = issued. If a certificate is issued fraudulently, based on its security = practices, it is up to the CA to either revoke the issued certificate, = or ask its issuing authority to revoke its own certificate.

 

-Piyush

 

 

 

 

= From:= pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] = On Behalf Of Stefan Santesson
Sent: Friday, October 19, = 2012 7:25 AM
To: Peter Rybar; 'Carl Wallace'; 'Simon = Tardell'
Cc: 'Peter Rybar'; pkix@ietf.org
Subject: Re: = [pkix] New draft-ietf-pkix-rfc2560bis-06

 

Peter,

 

An OCSP responder is by default a service providing information about = current certificates.

The default response you get from an OCSP responder is "good" = unless the cert is known to be bad or not a cert the responder can = provide status for.

 

If you need it to respond about old certificates, and as a client know = that the responder does this in a way that suits your needs, you will = need to add an extension.

Such extension will not be part of the rfc256bis effort.

 

Is there any text in the current draft that you think is unclear on = this?

 

/Stefan

 

 

From: Peter Rybar <rybar@nbusr.sk>
Date: = Friday, October 19, 2012 3:12 PM
To: 'Carl Wallace' <carl@redhoundsoftware.com&g= t;, 'Simon Tardell' <simon@tardell.se>
Cc: = 'Peter Rybar' <peterryb@gmail.com>, Stefan = Santesson <stefan@aaa-sec.com>, <pkix@ietf.org>
Subject: = RE: [pkix] New draft-ietf-pkix-rfc2560bis-06

 

Well, yes, sort of. You can only be sure to validate a signature at the = moment of production.

 

What if the signature key was compromised at the moment of production = but is not yet on a revocation list?

[P= R] According to clause 2.4  -  thisUpdate: The time at which = the status being indicated is known to be correct

It= means when signature time-stamp time is X then any OCSP responses with = thisUpdate time X+y are sufficient to validate because the status is = correct.

Y = is in the interval <0, producedAt - X>

 

At any later point in time the signature key may be compromised, or the = algorithms involved may have become to weak. (In which case the time of = revocation in the OCSP response is worth nothing to you). The risk = increases as time passes. And of course, the revocation information may = not be kept around after the expiry of the = certificate. 

 

That's why you should validate signatures as soon as = possible. 

 

For these archival purposes wouldn't it be better to have the final = revocation list before removed due to expiry?  In any case, you'd = need verification information collected after some grace period = following moment of production.

[P= R] Grace period is not a fixed value of the time interval.

Gr= ace period is changeable because the first OCSP response with thisUpdate = time value > than time of signature time-stamp contains correct = status.

 

 

If you need to ascertain that a signature was valid at a later time, = you have to trust your system that it performed the validation at the = time it first received the signature. That trust must be established = through some kind of mix of policies and technical measures (such as = timestamping).

 

In the dark corner just beyond the dark corner that is SCVP, there's a = spec (RFC 5276) that defines a binding of evidence records to artifacts = that can be returned viaSCVP.  This provides for timestamping. =  

[P= R] The validation is simplified when OCSP response with positive = statement as a hash value of requested certificate is used.

Po= sitive statement is evidence that OCSP know the status of certificate = and also protect the integrity of certificate with a new more secure = hash algorithm.

=  

Pe= ter Rybar

&n= bsp;



Simon Tardell, 

Technology Nexus.

On Fri, Oct 19, 2012 at 1:07 PM, Peter Rybar <rybar@nbusr.sk> = wrote:

Stefan,

I have a question about the present OCSP RFC and at the = end of the mail about the new situation which will happen according to = your new proposal.

The presence of the positive statement in OCSP = response is important for electronic signature validations, especially = for an expired certificate. Positive statement is the hash value of a = certificate whose status is provided in OCSP response.

Electronic = signature validation is usually about the signatures created in the past = and validated now, when the certificate is expired.

When the = certificate expires then revocation is usually removed from CRL and the = revoked certificate can be provided as "good" in OCSP = response.
Is it acceptable? I think not.

According to your new = draft there is not defined a value of revocationTime.
RFC must also = define the value of revocationTime when the certificate which was never = issued is as "revoked".
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pkix-rfc2= 560bis-06

Have you also covered the situation when the = certificate is expired, REMOVED FROM CRL and will be provided as revoked = with incorrect revocationTime e.g.with the value before or after the = revocationTime which was present in the removed record from = CRL?
Because according to sentence in your draft = ""revoked" - This state SHOULD also be returned if the = responder knows that the requested certificate has never been = issued." the following situation can happen: when certificate is = removed from CRL after expiration and CA/OCSP responder is responsible = for this certificate but have not record about expired certificate and = for that reason it is identified as "never been = issued".

...
revoked     [1]     = IMPLICIT RevokedInfo,
...

   RevokedInfo ::=3D = SEQUENCE {
       revocationTime     =          GeneralizedTime,
    =    revocationReason    [0]     EXPLICIT = CRLReason OPTIONAL }

As you have mentioned in the = mail:

"On the "revoked" state, the old spec did not even = consider the case of a certificate being requested where the OCSP = responder knows that the certificate was never issued."

"It simply recommend a known to be bad certificate to result
in = "revoked" in order to prevent damage as far as possible. It = also opens
for definition of new extensions through which such = knowledge could be
obtained."

Peter Rybar
National Security Authority
Information Security and Electronic Signature = Department
Budatinska 30, 850 07 = Bratislava 57, Slovak Republic
e-mail: peter.rybar@nbusr.sk
<= span class=3Dhoenzb>e-mail: peterryb@gmail.com


-----Original Message-----
From: pkix-bounces@ietf.org = [mailto:pkix-bounces@ietf.org] On = Behalf Of Stefan Santesson
Sent: Monday, October 15, 2012 1:49 = AM
To: pkix@ietf.org
Subject: = [pkix] New draft-ietf-pkix-rfc2560bis-06

All,

I have just = posted an update of rfc2560bis (OCSP update) after = carefully
reviewing all comments on the list.

Some notes about = the update:

- Added the previous OCSP editors with updated = affiliations.
- Added some calcifications on ResponderID as suggested = by Simon Josefsson.
- Updated the clarifications on Authorized = responders. The requirements
have not changed. I just tried to = improve the text.
- Updated a clarification on the = "revoked" state to be the preferred
response if a = certificate is known by the responder to never have been
issued.
- = Some minor editorial nits.


Regarding backwards compatibility = I mean that none of the clarifications
changes RFC 2560.

On = Authorized responders it has always been the case that a = responder
certificate issued with the same key as was used to issue = the certificate
being checked for revocation, represents a valid = Authorized responder.
There has never been an explicit requirement to = support key rollover and
key rollover support has never been in the = "spirit" of the original
standard as it clearly attempted = to provide direct cryptographic binding
between the responder and the = CA.

On the "revoked" state, the old spec did not even = consider the case of a
certificate being requested where the OCSP = responder knows that the
certificate was never issued. It is clearly = counterproductive to respond
good when a certificate is known to be = bad. A responder must pick one
response and picking = "revoked" breaks nothing, but has the desired effect,
that = is, to prevent the certificate from being accepted. The current = text
makes clear that there is no mechanism in the current standard = by which a
client can know how a responder will respond to a request = for a not issued
certificate. It simply recommend a known to be bad = certificate to result
in "revoked" in order to prevent = damage as far as possible. It also opens
for definition of new = extensions through which such knowledge could be
obtained.

The = current updates also clearly opens a path for the CAB forum efforts = to
define a suitable solution for server certificates.

I have = not, even thug suggested, added any requirements on what = clients
should do with the checked cert as a result of a particular = response. I
don't believe such requirements are suitable as it is = policy and not
protocol. We have no right to demand that all systems = MUST reject any
certificate for any reason as they may have a local = policy that overrules
the OCSP response. This protocol only provides = information about the cert
status, it does not mandate validation = policy.

I have not included any of the substantial changes i the = Pinkas draft. I
want to wait for a list of motivation for each change = before including any
of them. So there changed may be up for debate = before this draft is ready
for = WGLC.

/Stefan



_____________________________________= __________
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

 

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

------=_NextPart_000_0065_01CDAF78.D2B3D6B0-- From stefan@aaa-sec.com Sun Oct 21 11:06:59 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77D7921F88CE for ; Sun, 21 Oct 2012 11:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.201 X-Spam-Level: X-Spam-Status: No, score=-101.201 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+0bZCoANOj4 for ; Sun, 21 Oct 2012 11:06:50 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 2995021F888E for ; Sun, 21 Oct 2012 11:06:48 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 6E5A8586C for ; Sun, 21 Oct 2012 20:04:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id X8-QeLSKSvlP for ; Sun, 21 Oct 2012 20:04:20 +0200 (CEST) Received: from s331.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 27C975AB3 for ; Sun, 21 Oct 2012 20:03:26 +0200 (CEST) Received: (qmail 33760 invoked from network); 21 Oct 2012 18:03:25 -0000 Received: from 81-232-51-61-no39.business.telia.com (HELO [192.168.0.109]) (stefan@fiddler.nu@[81.232.51.61]) (envelope-sender ) by s331.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 21 Oct 2012 18:03:25 -0000 User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Sun, 21 Oct 2012 20:03:20 +0200 From: Stefan Santesson To: Piyush Jain , 'Peter Rybar' , 'Carl Wallace' , 'Simon Tardell' Message-ID: Thread-Topic: [pkix] New draft-ietf-pkix-rfc2560bis-06 In-Reply-To: <006401cdafb3$7f073d00$7d15b700$@ditenity.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3433694605_13143083" Cc: 'Peter Rybar' , pkix@ietf.org Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 18:06:59 -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_3433694605_13143083 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable In line; From: Piyush Jain Date: Sunday, October 21, 2012 7:42 PM To: Stefan Santesson , 'Peter Rybar' , 'Carl Wallace' , 'Simon Tardell' Cc: 'Peter Rybar' , Subject: RE: [pkix] New draft-ietf-pkix-rfc2560bis-06 > So what is =B3not-issued=B2 - not signed by the CA or not present in CA datab= ase? Not issued means it has never been issued. What's unclear about that? Of course it is not present in the database if it is not issued. If you delete things from your database and don't know if this one has been deleted, then you don't know that it has never been issued and can't reply revoked. > It is unclear to folks who have been using signature verification as a wa= y to > check issuance. Isn=B9t it a fair conclusion that I do not need to perform > signature checks if the responder can check issuance for me? No that is not a fair conclusion. These are entirely different things. > =20 > You said that the possibility to send revoked reply only applies when the > responder =B9knows=B9 that requested certificate has never been issued. > Please note that the responder will encounter this kind of request only i= n two > situations. First in which the RP sends a request for a certificate witho= ut > checking the signature and second in which the responder itself is compro= mised > by virtue of its issuing authority being compromised. In either case what= the > responder responds with does not matter. > =20 Some people are pretty convinced it does (from CAB forum), they are so convinced that they are prepared to break compatibility with OCSP. By this little extension that hurst no-one, they don't have to. > I=B9ve no problem with your proposal to respond with =8Crevoked=B9 in this > situation. Good. > I=B9ve fundamental problem with the introduction of =8Cnon-issued=B9 concept in > OCSP, which seems to provide additional security in this exceptional scen= ario > without actually providing any. It provides some, but not much. People keep coming back to that fact that i= f this had been the practice of Diginotar, the security breach would have bee= n discovered a lot earlier. So there might be some gain with no pain. However, in combination with an extension that adds information, this might actually be increasingly valuable. If an OCSP responder starts receiving status requests for certs it knows it has not issued, it can actually give explicit information about this using an extension and it can take adequate measures. But in order to respond to the user, it need to pick one of the responses. Either good + extension or revoked+extension. This proposal is not meant to require any OCSP responder to deal with the concept of "non-issued" certs. It merely allows an OCSP responder to respon= d to such request. > =20 > It=B9ll be very helpful if I can see at least one practical scenario where = this > additional text would add value. Stated in my previous comments. /Stefan > =20 > -Piyush >=20 > From: Stefan Santesson [mailto:stefan@aaa-sec.com] > Sent: Sunday, October 21, 2012 8:52 AM > To: Piyush Jain; 'Peter Rybar'; 'Carl Wallace'; 'Simon Tardell' > Cc: 'Peter Rybar'; pkix@ietf.org > Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 > =20 >=20 > I don't think the "not issued" is unclear. >=20 > =20 >=20 > The possibility to send a revoked reply only applies then the responder > "knows" that the requested certificate has never been issued. >=20 > How the responder knows this is totally irrelevant, but unless the respon= der > knows this, it can't choose this option and has to reply "good". >=20 > =20 >=20 > It does not make revocation checking non-deterministric. >=20 > "good" still means what is declared in the standard (The cert is not know= n to > be revoked, but it may never have been issued). >=20 > "revoked" still have a deterministic meaning, that is, don't trust this c= ert. > The old exact semantics was "the cert IS revoked". The new semantic is "t= he > cert is revoked or possibly might never been issued" >=20 > =20 >=20 > The new response semantic of revoked is backwards compatible and not less > deterministic than the good, response. >=20 > =20 >=20 > So, I still don't see any practical problems here. >=20 > =20 >=20 > /Stefan >=20 > =20 >=20 > =20 >=20 > From: Piyush Jain > Date: Saturday, October 20, 2012 5:48 PM > To: Stefan Santesson , 'Peter Rybar' = , > 'Carl Wallace' , 'Simon Tardell' > Cc: 'Peter Rybar' , > Subject: RE: [pkix] New draft-ietf-pkix-rfc2560bis-06 >=20 > =20 >>=20 >> Please see inline >> =20 >>=20 >> From: Stefan Santesson [mailto:stefan@aaa-sec.com] >> Sent: Friday, October 19, 2012 7:23 PM >> To: Piyush Jain; 'Peter Rybar'; 'Carl Wallace'; 'Simon Tardell' >> Cc: 'Peter Rybar'; pkix@ietf.org >> Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 >> =20 >>=20 >> I'm sorry. I fail to the any of the problems you raise. >>=20 >> =20 >>=20 >> If you receive a request for a certificate that you know has never been >> issued, and you choose to reply revoked, what problems can you cause? >>=20 >> [Piyush] It depends on how you define =B3never been issued=B2, which btw bec= omes >> unclear after introduction of the new text. There are two interpretation= s >> 1) Certificate is not signed by the CA or >>=20 >> 2) Certificate is not present in the database of issued certificate= s >> that CA maintains. >>=20 >> One unintended consequence of first interpretation will be that RPs woul= d >> stop performing signature checks if their responder/CA publicizes that i= t >> returns revoked for =B3non-issued=B2 certificates. >> If the interpretation is 2, then this scenario is not possible unless th= e CA >> is compromised. >> =20 >> What in your mind is a more appropriate response? >> [Piyush] I would say the appropriate response is good (if the certificat= e is >> not marked as revoked), because that is what the RP will see if it consu= lts a >> CRL or a responder detached from the CA. >> Revoked for =B3not issued=B2 adds no value because the only case in which an= RP >> would send a query for a =B3non-issued=B2 certificate is when the CA is >> compromised. >>=20 >> =20 >>=20 >> It does not make OCSP more non-deterministic. If you ask status for an i= ssued >> cert from a non-broken CA, nothing is non-deterministic. >> [Piyush] It does not make OCSP non-deterministic but it makes revocation >> checking non-deterministic. The goal of OCSP is to address operational >> limitations of CRLs, not functional limitations. The fact that you=B9ll g= et >> different answers from two sources, both of which are authorized by the = same >> CA makes revocation checking non deterministic. >> =20 >>=20 >> If you ask for status for a non-issued certificate, or a bad certificate= from >> a broken CA, then the result is by default non-deteministic and has alwa= ys >> been. However, choosing a revoked response may save the relying party, a= t >> best, but can hurt no-one >> [Piyush] I agree that a revoke response does not hurt anyone. But the po= int >> is that it provides a false sense of additional security to the RP witho= ut >> providing any. As an RP, I won=B9t trust what my responder says if the >> authority that certified it is compromised. >> =20 >>=20 >> What is your problem on the practical ground. >>=20 >> [Piyush] Let=B9s say that we still need to address this scenario and revo= ked >> is the appropriate response. In that case >> - The text needs to be explicit about the revocation time in th= is >> situation. Revoked implies good until a certain date and this distinctio= n is >> important for long term archiving applications. For unissued certificate= the >> revocation time should probably be set to =ADinfinity. >>=20 >> - It needs to call out that in this particular scenario it is >> addressing a functional limitation of CRLs (ability to detect CA comprom= ise) >> not an operational limitation. >>=20 >> - I think we need additional text in security considerations to >> indicate that RP is communicating with a responder certified by a compro= mised >> CA in this scenario. >>=20 >> =20 >> =20 >>=20 >> /Stefan >>=20 >> =20 >>=20 >> From: Piyush Jain >> Date: Friday, October 19, 2012 7:34 PM >> To: Stefan Santesson , 'Peter Rybar' , >> 'Carl Wallace' , 'Simon Tardell' >> >> Cc: 'Peter Rybar' , >> Subject: RE: [pkix] New draft-ietf-pkix-rfc2560bis-06 >>=20 >> =20 >>>=20 >>> Stefan, >>> =20 >>> I think some of you interpretations below are twisted to accommodate th= e new >>> provisions for providing revoked responses for unissued certificates. >>> Providing responses for expired certificates is within the scope of 256= 0 >>> using archive cutoff extension. >>> =20 >>> The original authors of 2560 can correct me if I=B9m wrong, but it is my >>> understanding that a response from OCSP responder is not supposed to >>> indicate if a certificate is good or bad but to indicate if a certifica= te is >>> revoked or unrevoked by the issuing authority. The fact that certificat= e is >>> issued by the CA is checked by the RP by verifying the signature on the >>> certificate. >>> =20 >>> This draft introduces the concept of returning revoked responses for >>> unissued certificates. There are many unintended consequences of this >>> approach >>> - Revocation statuses become non-deterministic based on who yo= u are >>> asking (A responder with access to CA database vs. one without vs. chec= king >>> status off a CRL). If I=B9m archiving a signed document with the relevant >>> artifacts to determine the validity status of the document, this become= s a >>> huge problem. Note that a revoked status implies that certificate was g= ood >>> between the time of its issuance and that of its revocation. Any docume= nt >>> that is signed within that period should still be considered valid. >>>=20 >>> - It would confuse an implementer about what =B3non-issued=B2 mean= s. >>> The fact that the CA signed the certificate implies it was issued. If a >>> certificate is issued fraudulently, based on its security practices, it= is >>> up to the CA to either revoke the issued certificate, or ask its issuin= g >>> authority to revoke its own certificate. >>>=20 >>> =20 >>> -Piyush >>> =20 >>> =20 >>> =20 >>> =20 >>>=20 >>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >>> Stefan Santesson >>> Sent: Friday, October 19, 2012 7:25 AM >>> To: Peter Rybar; 'Carl Wallace'; 'Simon Tardell' >>> Cc: 'Peter Rybar'; pkix@ietf.org >>> Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 >>> =20 >>>=20 >>> Peter, >>>=20 >>> =20 >>>=20 >>> An OCSP responder is by default a service providing information about >>> current certificates. >>>=20 >>> The default response you get from an OCSP responder is "good" unless th= e >>> cert is known to be bad or not a cert the responder can provide status = for. >>>=20 >>> =20 >>>=20 >>> If you need it to respond about old certificates, and as a client know = that >>> the responder does this in a way that suits your needs, you will need t= o add >>> an extension. >>>=20 >>> Such extension will not be part of the rfc256bis effort. >>>=20 >>> =20 >>>=20 >>> Is there any text in the current draft that you think is unclear on thi= s? >>>=20 >>> =20 >>>=20 >>> /Stefan >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>> From: Peter Rybar >>> Date: Friday, October 19, 2012 3:12 PM >>> To: 'Carl Wallace' , 'Simon Tardell' >>> >>> Cc: 'Peter Rybar' , Stefan Santesson >>> , >>> Subject: RE: [pkix] New draft-ietf-pkix-rfc2560bis-06 >>>=20 >>> =20 >>>>=20 >>>>> Well, yes, sort of. You can only be sure to validate a signature at t= he >>>>> moment of production. >>>>=20 >>>> =20 >>>>=20 >>>> What if the signature key was compromised at the moment of production = but >>>> is not yet on a revocation list? >>>> [PR] According to clause 2.4 - thisUpdate: The time at which the sta= tus >>>> being indicated is known to be correct >>>> It means when signature time-stamp time is X then any OCSP responses w= ith >>>> thisUpdate time X+y are sufficient to validate because the status is >>>> correct.=20 >>>> Y is in the interval <0, producedAt - X> >>>>=20 >>>> =20 >>>>> At any later point in time the signature key may be compromised, or t= he >>>>> algorithms involved may have become to weak. (In which case the time = of >>>>> revocation in the OCSP response is worth nothing to you). The risk >>>>> increases as time passes. And of course, the revocation information m= ay >>>>> not be kept around after the expiry of the certificate. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> That's why you should validate signatures as soon as possible. >>>>=20 >>>> =20 >>>>=20 >>>> For these archival purposes wouldn't it be better to have the final >>>> revocation list before removed due to expiry? In any case, you'd need >>>> verification information collected after some grace period following m= oment >>>> of production. >>>>=20 >>>> [PR] Grace period is not a fixed value of the time interval. >>>> Grace period is changeable because the first OCSP response with thisUp= date >>>> time value > than time of signature time-stamp contains correct status= . >>>> =20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> If you need to ascertain that a signature was valid at a later time, = you >>>>> have to trust your system that it performed the validation at the tim= e it >>>>> first received the signature. That trust must be established through = some >>>>> kind of mix of policies and technical measures (such as timestamping)= . >>>>=20 >>>> =20 >>>>=20 >>>> In the dark corner just beyond the dark corner that is SCVP, there's a= spec >>>> (RFC 5276) that defines a binding of evidence records to artifacts tha= t can >>>> be returned viaSCVP. This provides for timestamping. >>>> [PR] The validation is simplified when OCSP response with positive >>>> statement as a hash value of requested certificate is used. >>>> Positive statement is evidence that OCSP know the status of certificat= e and >>>> also protect the integrity of certificate with a new more secure hash >>>> algorithm. >>>>=20 >>>> =20 >>>> Peter Rybar >>>> =20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Simon Tardell, >>>>>=20 >>>>> Technology Nexus. >>>>>=20 >>>>> On Fri, Oct 19, 2012 at 1:07 PM, Peter Rybar wrote: >>>>> Stefan, >>>>>=20 >>>>> I have a question about the present OCSP RFC and at the end of the ma= il >>>>> about the new situation which will happen according to your new propo= sal. >>>>>=20 >>>>> The presence of the positive statement in OCSP response is important = for >>>>> electronic signature validations, especially for an expired certifica= te. >>>>> Positive statement is the hash value of a certificate whose status is >>>>> provided in OCSP response. >>>>>=20 >>>>> Electronic signature validation is usually about the signatures creat= ed in >>>>> the past and validated now, when the certificate is expired. >>>>>=20 >>>>> When the certificate expires then revocation is usually removed from = CRL >>>>> and the revoked certificate can be provided as "good" in OCSP respons= e. >>>>> Is it acceptable? I think not. >>>>>=20 >>>>> According to your new draft there is not defined a value of >>>>> revocationTime. >>>>> RFC must also define the value of revocationTime when the certificate >>>>> which was never issued is as "revoked". >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pkix-rfc2560bis-06 >>>>>=20 >>>>> Have you also covered the situation when the certificate is expired, >>>>> REMOVED FROM CRL and will be provided as revoked with incorrect >>>>> revocationTime e.g.with the value before or after the revocationTime = which >>>>> was present in the removed record from CRL? >>>>> Because according to sentence in your draft ""revoked" - This state S= HOULD >>>>> also be returned if the responder knows that the requested certificat= e has >>>>> never been issued." the following situation can happen: when certific= ate >>>>> is removed from CRL after expiration and CA/OCSP responder is respons= ible >>>>> for this certificate but have not record about expired certificate an= d for >>>>> that reason it is identified as "never been issued". >>>>>=20 >>>>> ... >>>>> revoked [1] IMPLICIT RevokedInfo, >>>>> ... >>>>>=20 >>>>> RevokedInfo ::=3D SEQUENCE { >>>>> revocationTime GeneralizedTime, >>>>> revocationReason [0] EXPLICIT CRLReason OPTIONAL } >>>>>=20 >>>>> As you have mentioned in the mail: >>>>>=20 >>>>> "On the "revoked" state, the old spec did not even consider the case = of a >>>>> certificate being requested where the OCSP responder knows that the >>>>> certificate was never issued." >>>>>=20 >>>>> "It simply recommend a known to be bad certificate to result >>>>> in "revoked" in order to prevent damage as far as possible. It also o= pens >>>>> for definition of new extensions through which such knowledge could b= e >>>>> obtained." >>>>> Peter Rybar >>>>> National Security Authority >>>>> Information Security and Electronic Signature Department >>>>> Budatinska 30, 850 07 Bratislava 57, Slovak Republic >>>>> e-mail: peter.rybar@nbusr.sk >>>>> e-mail: peterryb@gmail.com >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf = Of >>>>> Stefan Santesson >>>>> Sent: Monday, October 15, 2012 1:49 AM >>>>> To: pkix@ietf.org >>>>> Subject: [pkix] New draft-ietf-pkix-rfc2560bis-06 >>>>>=20 >>>>> All, >>>>>=20 >>>>> I have just posted an update of rfc2560bis (OCSP update) after carefu= lly >>>>> reviewing all comments on the list. >>>>>=20 >>>>> Some notes about the update: >>>>>=20 >>>>> - Added the previous OCSP editors with updated affiliations. >>>>> - Added some calcifications on ResponderID as suggested by Simon >>>>> Josefsson. >>>>> - Updated the clarifications on Authorized responders. The requiremen= ts >>>>> have not changed. I just tried to improve the text. >>>>> - Updated a clarification on the "revoked" state to be the preferred >>>>> response if a certificate is known by the responder to never have bee= n >>>>> issued. >>>>> - Some minor editorial nits. >>>>>=20 >>>>>=20 >>>>> Regarding backwards compatibility I mean that none of the clarificati= ons >>>>> changes RFC 2560. >>>>>=20 >>>>> On Authorized responders it has always been the case that a responder >>>>> certificate issued with the same key as was used to issue the certifi= cate >>>>> being checked for revocation, represents a valid Authorized responder= . >>>>> There has never been an explicit requirement to support key rollover = and >>>>> key rollover support has never been in the "spirit" of the original >>>>> standard as it clearly attempted to provide direct cryptographic bind= ing >>>>> between the responder and the CA. >>>>>=20 >>>>> On the "revoked" state, the old spec did not even consider the case o= f a >>>>> certificate being requested where the OCSP responder knows that the >>>>> certificate was never issued. It is clearly counterproductive to resp= ond >>>>> good when a certificate is known to be bad. A responder must pick one >>>>> response and picking "revoked" breaks nothing, but has the desired ef= fect, >>>>> that is, to prevent the certificate from being accepted. The current = text >>>>> makes clear that there is no mechanism in the current standard by whi= ch a >>>>> client can know how a responder will respond to a request for a not i= ssued >>>>> certificate. It simply recommend a known to be bad certificate to res= ult >>>>> in "revoked" in order to prevent damage as far as possible. It also o= pens >>>>> for definition of new extensions through which such knowledge could b= e >>>>> obtained. >>>>>=20 >>>>> The current updates also clearly opens a path for the CAB forum effor= ts to >>>>> define a suitable solution for server certificates. >>>>>=20 >>>>> I have not, even thug suggested, added any requirements on what clien= ts >>>>> should do with the checked cert as a result of a particular response.= I >>>>> don't believe such requirements are suitable as it is policy and not >>>>> protocol. We have no right to demand that all systems MUST reject any >>>>> certificate for any reason as they may have a local policy that overr= ules >>>>> the OCSP response. This protocol only provides information about the = cert >>>>> status, it does not mandate validation policy. >>>>>=20 >>>>> I have not included any of the substantial changes i the Pinkas draft= . I >>>>> want to wait for a list of motivation for each change before includin= g any >>>>> of them. So there changed may be up for debate before this draft is r= eady >>>>> for WGLC. >>>>>=20 >>>>> /Stefan >>>>>=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 --B_3433694605_13143083 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
In line;

From: Piyush Jain <piyush@ditenity.com>
Date: Sunday, October 21, 2012 7:42 PM
To: Stefan Santesson <stefan@aaa-sec.com>, 'Peter Rybar' <rybar@nbusr.sk>, 'Carl Wallace' <carl@redhoundsoftware.com>, 'Simon Tardell' <simon@tardell.se>
Cc: 'Peter Rybar' <peterryb@gmail.com>, <pkix@ietf.o= rg>
Subject: RE: [pkix] New= draft-ietf-pkix-rfc2560bis-06

So what is &= #8220;not-issued” - not signed by the CA or not present in CA database= ?


Not is= sued means it has never been issued. What's unclear about that?
Of course it is not present in the database if it is not issued= .
If you delete things from your database and don't know if this o= ne has been deleted, then you don't know that it has never been issued and c= an't reply revoked.


It is unclear to folks who have been using signature verification as = a way to check issuance. Isn’t it a fair conclusion that I do not need= to perform signature checks if the responder can check issuance for me?


= No that is not a fair conclusion. These are entirely different things.
=

<= div class=3D"WordSection1">

 

You said that the possibili= ty to send revoked reply only applies when the responder ’knows’= that requested certificate has never been issued.

Please note that the responder will encount= er this kind of request only in two situations. First in which the RP sends = a request for a certificate without checking the signature and second in whi= ch the responder itself is compromised by virtue of its issuing authority be= ing compromised. In either case what the responder responds with does not ma= tter.

 


Som= e people are pretty convinced it does (from CAB forum), they are so convince= d that they are prepared to break compatibility with OCSP. By this little ex= tension that hurst no-one, they don't have to.

I’ve no problem with your proposa= l to respond with ‘revoked’ in this situation.

<= /div>

Good.

I’ve fundamental problem with the introdu= ction of ‘non-issued’ concept in OCSP, which seems to provide ad= ditional security in this exceptional scenario without actually providing an= y.


It provides some, but not much. People keep coming back to that fact t= hat if this had been the practice of Diginotar, the security breach would ha= ve been discovered a lot earlier. So there might be some gain with no pain.<= /div>

However, in combination with an extension that adds= information, this might actually be increasingly valuable.
If an = OCSP responder starts receiving status requests for certs it knows it has no= t issued, it can actually give explicit information about this using an exte= nsion and it can take adequate measures.
But in order to respond t= o the user, it need to pick one of the responses. Either good + extension or= revoked+extension.

This proposal is not meant to r= equire any OCSP responder to deal with the concept of "non-issued" certs. It= merely allows an OCSP responder to respond to such request.

<= /div>

 <= /p>

It’ll be very helpful if I can = see at least one practical scenario where this additional text would add val= ue.


Stated in my previous comments.

/Stefan

=

 

-Piyush<= /p>

From: Stefan Santesson [mailto:stefan@aaa-sec.com]
Sent: Sunday, Octob= er 21, 2012 8:52 AM
To: Piyush Jain; 'Peter Rybar'; 'Carl Wallace'= ; 'Simon Tardell'
Cc: 'Peter Rybar'; pkix@ietf.org
Subject: Re: [pkix] New draft-ietf-pkix-rfc256= 0bis-06

 

I don't think the "not issued" is unc= lear.

 =

The possibility to se= nd a revoked reply only applies then the responder "knows" that the requeste= d certificate has never been issued.

How the responder knows this is totally irrelevant, but = unless the responder knows this, it can't choose this option and has to repl= y "good".

&n= bsp;

It does not make = revocation checking non-deterministric. 

"good" still means what is declared in the stan= dard (The cert is not known to be revoked, but it may never have been issued= ).

"revoked" stil= l have a deterministic meaning, that is, don't trust this cert. The old exac= t semantics was "the cert IS revoked". The new semantic is "the cert is revo= ked or possibly might never been issued"

 

The new response semantic of revoked is backwards compatible a= nd not less deterministic than the good, response.

 

So, I still don't see any practical problems here.

 <= /span>

/Stefan

 

 

From: Piyush Jain <piyush@ditenity.com>
Date: Saturday, Oct= ober 20, 2012 5:48 PM
To: Stefan Santesson <stefan@aaa-sec.com>, 'Peter Rybar' <rybar@nbusr.sk>, 'Carl Wallace' <carl@redhoundsoftware.com>, 'Simon Tarde= ll' <simon@tardell.se>
Cc:= 'Peter Rybar' <peterryb@gmail.co= m>, <pkix@ietf.org>
Su= bject: RE: [pkix] New draft-ietf-pkix-rfc2560bis-06

 

Please see inline

 

From: Stefan Santesson= [mailto:stefan@aaa-sec.com]
= Sent: Friday, October 19, 2012 7:23 PM
To: Piyush Jain; 'Peter= Rybar'; 'Carl Wallace'; 'Simon Tardell'
Cc: 'Peter Rybar'; pkix@ietf.org
Subject: Re: [pkix] New= draft-ietf-pkix-rfc2560bis-06

 

I'm sorry. I fail to the= any of the problems you raise.<= /span>

 

If yo= u receive a request for a certificate that you know has never been issued, a= nd you choose to reply revoked, what problems can you cause?

[Piyush] It depends on how you define “never been issu= ed”, which btw becomes unclear after introduction of the new text. The= re are two interpretations

= 1)&nb= sp;     Certificate is not signed by the CA or

2)      Certificate is not present in the database of is= sued certificates that CA maintains.

One uninten= ded consequence of first interpretation will be that RPs would stop performi= ng signature checks if their responder/CA publicizes that it returns revoked= for “non-issued” certificates.

If t= he interpretation is 2, then this scenario is not possible unless the CA is = compromised.

<= p class=3D"MsoNormal"> =

What in your mind is a more= appropriate response?

[Piyush] I would say the appropri= ate response is good (if the certificate is not marked as revoked), because = that is what the RP will see if it consults a CRL or a responder detached fr= om the CA.

Revoked for “not issued”= adds no value because the only case in which an RP would send a query for a= “non-issued” certificate is when the CA is compromised.<= /i>

 

It does not make OCSP more non-deter= ministic. If you ask status for an issued cert from a non-broken CA, nothing= is non-deterministic.

[Piyush] It does not make OCSP no= n-deterministic but it makes revocation checking non-deterministic. The goal= of OCSP is to address operational limitations of CRLs, not functional limit= ations.  The fact that you’ll get different answers from two sour= ces, both of which are authorized by the same CA makes revocation checking n= on deterministic.

 

If you ask f= or status for a non-issued certificate, or a bad certificate from a broken C= A, then the result is by default non-deteministic and has always been. Howev= er, choosing a revoked response may save the relying party, at best, but can= hurt no-one

[Piyush] I agree that a revoke response doe= s not hurt anyone. But the point is that it provides a false sense of additi= onal security to the RP without providing any. As an RP, I won’t trust= what my responder says if the authority that certified it is compromised.

 

What is your problem on the prac= tical ground.

[Piyush]  Let’s say that we still need to address this scenari= o and revoked is the appropriate response. In that case

-          The text needs to be explici= t about the revocation time in this situation. Revoked implies good until a = certain date and this distinction is important for long term archiving appli= cations. For unissued certificate the revocation time should probably be set= to –infinity.

<= p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l3 level1 lfo4= ">-   =        It needs to call out that in this particular scenario it is add= ressing a functional limitation of CRLs (ability to detect CA compromise) no= t an operational limitation.

- &nbs= p;        I think we need additional text in security considerati= ons to indicate that RP is communicating with a responder certified by a com= promised CA in this scenario.

 

 <= /span>

/Stefan

 

From: Piyush Jain <piyush@diteni= ty.com>
Date: Friday, October 19, 2012 7:34 PM
To: Stefan Santesson <stefan@aaa-sec.co= m>, 'Peter Rybar' <rybar@nbusr.sk<= /a>>, 'Carl Wallace' <carl@= redhoundsoftware.com>, 'Simon Tardell' <simon@tardell.se>
Cc: 'Peter Rybar' <peterryb@gmail.com>, <pkix@ietf.org>
Subject: RE: [pkix] New draft-ie= tf-pkix-rfc2560bis-06

=

 

Stefan,

&nbs= p;

I think some of you interpretations below are twisted to ac= commodate the new provisions for providing revoked responses for unissued ce= rtificates.

Providing responses for expired certificates is wi= thin the scope of 2560 using archive cutoff extension.

 <= /span>

<= span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31= , 73, 125); ">The original authors of 2560 can correct me if I’m wrong= , but it is my understanding that a response from OCSP responder is not supp= osed to indicate if a certificate is good or bad but to indicate if a certif= icate is revoked or unrevoked by the issuing authority. The fact that certif= icate is issued by the CA is checked by the RP by verifying the signature on= the certificate.

 =

This draft introduces t= he concept of returning revoked responses for unissued certificates. There a= re many unintended consequences of this approach

-          Revocation statuses become non-determ= inistic based on who you are asking (A responder with access to CA database = vs. one without vs. checking status off a CRL). If I’m archiving a sig= ned document with the relevant artifacts to determine the validity status of= the document, this becomes a huge problem. Note that a revoked status impli= es that certificate was good between the time of its issuance and that of it= s revocation. Any document that is signed within that period should still be= considered valid.

= -   &n= bsp;      It would confuse an implementer about what “non-issued”= means. The fact that the CA signed the certificate implies it was issued. I= f a certificate is issued fraudulently, based on its security practices, it = is up to the CA to either revoke the issued certificate, or ask its issuing = authority to revoke its own certificate.

 

= -Piyush

 

 

 

 

From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Stefan Santes= son
Sent: Friday, October 19, 2012 7:25 AM
To: Peter Ryb= ar; 'Carl Wallace'; 'Simon Tardell'
Cc: 'Peter Rybar'; pkix@ietf.org
Subject: Re: [pkix] New draf= t-ietf-pkix-rfc2560bis-06=

 

Peter,

 =

An OCSP responder is by default a service providing informa= tion about current certificates.=

The default response you ge= t from an OCSP responder is "good" unless the cert is known to be bad or not= a cert the responder can provide status for.

 <= span style=3D"color:black">

If you need it to respond about old certificates, and as a client k= now that the responder does this in a way that suits your needs, you will ne= ed to add an extension.

Such extension will not be part of t= he rfc256bis effort.

<= /div>

 =

Is there any tex= t in the current draft that you think is unclear on this?

&n= bsp;

/Stefan

 

 

From: Peter Rybar <rybar@nbusr.sk>
Date: Friday, October 19, 2012 3:= 12 PM
To: 'Carl Wallace' <carl@redhoundsoftware.com>, 'Simon Tardell' <simon@tardell.se>
Cc: 'Peter Rybar' <= peterryb@gmail.com>, Stefan Sante= sson <stefan@aaa-sec.com>, <= ;pkix@ietf.org>
Subject: RE:= [pkix] New draft-ietf-pkix-rfc2560bis-06

 

Well= , yes, sort of. You can only be sure to validate a signature at the moment o= f production.

 

What if the sig= nature key was compromised at the moment of production but is not yet on a r= evocation list?

[PR] According to clause 2.4  -  thisUpdate: The t= ime at which the status being indicated is known to be correct

It means when= signature time-stamp time is X then any OCSP responses with thisUpdate time= X+y are sufficient to validate because the status is correct.

Y is in the = interval <0, producedAt - X>

 

At any later point in time the s= ignature key may be compromised, or the algorithms involved may have become = to weak. (In which case the time of revocation in the OCSP response is worth= nothing to you). The risk increases as time passes. And of course, the revo= cation information may not be kept around after the expiry of the certificat= e. 

 =

That's why you should validate sig= natures as soon as possible. 

 

For these archival purposes wouldn't it be better to have the fin= al revocation list before removed due to expiry?  In any case, you'd ne= ed verification information collected after some grace period following mome= nt of production.

[PR] Grace period is not a fixed value of the t= ime interval.

Grace period is changeable because the first OCSP response wi= th thisUpdate time value > than time of signature time-stamp contains cor= rect status.

 <= /p>

 

If you need to ascertain that a signa= ture was valid at a later time, you have to trust your system that it perfor= med the validation at the time it first received the signature. That trust m= ust be established through some kind of mix of policies and technical measur= es (such as timestamping).

 

[PR] Th= e validation is simplified when OCSP response with positive statement as a h= ash value of requested certificate is used.=

Positive statement is evidence t= hat OCSP know the status of certificate and also protect the integrity of ce= rtificate with a new more secure hash algorithm.

 

Peter= Rybar

 

<= span style=3D"font-size: 10.5pt; font-family: Calibri, sans-serif; color: blac= k; ">

Simon Tardell, 

<= div>

On Fri, Oct 19, 2012 at 1:07 PM, Peter Rybar = <rybar@nbusr.sk> w= rote:

Stefan,

I have a question about the present OCSP RFC and a= t the end of the mail about the new situation which will happen according to= your new proposal.

The presence of the positive statement in OCSP re= sponse is important for electronic signature validations, especially for an = expired certificate. Positive statement is the hash value of a certificate w= hose status is provided in OCSP response.

Electronic signature valida= tion is usually about the signatures created in the past and validated now, = when the certificate is expired.

When the certificate expires then re= vocation is usually removed from CRL and the revoked certificate can be prov= ided as "good" in OCSP response.
Is it acceptable? I think not.

Ac= cording to your new draft there is not defined a value of revocationTime.RFC must also define the value of revocationTime when the certificate which= was never issued is as "revoked".
http://www.ietf.org/rfcdi= ff?url2=3Ddraft-ietf-pkix-rfc2560bis-06

Have you also covered the s= ituation when the certificate is expired, REMOVED FROM CRL and will be provi= ded as revoked with incorrect revocationTime e.g.with the value before or af= ter the revocationTime which was present in the removed record from CRL?
= Because according to sentence in your draft ""revoked" - This state SHOULD a= lso be returned if the responder knows that the requested certificate has ne= ver been issued." the following situation can happen: when certificate is re= moved from CRL after expiration and CA/OCSP responder is responsible for thi= s certificate but have not record about expired certificate and for that rea= son it is identified as "never been issued".

...
revoked   &n= bsp; [1]     IMPLICIT RevokedInfo,
...

   Revo= kedInfo ::=3D SEQUENCE {
       revocationTime   &= nbsp;          GeneralizedTime,
    &n= bsp;  revocationReason    [0]     EXPLICIT CRLReaso= n OPTIONAL }

As you have mentioned in the mail:

"On the "re= voked" state, the old spec did not even consider the case of a certificate b= eing requested where the OCSP responder knows that the certificate was never= issued."

<= p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">"It simply recommend = a known to be bad certificate to result
in "revoked" in order to prevent = damage as far as possible. It also opens
for definition of new extensions= through which such knowledge could be
obtained."

Peter Rybar
National Security Authority
In= formation Security and Electronic Signature Department
Budatinska 30, 850 07 Bratislava 57, Slovak Republic
e-mail: peter.rybar@= nbusr.sk
e-mail: peterryb@gmail.com


-----Original M= essage-----
From: pkix-bounces@iet= f.org [mailto:pkix-bounces@ietf.o= rg] On Behalf Of Stefan Santesson
Sent: Monday, October 15, 2012 1:49= AM
To: pkix@ietf.org
Subject: [pki= x] New draft-ietf-pkix-rfc2560bis-06

All,

I have just posted a= n update of rfc2560bis (OCSP update) after carefully
reviewing all commen= ts on the list.

Some notes about the update:

- Added the previ= ous OCSP editors with updated affiliations.
- Added some calcifications o= n ResponderID as suggested by Simon Josefsson.
- Updated the clarificatio= ns on Authorized responders. The requirements
have not changed. I just tr= ied to improve the text.
- Updated a clarification on the "revoked" state= to be the preferred
response if a certificate is known by the responder = to never have been
issued.
- Some minor editorial nits.


Reg= arding backwards compatibility I mean that none of the clarifications
cha= nges RFC 2560.

On Authorized responders it has always been the case t= hat a responder
certificate issued with the same key as was used to issue= the certificate
being checked for revocation, represents a valid Authori= zed responder.
There has never been an explicit requirement to support ke= y rollover and
key rollover support has never been in the "spirit" of the= original
standard as it clearly attempted to provide direct cryptographi= c binding
between the responder and the CA.

On the "revoked" state= , the old spec did not even consider the case of a
certificate being requ= ested where the OCSP responder knows that the
certificate was never issue= d. It is clearly counterproductive to respond
good when a certificate is = known to be bad. A responder must pick one
response and picking "revoked"= breaks nothing, but has the desired effect,
that is, to prevent the cert= ificate from being accepted. The current text
makes clear that there is n= o mechanism in the current standard by which a
client can know how a resp= onder will respond to a request for a not issued
certificate. It simply r= ecommend a known to be bad certificate to result
in "revoked" in order to= prevent damage as far as possible. It also opens
for definition of new e= xtensions through which such knowledge could be
obtained.

The curr= ent updates also clearly opens a path for the CAB forum efforts to
define= a suitable solution for server certificates.

I have not, even thug s= uggested, added any requirements on what clients
should do with the check= ed cert as a result of a particular response. I
don't believe such requir= ements are suitable as it is policy and not
protocol. We have no right to= demand that all systems MUST reject any
certificate for any reason as th= ey may have a local policy that overrules
the OCSP response. This protoco= l only provides information about the cert
status, it does not mandate va= lidation policy.

I have not included any of the substantial changes i= the Pinkas draft. I
want to wait for a list of motivation for each chang= e before including any
of them. So there changed may be up for debate bef= ore this draft is ready
for WGLC.

/Stefan



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

_______________________________________________
pkix mailing li= st
pkix@ietf.org
https://www.ietf.org/mail= man/listinfo/pkix

=

 

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

= --B_3433694605_13143083-- From stefan@aaa-sec.com Mon Oct 22 06:49:02 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F86B21F887B for ; Mon, 22 Oct 2012 06:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.516 X-Spam-Level: X-Spam-Status: No, score=-100.516 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L7X82jESE-S9 for ; Mon, 22 Oct 2012 06:49:00 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id EB69621F842F for ; Mon, 22 Oct 2012 06:48:59 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id EA1E722AA42A for ; Mon, 22 Oct 2012 15:48:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id d-kFZ0hyvy4P for ; Mon, 22 Oct 2012 15:48:54 +0200 (CEST) Received: from s331.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 9BE2A16CAD for ; Mon, 22 Oct 2012 15:48:52 +0200 (CEST) Received: (qmail 33939 invoked from network); 22 Oct 2012 13:48:52 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.209]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s331.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 22 Oct 2012 13:48:52 -0000 User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Mon, 22 Oct 2012 15:48:50 +0200 From: Stefan Santesson To: Peter Rybar Message-ID: Thread-Topic: [pkix] New draft-ietf-pkix-rfc2560bis-06 In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3433765733_15706370" Cc: pkix@ietf.org Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 13:49:02 -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_3433765733_15706370 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Peter, You have a point there. I missed that, good catch. /Stefan From: Peter Rybar Date: Monday, October 22, 2012 2:38 PM To: Stefan Santesson Cc: Peter Rybar , Carl Wallace , Simon Tardell , Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 > Stefan, > > You have defined in draft that certificate identified with correct (hash of > issuer name, hash of issuer key) and with unknown cert serial number xyz is > revoked. > Correct response must also contains the value of item revocationTime. > > Do you know the correct value of revocationTime in situation which you have > described? > ... > revoked [1] IMPLICIT RevokedInfo, > ... > > RevokedInfo ::= SEQUENCE { > revocationTime GeneralizedTime, > revocationReason [0] EXPLICIT CRLReason OPTIONAL } > Peter > > 2012/10/19 Stefan Santesson >> Peter, >> >> An OCSP responder is by default a service providing information about current >> certificates. >> The default response you get from an OCSP responder is "good" unless the cert >> is known to be bad or not a cert the responder can provide status for. >> >> If you need it to respond about old certificates, and as a client know that >> the responder does this in a way that suits your needs, you will need to add >> an extension. >> Such extension will not be part of the rfc256bis effort. >> >> Is there any text in the current draft that you think is unclear on this? >> >> /Stefan >> >> >> From: Peter Rybar >> Date: Friday, October 19, 2012 3:12 PM >> To: 'Carl Wallace' , 'Simon Tardell' >> >> >> Cc: 'Peter Rybar' , Stefan Santesson >> , >> Subject: RE: [pkix] New draft-ietf-pkix-rfc2560bis-06 >> >>>> Well, yes, sort of. You can only be sure to validate a signature at the >>>> moment of production. >>> >>> >>> >>> What if the signature key was compromised at the moment of production but is >>> not yet on a revocation list? >>> [PR] According to clause 2.4 - thisUpdate: The time at which the status >>> being indicated is known to be correct >>> It means when signature time-stamp time is X then any OCSP responses with >>> thisUpdate time X+y are sufficient to validate because the status is >>> correct. >>> Y is in the interval <0, producedAt - X> >>> >>> >>>> At any later point in time the signature key may be compromised, or the >>>> algorithms involved may have become to weak. (In which case the time of >>>> revocation in the OCSP response is worth nothing to you). The risk >>>> increases as time passes. And of course, the revocation information may not >>>> be kept around after the expiry of the certificate. >>>> >>>> >>>> >>>> That's why you should validate signatures as soon as possible. >>> >>> >>> >>> For these archival purposes wouldn't it be better to have the final >>> revocation list before removed due to expiry? In any case, you'd need >>> verification information collected after some grace period following moment >>> of production. >>> >>> [PR] Grace period is not a fixed value of the time interval. >>> Grace period is changeable because the first OCSP response with thisUpdate >>> time value > than time of signature time-stamp contains correct status. >>> >>>> >>>> >>>> >>>> If you need to ascertain that a signature was valid at a later time, you >>>> have to trust your system that it performed the validation at the time it >>>> first received the signature. That trust must be established through some >>>> kind of mix of policies and technical measures (such as timestamping). >>> >>> >>> >>> In the dark corner just beyond the dark corner that is SCVP, there's a spec >>> (RFC 5276) that defines a binding of evidence records to artifacts that can >>> be returned viaSCVP. This provides for timestamping. >>> >>> [PR] The validation is simplified when OCSP response with positive statement >>> as a hash value of requested certificate is used. >>> Positive statement is evidence that OCSP know the status of certificate and >>> also protect the integrity of certificate with a new more secure hash >>> algorithm. >>> >>> >>> Peter Rybar >>> >>>> >>>> >>>> >>>> Simon Tardell, >>>> >>>> Technology Nexus. >>>> >>>> On Fri, Oct 19, 2012 at 1:07 PM, Peter Rybar wrote: >>>> Stefan, >>>> >>>> I have a question about the present OCSP RFC and at the end of the mail >>>> about the new situation which will happen according to your new proposal. >>>> >>>> The presence of the positive statement in OCSP response is important for >>>> electronic signature validations, especially for an expired certificate. >>>> Positive statement is the hash value of a certificate whose status is >>>> provided in OCSP response. >>>> >>>> Electronic signature validation is usually about the signatures created in >>>> the past and validated now, when the certificate is expired. >>>> >>>> When the certificate expires then revocation is usually removed from CRL >>>> and the revoked certificate can be provided as "good" in OCSP response. >>>> Is it acceptable? I think not. >>>> >>>> According to your new draft there is not defined a value of revocationTime. >>>> RFC must also define the value of revocationTime when the certificate which >>>> was never issued is as "revoked". >>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-pkix-rfc2560bis-06 >>>> >>>> Have you also covered the situation when the certificate is expired, >>>> REMOVED FROM CRL and will be provided as revoked with incorrect >>>> revocationTime e.g.with the value before or after the revocationTime which >>>> was present in the removed record from CRL? >>>> >>>> Because according to sentence in your draft ""revoked" - This state SHOULD >>>> also be returned if the responder knows that the requested certificate has >>>> never been issued." the following situation can happen: when certificate is >>>> removed from CRL after expiration and CA/OCSP responder is responsible for >>>> this certificate but have not record about expired certificate and for that >>>> reason it is identified as "never been issued". >>>> >>>> ... >>>> revoked [1] IMPLICIT RevokedInfo, >>>> ... >>>> >>>> RevokedInfo ::= SEQUENCE { >>>> revocationTime GeneralizedTime, >>>> revocationReason [0] EXPLICIT CRLReason OPTIONAL } >>>> >>>> As you have mentioned in the mail: >>>> "On the "revoked" state, the old spec did not even consider the case of a >>>> certificate being requested where the OCSP responder knows that the >>>> certificate was never issued." >>>> >>>> "It simply recommend a known to be bad certificate to result >>>> in "revoked" in order to prevent damage as far as possible. It also opens >>>> for definition of new extensions through which such knowledge could be >>>> obtained." >>>> Peter Rybar >>>> National Security Authority >>>> Information Security and Electronic Signature Department >>>> Budatinska 30, 850 07 Bratislava 57, Slovak Republic >>>> e-mail: peter.rybar@nbusr.sk >>>> e-mail: peterryb@gmail.com >>>> >>>> >>>> -----Original Message----- >>>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >>>> Stefan Santesson >>>> Sent: Monday, October 15, 2012 1:49 AM >>>> To: pkix@ietf.org >>>> Subject: [pkix] New draft-ietf-pkix-rfc2560bis-06 >>>> >>>> All, >>>> >>>> I have just posted an update of rfc2560bis (OCSP update) after carefully >>>> reviewing all comments on the list. >>>> >>>> Some notes about the update: >>>> >>>> - Added the previous OCSP editors with updated affiliations. >>>> - Added some calcifications on ResponderID as suggested by Simon Josefsson. >>>> - Updated the clarifications on Authorized responders. The requirements >>>> have not changed. I just tried to improve the text. >>>> - Updated a clarification on the "revoked" state to be the preferred >>>> response if a certificate is known by the responder to never have been >>>> issued. >>>> - Some minor editorial nits. >>>> >>>> >>>> Regarding backwards compatibility I mean that none of the clarifications >>>> changes RFC 2560. >>>> >>>> On Authorized responders it has always been the case that a responder >>>> certificate issued with the same key as was used to issue the certificate >>>> being checked for revocation, represents a valid Authorized responder. >>>> There has never been an explicit requirement to support key rollover and >>>> key rollover support has never been in the "spirit" of the original >>>> standard as it clearly attempted to provide direct cryptographic binding >>>> between the responder and the CA. >>>> >>>> On the "revoked" state, the old spec did not even consider the case of a >>>> certificate being requested where the OCSP responder knows that the >>>> certificate was never issued. It is clearly counterproductive to respond >>>> good when a certificate is known to be bad. A responder must pick one >>>> response and picking "revoked" breaks nothing, but has the desired effect, >>>> that is, to prevent the certificate from being accepted. The current text >>>> makes clear that there is no mechanism in the current standard by which a >>>> client can know how a responder will respond to a request for a not issued >>>> certificate. It simply recommend a known to be bad certificate to result >>>> in "revoked" in order to prevent damage as far as possible. It also opens >>>> for definition of new extensions through which such knowledge could be >>>> obtained. >>>> >>>> The current updates also clearly opens a path for the CAB forum efforts to >>>> define a suitable solution for server certificates. >>>> >>>> I have not, even thug suggested, added any requirements on what clients >>>> should do with the checked cert as a result of a particular response. I >>>> don't believe such requirements are suitable as it is policy and not >>>> protocol. We have no right to demand that all systems MUST reject any >>>> certificate for any reason as they may have a local policy that overrules >>>> the OCSP response. This protocol only provides information about the cert >>>> status, it does not mandate validation policy. >>>> >>>> I have not included any of the substantial changes i the Pinkas draft. I >>>> want to wait for a list of motivation for each change before including any >>>> of them. So there changed may be up for debate before this draft is ready >>>> for WGLC. >>>> >>>> /Stefan >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >>>> >>>> >>>> _______________________________________________ pkix mailing list >>>> pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix > --B_3433765733_15706370 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Peter,

<= div>You have a point there. I missed that, good catch.

<= div>/Stefan

From: Pe= ter Rybar <peterryb@gmail.com>=
Date: Monday, October 22, 2012 2:= 38 PM
To: Stefan Santesson <stefan@aaa-sec.com>
Cc: Peter Rybar <rybar@nbusr.sk>, Carl Wallace <carl@redhoundsoftware.com>, Simon Tardell <simon@tardell.se>, <pkix@ietf.org>
Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06

Stefan,

You have defined in draft that certificate identified with correct = (hash of issuer name, hash of  issuer key) and with unknown cert serial number xyz is revoked.
Correct response must also contains the value of ite= m revocationTime.

Do you know the correct value of&= nbsp; revocationTime in situation which you have described?
...
revoked     [1]     IMPLICIT RevokedInfo,
...

   RevokedInfo ::=3D SEQUENCE {
       revocationTime          = ;    GeneralizedTime,
       revocationReason    [0]     EXPLICIT CRLReason OPTIONAL }
Peter

2012/10/19 Stefan Santesson <stefan@aaa-sec.com>
Peter,

An OCSP respond= er is by default a service providing information about current certificates.=
The default response you get from an OCSP responder is "good" unl= ess the cert is known to be bad or not a cert the responder can provide stat= us for.

If you need it to respond about old certifi= cates, and as a client know that the responder does this in a way that suits= your needs, you will need to add an extension.
Such extension wil= l not be part of the rfc256bis effort.

Is there any= text in the current draft that you think is unclear on this?

=
/Stefan


From: Peter Rybar <rybar@nbusr.sk>
Date: Friday, October 19, 2012 3:12 PM
To: 'Carl Wallace' <carl@redhoundsoftware.com>, 'Simon Tardell= ' <simon@tardell.se= >

Cc: 'Peter Ry= bar' <peterryb@gmail.= com>, Stefan Santesson <stefan@aaa-sec.com>, <pkix@ietf.org>
S= ubject: RE: [pkix] New draft-ietf-pkix-rfc2560bis-06
<= br>

Well, yes, sort of. You can only be sure to validate a signature at the moment of production. <= /span>

 

What if the signature key was compromised at the moment of production but is not yet on a revocat= ion list?

[P= R] According to clause 2.4  -  thisUpdate: The time at which the status being indicated = is known to be correct

= It means when signature time-stamp time is X then any OCSP responses with thisUpdate time X+y are s= ufficient to validate because the status is correct.

Y is in the interval <0, producedAt - X>

 

= At any= later point in time the signature key may be compromised, or the algorithms involved may have become to weak. (In which = case the time of revocation in the OCSP response is worth nothing to you). The r= isk increases as time passes. And of course, the revocation information may not= be kept around after the expiry of the certificate. =

 

That's why you shoul= d validate signatures as soon as possible. 

 

For these archiv= al purposes wouldn't it be better to have the final revocation list before rem= oved due to expiry?  In any case, you'd need verification information colle= cted after some grace period following moment of production.

[PR] Grace period= is not a fixed value of the time interval.

= Grace period is changeable because the first OCSP response with thisUpdate time value > than time o= f signature time-stamp contains correct status.

<= font color=3D"black" face=3D"Calibri"> 

&= nbsp;

If you need to ascertain that a signature was valid at a later time, you have to trust you= r system that it performed the validation at the time it first received the signature. That trust must be established through some kind of mix of polic= ies and technical measures (such as timestamping).

=  

In = the dark corner just beyond the dark corner that is SCVP, there's a spec (RFC 5276) that defines a binding of evidence records to artifacts that can be returned via= SCVP.  This provides for timestamping.  

[PR] The validatio= n is simplified when OCSP response with positive statement as a hash value of requested certificate is used.

Positive statement is evidence that OCSP know the status of certificate and also protect the integrity of certificate with a new more secure hash algorithm.

 

P= eter Rybar

 



Simon Tardell, 

Technology Nexus.

On Fri, Oct 19, 2012 at 1:07 PM, Peter Rybar <rybar@nbusr.sk> wrote:

Stefan,

I have a question about the present OCSP RFC and at the end of the mail abo= ut the new situation which will happen according to your new proposal.

= The presence of the positive statement in OCSP response is important for electronic signature validations, especially for an expired certificate. Po= sitive statement is the hash value of a certificate whose status is provided in OC= SP response.

Electronic signature validation is usually about the signatures created in = the past and validated now, when the certificate is expired.

When the certificate expires then revocation is usually removed from CRL an= d the revoked certificate can be provided as "good" in OCSP response.
Is it acceptable? I think not.

According to your new draft there is not defined a value of revocationTime.=
RFC must also define the value of revocationTime when the certificate which= was never issued is as "revoked".
http://www.ietf.org/rfcdiff?u= rl2=3Ddraft-ietf-pkix-rfc2560bis-06

Have you also covered the situation when the certificate is expired, REMOVE= D FROM CRL and will be provided as revoked with incorrect revocationTime e.g.= with the value before or after the revocationTime which was present in the removed record from CRL?

Because according to sentence in your draft ""revoked" - This state SHOULD also be returned if the responder knows that the requested certificate has never been issued." the following situation can happen: when certificate is removed from CRL after expiration and CA/OCSP responder= is responsible for this certificate but have not record about expired certific= ate and for that reason it is identified as "never been issued".

...
revoked     [1]     IMPLICIT RevokedInfo,
...

   RevokedInfo ::=3D SEQUENCE {
       revocationTime          = ;    GeneralizedTime,
       revocationReason    [0]     EXPLICIT CRLReason OPTIONAL }

As you have mentioned in the mail:
<= div>

"On the "revoked" state, the old spec did not even consider the case of a certificate being requested where the OCSP responder knows that the certifi= cate was never issued."

"It simply recommend a known to= be bad certificate to result
in "revoked" in order to prevent damage as far as possible. It also opens
for definition of new extensions through which such knowledge could be
obtained."

Peter Rybar
National Security Authority
In= formation Security and Electronic Signature Department
Budat= inska 30, 850 07 Bratislava 57, Slovak Republic
e-mail: peter.rybar@nbusr.sk
e-mail: peterryb@gmail.com

-----Original Message-----
From: pkix-bounces@i= etf.org [mailto:p= kix-bounces@ietf.org] On Behalf Of Stefan Santesson
Sent: Monday, October 15, 2012 1:49 AM
To: pkix@ietf.org
Subject: [pkix] New draft-ietf-pkix-rfc2560bis-06

All,

I have just posted an update of rfc2560bis (OCSP update) after carefully reviewing all comments on the list.

Some notes about the update:

- Added the previous OCSP editors with updated affiliations.
- Added some calcifications on ResponderID as suggested by Simon Josefsson.=
- Updated the clarifications on Authorized responders. The requirements
= have not changed. I just tried to improve the text.
- Updated a clarification on the "revoked" state to be the preferred
response if a certificate is known by the responder to never have been
issued.
- Some minor editorial nits.


Regarding backwards compatibility I mean that none of the clarifications changes RFC 2560.

On Authorized responders it has always been the case that a responder
certificate issued with the same key as was used to issue the certificate being checked for revocation, represents a valid Authorized responder.
There has never been an explicit requirement to support key rollover and key rollover support has never been in the "spirit" of the original
standard as it clearly attempted to provide direct cryptographic binding between the responder and the CA.

On the "revoked" state, the old spec did not even consider the case of a
certificate being requested where the OCSP responder knows that the
certificate was never issued. It is clearly counterproductive to respond good when a certificate is known to be bad. A responder must pick one
response and picking "revoked" breaks nothing, but has the desired effect,
that is, to prevent the certificate from being accepted. The current text makes clear that there is no mechanism in the current standard by which a client can know how a responder will respond to a request for a not issued<= br> certificate. It simply recommend a known to be bad certificate to result in "revoked" in order to prevent damage as far as possible. It also opens
for definition of new extensions through which such knowledge could be
obtained.

The current updates also clearly opens a path for the CAB forum efforts to<= br> define a suitable solution for server certificates.

I have not, even thug suggested, added any requirements on what clients
= should do with the checked cert as a result of a particular response. I
d= on't believe such requirements are suitable as it is policy and not
protocol. We have no right to demand that all systems MUST reject any
certificate for any reason as they may have a local policy that overrules the OCSP response. This protocol only provides information about the cert status, it does not mandate validation policy.

I have not included any of the substantial changes i the Pinkas draft. I want to wait for a list of motivation for each change before including any<= br> of them. So there changed may be up for debate before this draft is ready for WGLC.

/Stefan



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

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

 <= /span>

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


--B_3433765733_15706370-- From denis.pinkas@bull.net Mon Oct 22 07:03:37 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DEEF21F858B for ; Mon, 22 Oct 2012 07:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.934 X-Spam-Level: X-Spam-Status: No, score=-4.934 tagged_above=-999 required=5 tests=[AWL=1.314, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o53OtRM56qS1 for ; Mon, 22 Oct 2012 07:03:26 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0F47C21F8931 for ; Mon, 22 Oct 2012 07:03:24 -0700 (PDT) Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id E0246158034 for ; Mon, 22 Oct 2012 16:03:23 +0200 (CEST) Received: from [127.0.0.1] ([129.184.39.15]) by MSGC-007.bull.fr (Lotus Domino Release 8.5.3FP1) with ESMTP id 2012102216032171-1365 ; Mon, 22 Oct 2012 16:03:21 +0200 Message-ID: <50855225.1030202@bull.net> Date: Mon, 22 Oct 2012 16:03:17 +0200 From: Denis Pinkas User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: pkix@ietf.org References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 22/10/2012 16:03:23, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 22/10/2012 16:03:23, Serialize complete at 22/10/2012 16:03:23 Content-Type: multipart/alternative; boundary="------------090704070802010403070702" Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 14:03:37 -0000 This is a multi-part message in MIME format. --------------090704070802010403070702 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed To the PKIX list: Without changing the meaning of "good" and of either "revoked" or "unknown", it is not possible to address the case of what is presently called "non-issued certificates". The current text from RFC 2560 is: "The "good" state indicates a positive response to the state inquiry. At a minimum, this positive response indicates that the certificate is not revoked, but does not necessarily mean that the certificate was ever issued or that the time at which the response was produced is within the certificate's validity interval. Response extensions may be used to convey additional information on assertions made by the responder regarding the state of the certificate such as positive statement about issuance, validity, etc. The "revoked" state indicates that the certificate has been revoked (either permanantly or temporarily (on hold)). The "unknown" state indicates that the responder doesn't know about the certificate being requested". A minor change should be done to advertise that "good" may be returned when the certificate was never issued and CRLs are being used. Replacement text for the definition of the "good" state: "The "good" state indicates a positive response to the state inquiry. At a minimum, this positive response indicates that the certificate is not revoked, but does not necessarily mean that the certificate was ever issued *(e.g. when CRLs are used by the OCSP responders)* or that the time at which the response was produced is within the certificate's validity interval. Response extensions may be used to convey additional information on assertions made by the OCSP responder regarding the state of the certificate such as *an ** ** indication that the OCSP responder has a direct access to the ** ** database of issued certificates*, validity, etc ... " Then either the meaning of "rekoved" or of "unknown" needs to be changed. draft-ietf-pkix-rfc2560bis-06 attempts to address the issue and proposes to keep the meaning of "unknown" unchanged and to change the meaning of "revoked" in the following way: "The "revoked" state indicates that the certificate has been revoked (either permanently or temporarily (on hold)). This state SHOULD also be returned if the responder *knows that the requested certificate has ** ** never been issued*. Note that the receiver of a response may have to consult out-of-band knowledge, or information in an extension defined outside of this standard, to know whether a particular responder has knowledge about whether a requested certificate has been issued or not and whether it responds "good" or "revoked" to a state request for a non-issued certificate". There is a door opened for a future extension "to know whether a particular responder has knowledge about whether a requested certificate has been issued or not". However, the extension proposed in draft-pinkas-2560bis-certinfo-00.txt, carries a slightly different meaning: - an indication that the serial number of the target certificate is not present in the database, *Saying that the certificate has not been issued is not fully appropriate.* The text should be modified in the following way: "The "revoked" state indicates that the certificate has been revoked (either permanently or temporarily (on hold)). This state SHOULD also be returned if the responder *has an access to the database of **issued certificates and if the serial number of the target ** ** certificate is not present in that database. * *In this case, the "revoked" state indicates either that the ** ** certificate has never been issued or that it has been issued but ** ** subsequently removed (by an attack or by accident) from the database **of issued certificates.* Response extensions may be used to convey additional information on assertions made by the OCSP responder regarding the state of the certificate such as *an **indication that the OCSP responder has a direct access to the **database of issued certificates*, validity, etc ... " An alternative is to keep the meaning of "revoked" and to change the meaning of "unknown" in the following way: "The "unknown" status indicates either that the server doesn't know about the certificate being requested *or the revocation status of the certificate being requested* Response extensions may be used to convey additional information on assertions made by the OCSP responder regarding the state of the certificate such as *an **indication that the OCSP responder has a direct access to the **database of issued certificates*, validity, etc ..." There are pros and cons for each alternative. If the meaning of "revoked" is changed it is also necessary to say what should be the values of both revocationTime and revocationReason: CertStatus ::= CHOICE { good [0] IMPLICIT NULL, revoked [1] IMPLICIT RevokedInfo, unknown [2] IMPLICIT UnknownInfo } RevokedInfo ::= SEQUENCE { revocationTime GeneralizedTime, revocationReason [0] EXPLICIT CRLReason OPTIONAL } UnknownInfo ::= NULL CRLReason is imported from PKIX1Implicit88 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit(19) } CRLReason is defined in RFC 5280 as: CRLReason ::= ENUMERATED { unspecified (0), keyCompromise (1), cACompromise (2), affiliationChanged (3), superseded (4), cessationOfOperation (5), certificateHold (6), -- value 7 is not used removeFromCRL (8), privilegeWithdrawn (9), aACompromise (10) } For the revocationTime should we use the content of notBefore field from the certificate ? For the revocationReason should we use unspecified or keyCompromise ? In any case, guidance should be given. Although I understand that changing the meaning of "revoked" may be seen as "safer" for old implemenations, changing the meaning of "unknown" also seems to be a reasonable alternative. In this case, it might be useful (and sufficient) to say that if an OCSP responder is authoritative for the target certificate, then the OCSP client SHOULD NOT use an alternative source of revocation information like CRLs. Denis > In line; > > From: Piyush Jain > > Date: Sunday, October 21, 2012 7:42 PM > To: Stefan Santesson >, > 'Peter Rybar' >, 'Carl Wallace' > >, 'Simon > Tardell' > > Cc: 'Peter Rybar' >, > > > Subject: RE: [pkix] New draft-ietf-pkix-rfc2560bis-06 > > So what is "not-issued" - not signed by the CA or not present in > CA database? > > > Not issued means it has never been issued. What's unclear about that? > > Of course it is not present in the database if it is not issued. > If you delete things from your database and don't know if this one has > been deleted, then you don't know that it has never been issued and > can't reply revoked. > > > It is unclear to folks who have been using signature verification > as a way to check issuance. Isn't it a fair conclusion that I do > not need to perform signature checks if the responder can check > issuance for me? > > > No that is not a fair conclusion. These are entirely different things. > > You said that the possibility to send revoked reply only applies > when the responder 'knows' that requested certificate has never > been issued. > > Please note that the responder will encounter this kind of request > only in two situations. First in which the RP sends a request for > a certificate without checking the signature and second in which > the responder itself is compromised by virtue of its issuing > authority being compromised. In either case what the responder > responds with does not matter. > > > Some people are pretty convinced it does (from CAB forum), they are so > convinced that they are prepared to break compatibility with OCSP. By > this little extension that hurst no-one, they don't have to. > > I've no problem with your proposal to respond with 'revoked' in > this situation. > > > Good. > > I've fundamental problem with the introduction of 'non-issued' > concept in OCSP, which seems to provide additional security in > this exceptional scenario without actually providing any. > > > It provides some, but not much. People keep coming back to that fact > that if this had been the practice of Diginotar, the security breach > would have been discovered a lot earlier. So there might be some gain > with no pain. > > However, in combination with an extension that adds information, this > might actually be increasingly valuable. > If an OCSP responder starts receiving status requests for certs it > knows it has not issued, it can actually give explicit information > about this using an extension and it can take adequate measures. > But in order to respond to the user, it need to pick one of the > responses. Either good + extension or revoked+extension. > > This proposal is not meant to require any OCSP responder to deal with > the concept of "non-issued" certs. It merely allows an OCSP responder > to respond to such request. > > It'll be very helpful if I can see at least one practical scenario > where this additional text would add value. > > > Stated in my previous comments. > > /Stefan > > -Piyush > > *From:*Stefan Santesson [mailto:stefan@aaa-sec.com] > *Sent:* Sunday, October 21, 2012 8:52 AM > *To:* Piyush Jain; 'Peter Rybar'; 'Carl Wallace'; 'Simon Tardell' > *Cc:* 'Peter Rybar'; pkix@ietf.org > *Subject:* Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 > > I don't think the "not issued" is unclear. > > The possibility to send a revoked reply only applies then the > responder "knows" that the requested certificate has never been > issued. > > How the responder knows this is totally irrelevant, but unless the > responder knows this, it can't choose this option and has to reply > "good". > > It does not make revocation checking non-deterministric. > > "good" still means what is declared in the standard (The cert is > not known to be revoked, but it may never have been issued). > > "revoked" still have a deterministic meaning, that is, don't trust > this cert. The old exact semantics was "the cert IS revoked". The > new semantic is "the cert is revoked or possibly might never been > issued" > > The new response semantic of revoked is backwards compatible and > not less deterministic than the good, response. > > So, I still don't see any practical problems here. > > /Stefan > > *From: *Piyush Jain > > *Date: *Saturday, October 20, 2012 5:48 PM > *To: *Stefan Santesson >, 'Peter Rybar' >, 'Carl Wallace' > >, > 'Simon Tardell' > > *Cc: *'Peter Rybar' >, > > *Subject: *RE: [pkix] New draft-ietf-pkix-rfc2560bis-06 > > Please see inline > > *From:*Stefan Santesson [mailto:stefan@aaa-sec.com] > *Sent:* Friday, October 19, 2012 7:23 PM > *To:* Piyush Jain; 'Peter Rybar'; 'Carl Wallace'; 'Simon Tardell' > *Cc:* 'Peter Rybar'; pkix@ietf.org > *Subject:* Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 > > I'm sorry. I fail to the any of the problems you raise. > > If you receive a request for a certificate that you know has > never been issued, and you choose to reply revoked, what > problems can you cause? > > */[Piyush] It depends on how you define "never been issued", > which btw becomes unclear after introduction of the new text. > There are two interpretations/* > > 1)*/Certificate is not signed by the CA or/* > > 2)*/Certificate is not present in the database of issued > certificates that CA maintains./* > > */One unintended consequence of first interpretation will be > that RPs would stop performing signature checks if their > responder/CA publicizes that it returns revoked for > "non-issued" certificates./* > > */If the interpretation is 2, then this scenario is not > possible unless the CA is compromised./* > > What in your mind is a more appropriate response? > > */[Piyush] I would say the appropriate response is good (if > the certificate is not marked as revoked), because that is > what the RP will see if it consults a CRL or a responder > detached from the CA. /* > > */Revoked for "not issued" adds no value because the only case > in which an RP would send a query for a "non-issued" > certificate is when the CA is compromised./* > > It does not make OCSP more non-deterministic. If you ask > status for an issued cert from a non-broken CA, nothing is > non-deterministic. > > */[Piyush] It does not make OCSP non-deterministic but it > makes revocation checking non-deterministic. The goal of OCSP > is to address operational limitations of CRLs, not functional > limitations. The fact that you'll get different answers from > two sources, both of which are authorized by the same CA makes > revocation checking non deterministic. /* > > If you ask for status for a non-issued certificate, or a bad > certificate from a broken CA, then the result is by default > non-deteministic and has always been. However, choosing a > revoked response may save the relying party, at best, but can > hurt no-one > > */[Piyush] I agree that a revoke response does not hurt > anyone. But the point is that it provides a false sense of > additional security to the RP without providing any. As an RP, > I won't trust what my responder says if the authority that > certified it is compromised./* > > What is your problem on the practical ground. > > */[Piyush] /* Let's say that we still need to address this > scenario and revoked is the appropriate response. In that case > > -The text needs to be explicit about the revocation time in > this situation. Revoked implies good until a certain date and > this distinction is important for long term archiving > applications. For unissued certificate the revocation time > should probably be set to --infinity. > > -It needs to call out that in this particular scenario it is > addressing a functional limitation of CRLs (ability to detect > CA compromise) not an operational limitation. > > -I think we need additional text in security considerations to > indicate that RP is communicating with a responder certified > by a compromised CA in this scenario. > > /Stefan > > *From: *Piyush Jain > > *Date: *Friday, October 19, 2012 7:34 PM > *To: *Stefan Santesson >, 'Peter Rybar' >, 'Carl Wallace' > >, 'Simon Tardell' > > > *Cc: *'Peter Rybar' >, > > *Subject: *RE: [pkix] New draft-ietf-pkix-rfc2560bis-06 > > Stefan, > > I think some of you interpretations below are twisted to > accommodate the new provisions for providing revoked > responses for unissued certificates. > > Providing responses for expired certificates is within the > scope of 2560 using archive cutoff extension. > > The original authors of 2560 can correct me if I'm wrong, > but it is my understanding that a response from OCSP > responder is not supposed to indicate if a certificate is > good or bad but to indicate if a certificate is revoked or > unrevoked by the issuing authority. The fact that > certificate is issued by the CA is checked by the RP by > verifying the signature on the certificate. > > This draft introduces the concept of returning revoked > responses for unissued certificates. There are many > unintended consequences of this approach > > -Revocation statuses become non-deterministic based on who > you are asking (A responder with access to CA database vs. > one without vs. checking status off a CRL). If I'm > archiving a signed document with the relevant artifacts to > determine the validity status of the document, this > becomes a huge problem. Note that a revoked status implies > that certificate was good between the time of its issuance > and that of its revocation. Any document that is signed > within that period should still be considered valid. > > -It would confuse an implementer about what "non-issued" > means. The fact that the CA signed the certificate implies > it was issued. If a certificate is issued fraudulently, > based on its security practices, it is up to the CA to > either revoke the issued certificate, or ask its issuing > authority to revoke its own certificate. > > -Piyush > > *From:*pkix-bounces@ietf.org > > [mailto:pkix-bounces@ietf.org] *On Behalf Of *Stefan Santesson > *Sent:* Friday, October 19, 2012 7:25 AM > *To:* Peter Rybar; 'Carl Wallace'; 'Simon Tardell' > *Cc:* 'Peter Rybar'; pkix@ietf.org > *Subject:* Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 > > Peter, > > An OCSP responder is by default a service providing > information about current certificates. > > The default response you get from an OCSP responder is > "good" unless the cert is known to be bad or not a cert > the responder can provide status for. > > If you need it to respond about old certificates, and as a > client know that the responder does this in a way that > suits your needs, you will need to add an extension. > > Such extension will not be part of the rfc256bis effort. > > Is there any text in the current draft that you think is > unclear on this? > > /Stefan > > *From: *Peter Rybar > > *Date: *Friday, October 19, 2012 3:12 PM > *To: *'Carl Wallace' >, 'Simon Tardell' > > > *Cc: *'Peter Rybar' >, Stefan Santesson > >, > > > *Subject: *RE: [pkix] New draft-ietf-pkix-rfc2560bis-06 > > Well, yes, sort of. You can only be sure to > validate a signature at the moment of production. > > What if the signature key was compromised at the > moment of production but is not yet on a revocation list? > > [PR] According to clause 2.4 - thisUpdate: The time > at which the status being indicated is known to be correct > > It means when signature time-stamp time is X then any > OCSP responses with thisUpdate time X+y are sufficient > to validate because the status is correct. > > Y is in the interval <0, producedAt - X> > > At any later point in time the signature key may > be compromised, or the algorithms involved may > have become to weak. (In which case the time of > revocation in the OCSP response is worth nothing > to you). The risk increases as time passes. And of > course, the revocation information may not be kept > around after the expiry of the certificate. > > That's why you should validate signatures as soon > as possible. > > For these archival purposes wouldn't it be better to > have the final revocation list before removed due to > expiry? In any case, you'd need verification > information collected after some grace period > following moment of production. > > [PR] Grace period is not a fixed value of the time > interval. > > Grace period is changeable because the first OCSP > response with thisUpdate time value > than time of > signature time-stamp contains correct status. > > If you need to ascertain that a signature was > valid at a later time, you have to trust your > system that it performed the validation at the > time it first received the signature. That trust > must be established through some kind of mix of > policies and technical measures (such as > timestamping). > > In the dark corner just beyond the dark corner that is > SCVP, there's a spec (RFC 5276) that defines a binding > of evidence records to artifacts that can be returned > viaSCVP. This provides for timestamping. > > [PR] The validation is simplified when OCSP response > with positive statement as a hash value of requested > certificate is used. > > Positive statement is evidence that OCSP know the > status of certificate and also protect the integrity > of certificate with a new more secure hash algorithm. > > Peter Rybar > > > > Simon Tardell, > > Technology Nexus. > > On Fri, Oct 19, 2012 at 1:07 PM, Peter Rybar > > wrote: > > Stefan, > > I have a question about the present OCSP RFC and > at the end of the mail about the new situation > which will happen according to your new proposal. > > The presence of the positive statement in OCSP > response is important for electronic signature > validations, especially for an expired > certificate. Positive statement is the hash value > of a certificate whose status is provided in OCSP > response. > > Electronic signature validation is usually about > the signatures created in the past and validated > now, when the certificate is expired. > > When the certificate expires then revocation is > usually removed from CRL and the revoked > certificate can be provided as "good" in OCSP > response. > Is it acceptable? I think not. > > According to your new draft there is not defined a > value of revocationTime. > RFC must also define the value of revocationTime > when the certificate which was never issued is as > "revoked". > http://www.ietf.org/rfcdiff?url2=draft-ietf-pkix-rfc2560bis-06 > > Have you also covered the situation when the > certificate is expired, REMOVED FROM CRL and will > be provided as revoked with incorrect > revocationTime e.g.with the value before or after > the revocationTime which was present in the > removed record from CRL? > Because according to sentence in your draft > ""revoked" - This state SHOULD also be returned if > the responder knows that the requested certificate > has never been issued." the following situation > can happen: when certificate is removed from CRL > after expiration and CA/OCSP responder is > responsible for this certificate but have not > record about expired certificate and for that > reason it is identified as "never been issued". > > ... > revoked [1] IMPLICIT RevokedInfo, > ... > > RevokedInfo ::= SEQUENCE { > revocationTime GeneralizedTime, > revocationReason [0] EXPLICIT CRLReason > OPTIONAL } > > As you have mentioned in the mail: > > "On the "revoked" state, the old spec did not even > consider the case of a certificate being requested > where the OCSP responder knows that the > certificate was never issued." > > "It simply recommend a known to be bad certificate > to result > in "revoked" in order to prevent damage as far as > possible. It also opens > for definition of new extensions through which > such knowledge could be > obtained." > > Peter Rybar > National Security Authority > Information Security and Electronic Signature > Department > Budatinska 30, 850 07 Bratislava 57, Slovak Republic > e-mail: peter.rybar@nbusr.sk > > e-mail: peterryb@gmail.com > > > -----Original Message----- > From: pkix-bounces@ietf.org > > [mailto:pkix-bounces@ietf.org > ] On Behalf Of > Stefan Santesson > Sent: Monday, October 15, 2012 1:49 AM > To: pkix@ietf.org > Subject: [pkix] New draft-ietf-pkix-rfc2560bis-06 > > All, > > I have just posted an update of rfc2560bis (OCSP > update) after carefully > reviewing all comments on the list. > > Some notes about the update: > > - Added the previous OCSP editors with updated > affiliations. > - Added some calcifications on ResponderID as > suggested by Simon Josefsson. > - Updated the clarifications on Authorized > responders. The requirements > have not changed. I just tried to improve the text. > - Updated a clarification on the "revoked" state > to be the preferred > response if a certificate is known by the > responder to never have been > issued. > - Some minor editorial nits. > > > Regarding backwards compatibility I mean that none > of the clarifications > changes RFC 2560. > > On Authorized responders it has always been the > case that a responder > certificate issued with the same key as was used > to issue the certificate > being checked for revocation, represents a valid > Authorized responder. > There has never been an explicit requirement to > support key rollover and > key rollover support has never been in the > "spirit" of the original > standard as it clearly attempted to provide direct > cryptographic binding > between the responder and the CA. > > On the "revoked" state, the old spec did not even > consider the case of a > certificate being requested where the OCSP > responder knows that the > certificate was never issued. It is clearly > counterproductive to respond > good when a certificate is known to be bad. A > responder must pick one > response and picking "revoked" breaks nothing, but > has the desired effect, > that is, to prevent the certificate from being > accepted. The current text > makes clear that there is no mechanism in the > current standard by which a > client can know how a responder will respond to a > request for a not issued > certificate. It simply recommend a known to be bad > certificate to result > in "revoked" in order to prevent damage as far as > possible. It also opens > for definition of new extensions through which > such knowledge could be > obtained. > > The current updates also clearly opens a path for > the CAB forum efforts to > define a suitable solution for server certificates. > > I have not, even thug suggested, added any > requirements on what clients > should do with the checked cert as a result of a > particular response. I > don't believe such requirements are suitable as it > is policy and not > protocol. We have no right to demand that all > systems MUST reject any > certificate for any reason as they may have a > local policy that overrules > the OCSP response. This protocol only provides > information about the cert > status, it does not mandate validation policy. > > I have not included any of the substantial changes > i the Pinkas draft. I > want to wait for a list of motivation for each > change before including any > of them. So there changed may be up for debate > before this draft is ready > for WGLC. > > /Stefan > > > > _______________________________________________ > 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 > > _______________________________________________ > 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 --------------090704070802010403070702 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=ISO-8859-1
To the PKIX list:

   Without changing the meaning of "good" and of either "revoked" or
   "unknown", it is not possible to address the case of what is
    presently called "non-issued certificates".

The current text from RFC 2560 is:

   "The "good" state indicates a positive response to the state inquiry.
   At a minimum, this positive response indicates that the certificate
   is not revoked, but does not necessarily mean that the certificate
   was ever issued or that the time at which the response was produced
   is within the certificate's validity interval. Response extensions
   may be used to convey additional information on assertions made by
   the responder regarding the state of the certificate such as
   positive statement about issuance, validity, etc.

   The "revoked" state indicates that the certificate has been revoked
   (either permanantly or temporarily (on hold)).

   The "unknown" state indicates that the responder doesn't know about
   the certificate being requested".


   A minor change should be done to advertise that "good" may be
   returned when the certificate was never issued and CRLs are being
   used.


Replacement text for the definition of the "good" state:

   "The "good" state indicates a positive response to the state inquiry.
   At a minimum, this positive response indicates that the certificate
   is not revoked, but does not necessarily mean that the certificate
   was ever issued (e.g. when CRLs are used by the OCSP responders)
  or  that the time at which the response was produced is within the
   certificate's validity interval.  Response extensions may be used
   to convey additional information on assertions made by the OCSP
   responder regarding the state of the certificate such as an
   indication that the OCSP responder has a direct access to the
   database of issued certificates, validity, etc ... "

   Then either the meaning of "rekoved" or of "unknown" needs to be
   changed.

   draft-ietf-pkix-rfc2560bis-06 attempts to address the issue and
   proposes to keep the meaning of "unknown" unchanged and to change
   the meaning of "revoked" in the following way:

   "The "revoked" state indicates that the certificate has been revoked
   (either permanently or temporarily (on hold)). This state SHOULD also
   be returned if the responder knows that the requested certificate has
   never been issued. Note that the receiver of a response may have to
   consult out-of-band knowledge, or information in an extension defined
   outside of this standard, to know whether a particular responder has
   knowledge about whether a requested certificate has been issued or
   not and whether it responds "good" or "revoked" to a state request
   for a non-issued certificate".

   There is a door opened for a future extension "to know whether a
   particular responder has knowledge about whether a requested
   certificate has been issued or not".

   However, the extension proposed in draft-pinkas-2560bis-certinfo-00.txt,
   carries a slightly different meaning:

      - an indication that the serial number of the target
        certificate is not present in the database,

Saying that the certificate has not been issued is not fully appropriate.

The text should be modified in the following way:

   "The "revoked" state indicates that the certificate has been revoked
   (either permanently or temporarily (on hold)).  This state SHOULD
   also be returned if the responder has an access to the database
   of  issued certificates and if the serial number of the target
   certificate is not present in that database.

   In this case, the "revoked" state indicates either that the
   certificate has never been issued or that it has been issued but
   subsequently removed (by an attack or by accident) from the
   database of issued certificates.

   Response extensions may be used  to convey additional information
   on assertions made by the OCSP  responder regarding the state of the
   certificate such as an indication that the OCSP responder has
   a direct access to the database of issued certificates, validity, etc ... "

An alternative is to keep the meaning of "revoked" and to change
the meaning of "unknown" in the following way:

   "The "unknown" status indicates either that the server doesn't know
   about the certificate being requested or the revocation status
   of the certificate being requested

   Response extensions may be used  to convey additional information
   on assertions made by the OCSP  responder regarding the state of the
   certificate such as an indication that the OCSP responder has
   a direct access to the database of issued certificates, validity, etc ..."

There are pros and cons for each alternative. If the meaning of "revoked"
is changed it is also necessary to say what should be the values of both
revocationTime and revocationReason:

   CertStatus ::= CHOICE {
       good        [0]     IMPLICIT NULL,
       revoked     [1]     IMPLICIT RevokedInfo,
       unknown     [2]     IMPLICIT UnknownInfo }

   RevokedInfo ::= SEQUENCE {
       revocationTime              GeneralizedTime,
       revocationReason    [0]     EXPLICIT CRLReason
                                   OPTIONAL }

   UnknownInfo ::= NULL

CRLReason is imported from PKIX1Implicit88 { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-implicit(19) }

CRLReason is defined in RFC 5280 as:

   CRLReason ::= ENUMERATED {
        unspecified             (0),
        keyCompromise           (1),
        cACompromise            (2),
        affiliationChanged      (3),
        superseded              (4),
        cessationOfOperation    (5),
        certificateHold         (6),
             -- value 7 is not used
        removeFromCRL           (8),
        privilegeWithdrawn      (9),
        aACompromise           (10) }


For the revocationTime should we use the content of notBefore field from the certificate ?

For the revocationReason should we use unspecified or keyCompromise ?

In any case, guidance should be given.

Although I understand that changing the meaning of "revoked" may be seen as "safer"
for old implemenations, changing the meaning of "unknown" also seems to be a reasonable alternative.

In this case, it might be useful (and sufficient) to say that if an OCSP responder is authoritative
for the target certificate, then the OCSP client SHOULD NOT use an alternative source
of revocation information like CRLs.

Denis


In line;

From: Piyush Jain <piyush@ditenity.com>
Date: Sunday, October 21, 2012 7:42 PM
To: Stefan Santesson <stefan@aaa-sec.com>, 'Peter Rybar' <rybar@nbusr.sk>, 'Carl Wallace' <carl@redhoundsoftware.com>, 'Simon Tardell' <simon@tardell.se>
Cc: 'Peter Rybar' <peterryb@gmail.com>, <pkix@ietf.org>
Subject: RE: [pkix] New draft-ietf-pkix-rfc2560bis-06

So what is “not-issued” - not signed by the CA or not present in CA database?

Not issued means it has never been issued. What's unclear about that?

Of course it is not present in the database if it is not issued.
If you delete things from your database and don't know if this one has been deleted, then you don't know that it has never been issued and can't reply revoked.


It is unclear to folks who have been using signature verification as a way to check issuance. Isn’t it a fair conclusion that I do not need to perform signature checks if the responder can check issuance for me?

No that is not a fair conclusion. These are entirely different things.

 

You said that the possibility to send revoked reply only applies when the responder ’knows’ that requested certificate has never been issued.

Please note that the responder will encounter this kind of request only in two situations. First in which the RP sends a request for a certificate without checking the signature and second in which the responder itself is compromised by virtue of its issuing authority being compromised. In either case what the responder responds with does not matter.

 

Some people are pretty convinced it does (from CAB forum), they are so convinced that they are prepared to break compatibility with OCSP. By this little extension that hurst no-one, they don't have to.

I’ve no problem with your proposal to respond with ‘revoked’ in this situation.

Good.

I’ve fundamental problem with the introduction of ‘non-issued’ concept in OCSP, which seems to provide additional security in this exceptional scenario without actually providing any.

It provides some, but not much. People keep coming back to that fact that if this had been the practice of Diginotar, the security breach would have been discovered a lot earlier. So there might be some gain with no pain.

However, in combination with an extension that adds information, this might actually be increasingly valuable.
If an OCSP responder starts receiving status requests for certs it knows it has not issued, it can actually give explicit information about this using an extension and it can take adequate measures.
But in order to respond to the user, it need to pick one of the responses. Either good + extension or revoked+extension.

This proposal is not meant to require any OCSP responder to deal with the concept of "non-issued" certs. It merely allows an OCSP responder to respond to such request.

 

It’ll be very helpful if I can see at least one practical scenario where this additional text would add value.

Stated in my previous comments.

/Stefan

 

-Piyush

From: Stefan Santesson [mailto:stefan@aaa-sec.com]
Sent: Sunday, October 21, 2012 8:52 AM
To: Piyush Jain; 'Peter Rybar'; 'Carl Wallace'; 'Simon Tardell'
Cc: 'Peter Rybar'; pkix@ietf.org
Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06

 

I don't think the "not issued" is unclear.

 

The possibility to send a revoked reply only applies then the responder "knows" that the requested certificate has never been issued.

How the responder knows this is totally irrelevant, but unless the responder knows this, it can't choose this option and has to reply "good".

 

It does not make revocation checking non-deterministric. 

"good" still means what is declared in the standard (The cert is not known to be revoked, but it may never have been issued).

"revoked" still have a deterministic meaning, that is, don't trust this cert. The old exact semantics was "the cert IS revoked". The new semantic is "the cert is revoked or possibly might never been issued"

 

The new response semantic of revoked is backwards compatible and not less deterministic than the good, response.

 

So, I still don't see any practical problems here.

 

/Stefan

 

 

From: Piyush Jain <piyush@ditenity.com>
Date: Saturday, October 20, 2012 5:48 PM
To: Stefan Santesson <stefan@aaa-sec.com>, 'Peter Rybar' <rybar@nbusr.sk>, 'Carl Wallace' <carl@redhoundsoftware.com>, 'Simon Tardell' <simon@tardell.se>
Cc: 'Peter Rybar' <peterryb@gmail.com>, <pkix@ietf.org>
Subject: RE: [pkix] New draft-ietf-pkix-rfc2560bis-06

 

Please see inline

 

From: Stefan Santesson [mailto:stefan@aaa-sec.com]
Sent: Friday, October 19, 2012 7:23 PM
To: Piyush Jain; 'Peter Rybar'; 'Carl Wallace'; 'Simon Tardell'
Cc: 'Peter Rybar'; pkix@ietf.org
Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06

 

I'm sorry. I fail to the any of the problems you raise.

 

If you receive a request for a certificate that you know has never been issued, and you choose to reply revoked, what problems can you cause?

[Piyush] It depends on how you define “never been issued”, which btw becomes unclear after introduction of the new text. There are two interpretations

1)      Certificate is not signed by the CA or

2)      Certificate is not present in the database of issued certificates that CA maintains.

One unintended consequence of first interpretation will be that RPs would stop performing signature checks if their responder/CA publicizes that it returns revoked for “non-issued” certificates.

If the interpretation is 2, then this scenario is not possible unless the CA is compromised.

 

What in your mind is a more appropriate response?

[Piyush] I would say the appropriate response is good (if the certificate is not marked as revoked), because that is what the RP will see if it consults a CRL or a responder detached from the CA.

Revoked for “not issued” adds no value because the only case in which an RP would send a query for a “non-issued” certificate is when the CA is compromised.

 

It does not make OCSP more non-deterministic. If you ask status for an issued cert from a non-broken CA, nothing is non-deterministic.

[Piyush] It does not make OCSP non-deterministic but it makes revocation checking non-deterministic. The goal of OCSP is to address operational limitations of CRLs, not functional limitations.  The fact that you’ll get different answers from two sources, both of which are authorized by the same CA makes revocation checking non deterministic.

 

If you ask for status for a non-issued certificate, or a bad certificate from a broken CA, then the result is by default non-deteministic and has always been. However, choosing a revoked response may save the relying party, at best, but can hurt no-one

[Piyush] I agree that a revoke response does not hurt anyone. But the point is that it provides a false sense of additional security to the RP without providing any. As an RP, I won’t trust what my responder says if the authority that certified it is compromised.

 

What is your problem on the practical ground.

[Piyush]  Let’s say that we still need to address this scenario and revoked is the appropriate response. In that case

-          The text needs to be explicit about the revocation time in this situation. Revoked implies good until a certain date and this distinction is important for long term archiving applications. For unissued certificate the revocation time should probably be set to –infinity.

-          It needs to call out that in this particular scenario it is addressing a functional limitation of CRLs (ability to detect CA compromise) not an operational limitation.

-          I think we need additional text in security considerations to indicate that RP is communicating with a responder certified by a compromised CA in this scenario.

 

 

/Stefan

 

From: Piyush Jain <piyush@ditenity.com>
Date: Friday, October 19, 2012 7:34 PM
To: Stefan Santesson <stefan@aaa-sec.com>, 'Peter Rybar' <rybar@nbusr.sk>, 'Carl Wallace' <carl@redhoundsoftware.com>, 'Simon Tardell' <simon@tardell.se>
Cc: 'Peter Rybar' <peterryb@gmail.com>, <pkix@ietf.org>
Subject: RE: [pkix] New draft-ietf-pkix-rfc2560bis-06

 

Stefan,

 

I think some of you interpretations below are twisted to accommodate the new provisions for providing revoked responses for unissued certificates.

Providing responses for expired certificates is within the scope of 2560 using archive cutoff extension.

 

The original authors of 2560 can correct me if I’m wrong, but it is my understanding that a response from OCSP responder is not supposed to indicate if a certificate is good or bad but to indicate if a certificate is revoked or unrevoked by the issuing authority. The fact that certificate is issued by the CA is checked by the RP by verifying the signature on the certificate.

 

This draft introduces the concept of returning revoked responses for unissued certificates. There are many unintended consequences of this approach

-          Revocation statuses become non-deterministic based on who you are asking (A responder with access to CA database vs. one without vs. checking status off a CRL). If I’m archiving a signed document with the relevant artifacts to determine the validity status of the document, this becomes a huge problem. Note that a revoked status implies that certificate was good between the time of its issuance and that of its revocation. Any document that is signed within that period should still be considered valid.

-          It would confuse an implementer about what “non-issued” means. The fact that the CA signed the certificate implies it was issued. If a certificate is issued fraudulently, based on its security practices, it is up to the CA to either revoke the issued certificate, or ask its issuing authority to revoke its own certificate.

 

-Piyush

 

 

 

 

From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Stefan Santesson
Sent: Friday, October 19, 2012 7:25 AM
To: Peter Rybar; 'Carl Wallace'; 'Simon Tardell'
Cc: 'Peter Rybar'; pkix@ietf.org
Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06

 

Peter,

 

An OCSP responder is by default a service providing information about current certificates.

The default response you get from an OCSP responder is "good" unless the cert is known to be bad or not a cert the responder can provide status for.

 

If you need it to respond about old certificates, and as a client know that the responder does this in a way that suits your needs, you will need to add an extension.

Such extension will not be part of the rfc256bis effort.

 

Is there any text in the current draft that you think is unclear on this?

 

/Stefan

 

 

From: Peter Rybar <rybar@nbusr.sk>
Date: Friday, October 19, 2012 3:12 PM
To: 'Carl Wallace' <carl@redhoundsoftware.com>, 'Simon Tardell' <simon@tardell.se>
Cc: 'Peter Rybar' <peterryb@gmail.com>, Stefan Santesson <stefan@aaa-sec.com>, <pkix@ietf.org>
Subject: RE: [pkix] New draft-ietf-pkix-rfc2560bis-06

 

Well, yes, sort of. You can only be sure to validate a signature at the moment of production.

 

What if the signature key was compromised at the moment of production but is not yet on a revocation list?

[PR] According to clause 2.4  -  thisUpdate: The time at which the status being indicated is known to be correct

It means when signature time-stamp time is X then any OCSP responses with thisUpdate time X+y are sufficient to validate because the status is correct.

Y is in the interval <0, producedAt - X>

 

At any later point in time the signature key may be compromised, or the algorithms involved may have become to weak. (In which case the time of revocation in the OCSP response is worth nothing to you). The risk increases as time passes. And of course, the revocation information may not be kept around after the expiry of the certificate. 

 

That's why you should validate signatures as soon as possible. 

 

For these archival purposes wouldn't it be better to have the final revocation list before removed due to expiry?  In any case, you'd need verification information collected after some grace period following moment of production.

[PR] Grace period is not a fixed value of the time interval.

Grace period is changeable because the first OCSP response with thisUpdate time value > than time of signature time-stamp contains correct status.

 

 

If you need to ascertain that a signature was valid at a later time, you have to trust your system that it performed the validation at the time it first received the signature. That trust must be established through some kind of mix of policies and technical measures (such as timestamping).

 

In the dark corner just beyond the dark corner that is SCVP, there's a spec (RFC 5276) that defines a binding of evidence records to artifacts that can be returned viaSCVP.  This provides for timestamping.  

[PR] The validation is simplified when OCSP response with positive statement as a hash value of requested certificate is used.

Positive statement is evidence that OCSP know the status of certificate and also protect the integrity of certificate with a new more secure hash algorithm.

 

Peter Rybar

 



Simon Tardell, 

Technology Nexus.

On Fri, Oct 19, 2012 at 1:07 PM, Peter Rybar <rybar@nbusr.sk> wrote:

Stefan,

I have a question about the present OCSP RFC and at the end of the mail about the new situation which will happen according to your new proposal.

The presence of the positive statement in OCSP response is important for electronic signature validations, especially for an expired certificate. Positive statement is the hash value of a certificate whose status is provided in OCSP response.

Electronic signature validation is usually about the signatures created in the past and validated now, when the certificate is expired.

When the certificate expires then revocation is usually removed from CRL and the revoked certificate can be provided as "good" in OCSP response.
Is it acceptable? I think not.

According to your new draft there is not defined a value of revocationTime.
RFC must also define the value of revocationTime when the certificate which was never issued is as "revoked".
http://www.ietf.org/rfcdiff?url2=draft-ietf-pkix-rfc2560bis-06

Have you also covered the situation when the certificate is expired, REMOVED FROM CRL and will be provided as revoked with incorrect revocationTime e.g.with the value before or after the revocationTime which was present in the removed record from CRL?
Because according to sentence in your draft ""revoked" - This state SHOULD also be returned if the responder knows that the requested certificate has never been issued." the following situation can happen: when certificate is removed from CRL after expiration and CA/OCSP responder is responsible for this certificate but have not record about expired certificate and for that reason it is identified as "never been issued".

...
revoked     [1]     IMPLICIT RevokedInfo,
...

   RevokedInfo ::= SEQUENCE {
       revocationTime              GeneralizedTime,
       revocationReason    [0]     EXPLICIT CRLReason OPTIONAL }

As you have mentioned in the mail:

"On the "revoked" state, the old spec did not even consider the case of a certificate being requested where the OCSP responder knows that the certificate was never issued."

"It simply recommend a known to be bad certificate to result
in "revoked" in order to prevent damage as far as possible. It also opens
for definition of new extensions through which such knowledge could be
obtained."

Peter Rybar
National Security Authority
Information Security and Electronic Signature Department
Budatinska 30, 850 07 Bratislava 57, Slovak Republic
e-mail: peter.rybar@nbusr.sk
e-mail: peterryb@gmail.com


-----Original Message-----
From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Stefan Santesson
Sent: Monday, October 15, 2012 1:49 AM
To: pkix@ietf.org
Subject: [pkix] New draft-ietf-pkix-rfc2560bis-06

All,

I have just posted an update of rfc2560bis (OCSP update) after carefully
reviewing all comments on the list.

Some notes about the update:

- Added the previous OCSP editors with updated affiliations.
- Added some calcifications on ResponderID as suggested by Simon Josefsson.
- Updated the clarifications on Authorized responders. The requirements
have not changed. I just tried to improve the text.
- Updated a clarification on the "revoked" state to be the preferred
response if a certificate is known by the responder to never have been
issued.
- Some minor editorial nits.


Regarding backwards compatibility I mean that none of the clarifications
changes RFC 2560.

On Authorized responders it has always been the case that a responder
certificate issued with the same key as was used to issue the certificate
being checked for revocation, represents a valid Authorized responder.
There has never been an explicit requirement to support key rollover and
key rollover support has never been in the "spirit" of the original
standard as it clearly attempted to provide direct cryptographic binding
between the responder and the CA.

On the "revoked" state, the old spec did not even consider the case of a
certificate being requested where the OCSP responder knows that the
certificate was never issued. It is clearly counterproductive to respond
good when a certificate is known to be bad. A responder must pick one
response and picking "revoked" breaks nothing, but has the desired effect,
that is, to prevent the certificate from being accepted. The current text
makes clear that there is no mechanism in the current standard by which a
client can know how a responder will respond to a request for a not issued
certificate. It simply recommend a known to be bad certificate to result
in "revoked" in order to prevent damage as far as possible. It also opens
for definition of new extensions through which such knowledge could be
obtained.

The current updates also clearly opens a path for the CAB forum efforts to
define a suitable solution for server certificates.

I have not, even thug suggested, added any requirements on what clients
should do with the checked cert as a result of a particular response. I
don't believe such requirements are suitable as it is policy and not
protocol. We have no right to demand that all systems MUST reject any
certificate for any reason as they may have a local policy that overrules
the OCSP response. This protocol only provides information about the cert
status, it does not mandate validation policy.

I have not included any of the substantial changes i the Pinkas draft. I
want to wait for a list of motivation for each change before including any
of them. So there changed may be up for debate before this draft is ready
for WGLC.

/Stefan



_______________________________________________
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

 

_______________________________________________ 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

--------------090704070802010403070702-- From simon@tardell.se Mon Oct 22 07:35:23 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37F0A21F8BA5 for ; Mon, 22 Oct 2012 07:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oI0opUWHHIFH for ; Mon, 22 Oct 2012 07:35:22 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id E767021F8B6C for ; Mon, 22 Oct 2012 07:35:21 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id j40so1287550qab.10 for ; Mon, 22 Oct 2012 07:35:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=QBhm9I71wcknnVsd8eHmxf6l6Pq/GyGPs4On89lvpj4=; b=KUV7J527CXA3kk/q4DpjjQLgTTaSjHP+5WAMnvdvoOzZ6oWdJp9w3r8D6my5XPBQxn 1+7Hii06HCIoNc/MTX1Bpg4fnpLPHXjte2LEzwXwp1lknZFkMSDQ+qA+XGHgWPkcEEpM 70ygB3XaHMFokBNUHWjQvXIeUa1t+i9EHArnoKAlTmgeD2uDg3/NQ0g6W3CgiLstFaz9 aH+BQA967zPRr3kreJwWax4a9GwOXsyy0wv4/aIbIyEzQWgEEHA0sCLRWIA3VfqPbDUP 27B7UCSQi+6Eru6KvQ+sZNTRZ+XJE4eS6XlXgqoApZLWuBKIv13lUd5XtU2wyGA3X23B VaOA== MIME-Version: 1.0 Received: by 10.49.127.115 with SMTP id nf19mr5014122qeb.36.1350916521191; Mon, 22 Oct 2012 07:35:21 -0700 (PDT) Received: by 10.49.94.116 with HTTP; Mon, 22 Oct 2012 07:35:21 -0700 (PDT) In-Reply-To: <50855225.1030202@bull.net> References: <50855225.1030202@bull.net> Date: Mon, 22 Oct 2012 16:35:21 +0200 Message-ID: From: Simon Tardell To: Denis Pinkas Content-Type: multipart/alternative; boundary=047d7b5d58d25deaae04cca6c3ee X-Gm-Message-State: ALoCoQnVGPG5FoUGL3lgm+sbPac/iAGJzq/7yx3UD75+I8kL6iRGeDCCRpAuX1UGREHBh+IHNhv8 Cc: pkix@ietf.org Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 14:35:23 -0000 --047d7b5d58d25deaae04cca6c3ee Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable > If the meaning of "revoked" > is changed it is also necessary to say what should be the values of both > revocationTime and revocationReason: > [=85] > CRLReason is defined in RFC 5280 as: > > CRLReason ::=3D ENUMERATED { > unspecified (0), > keyCompromise (1), > cACompromise (2), > affiliationChanged (3), > superseded (4), > cessationOfOperation (5), > certificateHold (6), > -- value 7 is not used > removeFromCRL (8), > privilegeWithdrawn (9), > aACompromise (10) } > > For the revocationTime should we use the content of notBefore field from th= e > certificate ? > The certificate that was not issued could have any time. It is also not seen by the responder. The reasonable revocationTime would be "the beginning of time". Any time which is before any reasonable issuance time of any certificate in the PKI would do. The issuance time of the issuing CA would do, or for that matter the battle of Hastings. > For the revocationReason should we use unspecified or keyCompromise ? > revocationReason must be certificateHold, since, in principle, the certificate may be issued at a later point in time. If a key was compromised, it would be the CA key, not the key that the certificate. > > In any case, guidance should be given. > > Although I understand that changing the meaning of "revoked" may be seen > as "safer" > for old implemenations, changing the meaning of "unknown" also seems to b= e > a reasonable alternative. > > In this case, it might be useful (and sufficient) to say that if an OCSP > responder is authoritative > for the target certificate, then the OCSP client SHOULD NOT use an > alternative source > of revocation information like CRLs. > Which would be putting requirements on the behavior of already existing OCSP clients out there that we know are not true and are out of the control of most people setting up PKIs. Simon Tardell, Technology Nexus. --047d7b5d58d25deaae04cca6c3ee Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
=A0If the meaning of "revoked"
is changed it is also necessary to say what should be the values of both
revocationTime and revocationReason:
[=85]
=A0
CRLReason is defined in RFC 5280 as:

=A0=A0 CRLReason ::=3D ENUMERATED {
=A0=A0=A0=A0=A0=A0=A0 unspecified=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 (0),
=A0=A0=A0=A0=A0=A0=A0 keyCompromise=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (= 1),
=A0=A0=A0=A0=A0=A0=A0 cACompromise=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= (2),
=A0=A0=A0=A0=A0=A0=A0 affiliationChanged=A0=A0=A0=A0=A0 (3),
=A0=A0=A0=A0=A0=A0=A0 superseded=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 (4),
=A0=A0=A0=A0=A0=A0=A0 cessationOfOperation=A0=A0=A0 (5),
=A0=A0=A0=A0=A0=A0=A0 certificateHold=A0=A0=A0=A0=A0=A0=A0=A0 (6),<= br> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- value 7 is not used
=A0=A0=A0=A0=A0=A0=A0 removeFromCRL=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (= 8),
=A0=A0=A0=A0=A0=A0=A0 privilegeWithdrawn=A0=A0=A0=A0=A0 (9),
=A0=A0=A0=A0=A0=A0=A0 aACompromise=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (1= 0) }


F= or the revocationTime should we use the content of notBefore field from the certificate ?

The certificate that was not i= ssued could have any time. It is also not seen by the responder. The reason= able revocationTime would be "the beginning of time". Any time wh= ich is before any reasonable issuance time of any certificate in the PKI wo= uld do. The issuance time of the issuing CA would do, or for that matter th= e battle of Hastings.
=A0
For the revocationReason should we use uns= pecified or keyCompromise ?
revocationReason must be certificateHold, since, in principle,= the certificate may be issued at a later point in time. If a key was compr= omised, it would be the CA key, not the key that the certificate.=A0
=A0
In any case, guidance should be given.

Although I understand that changing the meaning of "revoked"= ; may be seen as "safer"
for old implemenations, changing the meaning of "unknown" a= lso seems to be a reasonable alternative.

In this case, it might be useful (and sufficient) to say that if an OCSP responder is authoritative
for the target certificate, then the OCSP client SHOULD NOT use an alternative source
of revocation information like CRLs.

Which would be putting requirements on the behavior of alre= ady existing OCSP clients out there that we know are not true and are out o= f the control of most people setting up PKIs.

Simon Tardell,
Technology Nexus.
<= br> --047d7b5d58d25deaae04cca6c3ee-- From denis.pinkas@bull.net Mon Oct 22 07:53:05 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B576C21F8B80 for ; Mon, 22 Oct 2012 07:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.967 X-Spam-Level: X-Spam-Status: No, score=-4.967 tagged_above=-999 required=5 tests=[AWL=1.281, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsepSbG6BYMn for ; Mon, 22 Oct 2012 07:53:04 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id D59EB21F8BB7 for ; Mon, 22 Oct 2012 07:53:01 -0700 (PDT) Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id 831C41C37A; Mon, 22 Oct 2012 16:52:57 +0200 (CEST) Received: from [127.0.0.1] ([129.184.39.15]) by MSGC-007.bull.fr (Lotus Domino Release 8.5.3FP1) with ESMTP id 2012102216525665-1594 ; Mon, 22 Oct 2012 16:52:56 +0200 Message-ID: <50855DC5.6010609@bull.net> Date: Mon, 22 Oct 2012 16:52:53 +0200 From: Denis Pinkas User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Simon Tardell References: <50855225.1030202@bull.net> In-Reply-To: X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 22/10/2012 16:52:56, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 22/10/2012 16:52:57, Serialize complete at 22/10/2012 16:52:57 X-TNEFEvaluated: 1 Content-Type: multipart/alternative; boundary="------------060306030306040807030403" Cc: pkix@ietf.org Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 14:53:06 -0000 This is a multi-part message in MIME format. --------------060306030306040807030403 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Simon, You said: "revocationReason must be certificateHold, since, in principle, the=20 certificate may be issued at a later point in time". I don't believe this is appropriate. If you have certificateHold then=20 the OCSP client may make other calls later on to check if the suspension state has finished or not. The less controversial revocationReason is "unspecified".Let us go for=20 "unspecified". Denis > > If the meaning of "revoked" > is changed it is also necessary to say what should be the values > of both > revocationTime and revocationReason: > > [=85] > > CRLReason is defined in RFC 5280 as: > > CRLReason ::=3D ENUMERATED { > unspecified (0), > keyCompromise (1), > cACompromise (2), > affiliationChanged (3), > superseded (4), > cessationOfOperation (5), > certificateHold (6), > -- value 7 is not used > removeFromCRL (8), > privilegeWithdrawn (9), > aACompromise (10) } > > > For the revocationTime should we use the content of notBefore > field from the certificate ? > > > The certificate that was not issued could have any time. It is also=20 > not seen by the responder. The reasonable revocationTime would be "the=20 > beginning of time". Any time which is before any reasonable issuance=20 > time of any certificate in the PKI would do. The issuance time of the=20 > issuing CA would do, or for that matter the battle of Hastings. > > For the revocationReason should we use unspecified or keyCompromise= ? > > > revocationReason must be certificateHold, since, in principle, the=20 > certificate may be issued at a later point in time. If a key was=20 > compromised, it would be the CA key, not the key that the certificate. > > In any case, guidance should be given. > > Although I understand that changing the meaning of "revoked" may > be seen as "safer" > for old implemenations, changing the meaning of "unknown" also > seems to be a reasonable alternative. > > In this case, it might be useful (and sufficient) to say that if > an OCSP responder is authoritative > for the target certificate, then the OCSP client SHOULD NOT use an > alternative source > of revocation information like CRLs. > > > Which would be putting requirements on the behavior of already=20 > existing OCSP clients out there that we know are not true and are out=20 > of the control of most people setting up PKIs. > > Simon Tardell, > Technology Nexus. > --------------060306030306040807030403 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Simon,

You said:

"revocationReason must be certificateHold, since, in principle, the certificate may be issued at a later point in time".

I don't believe this is appropriate. If you have certificateHold then the OCSP client may make other calls later on
to check if the suspension state has finished or not.

The less controversial revocationReason is "unspecified". Let us go for "unspecified".

Denis


=A0If the meaning of "revoked"
is changed it is also necessary to say what should be the values of both
revocationTime and revocationReason:
[=85]
=A0
CRLReason is defined in RFC 5280 as:

=A0=A0 CRLReason ::=3D ENUMERATE= D {
=A0=A0=A0=A0=A0=A0=A0 unspecified=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 (0),
=A0=A0=A0=A0=A0=A0=A0 keyCompromise=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 (1),
=A0=A0=A0=A0=A0=A0=A0 cACompromise=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 (2),
=A0=A0=A0=A0=A0=A0=A0 affiliationChanged=A0=A0=A0=A0=A0 (= 3),
=A0=A0=A0=A0=A0=A0=A0 superseded=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 (4),
=A0=A0=A0=A0=A0=A0=A0 cessationOfOperation=A0=A0=A0 (5),<= br> =A0=A0=A0=A0=A0=A0=A0 certificateHold=A0=A0=A0=A0=A0=A0=A0= =A0 (6),
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- value 7 is not us= ed
=A0=A0=A0=A0=A0=A0=A0 removeFromCRL=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 (8),
=A0=A0=A0=A0=A0=A0=A0 privilegeWithdrawn=A0=A0=A0=A0=A0 (= 9),
=A0=A0=A0=A0=A0=A0=A0 aACompromise=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 (10) }


For the revocationTime should we us= e the content of notBefore field from the certificate ?

The certificate that was not issued could have any time. It is also not seen by the responder. The reasonable revocationTime would be "the beginning of time". Any time which is before any reasonable issuance time of any certificate in the PKI would do. The issuance time of the issuing CA would do, or for that matter the battle of Hastings.
=A0
For the revocationReason should we use unspecified or keyCompromise = ?

revocationReason must be certificateHold, since, in principle, the certificate may be issued at a later point in time. If a key was compromised, it would be the CA key, not the key that the certificate.=A0
=A0
In any case, guidance should be given.

Although I understand that changing the meaning of "revoked" may be seen as "safer"
for old implemenations, changing the meaning of "unknown" also seems to be a reasonable alternative.

In this case, it might be useful (and sufficient) to say that if an OCSP responder is authoritative
for the target certificate, then the OCSP client SHOULD NOT use an alternative source
of revocation information like CRLs.

Which would be putting requirements on the behavior of already existing OCSP clients out there that we know are not true and are out of the control of most people setting up PKIs.

Simon Tardell,
Technology Nexus.


--------------060306030306040807030403-- From denis.pinkas@bull.net Mon Oct 22 07:53:52 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D6421F8BDB for ; Mon, 22 Oct 2012 07:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.556 X-Spam-Level: X-Spam-Status: No, score=-4.556 tagged_above=-999 required=5 tests=[AWL=0.808, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ouwZj0CG7EfN for ; Mon, 22 Oct 2012 07:53:50 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 3577F21F8BD2 for ; Mon, 22 Oct 2012 07:53:50 -0700 (PDT) Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id 97ACE1C37A; Mon, 22 Oct 2012 16:53:49 +0200 (CEST) Received: from [127.0.0.1] ([129.184.39.15]) by MSGC-007.bull.fr (Lotus Domino Release 8.5.3FP1) with ESMTP id 2012102216534812-1596 ; Mon, 22 Oct 2012 16:53:48 +0200 Message-ID: <50855DFB.1060704@bull.net> Date: Mon, 22 Oct 2012 16:53:47 +0200 From: Denis Pinkas User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Ryan Hurst References: <50855225.1030202@bull.net> In-Reply-To: X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 22/10/2012 16:53:48, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 22/10/2012 16:53:49, Serialize complete at 22/10/2012 16:53:49 X-TNEFEvaluated: 1 Content-Type: multipart/alternative; boundary="------------060306080803010402030907" Cc: pkix Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 14:53:52 -0000 This is a multi-part message in MIME format. --------------060306080803010402030907 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Ryan, Given your argumentation, let us go for "revoked", rather than "unknown "= . However, adding a note in the draft to record why this choice was made=20 might be useful. Denis > Though I prefer the Unknown approach today all OCSP capable browsers=20 > other than Opera ignore Unknown OCSP responses. > > Given the arguable limited value of changing the response definitions=20 > at all it seems accommodating this seems the most prudent approach. > > This is why the CABFORUM accepted the revoked response approach even=20 > though it is not as pure. > > Sent from my iPhone > > On Oct 22, 2012, at 7:03 AM, Denis Pinkas > wrote: > >> To the PKIX list: >> >> =C2 =C2 Without changing the meaning of "good" and of either "revoked= " or >> =C2 =C2 "unknown", it is not possible to address the case of what is >> =C2 =C2 =C2 presently called "non-issued certificates". >> >> The current text from RFC 2560 is: >> >> =C2 =C2 "The "good" state indicates a positive response to the state=20 >> inquiry. >> =C2 =C2 At a minimum, this positive response indicates that the certi= ficate >> =C2 =C2 is not revoked, but does not necessarily mean that the certif= icate >> =C2 =C2 was ever issued or that the time at which the response was pr= oduced >> =C2 =C2 is within the certificate's validity interval. Response exten= sions >> =C2 =C2 may be used to convey additional information on assertions ma= de by >> =C2 =C2 the responder regarding the state of the certificate such as >> =C2 =C2 positive statement about issuance, validity, etc. >> >> =C2 =C2 The "revoked" state indicates that the certificate has been r= evoked >> =C2 =C2 (either permanantly or temporarily (on hold)). >> >> =C2 =C2 The "unknown" state indicates that the responder doesn't know= about >> =C2 =C2 the certificate being requested". >> >> >> =C2 =C2 A minor change should be done to advertise that "good" may be >> =C2 =C2 returned when the certificate was never issued and CRLs are b= eing >> =C2 =C2 used. >> >> >> Replacement text for the definition of the "good" state: >> >> =C2 =C2 "The "good" state indicates a positive response to the state=20 >> inquiry. >> =C2 =C2 At a minimum, this positive response indicates that the certi= ficate >> =C2 =C2 is not revoked, but does not necessarily mean that the certif= icate >> =C2 =C2 was ever issued *(e.g. when CRLs are used by the OCSP respond= ers)* >> =C2 or=C2 that the time at which the response was produced is within= the >> =C2 =C2 certificate's validity interval.=C2 Response extensions may = be used >> =C2 =C2 to convey additional information on assertions made by the OC= SP >> =C2 =C2 responder regarding the state of the certificate such as *an = ** >> **=C2 =C2 indication that the OCSP responder has a direct access to t= he ** >> **=C2 =C2 database of issued certificates*, validity, etc ... " >> >> =C2 =C2 Then either the meaning of "rekoved" or of "unknown" needs to= be >> =C2 =C2 changed. >> >> =C2 =C2 draft-ietf-pkix-rfc2560bis-06 attempts to address the issue a= nd >> =C2 =C2 proposes to keep the meaning of "unknown" unchanged and to ch= ange >> =C2 =C2 the meaning of "revoked" in the following way: >> >> =C2 =C2 "The "revoked" state indicates that the certificate has been = revoked >> =C2 =C2 (either permanently or temporarily (on hold)). This state SHO= ULD=20 >> also >> =C2 =C2 be returned if the responder *knows that the requested=20 >> certificate has ** >> **=C2 =C2 never been issued*. Note that the receiver of a response ma= y=20 >> have to >> =C2 =C2 consult out-of-band knowledge, or information in an extension= =20 >> defined >> =C2 =C2 outside of this standard, to know whether a particular respon= der has >> =C2 =C2 knowledge about whether a requested certificate has been issu= ed or >> =C2 =C2 not and whether it responds "good" or "revoked" to a state re= quest >> =C2 =C2 for a non-issued certificate". >> >> =C2 =C2 There is a door opened for a future extension "to know whethe= r a >> =C2 =C2 particular responder has knowledge about whether a requested >> =C2 =C2 certificate has been issued or not". >> >> =C2 =C2 However, the extension proposed in=20 >> draft-pinkas-2560bis-certinfo-00.txt, >> =C2 =C2 carries a slightly different meaning: >> >> =C2 =C2 =C2 =C2 =C2 - an indication that the serial number of the tar= get >> =C2 =C2 =C2 =C2 =C2 =C2 =C2 certificate is not present in the databas= e, >> >> *Saying that the certificate has not been issued is not fully=20 >> appropriate.* >> >> The text should be modified in the following way: >> >> =C2 =C2 "The "revoked" state indicates that the certificate has been=20 >> revoked >> =C2 =C2 (either permanently or temporarily (on hold)).=C2 This state= SHOULD >> =C2 =C2 also be returned if the responder *has an access to the datab= ase >> =C2 =C2 of=C2 **issued certificates and if the serial number of the t= arget ** >> **=C2 =C2 certificate is not present in that database. * >> >> =C2 =C2 *In this case, the "revoked" state indicates either that the *= * >> **=C2 =C2 certificate has never been issued or that it has been issue= d=20 >> but ** >> **=C2 =C2 subsequently removed (by an attack or by accident) from the >> =C2 =C2 database **of issued certificates.* >> >> =C2 =C2 Response extensions may be used=C2 to convey additional info= rmation >> =C2 =C2 on assertions made by the OCSP=C2 responder regarding the st= ate=20 >> of the >> =C2 =C2 certificate such as *an **indication that the OCSP responder = has >> =C2 =C2 a direct access to the **database of issued certificates*,=20 >> validity, etc ... " >> >> An alternative is to keep the meaning of "revoked" and to change >> the meaning of "unknown" in the following way: >> >> =C2 =C2 "The "unknown" status indicates either that the server doesn'= t know >> =C2 =C2 about the certificate being requested *or the revocation stat= us >> =C2 =C2 of the certificate being requested* >> >> =C2 =C2 Response extensions may be used=C2 to convey additional info= rmation >> =C2 =C2 on assertions made by the OCSP=C2 responder regarding the st= ate=20 >> of the >> =C2 =C2 certificate such as *an **indication that the OCSP responder = has >> =C2 =C2 a direct access to the **database of issued certificates*,=20 >> validity, etc ..." >> >> There are pros and cons for each alternative. If the meaning of=20 >> "revoked" >> is changed it is also necessary to say what should be the values of bo= th >> revocationTime and revocationReason: >> >> =C2 =C2 CertStatus ::=3D CHOICE { >> =C2 =C2 =C2 =C2 =C2 =C2 good=C2 =C2 =C2 =C2 =C2 =C2 =C2 [0]=C2 =C2 =C2= =C2 IMPLICIT NULL, >> =C2 =C2 =C2 =C2 =C2 =C2 revoked=C2 =C2 =C2 =C2 [1]=C2 =C2 =C2 =C2 I= MPLICIT RevokedInfo, >> =C2 =C2 =C2 =C2 =C2 =C2 unknown=C2 =C2 =C2 =C2 [2]=C2 =C2 =C2 =C2 I= MPLICIT UnknownInfo } >> >> =C2 =C2 RevokedInfo ::=3D SEQUENCE { >> =C2 =C2 =C2 =C2 =C2 =C2 revocationTime=C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2= =C2 =C2 =C2 =C2 =C2 GeneralizedTime, >> =C2 =C2 =C2 =C2 =C2 =C2 revocationReason=C2 =C2 =C2 [0]=C2 =C2 =C2 =C2= EXPLICIT CRLReason >> =C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2= =C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2=20 >> OPTIONAL } >> >> =C2 =C2 UnknownInfo ::=3D NULL >> >> CRLReason is imported from PKIX1Implicit88 { iso(1)=20 >> identified-organization(3) >> dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) >> id-pkix1-implicit(19) } >> >> CRLReason is defined in RFC 5280 as: >> >> =C2 =C2 CRLReason ::=3D ENUMERATED { >> =C2 =C2 =C2 =C2 =C2 =C2 =C2 unspecified=C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2= =C2 =C2 =C2 =C2 (0), >> =C2 =C2 =C2 =C2 =C2 =C2 =C2 keyCompromise=C2 =C2 =C2 =C2 =C2 =C2 =C2 = =C2 =C2 =C2 (1), >> =C2 =C2 =C2 =C2 =C2 =C2 =C2 cACompromise=C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2= =C2 =C2 =C2 (2), >> =C2 =C2 =C2 =C2 =C2 =C2 =C2 affiliationChanged=C2 =C2 =C2 =C2 =C2 (3= ), >> =C2 =C2 =C2 =C2 =C2 =C2 =C2 superseded=C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2= =C2 =C2 =C2 =C2 =C2 (4), >> =C2 =C2 =C2 =C2 =C2 =C2 =C2 cessationOfOperation=C2 =C2 =C2 (5), >> =C2 =C2 =C2 =C2 =C2 =C2 =C2 certificateHold=C2 =C2 =C2 =C2 =C2 =C2 =C2= =C2 (6), >> =C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2 -- value 7 is not use= d >> =C2 =C2 =C2 =C2 =C2 =C2 =C2 removeFromCRL=C2 =C2 =C2 =C2 =C2 =C2 =C2 = =C2 =C2 =C2 (8), >> =C2 =C2 =C2 =C2 =C2 =C2 =C2 privilegeWithdrawn=C2 =C2 =C2 =C2 =C2 (9= ), >> =C2 =C2 =C2 =C2 =C2 =C2 =C2 aACompromise=C2 =C2 =C2 =C2 =C2 =C2 =C2 =C2= =C2 =C2 (10) } >> >> >> For the revocationTime should we use the content of notBefore field=20 >> from the certificate ? >> >> For the revocationReason should we use unspecified or keyCompromise ? >> >> In any case, guidance should be given. >> >> Although I understand that changing the meaning of "revoked" may be=20 >> seen as "safer" >> for old implemenations, changing the meaning of "unknown" also seems=20 >> to be a reasonable alternative. >> >> In this case, it might be useful (and sufficient) to say that if an=20 >> OCSP responder is authoritative >> for the target certificate, then the OCSP client SHOULD NOT use an=20 >> alternative source >> of revocation information like CRLs. >> >> Denis >> >> >>> In line; >>> >>> From: Piyush Jain > >>> Date: Sunday, October 21, 2012 7:42 PM >>> To: Stefan Santesson >> >, 'Peter Rybar' >> >, 'Carl Wallace' >> >, 'Simon Tardell'=20 >>> > >>> Cc: 'Peter Rybar' >,=20 >>> > >>> Subject: RE: [pkix] New draft-ietf-pkix-rfc2560bis-06 >>> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix --------------060306080803010402030907 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Ryan,

Given your argumentation, let us go for "revoked", rather than "unknown ".

However, adding a note in the draft to record why this choice was made might be useful.

Denis



Though I prefer the Unknown approach today all OCSP capable browsers other than Opera ignore Unknown OCSP responses.

Given the arguable limited value of changing the response definitions at all it seems accommodating this seems the most prudent approach.

This is why the CABFORUM accepted the revoked response approach even though it is not as pure.

Sent from my iPhone

On Oct 22, 2012, at 7:03 AM, Denis Pinkas <= denis.pinkas@bull.net> wrote:

To the PKIX list:

=C2=A0=C2=A0 Without changing the meaning of "good" and of ei= ther "revoked" or
=C2=A0=C2=A0 "unknown", it is not possible to address the cas= e of what is
=C2=A0=C2=A0=C2=A0 presently called "non-issued certificates"= .

The current text from RFC 2560 is:

=C2=A0=C2=A0 "The "good" state indicates a positive response = to the state inquiry.
=C2=A0=C2=A0 At a minimum, this positive response indicates t= hat the certificate
=C2=A0=C2=A0 is not revoked, but does not necessarily mean th= at the certificate
=C2=A0=C2=A0 was ever issued or that the time at which the re= sponse was produced
=C2=A0=C2=A0 is within the certificate's validity interval. R= esponse extensions
=C2=A0=C2=A0 may be used to convey additional information on assertions made by
=C2=A0=C2=A0 the responder regarding the state of the certifi= cate such as
=C2=A0=C2=A0 positive statement about issuance, validity, etc= .

=C2=A0=C2=A0 The "revoked" state indicates that the certifica= te has been revoked
=C2=A0=C2=A0 (either permanantly or temporarily (on hold)).
=C2=A0=C2=A0 The "unknown" state indicates that the responder doesn't know about
=C2=A0=C2=A0 the certificate being requested".


=C2=A0=C2=A0 A minor change should be done to advertise that = "good" may be
=C2=A0=C2=A0 returned when the certificate was never issued a= nd CRLs are being
=C2=A0=C2=A0 used.


Replacement text for the definition of the "good" state:

=C2=A0=C2=A0 "The "good" state indicates a positive response = to the state inquiry.
=C2=A0=C2=A0 At a minimum, this positive response indicates t= hat the certificate
=C2=A0=C2=A0 is not revoked, but does not necessarily mean th= at the certificate
=C2=A0=C2=A0 was ever issued (e.g. when CRLs are used by t= he OCSP responders)
=C2=A0 or=C2=A0 that the time at which the response was produ= ced is within the
=C2=A0=C2=A0 certificate's validity interval.=C2=A0 Response = extensions may be used
=C2=A0=C2=A0 to convey additional information on assertions m= ade by the OCSP
=C2=A0=C2=A0 responder regarding the state of the certificate= such as an
=C2=A0=C2=A0 indication that the OCSP responder has a = direct access to the
=C2=A0=C2=A0 database of issued certificates, vali= dity, etc ... "

=C2=A0=C2=A0 Then either the meaning of "rekoved" or of "unkn= own" needs to be
=C2=A0=C2=A0 changed.

=C2=A0=C2=A0 draft-ietf-pkix-rfc2560bis-06 attempts to addres= s the issue and
=C2=A0=C2=A0 proposes to keep the meaning of "unknown" unchan= ged and to change
=C2=A0=C2=A0 the meaning of "revoked" in the following way:
=C2=A0=C2=A0 "The "revoked" state indicates that the certific= ate has been revoked
=C2=A0=C2=A0 (either permanently or temporarily (on hold)). T= his state SHOULD also
=C2=A0=C2=A0 be returned if the responder knows that the requested certificate has
=C2=A0=C2=A0 never been issued. Note that the rece= iver of a response may have to
=C2=A0=C2=A0 consult out-of-band knowledge, or information in= an extension defined
=C2=A0=C2=A0 outside of this standard, to know whether a part= icular responder has
=C2=A0=C2=A0 knowledge about whether a requested certificate = has been issued or
=C2=A0=C2=A0 not and whether it responds "good" or "revoked" = to a state request
=C2=A0=C2=A0 for a non-issued certificate".

=C2=A0=C2=A0 There is a door opened for a future extension "t= o know whether a
=C2=A0=C2=A0 particular responder has knowledge about whether= a requested
=C2=A0=C2=A0 certificate has been issued or not".

=C2=A0=C2=A0 However, the extension proposed in draft-pinkas-2560bis-certinfo-00.txt,
=C2=A0=C2=A0 carries a slightly different meaning:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - an indication that the seria= l number of the target
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 certificate is not= present in the database,

Saying that the certificate has not been issued is not fully appropriate.

The text should be modified in the following way:

=C2=A0=C2=A0 "The "revoked" state indicates that the certific= ate has been revoked
=C2=A0=C2=A0 (either permanently or temporarily (on hold)).=C2= =A0 This state SHOULD
=C2=A0=C2=A0 also be returned if the responder has an acce= ss to the database
=C2=A0=C2=A0 of=C2=A0 issued certificates and if the= serial number of the target
=C2=A0=C2=A0 certificate is not present in that databa= se.

=C2=A0=C2=A0 In this case, the "revoked" state indicates e= ither that the
=C2=A0=C2=A0 certificate has never been issued or that= it has been issued but
=C2=A0=C2=A0 subsequently removed (by an attack or by accident) from the
=C2=A0=C2=A0 database of issued certificates.
=C2=A0=C2=A0 Response extensions may be used=C2=A0 to convey = additional information
=C2=A0=C2=A0 on assertions made by the OCSP=C2=A0 responder r= egarding the state of the
=C2=A0=C2=A0 certificate such as an indication that= the OCSP responder has
=C2=A0=C2=A0 a direct access to the database of issu= ed certificates, validity, etc ... "

An alternative is to keep the meaning of "revoked" and to change
the meaning of "unknown" in the following way:

=C2=A0=C2=A0 "The "unknown" status indicates either that the = server doesn't know
=C2=A0=C2=A0 about the certificate being requested or the revocation status
=C2=A0=C2=A0 of the certificate being requested

=C2=A0=C2=A0 Response extensions may be used=C2=A0 to convey = additional information
=C2=A0=C2=A0 on assertions made by the OCSP=C2=A0 responder r= egarding the state of the
=C2=A0=C2=A0 certificate such as an indication that= the OCSP responder has
=C2=A0=C2=A0 a direct access to the database of issu= ed certificates, validity, etc ..."

There are pros and cons for each alternative. If the meaning of "revoked"
is changed it is also necessary to say what should be the values of both
revocationTime and revocationReason:

=C2=A0=C2=A0 CertStatus ::=3D CHOI= CE {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 good=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 [0]=C2=A0=C2=A0=C2=A0=C2=A0 IMPLICIT NULL,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 revoked=C2=A0=C2=A0=C2= =A0=C2=A0 [1]=C2=A0=C2=A0=C2=A0=C2=A0 IMPLICIT RevokedInfo,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 unknown=C2=A0=C2=A0=C2= =A0=C2=A0 [2]=C2=A0=C2=A0=C2=A0=C2=A0 IMPLICIT UnknownInfo }

=C2=A0=C2=A0 RevokedInfo ::=3D SEQUENCE {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 revocationTime=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 GeneralizedTime,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 revocationReason=C2=A0= =C2=A0=C2=A0 [0]=C2=A0=C2=A0=C2=A0=C2=A0 EXPLICIT CRLReason
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OPTIONAL }

=C2=A0=C2=A0 UnknownInfo ::=3D NUL= L

CRLReason is imported from PKIX1Implicit88 { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-implicit(19) }

CRLReason is defined in RFC 5280 as:

=C2=A0=C2=A0 CRLReason ::=3D ENUME= RATED {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 unspecified=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (0), =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 keyCompromise=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (1),
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 cACompromise=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (2),
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 affiliationChang= ed=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (3),
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 superseded=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = (4),
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 cessationOfOpera= tion=C2=A0=C2=A0=C2=A0 (5),
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 certificateHold=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (6),
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 -- value 7 is not used
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 removeFromCRL=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (8),
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 privilegeWithdra= wn=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (9),
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 aACompromise=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (10) }


For the revocationTime should we use the content of notBefore field from the certificate ?

For the revocationReason should we use unspecified or keyCompromise ?

In any case, guidance should be given.

Although I understand that changing the meaning of "revoked" may be seen as "safer"
for old implemenations, changing the meaning of "unknown" also seems to be a reasonable alternative.

In this case, it might be useful (and sufficient) to say that if an OCSP responder is authoritative
for the target certificate, then the OCSP client SHOULD NOT use an alternative source
of revocation information like CRLs.

Denis


In line;

From: = Piyush Jain <piyush@ditenity.com= >
Date: Sunday, October 21, 2012 7:42 PM
To: Stefan Santesson <stefan@aaa-sec.com>, 'Peter Rybar' <rybar@nbusr.sk>, 'Carl Wallace' <carl@redhound= software.com>, 'Simon Tardell' <simon@tardell.se&g= t;
Cc: 'Peter Rybar' <peterryb@gmail.com>, <pkix@ietf.org>
Subject: RE: [pkix] New draft-ietf-pkix-rfc2560bis-06

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


--------------060306080803010402030907-- From piyush@ditenity.com Mon Oct 22 08:32:58 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 660BD21F8894 for ; Mon, 22 Oct 2012 08:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.237 X-Spam-Level: X-Spam-Status: No, score=-3.237 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9eMhKhwes-6 for ; Mon, 22 Oct 2012 08:32:46 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 151C221F8674 for ; Mon, 22 Oct 2012 08:32:45 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so4516204iec.31 for ; Mon, 22 Oct 2012 08:32:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language :x-gm-message-state; bh=5vwmT0msEfPxEeqBe8Xzb9DVV7jEqNZmW6plJvGCkhs=; b=SowrOtP+NpQgRvjqv7xP7segzoh+pj6hxV/hWn9cTW1ApxxP2XPpTEH+XTZF9yGwL2 9FSwGcRRA2g/GtClHylr2C/oWsOvHnBqLWrZNSwmy5IphM4T7YzclhKXdN1AZUxiswfs nd/m27IwsvCTX6XUB5g1UR5fSWqYFrw9X548gOboP0iACuJT4qUQ2EWw3a01qyq+3ph+ u6f70e53LcS5NNiB8bRMx4r10Ag2Y9YSVvpt63fRXO2Qe6yPYTN8qSkLTaB93SeYYcAI lCsEce2FMaltBj2u/J2841ZqLpfjPrQUYURsiVyb1o82dJ21OliFZlHCoJFtgowvO5bQ jKTQ== Received: by 10.50.197.169 with SMTP id iv9mr9677468igc.32.1350919964664; Mon, 22 Oct 2012 08:32:44 -0700 (PDT) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id x5sm13489686igc.14.2012.10.22.08.32.41 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 22 Oct 2012 08:32:43 -0700 (PDT) From: "Piyush Jain" To: "'Stefan Santesson'" , "'Peter Rybar'" , "'Carl Wallace'" , "'Simon Tardell'" References: <006401cdafb3$7f073d00$7d15b700$@ditenity.com> In-Reply-To: Date: Mon, 22 Oct 2012 08:32:39 -0700 Message-ID: <010201cdb06a$7a37c670$6ea75350$@ditenity.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0103_01CDB02F.CDE74650" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKpGXiT2xp3Vwl7Va1D/JHcfvu/m5YOkWbQ Content-Language: en-us X-Gm-Message-State: ALoCoQk4nAC8VuoBKtukukF9AmxBANakmgw9GIGv+OTQTIWEURGARpwn3mmyVZmyT94lqZfiqr8q Cc: 'Peter Rybar' , pkix@ietf.org Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 15:32:58 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0103_01CDB02F.CDE74650 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I'm sorry but definition of not issued is still unclear to me if you say that that a certificate can be cryptographically bound to the CA and still not-issued. The ambiguity is introduced because now I can do everything that 5280 asks me to validate a certificate and still cannot be sure if the certificate was ever issued. Here are the scenarios where meaning of not issued is unclear to me. 1) A genuine certificate issued by the CA, present in the CA database 2) A genuine certificate issued by the CA, removed from the CA database by the CA 3) A genuine certificate issued by the CA, removed from the CA database by an attacker 4) A fraudulent certificate issued by an attacker, present in the CA database 5) A fraudulent certificate issued by an attacker, removed from the CA database 6) A fraudulent certificate containing an AIA pointing to a fraudulent OCSP responder (also cryptographically bound to the CA), issued by an attacker, removed from the CA database. If the CA can differentiate among these cases, it can mark the fraudulent certificates as revoked and we won't need an overloaded definition of not-issued. Also not that if an attacker can carry out '4' it can also carry out '5' and '6' The people who are convinced that this is the way to go have not addressed the issues raised in this WG. The little extension does not hurt anyone but it does not provide any value in general except to a few implementations which are compromised. But it does take you down a slippery slope when you start promising that an OCSP responder can do much more than it is supposed to. I don't think that it is unreasonable for a smart implementer to stop signature checking if his responder claims that it checks issuance. As for the diginotor case, for some people who say that security breach could've been detected early if this practice was in place, there is another set of people who believe that attacker could've circumvented these measures quite easily with the kind of access he had. If you and other folks in the group feel that this text should be added, I think at the minimum we also need to do the following - Provide explicit guidance on what the revocation time should be. Such certificates are different from 'normal' revoked certificate and their revocation time should probably be set to something before the validity of issuing CA. This distinction is important for time based validations and long term archiving applications - I think it will be useful to indicate in the security considerations section, that in such a scenario, CA is compromised and that there is a high chance that RP is interacting with a compromised responder. From: Stefan Santesson [mailto:stefan@aaa-sec.com] Sent: Sunday, October 21, 2012 11:03 AM To: Piyush Jain; 'Peter Rybar'; 'Carl Wallace'; 'Simon Tardell' Cc: 'Peter Rybar'; pkix@ietf.org Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 In line; From: Piyush Jain Date: Sunday, October 21, 2012 7:42 PM To: Stefan Santesson , 'Peter Rybar' , 'Carl Wallace' , 'Simon Tardell' Cc: 'Peter Rybar' , Subject: RE: [pkix] New draft-ietf-pkix-rfc2560bis-06 So what is "not-issued" - not signed by the CA or not present in CA database? Not issued means it has never been issued. What's unclear about that? Of course it is not present in the database if it is not issued. If you delete things from your database and don't know if this one has been deleted, then you don't know that it has never been issued and can't reply revoked. It is unclear to folks who have been using signature verification as a way to check issuance. Isn't it a fair conclusion that I do not need to perform signature checks if the responder can check issuance for me? No that is not a fair conclusion. These are entirely different things. You said that the possibility to send revoked reply only applies when the responder 'knows' that requested certificate has never been issued. Please note that the responder will encounter this kind of request only in two situations. First in which the RP sends a request for a certificate without checking the signature and second in which the responder itself is compromised by virtue of its issuing authority being compromised. In either case what the responder responds with does not matter. Some people are pretty convinced it does (from CAB forum), they are so convinced that they are prepared to break compatibility with OCSP. By this little extension that hurst no-one, they don't have to. I've no problem with your proposal to respond with 'revoked' in this situation. Good. I've fundamental problem with the introduction of 'non-issued' concept in OCSP, which seems to provide additional security in this exceptional scenario without actually providing any. It provides some, but not much. People keep coming back to that fact that if this had been the practice of Diginotar, the security breach would have been discovered a lot earlier. So there might be some gain with no pain. However, in combination with an extension that adds information, this might actually be increasingly valuable. If an OCSP responder starts receiving status requests for certs it knows it has not issued, it can actually give explicit information about this using an extension and it can take adequate measures. But in order to respond to the user, it need to pick one of the responses. Either good + extension or revoked+extension. This proposal is not meant to require any OCSP responder to deal with the concept of "non-issued" certs. It merely allows an OCSP responder to respond to such request. It'll be very helpful if I can see at least one practical scenario where this additional text would add value. Stated in my previous comments. /Stefan -Piyush From: Stefan Santesson [mailto:stefan@aaa-sec.com] Sent: Sunday, October 21, 2012 8:52 AM To: Piyush Jain; 'Peter Rybar'; 'Carl Wallace'; 'Simon Tardell' Cc: 'Peter Rybar'; pkix@ietf.org Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 I don't think the "not issued" is unclear. The possibility to send a revoked reply only applies then the responder "knows" that the requested certificate has never been issued. How the responder knows this is totally irrelevant, but unless the responder knows this, it can't choose this option and has to reply "good". It does not make revocation checking non-deterministric. "good" still means what is declared in the standard (The cert is not known to be revoked, but it may never have been issued). "revoked" still have a deterministic meaning, that is, don't trust this cert. The old exact semantics was "the cert IS revoked". The new semantic is "the cert is revoked or possibly might never been issued" The new response semantic of revoked is backwards compatible and not less deterministic than the good, response. So, I still don't see any practical problems here. /Stefan From: Piyush Jain Date: Saturday, October 20, 2012 5:48 PM To: Stefan Santesson , 'Peter Rybar' , 'Carl Wallace' , 'Simon Tardell' Cc: 'Peter Rybar' , Subject: RE: [pkix] New draft-ietf-pkix-rfc2560bis-06 Please see inline From: Stefan Santesson [mailto:stefan@aaa-sec.com] Sent: Friday, October 19, 2012 7:23 PM To: Piyush Jain; 'Peter Rybar'; 'Carl Wallace'; 'Simon Tardell' Cc: 'Peter Rybar'; pkix@ietf.org Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 I'm sorry. I fail to the any of the problems you raise. If you receive a request for a certificate that you know has never been issued, and you choose to reply revoked, what problems can you cause? [Piyush] It depends on how you define "never been issued", which btw becomes unclear after introduction of the new text. There are two interpretations 1) Certificate is not signed by the CA or 2) Certificate is not present in the database of issued certificates that CA maintains. One unintended consequence of first interpretation will be that RPs would stop performing signature checks if their responder/CA publicizes that it returns revoked for "non-issued" certificates. If the interpretation is 2, then this scenario is not possible unless the CA is compromised. What in your mind is a more appropriate response? [Piyush] I would say the appropriate response is good (if the certificate is not marked as revoked), because that is what the RP will see if it consults a CRL or a responder detached from the CA. Revoked for "not issued" adds no value because the only case in which an RP would send a query for a "non-issued" certificate is when the CA is compromised. It does not make OCSP more non-deterministic. If you ask status for an issued cert from a non-broken CA, nothing is non-deterministic. [Piyush] It does not make OCSP non-deterministic but it makes revocation checking non-deterministic. The goal of OCSP is to address operational limitations of CRLs, not functional limitations. The fact that you'll get different answers from two sources, both of which are authorized by the same CA makes revocation checking non deterministic. If you ask for status for a non-issued certificate, or a bad certificate from a broken CA, then the result is by default non-deteministic and has always been. However, choosing a revoked response may save the relying party, at best, but can hurt no-one [Piyush] I agree that a revoke response does not hurt anyone. But the point is that it provides a false sense of additional security to the RP without providing any. As an RP, I won't trust what my responder says if the authority that certified it is compromised. What is your problem on the practical ground. [Piyush] Let's say that we still need to address this scenario and revoked is the appropriate response. In that case - The text needs to be explicit about the revocation time in this situation. Revoked implies good until a certain date and this distinction is important for long term archiving applications. For unissued certificate the revocation time should probably be set to -infinity. - It needs to call out that in this particular scenario it is addressing a functional limitation of CRLs (ability to detect CA compromise) not an operational limitation. - I think we need additional text in security considerations to indicate that RP is communicating with a responder certified by a compromised CA in this scenario. /Stefan From: Piyush Jain Date: Friday, October 19, 2012 7:34 PM To: Stefan Santesson , 'Peter Rybar' , 'Carl Wallace' , 'Simon Tardell' Cc: 'Peter Rybar' , Subject: RE: [pkix] New draft-ietf-pkix-rfc2560bis-06 Stefan, I think some of you interpretations below are twisted to accommodate the new provisions for providing revoked responses for unissued certificates. Providing responses for expired certificates is within the scope of 2560 using archive cutoff extension. The original authors of 2560 can correct me if I'm wrong, but it is my understanding that a response from OCSP responder is not supposed to indicate if a certificate is good or bad but to indicate if a certificate is revoked or unrevoked by the issuing authority. The fact that certificate is issued by the CA is checked by the RP by verifying the signature on the certificate. This draft introduces the concept of returning revoked responses for unissued certificates. There are many unintended consequences of this approach - Revocation statuses become non-deterministic based on who you are asking (A responder with access to CA database vs. one without vs. checking status off a CRL). If I'm archiving a signed document with the relevant artifacts to determine the validity status of the document, this becomes a huge problem. Note that a revoked status implies that certificate was good between the time of its issuance and that of its revocation. Any document that is signed within that period should still be considered valid. - It would confuse an implementer about what "non-issued" means. The fact that the CA signed the certificate implies it was issued. If a certificate is issued fraudulently, based on its security practices, it is up to the CA to either revoke the issued certificate, or ask its issuing authority to revoke its own certificate. -Piyush From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Stefan Santesson Sent: Friday, October 19, 2012 7:25 AM To: Peter Rybar; 'Carl Wallace'; 'Simon Tardell' Cc: 'Peter Rybar'; pkix@ietf.org Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Peter, An OCSP responder is by default a service providing information about current certificates. The default response you get from an OCSP responder is "good" unless the cert is known to be bad or not a cert the responder can provide status for. If you need it to respond about old certificates, and as a client know that the responder does this in a way that suits your needs, you will need to add an extension. Such extension will not be part of the rfc256bis effort. Is there any text in the current draft that you think is unclear on this? /Stefan From: Peter Rybar Date: Friday, October 19, 2012 3:12 PM To: 'Carl Wallace' , 'Simon Tardell' Cc: 'Peter Rybar' , Stefan Santesson , Subject: RE: [pkix] New draft-ietf-pkix-rfc2560bis-06 Well, yes, sort of. You can only be sure to validate a signature at the moment of production. What if the signature key was compromised at the moment of production but is not yet on a revocation list? [PR] According to clause 2.4 - thisUpdate: The time at which the status being indicated is known to be correct It means when signature time-stamp time is X then any OCSP responses with thisUpdate time X+y are sufficient to validate because the status is correct. Y is in the interval <0, producedAt - X> At any later point in time the signature key may be compromised, or the algorithms involved may have become to weak. (In which case the time of revocation in the OCSP response is worth nothing to you). The risk increases as time passes. And of course, the revocation information may not be kept around after the expiry of the certificate. That's why you should validate signatures as soon as possible. For these archival purposes wouldn't it be better to have the final revocation list before removed due to expiry? In any case, you'd need verification information collected after some grace period following moment of production. [PR] Grace period is not a fixed value of the time interval. Grace period is changeable because the first OCSP response with thisUpdate time value > than time of signature time-stamp contains correct status. If you need to ascertain that a signature was valid at a later time, you have to trust your system that it performed the validation at the time it first received the signature. That trust must be established through some kind of mix of policies and technical measures (such as timestamping). In the dark corner just beyond the dark corner that is SCVP, there's a spec (RFC 5276) that defines a binding of evidence records to artifacts that can be returned viaSCVP. This provides for timestamping. [PR] The validation is simplified when OCSP response with positive statement as a hash value of requested certificate is used. Positive statement is evidence that OCSP know the status of certificate and also protect the integrity of certificate with a new more secure hash algorithm. Peter Rybar Simon Tardell, Technology Nexus. On Fri, Oct 19, 2012 at 1:07 PM, Peter Rybar wrote: Stefan, I have a question about the present OCSP RFC and at the end of the mail about the new situation which will happen according to your new proposal. The presence of the positive statement in OCSP response is important for electronic signature validations, especially for an expired certificate. Positive statement is the hash value of a certificate whose status is provided in OCSP response. Electronic signature validation is usually about the signatures created in the past and validated now, when the certificate is expired. When the certificate expires then revocation is usually removed from CRL and the revoked certificate can be provided as "good" in OCSP response. Is it acceptable? I think not. According to your new draft there is not defined a value of revocationTime. RFC must also define the value of revocationTime when the certificate which was never issued is as "revoked". http://www.ietf.org/rfcdiff?url2=draft-ietf-pkix-rfc2560bis-06 Have you also covered the situation when the certificate is expired, REMOVED FROM CRL and will be provided as revoked with incorrect revocationTime e.g.with the value before or after the revocationTime which was present in the removed record from CRL? Because according to sentence in your draft ""revoked" - This state SHOULD also be returned if the responder knows that the requested certificate has never been issued." the following situation can happen: when certificate is removed from CRL after expiration and CA/OCSP responder is responsible for this certificate but have not record about expired certificate and for that reason it is identified as "never been issued". ... revoked [1] IMPLICIT RevokedInfo, ... RevokedInfo ::= SEQUENCE { revocationTime GeneralizedTime, revocationReason [0] EXPLICIT CRLReason OPTIONAL } As you have mentioned in the mail: "On the "revoked" state, the old spec did not even consider the case of a certificate being requested where the OCSP responder knows that the certificate was never issued." "It simply recommend a known to be bad certificate to result in "revoked" in order to prevent damage as far as possible. It also opens for definition of new extensions through which such knowledge could be obtained." Peter Rybar National Security Authority Information Security and Electronic Signature Department Budatinska 30, 850 07 Bratislava 57, Slovak Republic e-mail: peter.rybar@nbusr.sk e-mail: peterryb@gmail.com -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Stefan Santesson Sent: Monday, October 15, 2012 1:49 AM To: pkix@ietf.org Subject: [pkix] New draft-ietf-pkix-rfc2560bis-06 All, I have just posted an update of rfc2560bis (OCSP update) after carefully reviewing all comments on the list. Some notes about the update: - Added the previous OCSP editors with updated affiliations. - Added some calcifications on ResponderID as suggested by Simon Josefsson. - Updated the clarifications on Authorized responders. The requirements have not changed. I just tried to improve the text. - Updated a clarification on the "revoked" state to be the preferred response if a certificate is known by the responder to never have been issued. - Some minor editorial nits. Regarding backwards compatibility I mean that none of the clarifications changes RFC 2560. On Authorized responders it has always been the case that a responder certificate issued with the same key as was used to issue the certificate being checked for revocation, represents a valid Authorized responder. There has never been an explicit requirement to support key rollover and key rollover support has never been in the "spirit" of the original standard as it clearly attempted to provide direct cryptographic binding between the responder and the CA. On the "revoked" state, the old spec did not even consider the case of a certificate being requested where the OCSP responder knows that the certificate was never issued. It is clearly counterproductive to respond good when a certificate is known to be bad. A responder must pick one response and picking "revoked" breaks nothing, but has the desired effect, that is, to prevent the certificate from being accepted. The current text makes clear that there is no mechanism in the current standard by which a client can know how a responder will respond to a request for a not issued certificate. It simply recommend a known to be bad certificate to result in "revoked" in order to prevent damage as far as possible. It also opens for definition of new extensions through which such knowledge could be obtained. The current updates also clearly opens a path for the CAB forum efforts to define a suitable solution for server certificates. I have not, even thug suggested, added any requirements on what clients should do with the checked cert as a result of a particular response. I don't believe such requirements are suitable as it is policy and not protocol. We have no right to demand that all systems MUST reject any certificate for any reason as they may have a local policy that overrules the OCSP response. This protocol only provides information about the cert status, it does not mandate validation policy. I have not included any of the substantial changes i the Pinkas draft. I want to wait for a list of motivation for each change before including any of them. So there changed may be up for debate before this draft is ready for WGLC. /Stefan _______________________________________________ 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 _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix ------=_NextPart_000_0103_01CDB02F.CDE74650 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m sorry but definition of not issued is still unclear to me = if you say that that a certificate can be cryptographically bound to the = CA and still not-issued.

The ambiguity is introduced because now I can do everything that 5280 = asks me to validate a certificate and still cannot be sure if the = certificate was ever issued.

 

Here are the scenarios where meaning of not issued is unclear to = me.

1)      = A genuine certificate issued by the CA, present in the CA = database

2)      = A genuine certificate issued by the CA, removed from the CA database = by the CA

3)      = A genuine certificate issued by the CA, removed from the CA database = by an attacker

4)      = A fraudulent certificate issued by an attacker, present in the CA = database

5)      = A fraudulent certificate issued by an attacker, removed from the CA = database

6)      = A fraudulent certificate containing an AIA pointing to a fraudulent = OCSP responder (also cryptographically bound to the CA), issued by an = attacker, removed from the CA database.

 

If the CA can differentiate among these cases, it can mark the = fraudulent certificates as revoked and we won’t need an overloaded = definition of not-issued. Also not that if an attacker can carry out = ‘4’ it can also carry out ‘5’ and = ‘6’

 

The people who are convinced that this is the way to go have not = addressed the issues raised in this WG. The little extension does not = hurt anyone but it does not provide any value in general except to a few = implementations which are compromised. But it does take you down a = slippery slope when you start promising that an OCSP responder can do = much more than it is supposed to.

I don’t think that it is unreasonable for a smart implementer = to stop signature checking if his responder claims that it checks = issuance.

 

As for the diginotor case, for some people who say that security = breach could’ve been detected early if this practice was in place, = there is another set of people who believe that attacker could’ve = circumvented these measures quite easily with the kind of access he = had.

 

If you and other folks in the group feel that this text should be = added, I think at the minimum we also need to do the = following

-          = Provide explicit guidance on what the revocation time should be. Such = certificates are different from ‘normal’ revoked certificate = and their revocation time should probably be set to something before the = validity of issuing CA. This distinction is important for time based = validations and long term archiving applications

-          = I think it will be useful to indicate in the security considerations = section, that in such a scenario, CA is compromised and that there is a = high chance that RP is interacting with a compromised = responder.

 

 

From:= = Stefan Santesson [mailto:stefan@aaa-sec.com]
Sent: Sunday, = October 21, 2012 11:03 AM
To: Piyush Jain; 'Peter Rybar'; = 'Carl Wallace'; 'Simon Tardell'
Cc: 'Peter Rybar'; = pkix@ietf.org
Subject: Re: [pkix] New = draft-ietf-pkix-rfc2560bis-06

 

In line;

 

From: Piyush Jain <piyush@ditenity.com>
Dat= e: Sunday, October 21, 2012 7:42 PM
To: Stefan Santesson = <stefan@aaa-sec.com>, = 'Peter Rybar' <rybar@nbusr.sk>, 'Carl Wallace' = <carl@redhoundsoftware.com&g= t;, 'Simon Tardell' <simon@tardell.se>
Cc: = 'Peter Rybar' <peterryb@gmail.com>, <pkix@ietf.org>
Subject: = RE: [pkix] New = draft-ietf-pkix-rfc2560bis-06

 

So what is “not-issued” - not signed by the CA or not = present in CA database?

 

Not issued means it has never been issued. What's unclear about = that?

 

Of course it is not present in the database if it is not = issued.

If you delete things from your database and don't know if this one has = been deleted, then you don't know that it has never been issued and = can't reply revoked.

 

 

It is unclear to folks who have been using signature verification as = a way to check issuance. Isn’t it a fair conclusion that I do not = need to perform signature checks if the responder can check issuance for = me?

 

No that is not a fair conclusion. These are entirely different = things.

 

 

You said that the possibility to send revoked reply only applies when = the responder ’knows’ that requested certificate has never = been issued.

Please note that the responder will encounter this kind of request = only in two situations. First in which the RP sends a request for a = certificate without checking the signature and second in which the = responder itself is compromised by virtue of its issuing authority being = compromised. In either case what the responder responds with does not = matter.

 

 

Some people are pretty convinced it does (from CAB forum), they are so = convinced that they are prepared to break compatibility with OCSP. By = this little extension that hurst no-one, they don't have = to.

 

I’ve no problem with your proposal to respond with = ‘revoked’ in this situation.

 

Good.

 

I’ve fundamental problem with the introduction of = ‘non-issued’ concept in OCSP, which seems to provide = additional security in this exceptional scenario without actually = providing any.

 

It provides some, but not much. People keep coming back to that fact = that if this had been the practice of Diginotar, the security breach = would have been discovered a lot earlier. So there might be some gain = with no pain.

 

However, in combination with an extension that adds information, this = might actually be increasingly = valuable.

If an OCSP responder starts receiving status requests for certs it = knows it has not issued, it can actually give explicit information about = this using an extension and it can take adequate = measures.

But in order to respond to the user, it need to pick one of the = responses. Either good + extension or = revoked+extension.

 

This proposal is not meant to require any OCSP responder to deal with = the concept of "non-issued" certs. It merely allows an OCSP = responder to respond to such request.

 

 

It’ll be very helpful if I can see at least one practical = scenario where this additional text would add value.

 

Stated in my previous comments.

 

/Stefan

 

 

-Piyush

= From:= Stefan Santesson [mailto:stefan@aaa-sec.com] =
Sent: Sunday, October 21, 2012 8:52 AM
To: Piyush = Jain; 'Peter Rybar'; 'Carl Wallace'; 'Simon Tardell'
Cc: = 'Peter Rybar'; pkix@ietf.org
Subject: Re: = [pkix] New draft-ietf-pkix-rfc2560bis-06

 

I don't think the "not issued" is unclear.

 

The possibility to send a revoked reply only applies then the responder = "knows" that the requested certificate has never been = issued.

How the responder knows this is totally irrelevant, but unless the = responder knows this, it can't choose this option and has to reply = "good".

 

It does not make revocation checking = non-deterministric. 

"good" still means what is declared in the standard (The cert = is not known to be revoked, but it may never have been = issued).

"revoked" still have a deterministic meaning, that is, don't = trust this cert. The old exact semantics was "the cert IS = revoked". The new semantic is "the cert is revoked or possibly = might never been issued"

 

The new response semantic of revoked is backwards compatible and not = less deterministic than the good, response.

 

So, I still don't see any practical problems here.

 

/Stefan

 

 

From: Piyush Jain <piyush@ditenity.com>
Dat= e: Saturday, October 20, 2012 5:48 PM
To: Stefan Santesson = <stefan@aaa-sec.com>, = 'Peter Rybar' <rybar@nbusr.sk>, 'Carl Wallace' = <carl@redhoundsoftware.com&g= t;, 'Simon Tardell' <simon@tardell.se>
Cc: = 'Peter Rybar' <peterryb@gmail.com>, <pkix@ietf.org>
Subject: = RE: [pkix] New draft-ietf-pkix-rfc2560bis-06

 

Please see inline

 

= From:= Stefan Santesson [mailto:stefan@aaa-sec.com] =
Sent: Friday, October 19, 2012 7:23 PM
To: Piyush = Jain; 'Peter Rybar'; 'Carl Wallace'; 'Simon Tardell'
Cc: = 'Peter Rybar'; pkix@ietf.org
Subject: Re: = [pkix] New draft-ietf-pkix-rfc2560bis-06

 

I'm sorry. I fail to the any of the problems you raise.

 

If you receive a request for a certificate that you know has never been = issued, and you choose to reply revoked, what problems can you = cause?

[Piyush] It depends on how you define “never been = issued”, which btw becomes unclear after introduction of the new = text. There are two interpretations

1)      = Certificate is not signed by the CA or

2)      = Certificate is not present in the database of issued certificates = that CA maintains.

One unintended consequence of first interpretation will be that RPs = would stop performing signature checks if their responder/CA publicizes = that it returns revoked for “non-issued” = certificates.

If the interpretation is 2, then this scenario is not possible unless = the CA is compromised.

 

What in your mind is a more appropriate response?

[Piyush] I would say the appropriate response is good (if the = certificate is not marked as revoked), because that is what the RP will = see if it consults a CRL or a responder detached from the CA. =

Revoked for “not issued” adds no value because the only = case in which an RP would send a query for a “non-issued” = certificate is when the CA is compromised.

 

It does not make OCSP more non-deterministic. If you ask status for an = issued cert from a non-broken CA, nothing is = non-deterministic.

[Piyush] It does not make OCSP non-deterministic but it makes = revocation checking non-deterministic. The goal of OCSP is to address = operational limitations of CRLs, not functional limitations.  The = fact that you’ll get different answers from two sources, both of = which are authorized by the same CA makes revocation checking non = deterministic.

 

If you ask for status for a non-issued certificate, or a bad = certificate from a broken CA, then the result is by default = non-deteministic and has always been. However, choosing a revoked = response may save the relying party, at best, but can hurt = no-one

[Piyush] I agree that a revoke response does not hurt anyone. But the = point is that it provides a false sense of additional security to the RP = without providing any. As an RP, I won’t trust what my responder = says if the authority that certified it is = compromised.

 

What is your problem on the practical ground.

[Piyush]  Let’s say that we still need to address this scenario and = revoked is the appropriate response. In that case

-          = The text needs to be explicit about the revocation time in this = situation. Revoked implies good until a certain date and this = distinction is important for long term archiving applications. For = unissued certificate the revocation time should probably be set to = –infinity.

-          = It needs to call out that in this particular scenario it is = addressing a functional limitation of CRLs (ability to detect CA = compromise) not an operational limitation.

-          = I think we need additional text in security considerations to = indicate that RP is communicating with a responder certified by a = compromised CA in this scenario.

 

 

/Stefan

 

From: Piyush Jain <piyush@ditenity.com>
Dat= e: Friday, October 19, 2012 7:34 PM
To: Stefan Santesson = <stefan@aaa-sec.com>, = 'Peter Rybar' <rybar@nbusr.sk>, 'Carl Wallace' = <carl@redhoundsoftware.com&g= t;, 'Simon Tardell' <simon@tardell.se>
Cc: = 'Peter Rybar' <peterryb@gmail.com>, <pkix@ietf.org>
Subject: = RE: [pkix] New draft-ietf-pkix-rfc2560bis-06

 

Stefan,

 

I think some of you interpretations below are twisted to accommodate = the new provisions for providing revoked responses for unissued = certificates.

Providing responses for expired certificates is within the scope of = 2560 using archive cutoff extension.

 

The original authors of 2560 can correct me if I’m wrong, but = it is my understanding that a response from OCSP responder is not = supposed to indicate if a certificate is good or bad but to indicate if = a certificate is revoked or unrevoked by the issuing authority. The fact = that certificate is issued by the CA is checked by the RP by verifying = the signature on the certificate.

 

This draft introduces the concept of returning revoked responses for = unissued certificates. There are many unintended consequences of this = approach

-          = Revocation statuses become non-deterministic based on who you are = asking (A responder with access to CA database vs. one without vs. = checking status off a CRL). If I’m archiving a signed document = with the relevant artifacts to determine the validity status of the = document, this becomes a huge problem. Note that a revoked status = implies that certificate was good between the time of its issuance and = that of its revocation. Any document that is signed within that period = should still be considered valid.

-          = It would confuse an implementer about what “non-issued” = means. The fact that the CA signed the certificate implies it was = issued. If a certificate is issued fraudulently, based on its security = practices, it is up to the CA to either revoke the issued certificate, = or ask its issuing authority to revoke its own certificate.

 

-Piyush

 

 

 

 

= From:= pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] = On Behalf Of Stefan Santesson
Sent: Friday, October 19, = 2012 7:25 AM
To: Peter Rybar; 'Carl Wallace'; 'Simon = Tardell'
Cc: 'Peter Rybar'; pkix@ietf.org
Subject: Re: = [pkix] New draft-ietf-pkix-rfc2560bis-06

 

Peter,

 

An OCSP responder is by default a service providing information about = current certificates.

The default response you get from an OCSP responder is "good" = unless the cert is known to be bad or not a cert the responder can = provide status for.

 

If you need it to respond about old certificates, and as a client know = that the responder does this in a way that suits your needs, you will = need to add an extension.

Such extension will not be part of the rfc256bis effort.

 

Is there any text in the current draft that you think is unclear on = this?

 

/Stefan

 

 

From: Peter Rybar <rybar@nbusr.sk>
Date: = Friday, October 19, 2012 3:12 PM
To: 'Carl Wallace' <carl@redhoundsoftware.com&g= t;, 'Simon Tardell' <simon@tardell.se>
Cc: = 'Peter Rybar' <peterryb@gmail.com>, Stefan = Santesson <stefan@aaa-sec.com>, <pkix@ietf.org>
Subject: = RE: [pkix] New draft-ietf-pkix-rfc2560bis-06

 

Well, yes, sort of. You can only be sure to validate a signature at the = moment of production.

 

What if the signature key was compromised at the moment of production = but is not yet on a revocation list?

[P= R] According to clause 2.4  -  thisUpdate: The time at which = the status being indicated is known to be correct

It= means when signature time-stamp time is X then any OCSP responses with = thisUpdate time X+y are sufficient to validate because the status is = correct.

Y = is in the interval <0, producedAt - X>

 

At any later point in time the signature key may be compromised, or the = algorithms involved may have become to weak. (In which case the time of = revocation in the OCSP response is worth nothing to you). The risk = increases as time passes. And of course, the revocation information may = not be kept around after the expiry of the = certificate. 

 

That's why you should validate signatures as soon as = possible. 

 

For these archival purposes wouldn't it be better to have the final = revocation list before removed due to expiry?  In any case, you'd = need verification information collected after some grace period = following moment of production.

[P= R] Grace period is not a fixed value of the time interval.

Gr= ace period is changeable because the first OCSP response with thisUpdate = time value > than time of signature time-stamp contains correct = status.

 

 

If you need to ascertain that a signature was valid at a later time, = you have to trust your system that it performed the validation at the = time it first received the signature. That trust must be established = through some kind of mix of policies and technical measures (such as = timestamping).

 

In the dark corner just beyond the dark corner that is SCVP, there's a = spec (RFC 5276) that defines a binding of evidence records to artifacts = that can be returned viaSCVP.  This provides for timestamping. =  

[P= R] The validation is simplified when OCSP response with positive = statement as a hash value of requested certificate is used.

Po= sitive statement is evidence that OCSP know the status of certificate = and also protect the integrity of certificate with a new more secure = hash algorithm.

=  

Pe= ter Rybar

&n= bsp;



Simon Tardell, 

Technology Nexus.

On Fri, Oct 19, 2012 at 1:07 PM, Peter Rybar <rybar@nbusr.sk> = wrote:

Stefan,

I have a question about the present OCSP RFC and at the = end of the mail about the new situation which will happen according to = your new proposal.

The presence of the positive statement in OCSP = response is important for electronic signature validations, especially = for an expired certificate. Positive statement is the hash value of a = certificate whose status is provided in OCSP response.

Electronic = signature validation is usually about the signatures created in the past = and validated now, when the certificate is expired.

When the = certificate expires then revocation is usually removed from CRL and the = revoked certificate can be provided as "good" in OCSP = response.
Is it acceptable? I think not.

According to your new = draft there is not defined a value of revocationTime.
RFC must also = define the value of revocationTime when the certificate which was never = issued is as "revoked".
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pkix-rfc2= 560bis-06

Have you also covered the situation when the = certificate is expired, REMOVED FROM CRL and will be provided as revoked = with incorrect revocationTime e.g.with the value before or after the = revocationTime which was present in the removed record from = CRL?
Because according to sentence in your draft = ""revoked" - This state SHOULD also be returned if the = responder knows that the requested certificate has never been = issued." the following situation can happen: when certificate is = removed from CRL after expiration and CA/OCSP responder is responsible = for this certificate but have not record about expired certificate and = for that reason it is identified as "never been = issued".

...
revoked     [1]     = IMPLICIT RevokedInfo,
...

   RevokedInfo ::=3D = SEQUENCE {
       revocationTime     =          GeneralizedTime,
    =    revocationReason    [0]     EXPLICIT = CRLReason OPTIONAL }

As you have mentioned in the = mail:

"On the "revoked" state, the old spec did not even = consider the case of a certificate being requested where the OCSP = responder knows that the certificate was never issued."

"It simply recommend a known to be bad certificate to result
in = "revoked" in order to prevent damage as far as possible. It = also opens
for definition of new extensions through which such = knowledge could be
obtained."

Peter Rybar
National Security Authority
Information Security and Electronic Signature = Department
Budatinska 30, 850 07 = Bratislava 57, Slovak Republic
e-mail: peter.rybar@nbusr.sk
<= span class=3Dhoenzb>e-mail: peterryb@gmail.com


-----Original Message-----
From: pkix-bounces@ietf.org = [mailto:pkix-bounces@ietf.org] On = Behalf Of Stefan Santesson
Sent: Monday, October 15, 2012 1:49 = AM
To: pkix@ietf.org
Subject: = [pkix] New draft-ietf-pkix-rfc2560bis-06

All,

I have just = posted an update of rfc2560bis (OCSP update) after = carefully
reviewing all comments on the list.

Some notes about = the update:

- Added the previous OCSP editors with updated = affiliations.
- Added some calcifications on ResponderID as suggested = by Simon Josefsson.
- Updated the clarifications on Authorized = responders. The requirements
have not changed. I just tried to = improve the text.
- Updated a clarification on the = "revoked" state to be the preferred
response if a = certificate is known by the responder to never have been
issued.
- = Some minor editorial nits.


Regarding backwards compatibility = I mean that none of the clarifications
changes RFC 2560.

On = Authorized responders it has always been the case that a = responder
certificate issued with the same key as was used to issue = the certificate
being checked for revocation, represents a valid = Authorized responder.
There has never been an explicit requirement to = support key rollover and
key rollover support has never been in the = "spirit" of the original
standard as it clearly attempted = to provide direct cryptographic binding
between the responder and the = CA.

On the "revoked" state, the old spec did not even = consider the case of a
certificate being requested where the OCSP = responder knows that the
certificate was never issued. It is clearly = counterproductive to respond
good when a certificate is known to be = bad. A responder must pick one
response and picking = "revoked" breaks nothing, but has the desired effect,
that = is, to prevent the certificate from being accepted. The current = text
makes clear that there is no mechanism in the current standard = by which a
client can know how a responder will respond to a request = for a not issued
certificate. It simply recommend a known to be bad = certificate to result
in "revoked" in order to prevent = damage as far as possible. It also opens
for definition of new = extensions through which such knowledge could be
obtained.

The = current updates also clearly opens a path for the CAB forum efforts = to
define a suitable solution for server certificates.

I have = not, even thug suggested, added any requirements on what = clients
should do with the checked cert as a result of a particular = response. I
don't believe such requirements are suitable as it is = policy and not
protocol. We have no right to demand that all systems = MUST reject any
certificate for any reason as they may have a local = policy that overrules
the OCSP response. This protocol only provides = information about the cert
status, it does not mandate validation = policy.

I have not included any of the substantial changes i the = Pinkas draft. I
want to wait for a list of motivation for each change = before including any
of them. So there changed may be up for debate = before this draft is ready
for = WGLC.

/Stefan



_____________________________________= __________
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

 

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

------=_NextPart_000_0103_01CDB02F.CDE74650-- From stefan@aaa-sec.com Mon Oct 22 08:58:20 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB0C21F8C0D for ; Mon, 22 Oct 2012 08:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.169 X-Spam-Level: X-Spam-Status: No, score=-101.169 tagged_above=-999 required=5 tests=[AWL=-0.317, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1eLrVraf95Tr for ; Mon, 22 Oct 2012 08:58:02 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id DF19421F8C01 for ; Mon, 22 Oct 2012 08:57:56 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 20DAF17E60 for ; Mon, 22 Oct 2012 17:57:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id IZ0u_IUcJFbH for ; Mon, 22 Oct 2012 17:57:43 +0200 (CEST) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id AFDCC17E6F for ; Mon, 22 Oct 2012 17:57:32 +0200 (CEST) Received: (qmail 88176 invoked from network); 22 Oct 2012 15:57:31 -0000 Received: from 81-232-51-61-no39.business.telia.com (HELO [192.168.0.109]) (stefan@fiddler.nu@[81.232.51.61]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 22 Oct 2012 15:57:31 -0000 User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Mon, 22 Oct 2012 17:57:29 +0200 From: Stefan Santesson To: Piyush Jain , 'Peter Rybar' , 'Carl Wallace' , 'Simon Tardell' Message-ID: Thread-Topic: [pkix] New draft-ietf-pkix-rfc2560bis-06 In-Reply-To: <010201cdb06a$7a37c670$6ea75350$@ditenity.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3433773452_16079534" Cc: 'Peter Rybar' , pkix@ietf.org Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 15:58:21 -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_3433773452_16079534 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable 1-3 =3D issued 4-6 =3Dnot issued Given Peter Rybar's last comment, I'm leaning to my original suggestion to allow "unknown". We agree that this is a poor security measure. If the worlds largest PKI (web pki) decides to forbid the "good" response in situations where the responder knows that it revives a request for a fraudulent certificate, the= n I want to allow them that possibility. The alternative is to force them to break OCSP. I could live with a wording saying that a responder MAY respond "unknown" t= o a request for a known fraudulent (or not never issued) cert if the responde= r possess such knowledge of course.. Note that this does not have to mean that the CA is broken, is may also be due to an error in the request from the client. /Stefan From: Piyush Jain Date: Monday, October 22, 2012 5:32 PM To: Stefan Santesson , 'Peter Rybar' , 'Carl Wallace' , 'Simon Tardell' Cc: 'Peter Rybar' , Subject: RE: [pkix] New draft-ietf-pkix-rfc2560bis-06 > I=B9m sorry but definition of not issued is still unclear to me if you say = that > that a certificate can be cryptographically bound to the CA and still > not-issued. > The ambiguity is introduced because now I can do everything that 5280 ask= s me > to validate a certificate and still cannot be sure if the certificate was= ever > issued. > =20 > Here are the scenarios where meaning of not issued is unclear to me. > 1) A genuine certificate issued by the CA, present in the CA databas= e >=20 > 2) A genuine certificate issued by the CA, removed from the CA datab= ase > by the CA >=20 > 3) A genuine certificate issued by the CA, removed from the CA datab= ase > by an attacker >=20 > 4) A fraudulent certificate issued by an attacker, present in the CA > database >=20 > 5) A fraudulent certificate issued by an attacker, removed from the = CA > database >=20 > 6) A fraudulent certificate containing an AIA pointing to a fraudule= nt > OCSP responder (also cryptographically bound to the CA), issued by an > attacker, removed from the CA database. >=20 > =20 > If the CA can differentiate among these cases, it can mark the fraudulent > certificates as revoked and we won=B9t need an overloaded definition of > not-issued. Also not that if an attacker can carry out =8C4=B9 it can also ca= rry > out =8C5=B9 and =8C6=B9 > =20 > The people who are convinced that this is the way to go have not addresse= d the > issues raised in this WG. The little extension does not hurt anyone but i= t > does not provide any value in general except to a few implementations whi= ch > are compromised. But it does take you down a slippery slope when you star= t > promising that an OCSP responder can do much more than it is supposed to. > I don=B9t think that it is unreasonable for a smart implementer to stop > signature checking if his responder claims that it checks issuance. > =20 > As for the diginotor case, for some people who say that security breach > could=B9ve been detected early if this practice was in place, there is anot= her > set of people who believe that attacker could=B9ve circumvented these measu= res > quite easily with the kind of access he had. > =20 > If you and other folks in the group feel that this text should be added, = I > think at the minimum we also need to do the following > - Provide explicit guidance on what the revocation time should b= e. > Such certificates are different from =8Cnormal=B9 revoked certificate and the= ir > revocation time should probably be set to something before the validity o= f > issuing CA. This distinction is important for time based validations and = long > term archiving applications >=20 > - I think it will be useful to indicate in the security > considerations section, that in such a scenario, CA is compromised and th= at > there is a high chance that RP is interacting with a compromised responde= r. >=20 > =20 > =20 >=20 > From: Stefan Santesson [mailto:stefan@aaa-sec.com] > Sent: Sunday, October 21, 2012 11:03 AM > To: Piyush Jain; 'Peter Rybar'; 'Carl Wallace'; 'Simon Tardell' > Cc: 'Peter Rybar'; pkix@ietf.org > Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 > =20 >=20 > In line; >=20 > =20 >=20 > From: Piyush Jain > Date: Sunday, October 21, 2012 7:42 PM > To: Stefan Santesson , 'Peter Rybar' = , > 'Carl Wallace' , 'Simon Tardell' > Cc: 'Peter Rybar' , > Subject: RE: [pkix] New draft-ietf-pkix-rfc2560bis-06 >=20 > =20 >>=20 >> So what is =B3not-issued=B2 - not signed by the CA or not present in CA data= base? >=20 > =20 >=20 > Not issued means it has never been issued. What's unclear about that? >=20 > =20 >=20 > Of course it is not present in the database if it is not issued. >=20 > If you delete things from your database and don't know if this one has be= en > deleted, then you don't know that it has never been issued and can't repl= y > revoked. >=20 > =20 >=20 > =20 >>=20 >> It is unclear to folks who have been using signature verification as a w= ay to >> check issuance. Isn=B9t it a fair conclusion that I do not need to perform >> signature checks if the responder can check issuance for me? >=20 > =20 >=20 > No that is not a fair conclusion. These are entirely different things. >=20 > =20 >>=20 >> =20 >> You said that the possibility to send revoked reply only applies when th= e >> responder =B9knows=B9 that requested certificate has never been issued. >> Please note that the responder will encounter this kind of request only = in >> two situations. First in which the RP sends a request for a certificate >> without checking the signature and second in which the responder itself = is >> compromised by virtue of its issuing authority being compromised. In eit= her >> case what the responder responds with does not matter. >> =20 >=20 > =20 >=20 > Some people are pretty convinced it does (from CAB forum), they are so > convinced that they are prepared to break compatibility with OCSP. By thi= s > little extension that hurst no-one, they don't have to. >=20 > =20 >>=20 >> I=B9ve no problem with your proposal to respond with =8Crevoked=B9 in this >> situation. >=20 > =20 >=20 > Good. >=20 > =20 >>=20 >> I=B9ve fundamental problem with the introduction of =8Cnon-issued=B9 concept i= n >> OCSP, which seems to provide additional security in this exceptional sce= nario >> without actually providing any. >=20 > =20 >=20 > It provides some, but not much. People keep coming back to that fact that= if > this had been the practice of Diginotar, the security breach would have b= een > discovered a lot earlier. So there might be some gain with no pain. >=20 > =20 >=20 > However, in combination with an extension that adds information, this mig= ht > actually be increasingly valuable. >=20 > If an OCSP responder starts receiving status requests for certs it knows = it > has not issued, it can actually give explicit information about this usin= g an > extension and it can take adequate measures. >=20 > But in order to respond to the user, it need to pick one of the responses= . > Either good + extension or revoked+extension. >=20 > =20 >=20 > This proposal is not meant to require any OCSP responder to deal with the > concept of "non-issued" certs. It merely allows an OCSP responder to resp= ond > to such request. >=20 > =20 >>=20 >> =20 >> It=B9ll be very helpful if I can see at least one practical scenario where= this >> additional text would add value. >=20 > =20 >=20 > Stated in my previous comments. >=20 > =20 >=20 > /Stefan >=20 > =20 >>=20 >> =20 >> -Piyush >>=20 >> From: Stefan Santesson [mailto:stefan@aaa-sec.com] >> Sent: Sunday, October 21, 2012 8:52 AM >> To: Piyush Jain; 'Peter Rybar'; 'Carl Wallace'; 'Simon Tardell' >> Cc: 'Peter Rybar'; pkix@ietf.org >> Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 >> =20 >>=20 >> I don't think the "not issued" is unclear. >>=20 >> =20 >>=20 >> The possibility to send a revoked reply only applies then the responder >> "knows" that the requested certificate has never been issued. >>=20 >> How the responder knows this is totally irrelevant, but unless the respo= nder >> knows this, it can't choose this option and has to reply "good". >>=20 >> =20 >>=20 >> It does not make revocation checking non-deterministric. >>=20 >> "good" still means what is declared in the standard (The cert is not kno= wn to >> be revoked, but it may never have been issued). >>=20 >> "revoked" still have a deterministic meaning, that is, don't trust this = cert. >> The old exact semantics was "the cert IS revoked". The new semantic is "= the >> cert is revoked or possibly might never been issued" >>=20 >> =20 >>=20 >> The new response semantic of revoked is backwards compatible and not les= s >> deterministic than the good, response. >>=20 >> =20 >>=20 >> So, I still don't see any practical problems here. >>=20 >> =20 >>=20 >> /Stefan >>=20 >> =20 >>=20 >> =20 >>=20 >> From: Piyush Jain >> Date: Saturday, October 20, 2012 5:48 PM >> To: Stefan Santesson , 'Peter Rybar' , >> 'Carl Wallace' , 'Simon Tardell' >> >> Cc: 'Peter Rybar' , >> Subject: RE: [pkix] New draft-ietf-pkix-rfc2560bis-06 >>=20 >> =20 >>>=20 >>> Please see inline >>> =20 >>>=20 >>> From: Stefan Santesson [mailto:stefan@aaa-sec.com] >>> Sent: Friday, October 19, 2012 7:23 PM >>> To: Piyush Jain; 'Peter Rybar'; 'Carl Wallace'; 'Simon Tardell' >>> Cc: 'Peter Rybar'; pkix@ietf.org >>> Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 >>> =20 >>>=20 >>> I'm sorry. I fail to the any of the problems you raise. >>>=20 >>> =20 >>>=20 >>> If you receive a request for a certificate that you know has never been >>> issued, and you choose to reply revoked, what problems can you cause? >>>=20 >>> [Piyush] It depends on how you define =B3never been issued=B2, which btw be= comes >>> unclear after introduction of the new text. There are two interpretatio= ns >>> 1) Certificate is not signed by the CA or >>>=20 >>> 2) Certificate is not present in the database of issued certificat= es >>> that CA maintains. >>>=20 >>> One unintended consequence of first interpretation will be that RPs wou= ld >>> stop performing signature checks if their responder/CA publicizes that = it >>> returns revoked for =B3non-issued=B2 certificates. >>> If the interpretation is 2, then this scenario is not possible unless t= he CA >>> is compromised. >>> =20 >>> What in your mind is a more appropriate response? >>> [Piyush] I would say the appropriate response is good (if the certifica= te is >>> not marked as revoked), because that is what the RP will see if it cons= ults >>> a CRL or a responder detached from the CA. >>> Revoked for =B3not issued=B2 adds no value because the only case in which a= n RP >>> would send a query for a =B3non-issued=B2 certificate is when the CA is >>> compromised. >>>=20 >>> =20 >>>=20 >>> It does not make OCSP more non-deterministic. If you ask status for an >>> issued cert from a non-broken CA, nothing is non-deterministic. >>> [Piyush] It does not make OCSP non-deterministic but it makes revocatio= n >>> checking non-deterministic. The goal of OCSP is to address operational >>> limitations of CRLs, not functional limitations. The fact that you=B9ll = get >>> different answers from two sources, both of which are authorized by the= same >>> CA makes revocation checking non deterministic. >>> =20 >>>=20 >>> If you ask for status for a non-issued certificate, or a bad certificat= e >>> from a broken CA, then the result is by default non-deteministic and ha= s >>> always been. However, choosing a revoked response may save the relying >>> party, at best, but can hurt no-one >>> [Piyush] I agree that a revoke response does not hurt anyone. But the p= oint >>> is that it provides a false sense of additional security to the RP with= out >>> providing any. As an RP, I won=B9t trust what my responder says if the >>> authority that certified it is compromised. >>> =20 >>>=20 >>> What is your problem on the practical ground. >>>=20 >>> [Piyush] Let=B9s say that we still need to address this scenario and rev= oked >>> is the appropriate response. In that case >>> - The text needs to be explicit about the revocation time in t= his >>> situation. Revoked implies good until a certain date and this distincti= on is >>> important for long term archiving applications. For unissued certificat= e the >>> revocation time should probably be set to =ADinfinity. >>>=20 >>> - It needs to call out that in this particular scenario it is >>> addressing a functional limitation of CRLs (ability to detect CA compro= mise) >>> not an operational limitation. >>>=20 >>> - I think we need additional text in security considerations t= o >>> indicate that RP is communicating with a responder certified by a >>> compromised CA in this scenario. >>>=20 >>> =20 >>> =20 >>>=20 >>> /Stefan >>>=20 >>> =20 >>>=20 >>> From: Piyush Jain >>> Date: Friday, October 19, 2012 7:34 PM >>> To: Stefan Santesson , 'Peter Rybar' , >>> 'Carl Wallace' , 'Simon Tardell' >>> >>> Cc: 'Peter Rybar' , >>> Subject: RE: [pkix] New draft-ietf-pkix-rfc2560bis-06 >>>=20 >>> =20 >>>>=20 >>>> Stefan, >>>> =20 >>>> I think some of you interpretations below are twisted to accommodate t= he >>>> new provisions for providing revoked responses for unissued certificat= es. >>>> Providing responses for expired certificates is within the scope of 25= 60 >>>> using archive cutoff extension. >>>> =20 >>>> The original authors of 2560 can correct me if I=B9m wrong, but it is my >>>> understanding that a response from OCSP responder is not supposed to >>>> indicate if a certificate is good or bad but to indicate if a certific= ate >>>> is revoked or unrevoked by the issuing authority. The fact that certif= icate >>>> is issued by the CA is checked by the RP by verifying the signature on= the >>>> certificate. >>>> =20 >>>> This draft introduces the concept of returning revoked responses for >>>> unissued certificates. There are many unintended consequences of this >>>> approach >>>> - Revocation statuses become non-deterministic based on who y= ou >>>> are asking (A responder with access to CA database vs. one without vs. >>>> checking status off a CRL). If I=B9m archiving a signed document with th= e >>>> relevant artifacts to determine the validity status of the document, t= his >>>> becomes a huge problem. Note that a revoked status implies that certif= icate >>>> was good between the time of its issuance and that of its revocation. = Any >>>> document that is signed within that period should still be considered >>>> valid. >>>>=20 >>>> - It would confuse an implementer about what =B3non-issued=B2 mea= ns. >>>> The fact that the CA signed the certificate implies it was issued. If = a >>>> certificate is issued fraudulently, based on its security practices, i= t is >>>> up to the CA to either revoke the issued certificate, or ask its issui= ng >>>> authority to revoke its own certificate. >>>>=20 >>>> =20 >>>> -Piyush >>>> =20 >>>> =20 >>>> =20 >>>> =20 >>>>=20 >>>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf O= f >>>> Stefan Santesson >>>> Sent: Friday, October 19, 2012 7:25 AM >>>> To: Peter Rybar; 'Carl Wallace'; 'Simon Tardell' >>>> Cc: 'Peter Rybar'; pkix@ietf.org >>>> Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 >>>> =20 >>>>=20 >>>> Peter, >>>>=20 >>>> =20 >>>>=20 >>>> An OCSP responder is by default a service providing information about >>>> current certificates. >>>>=20 >>>> The default response you get from an OCSP responder is "good" unless t= he >>>> cert is known to be bad or not a cert the responder can provide status= for. >>>>=20 >>>> =20 >>>>=20 >>>> If you need it to respond about old certificates, and as a client know= that >>>> the responder does this in a way that suits your needs, you will need = to >>>> add an extension. >>>>=20 >>>> Such extension will not be part of the rfc256bis effort. >>>>=20 >>>> =20 >>>>=20 >>>> Is there any text in the current draft that you think is unclear on th= is? >>>>=20 >>>> =20 >>>>=20 >>>> /Stefan >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> From: Peter Rybar >>>> Date: Friday, October 19, 2012 3:12 PM >>>> To: 'Carl Wallace' , 'Simon Tardell' >>>> >>>> Cc: 'Peter Rybar' , Stefan Santesson >>>> , >>>> Subject: RE: [pkix] New draft-ietf-pkix-rfc2560bis-06 >>>>=20 >>>> =20 >>>>>=20 >>>>>> Well, yes, sort of. You can only be sure to validate a signature at = the >>>>>> moment of production. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> What if the signature key was compromised at the moment of production= but >>>>> is not yet on a revocation list? >>>>> [PR] According to clause 2.4 - thisUpdate: The time at which the st= atus >>>>> being indicated is known to be correct >>>>> It means when signature time-stamp time is X then any OCSP responses = with >>>>> thisUpdate time X+y are sufficient to validate because the status is >>>>> correct.=20 >>>>> Y is in the interval <0, producedAt - X> >>>>>=20 >>>>> =20 >>>>>> At any later point in time the signature key may be compromised, or = the >>>>>> algorithms involved may have become to weak. (In which case the time= of >>>>>> revocation in the OCSP response is worth nothing to you). The risk >>>>>> increases as time passes. And of course, the revocation information = may >>>>>> not be kept around after the expiry of the certificate. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> That's why you should validate signatures as soon as possible. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> For these archival purposes wouldn't it be better to have the final >>>>> revocation list before removed due to expiry? In any case, you'd nee= d >>>>> verification information collected after some grace period following >>>>> moment of production. >>>>>=20 >>>>> [PR] Grace period is not a fixed value of the time interval. >>>>> Grace period is changeable because the first OCSP response with thisU= pdate >>>>> time value > than time of signature time-stamp contains correct statu= s. >>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> If you need to ascertain that a signature was valid at a later time,= you >>>>>> have to trust your system that it performed the validation at the ti= me it >>>>>> first received the signature. That trust must be established through= some >>>>>> kind of mix of policies and technical measures (such as timestamping= ). >>>>>=20 >>>>> =20 >>>>>=20 >>>>> In the dark corner just beyond the dark corner that is SCVP, there's = a >>>>> spec (RFC 5276) that defines a binding of evidence records to artifac= ts >>>>> that can be returned viaSCVP. This provides for timestamping. >>>>> [PR] The validation is simplified when OCSP response with positive >>>>> statement as a hash value of requested certificate is used. >>>>> Positive statement is evidence that OCSP know the status of certifica= te >>>>> and also protect the integrity of certificate with a new more secure = hash >>>>> algorithm. >>>>>=20 >>>>> =20 >>>>> Peter Rybar >>>>> =20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Simon Tardell, >>>>>>=20 >>>>>> Technology Nexus. >>>>>>=20 >>>>>> On Fri, Oct 19, 2012 at 1:07 PM, Peter Rybar wrote: >>>>>> Stefan, >>>>>>=20 >>>>>> I have a question about the present OCSP RFC and at the end of the m= ail >>>>>> about the new situation which will happen according to your new prop= osal. >>>>>>=20 >>>>>> The presence of the positive statement in OCSP response is important= for >>>>>> electronic signature validations, especially for an expired certific= ate. >>>>>> Positive statement is the hash value of a certificate whose status i= s >>>>>> provided in OCSP response. >>>>>>=20 >>>>>> Electronic signature validation is usually about the signatures crea= ted >>>>>> in the past and validated now, when the certificate is expired. >>>>>>=20 >>>>>> When the certificate expires then revocation is usually removed from= CRL >>>>>> and the revoked certificate can be provided as "good" in OCSP respon= se. >>>>>> Is it acceptable? I think not. >>>>>>=20 >>>>>> According to your new draft there is not defined a value of >>>>>> revocationTime. >>>>>> RFC must also define the value of revocationTime when the certificat= e >>>>>> which was never issued is as "revoked". >>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pkix-rfc2560bis-06 >>>>>>=20 >>>>>> Have you also covered the situation when the certificate is expired, >>>>>> REMOVED FROM CRL and will be provided as revoked with incorrect >>>>>> revocationTime e.g.with the value before or after the revocationTime >>>>>> which was present in the removed record from CRL? >>>>>> Because according to sentence in your draft ""revoked" - This state >>>>>> SHOULD also be returned if the responder knows that the requested >>>>>> certificate has never been issued." the following situation can happ= en: >>>>>> when certificate is removed from CRL after expiration and CA/OCSP >>>>>> responder is responsible for this certificate but have not record ab= out >>>>>> expired certificate and for that reason it is identified as "never b= een >>>>>> issued". >>>>>>=20 >>>>>> ... >>>>>> revoked [1] IMPLICIT RevokedInfo, >>>>>> ... >>>>>>=20 >>>>>> RevokedInfo ::=3D SEQUENCE { >>>>>> revocationTime GeneralizedTime, >>>>>> revocationReason [0] EXPLICIT CRLReason OPTIONAL } >>>>>>=20 >>>>>> As you have mentioned in the mail: >>>>>>=20 >>>>>> "On the "revoked" state, the old spec did not even consider the case= of a >>>>>> certificate being requested where the OCSP responder knows that the >>>>>> certificate was never issued." >>>>>>=20 >>>>>> "It simply recommend a known to be bad certificate to result >>>>>> in "revoked" in order to prevent damage as far as possible. It also = opens >>>>>> for definition of new extensions through which such knowledge could = be >>>>>> obtained." >>>>>> Peter Rybar >>>>>> National Security Authority >>>>>> Information Security and Electronic Signature Department >>>>>> Budatinska 30, 850 07 Bratislava 57, Slovak Republic >>>>>> e-mail: peter.rybar@nbusr.sk >>>>>> e-mail: peterryb@gmail.com >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf= Of >>>>>> Stefan Santesson >>>>>> Sent: Monday, October 15, 2012 1:49 AM >>>>>> To: pkix@ietf.org >>>>>> Subject: [pkix] New draft-ietf-pkix-rfc2560bis-06 >>>>>>=20 >>>>>> All, >>>>>>=20 >>>>>> I have just posted an update of rfc2560bis (OCSP update) after caref= ully >>>>>> reviewing all comments on the list. >>>>>>=20 >>>>>> Some notes about the update: >>>>>>=20 >>>>>> - Added the previous OCSP editors with updated affiliations. >>>>>> - Added some calcifications on ResponderID as suggested by Simon >>>>>> Josefsson. >>>>>> - Updated the clarifications on Authorized responders. The requireme= nts >>>>>> have not changed. I just tried to improve the text. >>>>>> - Updated a clarification on the "revoked" state to be the preferred >>>>>> response if a certificate is known by the responder to never have be= en >>>>>> issued. >>>>>> - Some minor editorial nits. >>>>>>=20 >>>>>>=20 >>>>>> Regarding backwards compatibility I mean that none of the clarificat= ions >>>>>> changes RFC 2560. >>>>>>=20 >>>>>> On Authorized responders it has always been the case that a responde= r >>>>>> certificate issued with the same key as was used to issue the certif= icate >>>>>> being checked for revocation, represents a valid Authorized responde= r. >>>>>> There has never been an explicit requirement to support key rollover= and >>>>>> key rollover support has never been in the "spirit" of the original >>>>>> standard as it clearly attempted to provide direct cryptographic bin= ding >>>>>> between the responder and the CA. >>>>>>=20 >>>>>> On the "revoked" state, the old spec did not even consider the case = of a >>>>>> certificate being requested where the OCSP responder knows that the >>>>>> certificate was never issued. It is clearly counterproductive to res= pond >>>>>> good when a certificate is known to be bad. A responder must pick on= e >>>>>> response and picking "revoked" breaks nothing, but has the desired >>>>>> effect, >>>>>> that is, to prevent the certificate from being accepted. The current= text >>>>>> makes clear that there is no mechanism in the current standard by wh= ich a >>>>>> client can know how a responder will respond to a request for a not >>>>>> issued >>>>>> certificate. It simply recommend a known to be bad certificate to re= sult >>>>>> in "revoked" in order to prevent damage as far as possible. It also = opens >>>>>> for definition of new extensions through which such knowledge could = be >>>>>> obtained. >>>>>>=20 >>>>>> The current updates also clearly opens a path for the CAB forum effo= rts >>>>>> to >>>>>> define a suitable solution for server certificates. >>>>>>=20 >>>>>> I have not, even thug suggested, added any requirements on what clie= nts >>>>>> should do with the checked cert as a result of a particular response= . I >>>>>> don't believe such requirements are suitable as it is policy and not >>>>>> protocol. We have no right to demand that all systems MUST reject an= y >>>>>> certificate for any reason as they may have a local policy that over= rules >>>>>> the OCSP response. This protocol only provides information about the= cert >>>>>> status, it does not mandate validation policy. >>>>>>=20 >>>>>> I have not included any of the substantial changes i the Pinkas draf= t. I >>>>>> want to wait for a list of motivation for each change before includi= ng >>>>>> any >>>>>> of them. So there changed may be up for debate before this draft is = ready >>>>>> for WGLC. >>>>>>=20 >>>>>> /Stefan >>>>>>=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 --B_3433773452_16079534 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
1-3 =3D issued
4-6 =3D= not issued

Given Peter Rybar's last comment, I'm le= aning to my original suggestion to allow "unknown".

We agree that this is a poor security measure. If the worlds largest PKI (w= eb pki) decides to forbid the "good" response in situations where the respon= der knows that it revives a request for a fraudulent certificate, then I wan= t to allow them that possibility.

The alternative i= s to force them to break OCSP.

I could live with a = wording saying that a responder MAY respond "unknown" to a request for a kno= wn fraudulent (or not never issued) cert if the responder possess such knowl= edge of course..
Note that this does not have to mean that the CA = is broken, is may also be due to an error in the request from the client.

/Stefan


From: Piyush Jain <piyush@ditenity.com>
Date:= Monday, October 22, 2012 5:32 PM
= To: Stefan Santesson <stefan@= aaa-sec.com>, 'Peter Rybar' <rybar= @nbusr.sk>, 'Carl Wallace' <carl@redhoundsoftware.com>, 'Simon Tardell' <simon@tardell.se>
Cc: 'Peter Rybar' <peterryb@= gmail.com>, <pkix@ietf.org><= br>Subject: RE: [pkix] New draft-ietf= -pkix-rfc2560bis-06

I’m so= rry but definition of not issued is still unclear to me if you say that that= a certificate can be cryptographically bound to the CA and still not-issued= .

The ambiguity is = introduced because now I can do everything that 5280 asks me to validate a c= ertificate and still cannot be sure if the certificate was ever issued.=

 

Here are the scenarios where meanin= g of not issued is unclear to me.

1)   =    A genuine cer= tificate issued by the CA, present in the CA database

<= p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l1 level1 lfo7= ">2)A genuine certificate issued by the CA, removed from the CA database = by the CA

3)      A genuine certificate issued by the C= A, removed from the CA database by an attacker

4)=  = ;     = A fraudulent certificate issued by an attacker, present in the CA database

5)      <= !--[endif]-->A fraudulent certificate issued by an attacker, = removed from the CA database

A fraudulent certi= ficate containing an AIA pointing to a fraudulent OCSP responder (also crypt= ographically bound to the CA), issued by an attacker, removed from the CA da= tabase.

 =

If the CA can different= iate among these cases, it can mark the fraudulent certificates as revoked a= nd we won’t need an overloaded definition of not-issued. Also not that= if an attacker can carry out ‘4’ it can also carry out ‘5= ’ and ‘6’

 

The= people who are convinced that this is the way to go have not addressed the = issues raised in this WG. The little extension does not hurt anyone but it d= oes not provide any value in general except to a few implementations which a= re compromised. But it does take you down a slippery slope when you start pr= omising that an OCSP responder can do much more than it is supposed to.=

I don’t think tha= t it is unreasonable for a smart implementer to stop signature checking if h= is responder claims that it checks issuance.

 

= As for the diginotor case, for some people who say that secur= ity breach could’ve been detected early if this practice was in place,= there is another set of people who believe that attacker could’ve cir= cumvented these measures quite easily with the kind of access he had.

 <= /p>

If you and other folks in the group f= eel that this text should be added, I think at the minimum we also need to d= o the following

-      &= nbsp;   Provide = explicit guidance on what the revocation time should be. Such certificates a= re different from ‘normal’ revoked certificate and their revocat= ion time should probably be set to something before the validity of issuing = CA. This distinction is important for time based validations and long term a= rchiving applications

-     &= nbsp;    I = think it will be useful to indicate in the security considerations section, = that in such a scenario, CA is compromised and that there is a high chance t= hat RP is interacting with a compromised responder.

 

 

From: Stefan Santesson [mailto:stefan@a= aa-sec.com]
Sent: Sunday, October 21, 2012 11:03 AM
To:= Piyush Jain; 'Peter Rybar'; 'Carl Wallace'; 'Simon Tardell'
Cc: 'Peter Rybar'; pkix@ietf.org
Sub= ject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06

=

 

In line;

From: = Piyush Jain <piyush@d= itenity.com>
Date: Sunday, October 21, 2012 7:42 PM
T= o: Stefan Santesson <stefan@aaa-s= ec.com>, 'Peter Rybar' <rybar@nbus= r.sk>, 'Carl Wallace' <= carl@redhoundsoftware.com>, 'Simon Tardell' <simon@tardell.se>
Cc: 'Peter Rybar' <peterryb@gmail.com>, <pkix@ietf.org>
Subject: RE: [pkix] New dra= ft-ietf-pkix-rfc2560bis-06

 

So what is “not-issued” - not signed= by the CA or not present in CA database?

 

Not issue= d means it has never been issued. What's unclear about that?

 

Of course it is not present in the databas= e if it is not issued.

= If you delete things from your database and don't know if this one has= been deleted, then you don't know that it has never been issued and can't r= eply revoked.

 

 

It is unclear to folks who have been using signature verification as a = way to check issuance. Isn’t it a fair conclusion that I do not need t= o perform signature checks if the responder can check issuance for me?

 

No that is not a fair conclusion. These are entirely dif= ferent things.

 

 

You said that the possibility to send r= evoked reply only applies when the responder ’knows’ that reques= ted certificate has never been issued.

Please note that the r= esponder will encounter this kind of request only in two situations. First i= n which the RP sends a request for a certificate without checking the signat= ure and second in which the responder itself is compromised by virtue of its= issuing authority being compromised. In either case what the responder resp= onds with does not matter.

 

 

Som= e people are pretty convinced it does (from CAB forum), they are so convince= d that they are prepared to break compatibility with OCSP. By this little ex= tension that hurst no-one, they don't have to.

 

I’ve no problem with y= our proposal to respond with ‘revoked’ in this situation.=

 

Good.

 

I’ve fundamental problem with the introducti= on of ‘non-issued’ concept in OCSP, which seems to provide addit= ional security in this exceptional scenario without actually providing any.<= /span>

 

It provides some, but not much. People keep coming = back to that fact that if this had been the practice of Diginotar, the secur= ity breach would have been discovered a lot earlier. So there might be some = gain with no pain.

However,= in combination with an extension that adds information, this might actually= be increasingly valuable.

If an OCSP responder starts receiving status requests for certs it= knows it has not issued, it can actually give explicit information about th= is using an extension and it can take adequate measures.

But in order to respond to the user,= it need to pick one of the responses. Either good + extension or revoked+ex= tension.

&nb= sp;

This proposal is n= ot meant to require any OCSP responder to deal with the concept of "non-issu= ed" certs. It merely allows an OCSP responder to respond to such request.

 

&= nbsp;

It’ll be very helpful if I can see at least one pr= actical scenario where this additional text would add value.

 

Stated in my previous comments.

 

/Stefan

=  

 

-Piyush

Fro= m: Stefan Santesson [mailt= o:stefan@aaa-sec.com]
Sent: Sunday, October 21, 2012 8:52 AM<= br>To: Piyush Jain; 'Peter Rybar'; 'Carl Wallace'; 'Simon Tardell'Cc: 'Peter Rybar'; pkix@ietf.org<= br>Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06

<= span style=3D"color:black"> 

I don't think the "not issued" is unclear.

 

The possibility to send a revoked reply only applies then the= responder "knows" that the requested certificate has never been issued.

How the responder knows this is totally irrelevant, but unless = the responder knows this, it can't choose this option and has to reply "good= ".

 =

It does not make revocation checki= ng non-deterministric. 

"good" still means what is decl= ared in the standard (The cert is not known to be revoked, but it may never = have been issued).

"revoked" still have a deterministic mean= ing, that is, don't trust this cert. The old exact semantics was "the cert I= S revoked". The new semantic is "the cert is revoked or possibly might never= been issued"

 

The new response semant= ic of revoked is backwards compatible and not less deterministic than the go= od, response.

 

So, I still don't see a= ny practical problems here.

 

/Stefan

 

=

 

From: = Piyush Jain <piyush@ditenity= .com>
Date: Saturday, October 20, 2012 5:48 PM
To: Stefan Santesson <stefan@aaa-sec.co= m>, 'Peter Rybar' <rybar@nbusr.sk<= /a>>, 'Carl Wallace' <carl@= redhoundsoftware.com>, 'Simon Tardell' <simon@tardell.se>
Cc: 'Peter Rybar' <peterryb@gmail.com>, <pkix@ietf.org>
Subject: RE: [pkix] New draft-ie= tf-pkix-rfc2560bis-06

=

 

Please see inline

 

=

From: Stefan Santesson [mailto:stefan@aaa-sec.com]
Sent: Friday, October 19, 2012 7:23 PM
To: Piyush Jain; 'Peter Rybar'= ; 'Carl Wallace'; 'Simon Tardell'
Cc: 'Peter Rybar'; pkix@ietf.org
Subject: Re: [pkix] New draft-= ietf-pkix-rfc2560bis-06

 

I'm sorry. I fail to the any of= the problems you raise.<= /p>

 

If you recei= ve a request for a certificate that you know has never been issued, and you = choose to reply revoked, what problems can you cause?

[Piyush] It depends on how you define “never been issued̶= 1;, which btw becomes unclear after introduction of the new text. There are = two interpretations

1) &nbs= p;    Certificate is not signed by the CA or

2)      = Certificate is not present in the database of issued ce= rtificates that CA maintains.<= /o:p>

One unintended con= sequence of first interpretation will be that RPs would stop performing sign= ature checks if their responder/CA publicizes that it returns revoked for &#= 8220;non-issued” certificates.

If the inte= rpretation is 2, then this scenario is not possible unless the CA is comprom= ised.

 

What in your mind is a more approp= riate response?

[Piyush] I would say the appropriate res= ponse is good (if the certificate is not marked as revoked), because that is= what the RP will see if it consults a CRL or a responder detached from the = CA.

Revoked for “not issued” adds n= o value because the only case in which an RP would send a query for a “= ;non-issued” certificate is when the CA is compromised.=

 

It does not make OCSP more non-deterministi= c. If you ask status for an issued cert from a non-broken CA, nothing is non= -deterministic.

[Piyush] It does not make OCSP non-deter= ministic but it makes revocation checking non-deterministic. The goal of OCS= P is to address operational limitations of CRLs, not functional limitations.=   The fact that you’ll get different answers from two sources, bo= th of which are authorized by the same CA makes revocation checking non dete= rministic.

 

If you ask for stat= us for a non-issued certificate, or a bad certificate from a broken CA, then= the result is by default non-deteministic and has always been. However, cho= osing a revoked response may save the relying party, at best, but can hurt n= o-one

[Piyush] I agree that a revoke response does not h= urt anyone. But the point is that it provides a false sense of additional se= curity to the RP without providing any. As an RP, I won’t trust what m= y responder says if the authority that certified it is compromised.

<= span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31= , 73, 125); "> 

<= /div>

What is your problem on the practical g= round.

[Piyush]  Let’s say that we still need to address this scenario and r= evoked is the appropriate response. In that case

-          The text needs to be explicit about= the revocation time in this situation. Revoked implies good until a certain= date and this distinction is important for long term archiving applications= . For unissued certificate the revocation time should probably be set to = 211;infinity.

-    &= nbsp;     It needs to call out that in this particular scenario it is addressing= a functional limitation of CRLs (ability to detect CA compromise) not an op= erational limitation.

=

-   = ;       I think we need additional text in security considerations to = indicate that RP is communicating with a responder certified by a compromise= d CA in this scenario.

 

 <= span style=3D"color:black">

/Stefan

 

From: <= span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: black;= ">Piyush Jain <piyush@ditenity.com<= /a>>
Date: Friday, October 19, 2012 7:34 PM
To: Stefa= n Santesson <stefan@aaa-sec.com&g= t;, 'Peter Rybar' <rybar@nbusr.sk>= , 'Carl Wallace' <carl@redhoun= dsoftware.com>, 'Simon Tardell' <simon@tardell.se>
Cc: 'Peter Rybar' <peterryb@gmail.com>, <pkix@ietf.org>
Subject: RE: [pkix] New draft-ietf-pkix= -rfc2560bis-06

<= div>

 <= /o:p>

Stefan,

 

I think some of you interpretations below are twisted to accommoda= te the new provisions for providing revoked responses for unissued certifica= tes.

Providing responses for expired certificates is within th= e scope of 2560 using archive cutoff extension.

 <= span style=3D"color:black">

The original authors of 2560 can correct me if I’m wrong, but i= t is my understanding that a response from OCSP responder is not supposed to= indicate if a certificate is good or bad but to indicate if a certificate i= s revoked or unrevoked by the issuing authority. The fact that certificate i= s issued by the CA is checked by the RP by verifying the signature on the ce= rtificate.

 <= /span>

This draft introduces the conc= ept of returning revoked responses for unissued certificates. There are many= unintended consequences of this approach

-Revocation statuses become non-deterministic= based on who you are asking (A responder with access to CA database vs. one= without vs. checking status off a CRL). If I’m archiving a signed doc= ument with the relevant artifacts to determine the validity status of the do= cument, this becomes a huge problem. Note that a revoked status implies that= certificate was good between the time of its issuance and that of its revoc= ation. Any document that is signed within that period should still be consid= ered valid.

-    &nb= sp;    

 

-Piyush=

=  

=

 <= o:p>

 

From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Stefan Santesson
= Sent: Friday, October 19, 2012 7:25 AM
To: Peter Rybar; 'Ca= rl Wallace'; 'Simon Tardell'
Cc: 'Peter Rybar'; pkix@ietf.org
Subject: Re: [pkix] New draft-ietf-= pkix-rfc2560bis-06

 

Peter,

 =

An OCSP responder is by default a service providing information ab= out current certificates.=

The default response you get from = an OCSP responder is "good" unless the cert is known to be bad or not a cert= the responder can provide status for.=

 

Such extension will not be part of the rfc2= 56bis effort.

 

Is there any text in th= e current draft that you think is unclear on this?

 

/Stefan

=

 

 

From: Peter Rybar <rybar@nbusr.sk>
Date: Friday, October 19, 2012 3:12 PMTo: 'Carl Wallace' <c= arl@redhoundsoftware.com>, 'Simon Tardell' <simon@tardell.se>
Cc: 'Peter Rybar' <peterryb@gmail.com>, Stefan Santesson &l= t;stefan@aaa-sec.com>, <pkix@ietf.org>
Subject: RE: [pkix]= New draft-ietf-pkix-rfc2560bis-06

 

Well, yes, = sort of. You can only be sure to validate a signature at the moment of produ= ction.

<= div>

 <= /o:p>

What if the signature = key was compromised at the moment of production but is not yet on a revocati= on list?

[PR] According to clause 2.4  -  thisUpdate: The time at = which the status being indicated is known to be correct

It means when signat= ure time-stamp time is X then any OCSP responses with thisUpdate time X+y ar= e sufficient to validate because the status is correct.

Y is in the interva= l <0, producedAt - X>

 

At any later point in time the signatur= e key may be compromised, or the algorithms involved may have become to weak= . (In which case the time of revocation in the OCSP response is worth nothin= g to you). The risk increases as time passes. And of course, the revocation = information may not be kept around after the expiry of the certificate. = ;

 

That's why you should validate signatures= as soon as possible. 

 

For these archival purposes wouldn't it be better to have the final revo= cation list before removed due to expiry?  In any case, you'd need veri= fication information collected after some grace period following moment of p= roduction.

=

[PR] Grace period is not a fixed value of the time int= erval.

Grace period is changeable because the first OCSP response with this= Update time value > than time of signature time-stamp contains correct st= atus.

 

 

=

If you need to ascertain that a signature wa= s valid at a later time, you have to trust your system that it performed the= validation at the time it first received the signature. That trust must be = established through some kind of mix of policies and technical measures (suc= h as timestamping).

 

In t= he dark corner just beyond the dark corner that is SCVP, there's a spec (RFC= 5276) that defines a binding of evidence records to artifacts that can be r= eturned viaSCVP.  This provides for timestamping.  

[PR] The valid= ation is simplified when OCSP response with positive statement as a hash val= ue of requested certificate is used.

Positive statement is evidence that OCS= P know the status of certificate and also protect the integrity of certifica= te with a new more secure hash algorithm.

 

Peter Rybar<= /span>

<= span style=3D"font-size: 10pt; font-family: Arial, sans-serif; color: navy; ">=  


Simon Tardell, 

Tech= nology Nexus.

On Fri, Oct 19, 2012 at 1:07 PM, Peter Rybar <rybar@nbusr.sk> wrote:

Stefan,

I have a question about the present OCSP RFC and at the e= nd of the mail about the new situation which will happen according to your n= ew proposal.

The presence of the positive statement in OCSP response = is important for electronic signature validations, especially for an expired= certificate. Positive statement is the hash value of a certificate whose st= atus is provided in OCSP response.

Electronic signature validation is= usually about the signatures created in the past and validated now, when th= e certificate is expired.

When the certificate expires then revocatio= n is usually removed from CRL and the revoked certificate can be provided as= "good" in OCSP response.
Is it acceptable? I think not.

According= to your new draft there is not defined a value of revocationTime.
RFC mu= st also define the value of revocationTime when the certificate which was ne= ver issued is as "revoked".
http://www.ietf.org/rfcdiff?url2= =3Ddraft-ietf-pkix-rfc2560bis-06

Have you also covered the situatio= n when the certificate is expired, REMOVED FROM CRL and will be provided as = revoked with incorrect revocationTime e.g.with the value before or after the= revocationTime which was present in the removed record from CRL?
Because= according to sentence in your draft ""revoked" - This state SHOULD also be = returned if the responder knows that the requested certificate has never bee= n issued." the following situation can happen: when certificate is removed f= rom CRL after expiration and CA/OCSP responder is responsible for this certi= ficate but have not record about expired certificate and for that reason it = is identified as "never been issued".

...
revoked     [1= ]     IMPLICIT RevokedInfo,
...

   RevokedInfo= ::=3D SEQUENCE {
       revocationTime     &= nbsp;        GeneralizedTime,
      &n= bsp;revocationReason    [0]     EXPLICIT CRLReason OPTIO= NAL }

As you have mentioned in the mail:

"On the "revoked" = state, the old spec did not even consider the case of a certificate being re= quested where the OCSP responder knows that the certificate was never issued= ."

"It simply recommend a known= to be bad certificate to result
in "revoked" in order to prevent damage = as far as possible. It also opens
for definition of new extensions throug= h which such knowledge could be
obtained."

Peter Rybar
National Security Authority
Informati= on Security and Electronic Signature Department
Budatinska 30, 850 07 Bratislava 57, Slovak Republic
e-mail: peter.rybar@nbusr.s= k
e-mail: peterryb@gmail.com


-----Original Message-= ----
From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org]= On Behalf Of Stefan Santesson
Sent: Monday, October 15, 2012 1:49 AM
= To: pkix@ietf.org
Subject: [pkix] New = draft-ietf-pkix-rfc2560bis-06

All,

I have just posted an updat= e of rfc2560bis (OCSP update) after carefully
reviewing all comments on t= he list.

Some notes about the update:

- Added the previous OCS= P editors with updated affiliations.
- Added some calcifications on Respo= nderID as suggested by Simon Josefsson.
- Updated the clarifications on A= uthorized responders. The requirements
have not changed. I just tried to = improve the text.
- Updated a clarification on the "revoked" state to be = the preferred
response if a certificate is known by the responder to neve= r have been
issued.
- Some minor editorial nits.


Regarding = backwards compatibility I mean that none of the clarifications
changes RF= C 2560.

On Authorized responders it has always been the case that a r= esponder
certificate issued with the same key as was used to issue the ce= rtificate
being checked for revocation, represents a valid Authorized res= ponder.
There has never been an explicit requirement to support key rollo= ver and
key rollover support has never been in the "spirit" of the origin= al
standard as it clearly attempted to provide direct cryptographic bindi= ng
between the responder and the CA.

On the "revoked" state, the o= ld spec did not even consider the case of a
certificate being requested w= here the OCSP responder knows that the
certificate was never issued. It i= s clearly counterproductive to respond
good when a certificate is known t= o be bad. A responder must pick one
response and picking "revoked" breaks= nothing, but has the desired effect,
that is, to prevent the certificate= from being accepted. The current text
makes clear that there is no mecha= nism in the current standard by which a
client can know how a responder w= ill respond to a request for a not issued
certificate. It simply recommen= d a known to be bad certificate to result
in "revoked" in order to preven= t damage as far as possible. It also opens
for definition of new extensio= ns through which such knowledge could be
obtained.

The current upd= ates also clearly opens a path for the CAB forum efforts to
define a suit= able solution for server certificates.

I have not, even thug suggeste= d, added any requirements on what clients
should do with the checked cert= as a result of a particular response. I
don't believe such requirements = are suitable as it is policy and not
protocol. We have no right to demand= that all systems MUST reject any
certificate for any reason as they may = have a local policy that overrules
the OCSP response. This protocol only = provides information about the cert
status, it does not mandate validatio= n policy.

I have not included any of the substantial changes i the Pi= nkas draft. I
want to wait for a list of motivation for each change befor= e including any
of them. So there changed may be up for debate before thi= s draft is ready
for WGLC.

/Stefan



________________= _______________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
<= br>_______________________________________________
pkix mailing list
<= a href=3D"mailto:pkix@ietf.org">pkix@ietf.org
https://www.ietf.org/mailman/lis= tinfo/pkix

<= /div>

 

____________________= ___________________________ pkix mailing list pkix@ietf.org http= s://www.ietf.org/mailman/listinfo/pkix<= o:p>

= --B_3433773452_16079534-- From simon@tardell.se Mon Oct 22 09:30:44 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4500221F892E for ; Mon, 22 Oct 2012 09:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ClrSCWHji375 for ; Mon, 22 Oct 2012 09:30:43 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id E26D521F849D for ; Mon, 22 Oct 2012 09:30:42 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so2022594lam.31 for ; Mon, 22 Oct 2012 09:30:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=MFIZOW3DQOrYuHzlP69S0t1NNN5/CI9xgsBUnvnIfjg=; b=lIzoLQBl0nKzbgAUl1ZqcPl5BVS3OmuxTwcvynj+2BjUIrvICtGu0oAzuRyENTKtfP sVX95+Qw+P3eHkbUQcOl1aABpYGcWJNCZA/MY91xWxsJPBCdz0vSzO46NIuwZ4QjFUv1 NoQsoCezLx8nEyfZZ2R0MFwdrVJ/6GNIneJSiOD+QBDLrC4EIt2CYtAF24ekZsGjEHtI jKYyGyBBYT+uQSdU63Zlpv+fxOZ5d2CskLGWAs5GuKYLbqgXziFM+bIfxx8yBkox0jWJ iZssWqnx+uZ+PfeNq0pyKy8db/hJ5Rkygz+7J4txsYnQrWhk1yVzQ8+4iVwSrUdqwXOT mTfA== MIME-Version: 1.0 Received: by 10.152.124.201 with SMTP id mk9mr8849642lab.33.1350923441427; Mon, 22 Oct 2012 09:30:41 -0700 (PDT) Received: by 10.112.27.105 with HTTP; Mon, 22 Oct 2012 09:30:41 -0700 (PDT) In-Reply-To: <50855DC5.6010609@bull.net> References: <50855225.1030202@bull.net> <50855DC5.6010609@bull.net> Date: Mon, 22 Oct 2012 18:30:41 +0200 Message-ID: From: Simon Tardell To: Denis Pinkas Content-Type: multipart/alternative; boundary=f46d0434bcead854e704cca85fd3 X-Gm-Message-State: ALoCoQm+Xb2gEdpNP2TmS/lp+5RTfaF1MGfjaOjHoI8euZtkzBHpZ4qkl4hOroCmpXirE+gUyoci Cc: pkix@ietf.org Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 16:30:44 -0000 --f46d0434bcead854e704cca85fd3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Mon, Oct 22, 2012 at 4:52 PM, Denis Pinkas wrote= : > Simon, > > > You said: > > "revocationReason must be certificateHold, since, in principle, the > certificate may be issued at a later point in time". > > I don't believe this is appropriate. If you have certificateHold then the > OCSP client may make other calls later on > to check if the suspension state has finished or not. > Which is entirely appropriate. If you make a standard OCSP query the certificate is identified with the hash of the issuer name and key and the serial number. There is nothing that prevents a CA from later issuing a certificate with the just-queried key. It would be unlikely, given best practices for generating serial numbers, but still. On the other hand, one could imagine a scenario where there is a time lag between the issuance of the certificate and the insertion of the certificate into the responder database (e.g. where the token hasn't been "activated" or "acknowledged" yet and the issuer wants to prevent the token from being used before such "activation"). If the relying party would get a definite revocation reason code it would not (necessarily) try again once the token has been "activated" and the certificate is valid for use and used to generate a second signature (since it knows a definite reason code doesn't change). This scenario isn't as contrived as it may seem. /Simon The less controversial revocationReason is "unspecified". Let us go for > "unspecified". > > Denis > > > If the meaning of "revoked" >> is changed it is also necessary to say what should be the values of both >> revocationTime and revocationReason: >> > [=85] > > >> CRLReason is defined in RFC 5280 as: >> >> CRLReason ::=3D ENUMERATED { >> unspecified (0), >> keyCompromise (1), >> cACompromise (2), >> affiliationChanged (3), >> superseded (4), >> cessationOfOperation (5), >> certificateHold (6), >> -- value 7 is not used >> removeFromCRL (8), >> privilegeWithdrawn (9), >> aACompromise (10) } >> >> > For the revocationTime should we use the content of notBefore field >> from the certificate ? >> > > The certificate that was not issued could have any time. It is also not > seen by the responder. The reasonable revocationTime would be "the > beginning of time". Any time which is before any reasonable issuance time > of any certificate in the PKI would do. The issuance time of the issuing = CA > would do, or for that matter the battle of Hastings. > > >> For the revocationReason should we use unspecified or keyCompromise ? >> > > revocationReason must be certificateHold, since, in principle, the > certificate may be issued at a later point in time. If a key was > compromised, it would be the CA key, not the key that the certificate. > > >> In any case, guidance should be given. >> >> Although I understand that changing the meaning of "revoked" may be seen >> as "safer" >> for old implemenations, changing the meaning of "unknown" also seems to >> be a reasonable alternative. >> >> In this case, it might be useful (and sufficient) to say that if an OCSP >> responder is authoritative >> for the target certificate, then the OCSP client SHOULD NOT use an >> alternative source >> of revocation information like CRLs. >> > > Which would be putting requirements on the behavior of already existing > OCSP clients out there that we know are not true and are out of the contr= ol > of most people setting up PKIs. > > Simon Tardell, > Technology Nexus. > > > --f46d0434bcead854e704cca85fd3 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

<= /div>
--bcaec554df5a9a974404cca88a37-- From mrex@sap.com Mon Oct 22 14:53:32 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA3521F88C7 for ; Mon, 22 Oct 2012 14:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.204 X-Spam-Level: X-Spam-Status: No, score=-10.204 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0kMe0xoPBdF for ; Mon, 22 Oct 2012 14:53:31 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 540AD21F88B0 for ; Mon, 22 Oct 2012 14:53:24 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q9MLrKaX007033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 22 Oct 2012 23:53:20 +0200 (MEST) In-Reply-To: To: Simon Tardell Date: Mon, 22 Oct 2012 23:53:19 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20121022215319.55EC71A2EB@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: Peter Rybar , Stefan Santesson , pkix@ietf.org Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 21:53:32 -0000 Simon Tardell wrote: > > I suggest that we use your current text plus that, if "revoked" is used > to say "never issued/not in database", the revocationReason should be > certificateHold and that revocationTime should be set to midnight Jan 1 > 1950 (or some other time before the rise of PKI). I support the "revoked, ReasonCode=CertificateHold" for OCSP responders that can not find proof/indication that the cert in question was properly issued. The CertificateHold reason code is vitally important, because otherwise the CA would have to keep track of OCSP responses given out from the CA's OCSP responder that declared a serial as "permanently revoked" in order to ensure that the CA will never issue a cert with that serial in the future. Looks like an unnecessary and easily avoidable burden to me. I don't like the particular date Jan 1, 1950, for safety, a date >= 1970 ought to be chosen (so that it does not get negative when converted to time_t, which has potential to confuse some code). And since the timestamp is a GeneralizedTime, the date ought to be given in exactly that format, e.g. "700101010101Z" What also should be noted is that the optional OCSP SingleResponseExtension "CrlID" must not be used when this "not issued" certificate was not conveyed through a CRL--and there currently is no means to convey proof-of-cert-existence through CRLs unless they're revoked, and in the latter case there would be no "not issued" OCSP response to convey. > > On the other hand, I think we should consider Denis' comment: > > *Saying that the certificate has not been issued is not fully appropriate.* I believe it is very inappropriate for the spec to make any assumptions about why exactly the OCSP responder believes that a cert (serial) has not ever been issued. The reason can be manyfold. Besides an accidental or fraudulent deletion (attack), it may be something as simple as a database software bug. What we might want to say is that failures to access the database of issued certs ought to result in an unknown rather than revoked OCSP response. The records of issuance, that the OCSP responder has access to, need not contain the whole certificate. The information may be limited to serial numbers of issued certificates, and it SHOULD include a hash of the cert (at least SHA-1, preferably SHA-256 as well). In particular, the OCSP responder may not have access to the validity of issued certs or any other certificate characteristics or certificate attributes. -Martin From internet-drafts@ietf.org Mon Oct 22 15:04:45 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E96B811E80DF; Mon, 22 Oct 2012 15:04:45 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cj9oEWHfGs48; Mon, 22 Oct 2012 15:04:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D060311E80E4; Mon, 22 Oct 2012 15:04:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022220443.9287.2326.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 15:04:43 -0700 Cc: pkix@ietf.org Subject: [pkix] I-D Action: draft-ietf-pkix-est-03.txt X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 22:04:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Public-Key Infrastructure (X.509) Working= Group of the IETF. Title : Enrollment over Secure Transport Author(s) : Max Pritikin Peter E. Yee Dan Harkins Filename : draft-ietf-pkix-est-03.txt Pages : 48 Date : 2012-10-22 Abstract: This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple yet functional certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificate(s) and associated Certification Authority (CA) certificate(s). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pkix-est There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pkix-est-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pkix-est-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From stefan@aaa-sec.com Mon Oct 22 15:19:21 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D78811E80E1 for ; Mon, 22 Oct 2012 15:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.326 X-Spam-Level: X-Spam-Status: No, score=-101.326 tagged_above=-999 required=5 tests=[AWL=0.923, BAYES_00=-2.599, HELO_EQ_SE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYvtNeCD2xDP for ; Mon, 22 Oct 2012 15:19:21 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id A02C111E809C for ; Mon, 22 Oct 2012 15:19:20 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 8F5381D399 for ; Tue, 23 Oct 2012 00:19:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id QG8UxFYT3TmJ for ; Tue, 23 Oct 2012 00:19:07 +0200 (CEST) Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 2EA4A1D1A4 for ; Tue, 23 Oct 2012 00:19:07 +0200 (CEST) Received: (qmail 67334 invoked from network); 22 Oct 2012 22:19:06 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.214]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 22 Oct 2012 22:19:06 -0000 User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Tue, 23 Oct 2012 00:19:04 +0200 From: Stefan Santesson To: , Simon Tardell Message-ID: Thread-Topic: [pkix] New draft-ietf-pkix-rfc2560bis-06 In-Reply-To: <20121022215319.55EC71A2EB@ld9781.wdf.sap.corp> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Peter Rybar , pkix@ietf.org Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 22:19:21 -0000 Martin, What you say here makes sense to me. I do in particular support the 1 jan 1970 time as it is the time zero point for may Date formats. /Stefan On 10/22/12 11:53 PM, "Martin Rex" wrote: >Simon Tardell wrote: >> >> I suggest that we use your current text plus that, if "revoked" is used >> to say "never issued/not in database", the revocationReason should be >> certificateHold and that revocationTime should be set to midnight Jan 1 >> 1950 (or some other time before the rise of PKI). > >I support the "revoked, ReasonCode=CertificateHold" for OCSP responders >that can not find proof/indication that the cert in question was properly >issued. > >The CertificateHold reason code is vitally important, because otherwise >the CA would have to keep track of OCSP responses given out from the >CA's OCSP responder that declared a serial as "permanently revoked" >in order to ensure that the CA will never issue a cert with that serial >in the future. Looks like an unnecessary and easily avoidable burden to >me. > > >I don't like the particular date Jan 1, 1950, for safety, a date >= 1970 >ought to be chosen (so that it does not get negative when converted >to time_t, which has potential to confuse some code). > >And since the timestamp is a GeneralizedTime, the date ought to be >given in exactly that format, e.g. "700101010101Z" > > >What also should be noted is that the optional OCSP >SingleResponseExtension >"CrlID" must not be used when this "not issued" certificate was not >conveyed through a CRL--and there currently is no means to convey >proof-of-cert-existence through CRLs unless they're revoked, and in the >latter case there would be no "not issued" OCSP response to convey. > > >> >> On the other hand, I think we should consider Denis' comment: >> >> *Saying that the certificate has not been issued is not fully >>appropriate.* > > >I believe it is very inappropriate for the spec to make any assumptions >about why exactly the OCSP responder believes that a cert (serial) has not >ever been issued. The reason can be manyfold. Besides an accidental or >fraudulent deletion (attack), it may be something as simple as a >database software bug. > >What we might want to say is that failures to access the database >of issued certs ought to result in an unknown rather than revoked >OCSP response. > >The records of issuance, that the OCSP responder has access to, >need not contain the whole certificate. The information may be >limited to serial numbers of issued certificates, and it SHOULD >include a hash of the cert (at least SHA-1, preferably SHA-256 as well). >In particular, the OCSP responder may not have access to the >validity of issued certs or any other certificate characteristics or >certificate attributes. > > >-Martin From eabalea@gmail.com Tue Oct 23 00:07:06 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C91371F0C54 for ; Tue, 23 Oct 2012 00:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3A+Zav9xb3h for ; Tue, 23 Oct 2012 00:07:06 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id E897E1F0429 for ; Tue, 23 Oct 2012 00:07:05 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so1976226wgb.13 for ; Tue, 23 Oct 2012 00:07:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=C7WUn5n8h+3rOB4yhJypOLY9a1psVk81oo1K583eclc=; b=xb9kO6qy8sb96x5cgqGV7Sp6KIKb7peLcjOVLW6GkpBs4VohdSRxnxciQl0iDrqe2t h+FQr7kIA7ERj5bHSIACz0yLIE5GDGYqXDAA4VnvPhXirm7H5/fKd1srycb3dmpJK0Ss 1s++a62KDJRRW4V9MPTbsa7LkxopD+s0KOo4V5fYWrcqYXd1VaL0th02poS8PgIu3lD4 /Tf8nrnAoiVAGqRZwc/jrDbGnWt15DuF6aAgTkh4+pOGPIWc6UD830/cy0yxhmOjuCQY bL6ilafEBa8cvlkjgrF4NaBkUWDDFHaY7YnbEcc+pFsHudS7RY1/oihUNm23cgjSUNNo ZYOw== MIME-Version: 1.0 Received: by 10.216.197.99 with SMTP id s77mr7280630wen.64.1350976024957; Tue, 23 Oct 2012 00:07:04 -0700 (PDT) Received: by 10.223.133.194 with HTTP; Tue, 23 Oct 2012 00:07:04 -0700 (PDT) In-Reply-To: <20121022215319.55EC71A2EB@ld9781.wdf.sap.corp> References: <20121022215319.55EC71A2EB@ld9781.wdf.sap.corp> Date: Tue, 23 Oct 2012 09:07:04 +0200 Message-ID: From: Erwann Abalea To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Cc: Peter Rybar , pkix@ietf.org, Stefan Santesson Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 07:07:06 -0000 Bonjour, 2012/10/22 Martin Rex : > Simon Tardell wrote: >> >> I suggest that we use your current text plus that, if "revoked" is used >> to say "never issued/not in database", the revocationReason should be >> certificateHold and that revocationTime should be set to midnight Jan 1 >> 1950 (or some other time before the rise of PKI). > > I support the "revoked, ReasonCode=CertificateHold" for OCSP responders > that can not find proof/indication that the cert in question was properly > issued. I don't think it's wise to use one reason code to cover two reasons. The latest CAs we deployed want to have certificates issued in a suspended state until the smartcard has been delivered, whence "certificateHold" reason code, with CRLs filled in that way. For these CAs, an OCSP responder will respond "certificateHold" for legitimate certificates, and you're proposing to also reply "certificateHold" for random serial numbers. > The CertificateHold reason code is vitally important, because otherwise > the CA would have to keep track of OCSP responses given out from the > CA's OCSP responder that declared a serial as "permanently revoked" > in order to ensure that the CA will never issue a cert with that serial > in the future. Looks like an unnecessary and easily avoidable burden to me. This is why I don't think that declaring an unknown and potentially random serial number as revoked is good. Nor useful. An attacker will most likely intercept communications with the responder and reply something like "unauthorized", or any unsigned error code. > I don't like the particular date Jan 1, 1950, for safety, a date >= 1970 > ought to be chosen (so that it does not get negative when converted > to time_t, which has potential to confuse some code). > > And since the timestamp is a GeneralizedTime, the date ought to be > given in exactly that format, e.g. "700101010101Z" > > What also should be noted is that the optional OCSP SingleResponseExtension > "CrlID" must not be used when this "not issued" certificate was not > conveyed through a CRL--and there currently is no means to convey > proof-of-cert-existence through CRLs unless they're revoked, and in the > latter case there would be no "not issued" OCSP response to convey. See, by declaring a non-issued certificate as revoked, you're asking the CA to lie about its revocation date and declare it's not been issued in a CRL. How can it be right? > I believe it is very inappropriate for the spec to make any assumptions > about why exactly the OCSP responder believes that a cert (serial) has not > ever been issued. The reason can be manyfold. Besides an accidental or > fraudulent deletion (attack), it may be something as simple as a > database software bug. Or invalid encoding in client, or wrong issuerKeyHash (the serial exists, but for another CA), or random serial, or specially crafted numbers, or unrecognized hash function, ... All these cases have been spotted on our responders, and we haven't wrongly issued certificates. -- Erwann. From mrex@sap.com Tue Oct 23 00:32:40 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0330E21F84F6 for ; Tue, 23 Oct 2012 00:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.205 X-Spam-Level: X-Spam-Status: No, score=-10.205 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KECAixgHocPm for ; Tue, 23 Oct 2012 00:32:39 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1183E21F84D7 for ; Tue, 23 Oct 2012 00:32:38 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q9N7WMQM007640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 23 Oct 2012 09:32:22 +0200 (MEST) In-Reply-To: To: Erwann Abalea Date: Tue, 23 Oct 2012 09:31:25 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20121023073125.CC0A91A2ED@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: Peter Rybar , pkix@ietf.org, Stefan Santesson Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 07:32:40 -0000 Erwann Abalea wrote: > > Martin Rex : >> >> Simon Tardell wrote: >>> >>> I suggest that we use your current text plus that, if "revoked" is used >>> to say "never issued/not in database", the revocationReason should be >>> certificateHold and that revocationTime should be set to midnight Jan 1 >>> 1950 (or some other time before the rise of PKI). >> >> I support the "revoked, ReasonCode=CertificateHold" for OCSP responders >> that can not find proof/indication that the cert in question was properly >> issued. > > I don't think it's wise to use one reason code to cover two reasons. > The latest CAs we deployed want to have certificates issued in a > suspended state until the smartcard has been delivered, whence > "certificateHold" reason code, with CRLs filled in that way. For these > CAs, an OCSP responder will respond "certificateHold" for legitimate > certificates, and you're proposing to also reply "certificateHold" for > random serial numbers. CertificateHold is EXACTLY the correct ReasonCode: It indicates that the CA has not issued a cert with the given serial *YET*, but it MAY eventually issue such a cert in the future (sometimes even in the _very_next_future_ ... i.e. it is about to become visible to the OCSP responder, but not visible yet). > > > The CertificateHold reason code is vitally important, because otherwise > > the CA would have to keep track of OCSP responses given out from the > > CA's OCSP responder that declared a serial as "permanently revoked" > > in order to ensure that the CA will never issue a cert with that serial > > in the future. Looks like an unnecessary and easily avoidable burden to me. > > This is why I don't think that declaring an unknown and potentially > random serial number as revoked is good. Nor useful. > An attacker will most likely intercept communications with the > responder and reply something like "unauthorized", or any unsigned > error code. This rationale is a non-sequitur. An attacker can substitute any response with any kind of error. Or make the DNS lookup of the OCSP responder fail, or insert a ICMP error or TCP on the connection attempt to the OCSP responder. The purpose of the change here is to have the proper OCSP responder return completely useless responses in a situation where the OCSP responder has access to the CA issue logs and can determine that the cert in the request has not been issued (yet). > > > I don't like the particular date Jan 1, 1950, for safety, a date >= 1970 > > ought to be chosen (so that it does not get negative when converted > > to time_t, which has potential to confuse some code). > > > > And since the timestamp is a GeneralizedTime, the date ought to be > > given in exactly that format, e.g. "700101010101Z" > > > > What also should be noted is that the optional OCSP SingleResponseExtension > > "CrlID" must not be used when this "not issued" certificate was not > > conveyed through a CRL--and there currently is no means to convey > > proof-of-cert-existence through CRLs unless they're revoked, and in the > > latter case there would be no "not issued" OCSP response to convey. > > See, by declaring a non-issued certificate as revoked, you're asking > the CA to lie about its revocation date and declare it's not been > issued in a CRL. How can it be right? You're absolutely NOT lying at all. The cert with that serial has not been issued yet, but a cert with that cert may get issued in the future. The CertificateHold is perfectly appropriate to describe this situation. > > > I believe it is very inappropriate for the spec to make any assumptions > > about why exactly the OCSP responder believes that a cert (serial) has not > > ever been issued. The reason can be manyfold. Besides an accidental or > > fraudulent deletion (attack), it may be something as simple as a > > database software bug. > > Or invalid encoding in client, or wrong issuerKeyHash (the serial > exists, but for another CA), or random serial, or specially crafted > numbers, or unrecognized hash function, ... All these cases have been > spotted on our responders, and we haven't wrongly issued certificates. I was saying that the spec should advise against OCSP response recipients to draw conclusions (about causes), and take the response as what it is, a description of state, *NOT* an indicator of any precice cause. -Martin From denis.pinkas@bull.net Tue Oct 23 02:59:05 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7B621F865E for ; Tue, 23 Oct 2012 02:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.017 X-Spam-Level: X-Spam-Status: No, score=-5.017 tagged_above=-999 required=5 tests=[AWL=1.231, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DK6oBz2T6iNU for ; Tue, 23 Oct 2012 02:59:05 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id EA96421F8654 for ; Tue, 23 Oct 2012 02:59:04 -0700 (PDT) Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id C953F418155 for ; Tue, 23 Oct 2012 11:59:03 +0200 (CEST) Received: from [127.0.0.1] ([129.184.39.15]) by MSGC-007.bull.fr (Lotus Domino Release 8.5.3FP1) with ESMTP id 2012102311590348-2318 ; Tue, 23 Oct 2012 11:59:03 +0200 Message-ID: <50866A61.3070404@bull.net> Date: Tue, 23 Oct 2012 11:58:57 +0200 From: Denis Pinkas User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: pkix@ietf.org References: <20121023073125.CC0A91A2ED@ld9781.wdf.sap.corp> In-Reply-To: <20121023073125.CC0A91A2ED@ld9781.wdf.sap.corp> X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 23/10/2012 11:59:03, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 23/10/2012 11:59:03, Serialize complete at 23/10/2012 11:59:03 X-TNEFEvaluated: 1 Content-Type: multipart/alternative; boundary="------------040505000603060806010408" Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 09:59:05 -0000 This is a multi-part message in MIME format. --------------040505000603060806010408 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed Martin, Erwann said: "I don't think it's wise to use one reason code to cover two reasons. The latest CAs we deployed want to have certificates issued in a suspended state until the smartcard has been delivered, whence "certificateHold" reason code, with CRLs filled in that way. For these CAs, an OCSP responder will respond "certificateHold" for legitimate certificates, and you're proposing to also reply "certificateHold" for random serial numbers". You said: "CertificateHold is EXACTLY the correct ReasonCode: It indicates that the CA has not issued a cert with the given serial *YET*, but it MAY eventually issue such a cert in the future (sometimes even in the_very_next_future_ ... i.e. it is about to become visible to the OCSP responder, but not visible yet)". I am sorry, but I agree with Erwann and thus I disagree with you. The certificateHold state was not created to have certificates issued in a suspended state. It was created to allow a user to suspend its certificates rather than revoking its certificates, in case a smart card was temporarily lost and since after a revocation it may take a while to get a new smart card. Some people, then used also the certificateHold state to have certificates issued in a suspended state. This is legitimate since it complies with the semantics of the certificateHold state. We should not change/overload the meaning of CertificateHold. . Denis --------------040505000603060806010408 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=ISO-8859-1
Martin,
 
Erwann said:

"I don't think it's wise to use one reason code to cover two reasons.

The latest CAs we deployed want to have certificates issued in a
suspended state until the smartcard has been delivered, whence
"certificateHold" reason code, with CRLs filled in that way. For these
CAs, an OCSP responder will respond "certificateHold" for legitimate
certificates, and you're proposing to also reply "certificateHold" for
random serial numbers".

You said: 

"CertificateHold is EXACTLY the correct ReasonCode:
It indicates that the CA has not issued a cert with the given serial
*YET*, but it MAY eventually issue such a cert in the future
(sometimes even in the _very_next_future_ ... i.e. it is about
 to become visible to the OCSP responder, but not visible yet)".

I am sorry, but I agree with Erwann and thus I disagree with you.

The certificateHold state was not created to have certificates issued 
in a suspended state. It was created to allow a user to suspend its certificates 
rather than revoking its certificates, in case a smart card was temporarily lost and 
since after a revocation it may take a while to get a new smart card.

Some people, then used also the certificateHold state to have certificates issued 
in a suspended state. This is legitimate since it complies with the semantics of 
the certificateHold state.

We should not change/overload the meaning of CertificateHold. 
.
Denis
 
--------------040505000603060806010408-- From mrex@sap.com Tue Oct 23 03:17:28 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA3421F865E for ; Tue, 23 Oct 2012 03:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.207 X-Spam-Level: X-Spam-Status: No, score=-10.207 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bO6wfOQ8hBKt for ; Tue, 23 Oct 2012 03:17:28 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id B17F221F8654 for ; Tue, 23 Oct 2012 03:17:27 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q9NAHP2c012819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 23 Oct 2012 12:17:25 +0200 (MEST) In-Reply-To: <50866A61.3070404@bull.net> To: Denis Pinkas Date: Tue, 23 Oct 2012 12:17:25 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20121023101725.6273E1A2EE@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 10:17:28 -0000 Denis Pinkas wrote: > > The certificateHold state was not created to have certificates issued > in a suspended state. It was created to allow a user to suspend its > certificates rather than revoking its certificates, in case a smart > card was temporarily lost and since after a revocation it may take > a while to get a new smart card. > > Some people, then used also the certificateHold state to have > certificates issued in a suspended state. This is legitimate since > it complies with the semantics of the certificateHold state. > > We should not change/overload the meaning of CertificateHold. The purpose of the CertificateHold is to convey from the CA to the RP "you should not currently trust the certificate with this serial, because it is not certain that the entity which is currently in control of the associated private key is actually the entity which the cert says it is." When an OCSP responder has access to the certificate issue logs, and does not find proof that a requested serial was issued, then the message it wants to convey to the RP is "you should not currently trust the certificate with this serial, because it is not certain that the entity which is currently in control of the associated private key is actually the entity which the cert says it is." So we are *NOT* changing nor overloading the semantics of CertificateHold _at_all_ with this expanded definition ! -Martin " From eabalea@gmail.com Tue Oct 23 03:18:22 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EAD121F86A8 for ; Tue, 23 Oct 2012 03:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3jqSCa8qsMN for ; Tue, 23 Oct 2012 03:18:21 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 19CF621F86A3 for ; Tue, 23 Oct 2012 03:18:20 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id hm2so3043289wib.1 for ; Tue, 23 Oct 2012 03:18:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xDEps2cx93JUffm6cShAGE2wAFNTntY85u1sRae3M2E=; b=KaJBvPVjOhypiH3LAwaq8PIzjUmajkC2wwSxXsTUYnGIV84u1ESUHjmMJmsb4ckQt3 jP41WtPZcV2AwZ2yR1sknOk7DiRwAYrxWwoeoN9rxmo3PIZg9bDDyQ/Pm2K7zcAE+pvf lAKDz3EtMqDSI5KJ7dnSXX31pZxkZiDc/n6+lhMpc1NIwrEZDJeAu//VA7mZ8IbM4xCM sIa2dAN/mkGDMiFpdEdmsQBzi/8F4DlACyGmfuUnUsMzeJ90bt2Huo3Vu1zY7XxHamTM tKv0U+Oz1pCek5fvI7xhLw6uR3Hr63AdWhEPBGVQq+xHIW5eX3yiFiNDgrDX18NWSdky TgqA== MIME-Version: 1.0 Received: by 10.180.81.37 with SMTP id w5mr27881309wix.10.1350987500085; Tue, 23 Oct 2012 03:18:20 -0700 (PDT) Received: by 10.223.133.194 with HTTP; Tue, 23 Oct 2012 03:18:19 -0700 (PDT) In-Reply-To: <20121023073125.CC0A91A2ED@ld9781.wdf.sap.corp> References: <20121023073125.CC0A91A2ED@ld9781.wdf.sap.corp> Date: Tue, 23 Oct 2012 12:18:19 +0200 Message-ID: From: Erwann Abalea To: mrex@sap.com Content-Type: multipart/alternative; boundary=f46d04428dc009e31e04ccb74ac1 Cc: Peter Rybar , pkix@ietf.org, Stefan Santesson Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 10:18:22 -0000 --f46d04428dc009e31e04ccb74ac1 Content-Type: text/plain; charset=UTF-8 2012/10/23 Martin Rex > Erwann Abalea wrote: > > > > Martin Rex : > >> > >> Simon Tardell wrote: > >>> > >>> I suggest that we use your current text plus that, if "revoked" is used > >>> to say "never issued/not in database", the revocationReason should be > >>> certificateHold and that revocationTime should be set to midnight Jan 1 > >>> 1950 (or some other time before the rise of PKI). > >> > >> I support the "revoked, ReasonCode=CertificateHold" for OCSP responders > >> that can not find proof/indication that the cert in question was > properly > >> issued. > > > > I don't think it's wise to use one reason code to cover two reasons. > > The latest CAs we deployed want to have certificates issued in a > > suspended state until the smartcard has been delivered, whence > > "certificateHold" reason code, with CRLs filled in that way. For these > > CAs, an OCSP responder will respond "certificateHold" for legitimate > > certificates, and you're proposing to also reply "certificateHold" for > > random serial numbers. > > CertificateHold is EXACTLY the correct ReasonCode: > It indicates that the CA has not issued a cert with the given serial > *YET*, but it MAY eventually issue such a cert in the future > (sometimes even in the _very_next_future_ ... i.e. it is about > to become visible to the OCSP responder, but not visible yet). No. It indicates that the corresponding (existent) certificate has been put on hold. You're asking the CA to assert a status for a non-existent certificate. What's next? Ask CAs to sign the next OCSP response with a "removeFromCRL" code for dumb serial numbers for which they replied "certificateHold"? Why not also add a holdInstructionCode extension to the OCSP response, and define proper codes? The number of bogus requests far outweighs the number of bad certificates. In our case, as a public CA, it even outweighs the number of good public certificates we produced. Asking for a signed response to a bogus request gives anonymous attackers much power. Consider big CAs that receive billions of OCSP requests a week, or even a day (that's reality). Do you really consider that asking for billions of signatures a day for bogus requests, asserting an authoritative status for nonexistent certificate is the right thing to do? With my "CA" hat, I see that OCSP is a hidden cost, and you want to make it more costly. With my "user" hat, I see that revocation checks are not properly done, pressure is put on certificate issuers but if relying parties don't do their job it's useless. The two added together will just build something more costly but still useless. > > The CertificateHold reason code is vitally important, because otherwise > > > the CA would have to keep track of OCSP responses given out from the > > > CA's OCSP responder that declared a serial as "permanently revoked" > > > in order to ensure that the CA will never issue a cert with that serial > > > in the future. Looks like an unnecessary and easily avoidable burden > to me. > > > > This is why I don't think that declaring an unknown and potentially > > random serial number as revoked is good. Nor useful. > > An attacker will most likely intercept communications with the > > responder and reply something like "unauthorized", or any unsigned > > error code. > > This rationale is a non-sequitur. > No sophism here. My point is that I don't think the problem is correctly addressed. > An attacker can substitute any response with any kind of error. > Or make the DNS lookup of the OCSP responder fail, or insert > a ICMP error or TCP on the connection attempt to the OCSP responder. > Correct. And? Whatever you ask the CA to do, the attacker can avoid it. Wrong end of the problem. > > > I don't like the particular date Jan 1, 1950, for safety, a date >= > 1970 > > > ought to be chosen (so that it does not get negative when converted > > > to time_t, which has potential to confuse some code). > > > > > > And since the timestamp is a GeneralizedTime, the date ought to be > > > given in exactly that format, e.g. "700101010101Z" > > > > > > What also should be noted is that the optional OCSP > SingleResponseExtension > > > "CrlID" must not be used when this "not issued" certificate was not > > > conveyed through a CRL--and there currently is no means to convey > > > proof-of-cert-existence through CRLs unless they're revoked, and in the > > > latter case there would be no "not issued" OCSP response to convey. > > > > See, by declaring a non-issued certificate as revoked, you're asking > > the CA to lie about its revocation date and declare it's not been > > issued in a CRL. How can it be right? > > You're absolutely NOT lying at all. The cert with that serial has > not been issued yet, but a cert with that cert may get issued in the > future. The CertificateHold is perfectly appropriate to describe > this situation. The OCSP request doesn't match an existent certificate, yet you want the CA to declare it as revoked, discuss about the correct revocation reason to use, and a correct revocation date. But this response is not a lie. Something's wrong. > > > I believe it is very inappropriate for the spec to make any assumptions > > > about why exactly the OCSP responder believes that a cert (serial) has > not > > > ever been issued. The reason can be manyfold. Besides an accidental > or > > > fraudulent deletion (attack), it may be something as simple as a > > > database software bug. > > > > Or invalid encoding in client, or wrong issuerKeyHash (the serial > > exists, but for another CA), or random serial, or specially crafted > > numbers, or unrecognized hash function, ... All these cases have been > > spotted on our responders, and we haven't wrongly issued certificates. > > I was saying that the spec should advise against OCSP response recipients > to draw conclusions (about causes), and take the response as what it is, > a description of state, *NOT* an indicator of any precice cause. > That's the good end of the problem. -- Erwann. --f46d04428dc009e31e04ccb74ac1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2012/10/23 Martin Rex <mrex@sap.com>
Erwann Abalea wrote:
>
> Martin Rex <mrex@sap.com>: >>
>> Simon Tardell wrote:
>>>
>>> I suggest that we use your current text plus that, if "re= voked" is used
>>> to say "never issued/not in database", the revocatio= nReason should be
>>> certificateHold and that revocationTime should be set to midni= ght Jan 1
>>> 1950 (or some other time before the rise of PKI).
>>
>> I support the "revoked, ReasonCode=3DCertificateHold" fo= r OCSP responders
>> that can not find proof/indication that the cert in question was p= roperly
>> issued.
>
> I don't think it's wise to use one reason code to cover two re= asons.
> The latest CAs we deployed want to have certificates issued in a
> suspended state until the smartcard has been delivered, whence
> "certificateHold" reason code, with CRLs filled in that way.= For these
> CAs, an OCSP responder will respond "certificateHold" for le= gitimate
> certificates, and you're proposing to also reply "certificate= Hold" for
> random serial numbers.

CertificateHold is EXACTLY the correct ReasonCode:
It indicates that the CA has not issued a cert with the given serial
*YET*, but it MAY eventually issue such a cert in the future
(sometimes even in the _very_next_future_ ... i.e. it is about
=C2=A0to become visible to the OCSP responder, but not visible yet).

No. It indicates that the corresponding (existent= ) certificate has been put on hold.
You're asking the CA to a= ssert a status for a non-existent certificate.

What's next? Ask CAs to sign the next OCSP response= with a "removeFromCRL" code for dumb serial numbers for which th= ey replied "certificateHold"? Why not also add a holdInstructionC= ode extension to the OCSP response, and define proper codes?

The number of bogus requests far outweighs the number o= f bad certificates. In our case, as a public CA, it even outweighs the numb= er of good public certificates we produced.

Asking= for a signed response to a bogus request gives anonymous attackers much po= wer. Consider big CAs that receive billions of OCSP requests a week, or eve= n a day (that's reality). Do you really consider that asking for billio= ns of signatures a day for bogus requests, asserting an authoritative statu= s for nonexistent certificate is the right thing to do?

With my "CA" hat, I see that OCSP is a hidden= cost, and you want to make it more costly.
With my "user&qu= ot; hat, I see that revocation checks are not properly done, pressure is pu= t on certificate issuers but if relying parties don't do their job it&#= 39;s useless.
The two added together will just build something more costly but still= useless.

> > The CertificateHold reason code is vitally important, because oth= erwise
> > the CA would have to keep track of OCSP responses given out from = the
> > CA's OCSP responder that declared a serial as "permanent= ly revoked"
> > in order to ensure that the CA will never issue a cert with that = serial
> > in the future. =C2=A0Looks like an unnecessary and easily avoidab= le burden to me.
>
> This is why I don't think that declaring an unknown and potentiall= y
> random serial number as revoked is good. Nor useful.
> An attacker will most likely intercept communications with the
> responder and reply something like "unauthorized", or any un= signed
> error code.

This rationale is a non-sequitur.

No sophism here. My point is that I don't think the problem is correct= ly addressed.
=C2=A0
On Mon, Oct 22, 2012 at 4:52 PM, Denis P= inkas <denis.pinkas@bull.net> wrote:
=20 =20 =20
Simon,


You said:

"revocationReason must be certificateHold, since, in principle, the certificate may be issued at a later point in time".

I don't believe this is appropriate. If you have certificateHold then the OCSP client may make other calls later on
to check if the suspension state has finished or not.
=

Which is entirely appropriate. =A0If you m= ake a standard OCSP query the certificate is identified with the hash of th= e issuer name and key and the serial number. There is nothing that prevents= a CA from later issuing a certificate with the just-queried key. It would = be unlikely, given best practices for generating serial numbers, but still.= =A0

On the other hand, one could imagine a scenario where t= here is a time lag between the issuance of the certificate and the insertio= n of the certificate into the responder database (e.g. where the token hasn= 't been "activated" or "acknowledged" yet and the i= ssuer wants to prevent the token from being used before such "activati= on"). If the relying party would get a definite revocation reason code= it would not (necessarily) try again once the token has been "activat= ed" and the certificate is valid for use and used to generate a second= signature (since it knows a definite reason code doesn't change).

This scenario isn't as contrived as it may seem.=A0=

/Simon

The less controversial revocationReason is "unspecified". Let us go for "unspecified". <= br>
<= font face=3D"Arial">Denis


=A0If the meaning of "revoked"
is changed it is also necessary to say what should be the values of both
revocationTime and revocationReason:
[=85]
=A0
CRLReason is defined in RFC 5280 as:

=A0=A0 CRLReason ::=3D ENUMERATED = {
=A0=A0=A0=A0=A0=A0=A0 unspecified=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 (0),
=A0=A0=A0=A0=A0=A0=A0 keyCompromise=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 (1),
=A0=A0=A0=A0=A0=A0=A0 cACompromise=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 (2),
=A0=A0=A0=A0=A0=A0=A0 affiliationChanged=A0=A0=A0=A0=A0 (3)= ,
=A0=A0=A0=A0=A0=A0=A0 superseded=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 (4),
=A0=A0=A0=A0=A0=A0=A0 cessationOfOperation=A0=A0=A0 (5), =A0=A0=A0=A0=A0=A0=A0 certificateHold=A0=A0=A0=A0=A0=A0=A0= =A0 (6),
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- value 7 is not used=
=A0=A0=A0=A0=A0=A0=A0 removeFromCRL=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 (8),
=A0=A0=A0=A0=A0=A0=A0 privilegeWithdrawn=A0=A0=A0=A0=A0 (9)= ,
=A0=A0=A0=A0=A0=A0=A0 aACompromise=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 (10) }


For the revocationTime should we use the content of notBefore field from the certificate ?

The certificate that was not issued could have any time. It is also not seen by the responder. The reasonable revocationTime would be "the beginning of time". Any ti= me which is before any reasonable issuance time of any certificate in the PKI would do. The issuance time of the issuing CA would do, or for that matter the battle of Hastings.
=A0
For the revocationReason should we use unspecified or keyCompromise ?

revocationReason must be certificateHold, since, in principle, the certificate may be issued at a later point in time. If a key was compromised, it would be the CA key, not the key that the certificate.=A0
=A0
In any case, guidance should be given.

Although I understand that changing the meaning of "revoked" may be seen as "safer"
for old implemenations, changing the meaning of "unknown= " also seems to be a reasonable alternative.

In this case, it might be useful (and sufficient) to say that if an OCSP responder is authoritative
for the target certificate, then the OCSP client SHOULD NOT use an alternative source
of revocation information like CRLs.

Which would be putting requirements on the behavior of already existing OCSP clients out there that we know are not true and are out of the control of most people setting up PKIs.

Simon Tardell,
Technology Nexus.



--f46d0434bcead854e704cca85fd3-- From simon@tardell.se Mon Oct 22 09:42:44 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93A4F11E8097 for ; Mon, 22 Oct 2012 09:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G22qeqr21iLu for ; Mon, 22 Oct 2012 09:42:41 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC0621F843E for ; Mon, 22 Oct 2012 09:42:39 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so2031370lam.31 for ; Mon, 22 Oct 2012 09:42:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=6lcbts0fPUXELHP+m8ergI0IK4nmO6w1QeaENxf1dtc=; b=IcbR2FWilKvIbFDhB189tTbgeBdwIxthmZw88Zi4qPhJuU/rlnn9gjhC1SET15IUY1 VFKQ1jckz5dE9TAApFNHBru0y3vWU4YWBh979Ji0jGyt+z1qaTDgZcTI408GzsEetBrR vVmbGQ1BrVML+c2npuQLzsyL61uiFeampgGEDer3sM4O0LcS31WEhsjO7u2BEuDx7dTZ JcwUBpDixSzV7EHhxZ+VqnHfSFJeLZI0+X3WvXQem4rhSPTtzpC1bORw/iuQqf3YuNhy 5IFkS4phBElmg0xYojKwGtT4ZZXTpNk83rKxF2pJDzhLLqaJNuuYRbH5xSsy02og27GI pXmQ== MIME-Version: 1.0 Received: by 10.112.45.231 with SMTP id q7mr3891713lbm.133.1350924158801; Mon, 22 Oct 2012 09:42:38 -0700 (PDT) Received: by 10.112.27.105 with HTTP; Mon, 22 Oct 2012 09:42:38 -0700 (PDT) In-Reply-To: References: <010201cdb06a$7a37c670$6ea75350$@ditenity.com> Date: Mon, 22 Oct 2012 18:42:38 +0200 Message-ID: From: Simon Tardell To: Stefan Santesson Content-Type: multipart/alternative; boundary=bcaec554df5a9a974404cca88a37 X-Gm-Message-State: ALoCoQkiQwPORliGV+yXgb8HrfI3F8nlgfzqzR6Cl1Fzoo6HPPIEm3GOwukQKnuZHekg9MeDo2i4 Cc: Peter Rybar , pkix@ietf.org Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 16:42:44 -0000 --bcaec554df5a9a974404cca88a37 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Mon, Oct 22, 2012 at 5:57 PM, Stefan Santesson wrote= : I could live with a wording saying that a responder MAY respond "unknown" > to a request for a known fraudulent (or not never issued) cert if the > responder possess such knowledge of course.. > I think it is unfortunate to reopen this discussion now. I suggest that we use your current text plus that, if "revoked" is used to say "never issued/not in database", the revocationReason should be certificateHold and that revocationTime should be set to midnight Jan 1 1950 (or some other time before the rise of PKI). On the other hand, I think we should consider Denis' comment: *Saying that the certificate has not been issued is not fully appropriate.* > The text should be modified in the following way: > "The "revoked" state indicates that the certificate has been revoked > (either permanently or temporarily (on hold)). This state SHOULD > also be returned if the responder *has an access to the database > of > ** of ** issued certificates and if the serial number of the target > ** certificate is not present in that database. * > * In this case, the "revoked" state indicates either that the > ** certificate has never been issued or that it has been issued but > ** subsequently removed (by an attack or by accident) from the > ** database **of issued certificates.* > Response extensions may be used to convey additional information > on assertions made by the OCSP responder regarding the state of the > certificate such as *an **indication that the OCSP responder has > a direct access to the > ** a direct access to the **database of issued certificates*, validity, > etc ... " It should be difficult for the responder to tell the difference by itself, but I think, given the kind of hair-splitters we are, it is best to be as clear as possible. ;) /Simon Note that this does not have to mean that the CA is broken, is may also be > due to an error in the request from the client. > > /Stefan > > > From: Piyush Jain > Date: Monday, October 22, 2012 5:32 PM > > To: Stefan Santesson , 'Peter Rybar' = , > 'Carl Wallace' , 'Simon Tardell' < > simon@tardell.se> > Cc: 'Peter Rybar' , > Subject: RE: [pkix] New draft-ietf-pkix-rfc2560bis-06 > > I=92m sorry but definition of not issued is still unclear to me if you sa= y > that that a certificate can be cryptographically bound to the CA and stil= l > not-issued.**** > > The ambiguity is introduced because now I can do everything that 5280 ask= s > me to validate a certificate and still cannot be sure if the certificate > was ever issued.**** > > ** ** > > Here are the scenarios where meaning of not issued is unclear to me.**** > > 1) A genuine certificate issued by the CA, present in the CA databas= e > **** > > 2) A genuine certificate issued by the CA, removed from the CA > database by the CA**** > > 3) A genuine certificate issued by the CA, removed from the CA > database by an attacker**** > > 4) A fraudulent certificate issued by an attacker, present in the CA > database**** > > 5) A fraudulent certificate issued by an attacker, removed from the > CA database**** > > 6) A fraudulent certificate containing an AIA pointing to a > fraudulent OCSP responder (also cryptographically bound to the CA), issue= d > by an attacker, removed from the CA database.**** > > ** ** > > If the CA can differentiate among these cases, it can mark the fraudulent > certificates as revoked and we won=92t need an overloaded definition of > not-issued. Also not that if an attacker can carry out =914=92 it can als= o > carry out =915=92 and =916=92**** > > ** ** > > The people who are convinced that this is the way to go have not addresse= d > the issues raised in this WG. The little extension does not hurt anyone b= ut > it does not provide any value in general except to a few implementations > which are compromised. But it does take you down a slippery slope when yo= u > start promising that an OCSP responder can do much more than it is suppos= ed > to.**** > > I don=92t think that it is unreasonable for a smart implementer to stop > signature checking if his responder claims that it checks issuance. **** > > ** ** > > As for the diginotor case, for some people who say that security breach > could=92ve been detected early if this practice was in place, there is > another set of people who believe that attacker could=92ve circumvented t= hese > measures quite easily with the kind of access he had.**** > > ** ** > > If you and other folks in the group feel that this text should be added, = I > think at the minimum we also need to do the following**** > > - Provide explicit guidance on what the revocation time should > be. Such certificates are different from =91normal=92 revoked certificate= and > their revocation time should probably be set to something before the > validity of issuing CA. This distinction is important for time based > validations and long term archiving applications**** > > - I think it will be useful to indicate in the security > considerations section, that in such a scenario, CA is compromised and th= at > there is a high chance that RP is interacting with a compromised responde= r. > **** > > ** ** > > ** ** > > *From:* Stefan Santesson [mailto:stefan@aaa-sec.com ] > *Sent:* Sunday, October 21, 2012 11:03 AM > *To:* Piyush Jain; 'Peter Rybar'; 'Carl Wallace'; 'Simon Tardell' > *Cc:* 'Peter Rybar'; pkix@ietf.org > *Subject:* Re: [pkix] New draft-ietf-pkix-rfc2560bis-06**** > > ** ** > > In line;**** > > ** ** > > *From: *Piyush Jain > *Date: *Sunday, October 21, 2012 7:42 PM > *To: *Stefan Santesson , 'Peter Rybar' , > 'Carl Wallace' , 'Simon Tardell' < > simon@tardell.se> > *Cc: *'Peter Rybar' , > *Subject: *RE: [pkix] New draft-ietf-pkix-rfc2560bis-06**** > > ** ** > > So what is =93not-issued=94 - not signed by the CA or not present in CA > database?**** > > ** ** > > Not issued means it has never been issued. What's unclear about that?**** > > ** ** > > Of course it is not present in the database if it is not issued.**** > > If you delete things from your database and don't know if this one has > been deleted, then you don't know that it has never been issued and can't > reply revoked.**** > > ** ** > > ** ** > > It is unclear to folks who have been using signature verification as a wa= y > to check issuance. Isn=92t it a fair conclusion that I do not need to per= form > signature checks if the responder can check issuance for me?**** > > ** ** > > No that is not a fair conclusion. These are entirely different things.***= * > > ** ** > > **** > > You said that the possibility to send revoked reply only applies when the > responder =92knows=92 that requested certificate has never been issued. *= *** > > Please note that the responder will encounter this kind of request only i= n > two situations. First in which the RP sends a request for a certificate > without checking the signature and second in which the responder itself i= s > compromised by virtue of its issuing authority being compromised. In eith= er > case what the responder responds with does not matter.**** > > **** > > ** ** > > Some people are pretty convinced it does (from CAB forum), they are so > convinced that they are prepared to break compatibility with OCSP. By thi= s > little extension that hurst no-one, they don't have to.**** > > ** ** > > I=92ve no problem with your proposal to respond with =91revoked=92 in thi= s > situation.**** > > ** ** > > Good.**** > > ** ** > > I=92ve fundamental problem with the introduction of =91non-issued=92 conc= ept in > OCSP, which seems to provide additional security in this exceptional > scenario without actually providing any.**** > > ** ** > > It provides some, but not much. People keep coming back to that fact that > if this had been the practice of Diginotar, the security breach would hav= e > been discovered a lot earlier. So there might be some gain with no pain.*= * > ** > > ** ** > > However, in combination with an extension that adds information, this > might actually be increasingly valuable.**** > > If an OCSP responder starts receiving status requests for certs it knows > it has not issued, it can actually give explicit information about this > using an extension and it can take adequate measures.**** > > But in order to respond to the user, it need to pick one of the responses= . > Either good + extension or revoked+extension.**** > > ** ** > > This proposal is not meant to require any OCSP responder to deal with the > concept of "non-issued" certs. It merely allows an OCSP responder to > respond to such request.**** > > ** ** > > **** > > It=92ll be very helpful if I can see at least one practical scenario wher= e > this additional text would add value.**** > > ** ** > > Stated in my previous comments.**** > > ** ** > > /Stefan**** > > ** ** > > **** > > -Piyush**** > > *From:* Stefan Santesson [mailto:stefan@aaa-sec.com ] > *Sent:* Sunday, October 21, 2012 8:52 AM > *To:* Piyush Jain; 'Peter Rybar'; 'Carl Wallace'; 'Simon Tardell' > *Cc:* 'Peter Rybar'; pkix@ietf.org > *Subject:* Re: [pkix] New draft-ietf-pkix-rfc2560bis-06**** > > **** > > I don't think the "not issued" is unclear.**** > > **** > > The possibility to send a revoked reply only applies then the responder > "knows" that the requested certificate has never been issued.**** > > How the responder knows this is totally irrelevant, but unless the > responder knows this, it can't choose this option and has to reply "good"= . > **** > > **** > > It does not make revocation checking non-deterministric. **** > > "good" still means what is declared in the standard (The cert is not know= n > to be revoked, but it may never have been issued).**** > > "revoked" still have a deterministic meaning, that is, don't trust this > cert. The old exact semantics was "the cert IS revoked". The new semantic > is "the cert is revoked or possibly might never been issued"**** > > **** > > The new response semantic of revoked is backwards compatible and not less > deterministic than the good, response.**** > > **** > > So, I still don't see any practical problems here.**** > > **** > > /Stefan**** > > **** > > **** > > *From: *Piyush Jain > *Date: *Saturday, October 20, 2012 5:48 PM > *To: *Stefan Santesson , 'Peter Rybar' , > 'Carl Wallace' , 'Simon Tardell' < > simon@tardell.se> > *Cc: *'Peter Rybar' , > *Subject: *RE: [pkix] New draft-ietf-pkix-rfc2560bis-06**** > > **** > > Please see inline**** > > **** > > *From:* Stefan Santesson [mailto:stefan@aaa-sec.com ] > *Sent:* Friday, October 19, 2012 7:23 PM > *To:* Piyush Jain; 'Peter Rybar'; 'Carl Wallace'; 'Simon Tardell' > *Cc:* 'Peter Rybar'; pkix@ietf.org > *Subject:* Re: [pkix] New draft-ietf-pkix-rfc2560bis-06**** > > **** > > I'm sorry. I fail to the any of the problems you raise.**** > > **** > > If you receive a request for a certificate that you know has never been > issued, and you choose to reply revoked, what problems can you cause?**** > > *[Piyush] It depends on how you define =93never been issued=94, which btw > becomes unclear after introduction of the new text. There are two > interpretations***** > > 1) *Certificate is not signed by the CA or***** > > 2) *Certificate is not present in the database of issued > certificates that CA maintains.***** > > *One unintended consequence of first interpretation will be that RPs > would stop performing signature checks if their responder/CA publicizes > that it returns revoked for =93non-issued=94 certificates.***** > > *If the interpretation is 2, then this scenario is not possible unless > the CA is compromised.***** > > **** > > What in your mind is a more appropriate response?**** > > *[Piyush] I would say the appropriate response is good (if the > certificate is not marked as revoked), because that is what the RP will s= ee > if it consults a CRL or a responder detached from the CA. ***** > > *Revoked for =93not issued=94 adds no value because the only case in whic= h an > RP would send a query for a =93non-issued=94 certificate is when the CA i= s > compromised.***** > > **** > > It does not make OCSP more non-deterministic. If you ask status for an > issued cert from a non-broken CA, nothing is non-deterministic.**** > > *[Piyush] It does not make OCSP non-deterministic but it makes revocation > checking non-deterministic. The goal of OCSP is to address operational > limitations of CRLs, not functional limitations. The fact that you=92ll = get > different answers from two sources, both of which are authorized by the > same CA makes revocation checking non deterministic. ***** > > **** > > If you ask for status for a non-issued certificate, or a bad certificate > from a broken CA, then the result is by default non-deteministic and has > always been. However, choosing a revoked response may save the relying > party, at best, but can hurt no-one**** > > *[Piyush] I agree that a revoke response does not hurt anyone. But the > point is that it provides a false sense of additional security to the RP > without providing any. As an RP, I won=92t trust what my responder says i= f > the authority that certified it is compromised.***** > > **** > > What is your problem on the practical ground.**** > > *[Piyush] * Let=92s say that we still need to address this scenario and > revoked is the appropriate response. In that case**** > > - The text needs to be explicit about the revocation time in > this situation. Revoked implies good until a certain date and this > distinction is important for long term archiving applications. For unissu= ed > certificate the revocation time should probably be set to =96infinity.***= * > > - It needs to call out that in this particular scenario it is > addressing a functional limitation of CRLs (ability to detect CA > compromise) not an operational limitation.**** > > - I think we need additional text in security considerations to > indicate that RP is communicating with a responder certified by a > compromised CA in this scenario.**** > > **** > > **** > > /Stefan**** > > **** > > *From: *Piyush Jain > *Date: *Friday, October 19, 2012 7:34 PM > *To: *Stefan Santesson , 'Peter Rybar' , > 'Carl Wallace' , 'Simon Tardell' < > simon@tardell.se> > *Cc: *'Peter Rybar' , > *Subject: *RE: [pkix] New draft-ietf-pkix-rfc2560bis-06**** > > **** > > Stefan,**** > > **** > > I think some of you interpretations below are twisted to accommodate the > new provisions for providing revoked responses for unissued certificates.= * > *** > > Providing responses for expired certificates is within the scope of 2560 > using archive cutoff extension.**** > > **** > > The original authors of 2560 can correct me if I=92m wrong, but it is my > understanding that a response from OCSP responder is not supposed to > indicate if a certificate is good or bad but to indicate if a certificate > is revoked or unrevoked by the issuing authority. The fact that certifica= te > is issued by the CA is checked by the RP by verifying the signature on th= e > certificate.**** > > **** > > This draft introduces the concept of returning revoked responses for > unissued certificates. There are many unintended consequences of this > approach**** > > - Revocation statuses become non-deterministic based on who you > are asking (A responder with access to CA database vs. one without vs. > checking status off a CRL). If I=92m archiving a signed document with the > relevant artifacts to determine the validity status of the document, this > becomes a huge problem. Note that a revoked status implies that certifica= te > was good between the time of its issuance and that of its revocation. Any > document that is signed within that period should still be considered val= id. > **** > > - It would confuse an implementer about what =93non-issued=94 me= ans. > The fact that the CA signed the certificate implies it was issued. If a > certificate is issued fraudulently, based on its security practices, it i= s > up to the CA to either revoke the issued certificate, or ask its issuing > authority to revoke its own certificate.**** > > **** > > -Piyush**** > > **** > > **** > > **** > > **** > > *From:* pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] > *On Behalf Of *Stefan Santesson > *Sent:* Friday, October 19, 2012 7:25 AM > *To:* Peter Rybar; 'Carl Wallace'; 'Simon Tardell' > *Cc:* 'Peter Rybar'; pkix@ietf.org > *Subject:* Re: [pkix] New draft-ietf-pkix-rfc2560bis-06**** > > **** > > Peter,**** > > **** > > An OCSP responder is by default a service providing information about > current certificates.**** > > The default response you get from an OCSP responder is "good" unless the > cert is known to be bad or not a cert the responder can provide status fo= r. > **** > > **** > > If you need it to respond about old certificates, and as a client know > that the responder does this in a way that suits your needs, you will nee= d > to add an extension.**** > > Such extension will not be part of the rfc256bis effort.**** > > **** > > Is there any text in the current draft that you think is unclear on this?= * > *** > > **** > > /Stefan**** > > **** > > **** > > *From: *Peter Rybar > *Date: *Friday, October 19, 2012 3:12 PM > *To: *'Carl Wallace' , 'Simon Tardell' < > simon@tardell.se> > *Cc: *'Peter Rybar' , Stefan Santesson < > stefan@aaa-sec.com>, > *Subject: *RE: [pkix] New draft-ietf-pkix-rfc2560bis-06**** > > **** > > Well, yes, sort of. You can only be sure to validate a signature at the > moment of production. **** > > **** > > What if the signature key was compromised at the moment of production but > is not yet on a revocation list?**** > > [PR] According to clause 2.4 - thisUpdate: The time at which the status > being indicated is known to be correct**** > > It means when signature time-stamp time is X then any OCSP responses with > thisUpdate time X+y are sufficient to validate because the status is > correct. **** > > Y is in the interval <0, producedAt - X>**** > > **** > > At any later point in time the signature key may be compromised, or the > algorithms involved may have become to weak. (In which case the time of > revocation in the OCSP response is worth nothing to you). The risk > increases as time passes. And of course, the revocation information may n= ot > be kept around after the expiry of the certificate. **** > > **** > > That's why you should validate signatures as soon as possible. **** > > **** > > For these archival purposes wouldn't it be better to have the final > revocation list before removed due to expiry? In any case, you'd need > verification information collected after some grace period following mome= nt > of production.**** > > [PR] Grace period is not a fixed value of the time interval. **** > > Grace period is changeable because the first OCSP response with thisUpdat= e > time value > than time of signature time-stamp contains correct status.**= * > * > > **** > > **** > > If you need to ascertain that a signature was valid at a later time, you > have to trust your system that it performed the validation at the time it > first received the signature. That trust must be established through some > kind of mix of policies and technical measures (such as timestamping).***= * > > **** > > In the dark corner just beyond the dark corner that is SCVP, there's a > spec (RFC 5276) that defines a binding of evidence records to artifacts > that can be returned viaSCVP. This provides for timestamping. **** > > [PR] The validation is simplified when OCSP response with positive > statement as a hash value of requested certificate is used.**** > > Positive statement is evidence that OCSP know the status of certificate > and also protect the integrity of certificate with a new more secure hash > algorithm.**** > > **** > > Peter Rybar**** > > **** > > > > Simon Tardell, **** > > Technology Nexus.**** > > On Fri, Oct 19, 2012 at 1:07 PM, Peter Rybar wrote:**** > > Stefan, > > I have a question about the present OCSP RFC and at the end of the mail > about the new situation which will happen according to your new proposal. > > The presence of the positive statement in OCSP response is important for > electronic signature validations, especially for an expired certificate. > Positive statement is the hash value of a certificate whose status is > provided in OCSP response. > > Electronic signature validation is usually about the signatures created i= n > the past and validated now, when the certificate is expired. > > When the certificate expires then revocation is usually removed from CRL > and the revoked certificate can be provided as "good" in OCSP response. > Is it acceptable? I think not. > > According to your new draft there is not defined a value of revocationTim= e. > RFC must also define the value of revocationTime when the certificate > which was never issued is as "revoked". > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pkix-rfc2560bis-06 > > Have you also covered the situation when the certificate is expired, > REMOVED FROM CRL and will be provided as revoked with incorrect > revocationTime e.g.with the value before or after the revocationTime whic= h > was present in the removed record from CRL? > Because according to sentence in your draft ""revoked" - This state SHOUL= D > also be returned if the responder knows that the requested certificate ha= s > never been issued." the following situation can happen: when certificate = is > removed from CRL after expiration and CA/OCSP responder is responsible fo= r > this certificate but have not record about expired certificate and for th= at > reason it is identified as "never been issued". > > ... > revoked [1] IMPLICIT RevokedInfo, > ... > > RevokedInfo ::=3D SEQUENCE { > revocationTime GeneralizedTime, > revocationReason [0] EXPLICIT CRLReason OPTIONAL } > > As you have mentioned in the mail:**** > > "On the "revoked" state, the old spec did not even consider the case of a > certificate being requested where the OCSP responder knows that the > certificate was never issued."**** > > "It simply recommend a known to be bad certificate to result > in "revoked" in order to prevent damage as far as possible. It also opens > for definition of new extensions through which such knowledge could be > obtained."**** > > Peter Rybar > National Security Authority > Information Security and Electronic Signature Department > Budatinska 30, 850 07 Bratislava 57, Slovak Republic > e-mail: peter.rybar@nbusr.sk > e-mail: peterryb@gmail.com**** > > > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > Stefan Santesson > Sent: Monday, October 15, 2012 1:49 AM > To: pkix@ietf.org > Subject: [pkix] New draft-ietf-pkix-rfc2560bis-06 > > All, > > I have just posted an update of rfc2560bis (OCSP update) after carefully > reviewing all comments on the list. > > Some notes about the update: > > - Added the previous OCSP editors with updated affiliations. > - Added some calcifications on ResponderID as suggested by Simon Josefsso= n. > - Updated the clarifications on Authorized responders. The requirements > have not changed. I just tried to improve the text. > - Updated a clarification on the "revoked" state to be the preferred > response if a certificate is known by the responder to never have been > issued. > - Some minor editorial nits. > > > Regarding backwards compatibility I mean that none of the clarifications > changes RFC 2560. > > On Authorized responders it has always been the case that a responder > certificate issued with the same key as was used to issue the certificate > being checked for revocation, represents a valid Authorized responder. > There has never been an explicit requirement to support key rollover and > key rollover support has never been in the "spirit" of the original > standard as it clearly attempted to provide direct cryptographic binding > between the responder and the CA. > > On the "revoked" state, the old spec did not even consider the case of a > certificate being requested where the OCSP responder knows that the > certificate was never issued. It is clearly counterproductive to respond > good when a certificate is known to be bad. A responder must pick one > response and picking "revoked" breaks nothing, but has the desired effect= , > that is, to prevent the certificate from being accepted. The current text > makes clear that there is no mechanism in the current standard by which a > client can know how a responder will respond to a request for a not issue= d > certificate. It simply recommend a known to be bad certificate to result > in "revoked" in order to prevent damage as far as possible. It also opens > for definition of new extensions through which such knowledge could be > obtained. > > The current updates also clearly opens a path for the CAB forum efforts t= o > define a suitable solution for server certificates. > > I have not, even thug suggested, added any requirements on what clients > should do with the checked cert as a result of a particular response. I > don't believe such requirements are suitable as it is policy and not > protocol. We have no right to demand that all systems MUST reject any > certificate for any reason as they may have a local policy that overrules > the OCSP response. This protocol only provides information about the cert > status, it does not mandate validation policy. > > I have not included any of the substantial changes i the Pinkas draft. I > want to wait for a list of motivation for each change before including an= y > of them. So there changed may be up for debate before this draft is ready > for WGLC. > > /Stefan > > > > _______________________________________________ > 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**** > > **** > > _______________________________________________ pkix mailing list > pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix**** > > --bcaec554df5a9a974404cca88a37 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Mon, Oct 22, 2012 at 5:57 PM, Stefan = Santesson <stefan@aaa-sec.com> wrote:

I could live with a wording = saying that a responder MAY respond "unknown" to a request for a = known fraudulent (or not never issued) cert if the responder possess such k= nowledge of course..

I think it is unfortunate to reopen = this discussion now.

I suggest that we use your cu= rrent text plus that, if "revoked" is used to say "never iss= ued/not in database", the revocationReason should be certificateHold a= nd that revocationTime should be set to midnight Jan 1 1950 (or some other = time before the rise of PKI).
=A0
On the other hand, I think we should consider Denis'= comment:

Saying that the certificate has not bee= n issued is not fully appropriate.
The text should be modified in the f= ollowing way:
=A0=A0 "The "revoked"= state indicates that the certificate has been revoked=A0
=A0=A0 (either permanently or temporarily (= on hold)).=A0 This state SHOULD=A0
=A0=A0 also be returned if th= e responder=A0has an access to t= he database=A0
=A0=A0 of=A0
=A0=A0 of=A0=A0issued certificates and if the serial n= umber of the target=A0
=A0=A0 certificate is not present i= n that database.=A0
=A0=A0=A0In this case, the "revoked" state indicates eithe= r that the=A0
=A0=A0 certificate has never been i= ssued or that it has been issued but=A0
=A0=A0 subsequently removed (by an attack or by accident) from the= =A0
=A0=A0 database=A0of issued certificates.
=A0=A0 Response extensions may be us= ed=A0 to convey additional information=A0
=A0=A0 on assertions made by the=A0OCSP=A0 responder regarding the state of the=A0
=A0=A0 certificate such as=A0= an=A0indication that the=A0OCSP=A0responder has=A0
=A0=A0 a direct access to the=A0
=A0=A0 a direct access to the=A0da= tabase of issued certificates, v= alidity, etc ... "

It should be difficult for the responder to tell the di= fference by itself, but I think, given the kind of hair-splitters we are, i= t is best to be as clear as possible. ;)

/Simon

Note that this does not have to mean that the CA is broken, is = may also be due to an error in the request from the client.

/Stefan


From: Piyush Jain <piyush@ditenity.com>Date: Monday, October 22, 2012 5:= 32 PM

I=92m sorry but definition of not issued is still unclear to= me if you say that that a certificate can be cryptographically bound to th= e CA and still not-issued.

The ambiguity is introduced because now I ca= n do everything that 5280 asks me to validate a certificate and still canno= t be sure if the certificate was ever issued.

=A0

Here are the scenarios where meaning of not issued is unclea= r to me.

1)=A0=A0=A0=A0=A0 A genuine certificate issued by the CA, present in the CA database=

2)=A0=A0=A0=A0=A0 A genuine certificate issued by the CA, removed from the CA database by t= he CA

3)=A0=A0=A0=A0=A0 A genuine certificate issued by the CA, removed from the CA database by a= n attacker

4)=A0=A0=A0=A0=A0 A fraudulent certificate issued by an attacker, present in the CA databas= e

5)=A0=A0=A0=A0=A0 A fraudulent certificate issued by an attacker, removed from the CA datab= ase

6)=A0=A0=A0=A0=A0 A fraudulent certificate containing an AIA pointing to a fraudulent OCSP = responder (also cryptographically bound to the CA), issued by an attacker, = removed from the CA database.

=A0

If the CA can differentiate among these cases, it can mark t= he fraudulent certificates as revoked and we won=92t need an overloaded def= inition of not-issued. Also not that if an attacker can carry out =914=92 i= t can also carry out =915=92 and =916=92

=A0

The people who are convinced that this is the way to go have= not addressed the issues raised in this WG. The little extension does not = hurt anyone but it does not provide any value in general except to a few im= plementations which are compromised. But it does take you down a slippery s= lope when you start promising that an OCSP responder can do much more than = it is supposed to.

I don=92t think that it is unreasonable for = a smart implementer to stop signature checking if his responder claims that= it checks issuance.

=A0

As for the diginotor case, for some people who say that secu= rity breach could=92ve been detected early if this practice was in place, t= here is another set of people who believe that attacker could=92ve circumve= nted these measures quite easily with the kind of access he had.<= /u>

=A0

If you and other folks in the group feel that this text shou= ld be added, I think at the minimum we also need to do the following=

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 Provide explicit guidance on what the revocation time should b= e. Such certificates are different from =91normal=92 revoked certificate an= d their revocation time should probably be set to something before the vali= dity of issuing CA. This distinction is important for time based validation= s and long term archiving applications

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 I think it will be useful to indicate in the security consider= ations section, that in such a scenario, CA is compromised and that there i= s a high chance that RP is interacting with a compromised responder.=

=A0

=A0

From: Stefan Santesson [mailto:stefan@aaa-sec.com]
Sent: Sunday, October 21, 2012 11:03 AM
To: Piyush Jain; &= #39;Peter Rybar'; 'Carl Wallace'; 'Simon Tardell'
Cc: 'Peter Rybar'; pkix@ietf.org
Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06<= /span>

=A0

In line;

=A0

From: Piyush= Jain <piyush@d= itenity.com>
Date: Sunday, October 21, 2012 7:42 PM
To: Stefan Santesso= n <stefan@aaa-se= c.com>, 'Peter Rybar' <rybar@nbusr.sk>, 'Carl Wallace' <carl@redhoundsoftw= are.com>, 'Simon Tardell' <simon@tardell.se>
Cc: 'Peter Rybar' <peterryb@gmail.com>, <pkix@ietf.org>
Subject: RE: [pki= x] New draft-ietf-pkix-rfc2560bis-06

=A0

So what is =93not-issued=94 - not = signed by the CA or not present in CA database?<= /span>

=A0

Not issued means it has never been issued. What's unc= lear about that?

=A0

O= f course it is not present in the database if it is not issued.

If you delete things from your database and don'= t know if this one has been deleted, then you don't know that it has ne= ver been issued and can't reply revoked.

=A0

<= u>=A0

It is unclear to folks who have been using signatu= re verification as a way to check issuance. Isn=92t it a fair conclusion th= at I do not need to perform signature checks if the responder can check iss= uance for me?

=A0

No that is not a fair conclusion. These are entirely diff= erent things.

=A0

=A0

You said that the possibility to send= revoked reply only applies when the responder =92knows=92 that requested c= ertificate has never been issued.

Please note that the responder will encounte= r this kind of request only in two situations. First in which the RP sends = a request for a certificate without checking the signature and second in wh= ich the responder itself is compromised by virtue of its issuing authority = being compromised. In either case what the responder responds with does not= matter.

=A0

=A0

Some people are pretty convinced it does (from CAB f= orum), they are so convinced that they are prepared to break compatibility = with OCSP. By this little extension that hurst no-one, they don't have = to.

=A0

I=92ve no problem with your propos= al to respond with =91revoked=92 in this situation.<= /u>

=A0

Good.

=A0

I=92ve fundamental problem with th= e introduction of =91non-issued=92 concept in OCSP, which seems to provide = additional security in this exceptional scenario without actually providing= any.

=A0

It provides some, but not much. People keep coming back t= o that fact that if this had been the practice of Diginotar, the security b= reach would have been discovered a lot earlier. So there might be some gain= with no pain.

=A0

H= owever, in combination with an extension that adds information, this might = actually be increasingly valuable.

If an OCSP responder starts receiving status request= s for certs it knows it has not issued, it can actually give explicit infor= mation about this using an extension and it can take adequate measures.<= /u>

But in order to respond to the user, it need to pick= one of the responses. Either good + extension or revoked+extension.=

=A0

T= his proposal is not meant to require any OCSP responder to deal with the co= ncept of "non-issued" certs. It merely allows an OCSP responder t= o respond to such request.

=A0

=A0

It=92ll be very helpful if I can see = at least one practical scenario where this additional text would add value.=

=A0

Stated in my previous comments.

=A0

/= Stefan

=A0

=A0

-Piyush

From: Stefan Santesson [mailto:stefan@aaa-sec.com]
Sent: Sunday, October 21, 2012 8:52 AM
To: Piyush Jain; &#= 39;Peter Rybar'; 'Carl Wallace'; 'Simon Tardell'
= Cc: 'Peter Rybar'; pkix@ietf.org
Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06

=A0<= u>

I don't think the "not issued&qu= ot; is unclear.

=A0

=

The possibility to send a revoked reply only applies then the r= esponder "knows" that the requested certificate has never been is= sued.

How the responder knows this is totally irrelevant, = but unless the responder knows this, it can't choose this option and ha= s to reply "good".

=A0

=

It does not make revocation checking non-deterministric.=A0

"good" still means what is declared in the= standard (The cert is not known to be revoked, but it may never have been = issued).

"revoked" still have a deterministic meani= ng, that is, don't trust this cert. The old exact semantics was "t= he cert IS revoked". The new semantic is "the cert is revoked or = possibly might never been issued"

=A0

=

The new response semantic of revoked is backwards compatible an= d not less deterministic than the good, response.

=A0

=

So, I still don't see any practical problems here.

=A0

=

/Stefan

=A0

=

=A0

From: Piyush Jain <piyush@ditenity.com>
Date: Saturday, October 20, 2012 5:48 PM
To: Stefan Santes= son <stefan@aaa-= sec.com>, 'Peter Rybar' <rybar@nbusr.sk>, 'Carl Wallace' <carl@redhoundsof= tware.com>, 'Simon Tardell' <simon@tardell.se>
Cc: 'Peter Rybar' <peterryb@gmail.com>, <pkix@ietf.org>
Subject: RE: [pki= x] New draft-ietf-pkix-rfc2560bis-06

=A0

Please see inline<= /u>

=A0=

From: Stefan Santesson [mailto:stefan@aaa-sec.com]
Sent: Friday, October 19, 2012 7:23 PM
To: Piyush Jain; &#= 39;Peter Rybar'; 'Carl Wallace'; 'Simon Tardell'
= Cc: 'Peter Rybar'; pkix@ietf.org
Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06

=A0<= u>

I'm sorry. I fail to the any of the p= roblems you raise.

=A0

=

If you receive a request for a certificate that you know has ne= ver been issued, and you choose to reply revoked, what problems can you cau= se?

[Piyush] It depends on how = you define =93never been issued=94, which btw becomes unclear after introdu= ction of the new text. There are two interpretations

<= span>1)=A0=A0=A0=A0=A0 Certificate is not sign= ed by the CA or

<= span>2)=A0=A0=A0=A0=A0 Certificate is not pres= ent in the database of issued certificates that CA maintains.

One unintended consequence of first in= terpretation will be that RPs would stop performing signature checks if the= ir responder/CA publicizes that it returns revoked for =93non-issued=94 cer= tificates.

If the interpretation is 2, then this = scenario is not possible unless the CA is compromised.=

=A0

<= p class=3D"MsoNormal">What in your mind is a more appropriate response?

[Piyush] I would say the appropriate r= esponse is good (if the certificate is not marked as revoked), because that= is what the RP will see if it consults a CRL or a responder detached from = the CA.

Revoked for =93not issued=94 adds no v= alue because the only case in which an RP would send a query for a =93non-i= ssued=94 certificate is when the CA is compromised.=

=A0

=

It does not make OCSP more non-deterministic. If you ask status= for an issued cert from a non-broken CA, nothing is non-deterministic.

[Piyush] It does not make OCSP non-det= erministic but it makes revocation checking non-deterministic. The goal of = OCSP is to address operational limitations of CRLs, not functional limitati= ons.=A0 The fact that you=92ll get different answers from two sources, both= of which are authorized by the same CA makes revocation checking non deter= ministic.

=A0

If you ask for status for a non-issued certificate, or = a bad certificate from a broken CA, then the result is by default non-detem= inistic and has always been. However, choosing a revoked response may save = the relying party, at best, but can hurt no-one<= /span>

[Piyush] I agree that a revoke respons= e does not hurt anyone. But the point is that it provides a false sense of = additional security to the RP without providing any. As an RP, I won=92t tr= ust what my responder says if the authority that certified it is compromise= d.

=A0

What is your problem on the practical ground.

[Piyush] <= span style=3D"font-size:10.5pt;font-family:Calibri,sans-serif;color:rgb(31,= 73,125)">=A0Let=92s say that we still need to address this scenario and rev= oked is the appropriate response. In that case

<= span>-= =A0=A0=A0=A0=A0=A0=A0=A0=A0 The text needs t= o be explicit about the revocation time in this situation. Revoked implies = good until a certain date and this distinction is important for long term a= rchiving applications. For unissued certificate the revocation time should = probably be set to =96infinity.

<= span>-= =A0=A0=A0=A0=A0=A0=A0=A0=A0 It needs to call= out that in this particular scenario it is addressing a functional limitat= ion of CRLs (ability to detect CA compromise) not an operational limitation= .

<= span>-= =A0=A0=A0=A0=A0=A0=A0=A0=A0 I think we need = additional text in security considerations to indicate that RP is communica= ting with a responder certified by a compromised CA in this scenario.

=A0

<= p class=3D"MsoNormal">=A0

/Stefan

<= div>

=A0

From: Piyush Jain <piyush@ditenity.com>
Date: Friday, October 19, 2012 7:34 PM
To: Stefan Santesso= n <stefan@aaa-se= c.com>, 'Peter Rybar' <rybar@nbusr.sk>, 'Carl Wallace' <carl@redhoundsoftw= are.com>, 'Simon Tardell' <simon@tardell.se>
Cc: 'Peter Rybar' <peterryb@gmail.com>, <pkix@ietf.org>
Subject: RE: [pki= x] New draft-ietf-pkix-rfc2560bis-06

=A0

Stefan,=

=A0

I think some of you interpretations below ar= e twisted to accommodate the new provisions for providing revoked responses= for unissued certificates.

Providing responses for expired certificates= is within the scope of 2560 using archive cutoff extension.

=A0

The original authors of 2560 can correct me if = I=92m wrong, but it is my understanding that a response from OCSP responder= is not supposed to indicate if a certificate is good or bad but to indicat= e if a certificate is revoked or unrevoked by the issuing authority. The fa= ct that certificate is issued by the CA is checked by the RP by verifying t= he signature on the certificate.

=A0

This draft introduces the concept of returning = revoked responses for unissued certificates. There are many unintended cons= equences of this approach

<= span>-= =A0=A0=A0=A0=A0=A0=A0=A0=A0 Revocation statuse= s become non-deterministic based on who you are asking (A responder with ac= cess to CA database vs. one without vs. checking status off a CRL). If I=92= m archiving a signed document with the relevant artifacts to determine the = validity status of the document, this becomes a huge problem. Note that a r= evoked status implies that certificate was good between the time of its iss= uance and that of its revocation. Any document that is signed within that p= eriod should still be considered valid.

<= span>-= =A0=A0=A0=A0=A0=A0=A0=A0=A0 It would confuse a= n implementer about what =93non-issued=94 means. The fact that the CA signe= d the certificate implies it was issued. If a certificate is issued fraudul= ently, based on its security practices, it is up to the CA to either revoke= the issued certificate, or ask its issuing authority to revoke its own cer= tificate.

=A0

-Piyush

=A0

=A0

=A0

=A0

From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Beha= lf Of Stefan Santesson
Sent: Friday, October 19, 2012 7:25 AM
To: Peter Rybar; &#= 39;Carl Wallace'; 'Simon Tardell'
Cc: 'Peter Ryba= r'; pkix@ietf.org
Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06

=A0<= u>

From: Peter Rybar <rybar@nbusr.sk>
Date: Friday, October 19, 2012 3:12 PM
To: 'Carl Walla= ce' <= carl@redhoundsoftware.com>, 'Simon Tardell' <simon@tardell.se>
Cc: 'Peter Rybar' <peterryb@gmail.com>, Stefan Santesson <stefan@aaa-sec.com>= , <pkix@ietf.org&= gt;
Subject: RE: [pkix] New draft-ietf-pkix-rfc2560bis-06

=A0

Well, yes, sort of. You can only be sure to validate a signatur= e at the moment of production.

=A0

What if the signature key was compromised at the moment = of production but is not yet on a revocation list?

[PR] According to clause 2.4 =A0-=A0 thisUpdate: The tim= e at which the status being indicated is known to be correct

It means when signature time-stamp time is X then any OC= SP responses with thisUpdate time X+y are sufficient to validate because th= e status is correct.

Y is in the interval <0, producedAt - X>

=A0

At any later point in time the signature k= ey may be compromised, or the algorithms involved may have become to weak. = (In which case the time of revocation in the OCSP response is worth nothing= to you). The risk increases as time passes. And of course, the revocation = information may not be kept around after the expiry of the certificate.=A0<= /span>

=A0

That's why you should validate signatures as soon as possible.=A0=

=A0

For these archival purposes wouldn't it be bet= ter to have the final revocation list before removed due to expiry? =A0In a= ny case, you'd need verification information collected after some grace= period following moment of production.

[PR] Grace period is not a fixed value of the= time interval.

Grac= e period is changeable because the first OCSP response with thisUpdate time= value > than time of signature time-stamp contains correct status.

=A0

=A0

If you need to ascertain that a signature was valid at a later time, = you have to trust your system that it performed the validation at the time = it first received the signature. That trust must be established through som= e kind of mix of policies and technical measures (such as timestamping).

=A0

In the dark corner just beyond the dark corner tha= t is SCVP, there's a spec (RFC 5276) that defines a binding of evidence= records to artifacts that can be returned viaSCVP. =A0This provides for ti= mestamping. =A0

[PR] The validation is simplified when OCSP response wit= h positive statement as a hash value of requested certificate is used.

Positive statement is evidence that OCSP know the status= of certificate and also protect the integrity of certificate with a new mo= re secure hash algorithm.

=A0

=

Peter Rybar

=A0



Simon Tardell,=A0

Technology Nexus= .

On Fri, Oct 19, 2012 at 1:07 PM, Peter Rybar <rybar@nbusr.sk> wrote:<= /span>

Stefan,

I have a question about the present OCSP RFC and= at the end of the mail about the new situation which will happen according= to your new proposal.

The presence of the positive statement in OCSP response is important fo= r electronic signature validations, especially for an expired certificate. = Positive statement is the hash value of a certificate whose status is provi= ded in OCSP response.

Electronic signature validation is usually about the signatures created= in the past and validated now, when the certificate is expired.

Whe= n the certificate expires then revocation is usually removed from CRL and t= he revoked certificate can be provided as "good" in OCSP response= .
Is it acceptable? I think not.

According to your new draft there is = not defined a value of revocationTime.
RFC must also define the value of= revocationTime when the certificate which was never issued is as "rev= oked".
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pkix-rfc2= 560bis-06

Have you also covered the situation when the certifica= te is expired, REMOVED FROM CRL and will be provided as revoked with incorr= ect revocationTime e.g.with the value before or after the revocationTime wh= ich was present in the removed record from CRL?
Because according to sentence in your draft ""revoked" - Thi= s state SHOULD also be returned if the responder knows that the requested c= ertificate has never been issued." the following situation can happen:= when certificate is removed from CRL after expiration and CA/OCSP responde= r is responsible for this certificate but have not record about expired cer= tificate and for that reason it is identified as "never been issued&qu= ot;.

...
revoked =A0 =A0 [1] =A0 =A0 IMPLICIT RevokedInfo,
...

= =A0 =A0RevokedInfo ::=3D SEQUENCE {
=A0 =A0 =A0 =A0revocationTime =A0 = =A0 =A0 =A0 =A0 =A0 =A0GeneralizedTime,
=A0 =A0 =A0 =A0revocationReason = =A0 =A0[0] =A0 =A0 EXPLICIT CRLReason OPTIONAL }

As you have mentioned in the mail:

"On the "revoked" state, the old spec did = not even consider the case of a certificate being requested where the OCSP = responder knows that the certificate was never issued."

"It simply recom= mend a known to be bad certificate to result
in "revoked" in o= rder to prevent damage as far as possible. It also opens
for definition of new extensions through which such knowledge could be
o= btained."

Peter Rybar
National Security Authority
Information Security and = Electronic Signature Department
Budatinska 30, 850 07 Brati= slava 57, Slovak Republic
e-mail: peter.rybar@nbusr.sk
e-mail: peter= ryb@gmail.com


-----Original Message-----
From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf = Of Stefan Santesson
Sent: Monday, October 15, 2012 1:49 AM
To: pkix@ietf.org
Subject: [pkix] New draft-ietf-p= kix-rfc2560bis-06

All,

I have just posted an update of rfc256= 0bis (OCSP update) after carefully
reviewing all comments on the list.

Some notes about the update:
=
- Added the previous OCSP editors with updated affiliations.
- Added= some calcifications on ResponderID as suggested by Simon Josefsson.
- Updated the clarifications on Authorized responders. The requirements
= have not changed. I just tried to improve the text.
- Updated a clarific= ation on the "revoked" state to be the preferred
response if a= certificate is known by the responder to never have been
issued.
- Some minor editorial nits.


Regarding backwards comp= atibility I mean that none of the clarifications
changes RFC 2560.
On Authorized responders it has always been the case that a responder
certificate issued with the same key as was used to issue the certificatebeing checked for revocation, represents a valid Authorized responder.There has never been an explicit requirement to support key rollover and key rollover support has never been in the "spirit" of the origin= al
standard as it clearly attempted to provide direct cryptographic bind= ing
between the responder and the CA.

On the "revoked" = state, the old spec did not even consider the case of a
certificate being requested where the OCSP responder knows that the
cert= ificate was never issued. It is clearly counterproductive to respond
goo= d when a certificate is known to be bad. A responder must pick one
response and picking "revoked" breaks nothing, but has the desire= d effect,
that is, to prevent the certificate from being accepted. The current textmakes clear that there is no mechanism in the current standard by which a=
client can know how a responder will respond to a request for a not iss= ued
certificate. It simply recommend a known to be bad certificate to resultin "revoked" in order to prevent damage as far as possible. It a= lso opens
for definition of new extensions through which such knowledge = could be
obtained.

The current updates also clearly opens a path for the CAB = forum efforts to
define a suitable solution for server certificates.
=
I have not, even thug suggested, added any requirements on what clients=
should do with the checked cert as a result of a particular response. I
= don't believe such requirements are suitable as it is policy and notprotocol. We have no right to demand that all systems MUST reject any
certificate for any reason as they may have a local policy that overrulesthe OCSP response. This protocol only provides information about the cert=
status, it does not mandate validation policy.

I have not includ= ed any of the substantial changes i the Pinkas draft. I
want to wait for a list of motivation for each change before including any<= br>of them. So there changed may be up for debate before this draft is read= y
for WGLC.

/Stefan



______________________________= _________________
pkix mailing list
pki= x@ietf.org
https://www.ietf.org/mailman/listinfo/pkix

_____= __________________________________________
pkix mailing list
pki= x@ietf.org
https://www.ietf.org/mailman/listinfo/pkix=

=A0

_______________________________________________ pkix mailing = list pkix@ietf.org <= a href=3D"https://www.ietf.org/mailman/listinfo/pkix" target=3D"_blank">htt= ps://www.ietf.org/mailman/listinfo/pkix

=
An attacker can substitute any response with any kind of error.
Or make the DNS lookup of the OCSP responder fail, or insert
a ICMP error or TCP on the connection attempt to the OCSP responder.

Correct. And? Whatever you ask the CA to do, = the attacker can avoid it. Wrong end of the problem.
=C2=A0
> > I don't like= the particular date Jan 1, 1950, for safety, a date >=3D 1970
> > ought to be chosen (so that it does not get negative when convert= ed
> > to time_t, which has potential to confuse some code).
> >
> > And since the timestamp is a GeneralizedTime, the date ought to b= e
> > given in exactly that format, e.g. =C2=A0"700101010101Z"= ;
> >
> > What also should be noted is that the optional OCSP SingleRespons= eExtension
> > "CrlID" must not be used when this "not issued&quo= t; certificate was not
> > conveyed through a CRL--and there currently is no means to convey=
> > proof-of-cert-existence through CRLs unless they're revoked, = and in the
> > latter case there would be no "not issued" OCSP respons= e to convey.
>
> See, by declaring a non-issued certificate as revoked, you're aski= ng
> the CA to lie about its revocation date and declare it's not been<= br> > issued in a CRL. How can it be right?

You're absolutely NOT lying at all. =C2=A0The cert with that seri= al has
not been issued yet, but a cert with that cert may get issued in the
future. =C2=A0The CertificateHold is perfectly appropriate to describe
this situation.

The OCSP request doesn'= t match an existent certificate, yet you want the CA to declare it as revok= ed, discuss about the correct revocation reason to use, and a correct revoc= ation date. But this response is not a lie. Something's wrong.
=C2=A0
> >= I believe it is very inappropriate for the spec to make any assumptions > > about why exactly the OCSP responder believes that a cert (serial= ) has not
> > ever been issued. =C2=A0The reason can be manyfold. =C2=A0Besides= an accidental or
> > fraudulent deletion (attack), it may be something as simple as a<= br> > > database software bug.
>
> Or invalid encoding in client, or wrong issuerKeyHash (the serial
> exists, but for another CA), or random serial, or specially crafted > numbers, or unrecognized hash function, ... All these cases have been<= br> > spotted on our responders, and we haven't wrongly issued certifica= tes.

I was saying that the spec should advise against OCSP response recipi= ents
to draw conclusions (about causes), and take the response as what it is, a description of state, *NOT* an indicator of any precice cause.

That's the good end of = the problem.

--
Erwann.
--f46d04428dc009e31e04ccb74ac1-- From eabalea@gmail.com Tue Oct 23 03:28:02 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5E0421F86B4 for ; Tue, 23 Oct 2012 03:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qOoPy+CLp-NX for ; Tue, 23 Oct 2012 03:28:02 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id C421121F86AA for ; Tue, 23 Oct 2012 03:28:01 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so2063664wgb.13 for ; Tue, 23 Oct 2012 03:27:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=r8EIE0v16GO2ya1er/LoXIBN+T53Qx9iDQcF2SQyMIg=; b=I9Qxjrxod75uZC2ERvi//NxrIbegyKwTUYyv+RKT7I7mQjHea3GImxkb06WQHry7My ReA83QOzIfECPSBJNtAHWiLdk+W0wDIqEUPjA/zDJgwAWsJIa0drWFW6cwVfriYCEa+z e2H68VgHGp6IpnyazSceBez+TOGQdkysc4XZFMHOd4peEhpLNhI+h8qXu5HCFlyh9DBj e97Aqkl6PeTqtXW2BQoa6PEXOBaQZEP/DHXisWhjY1eoPCb/AvbCXRaCba4sxPT5q1x6 J9IHU0KhpTVmFdrH7WC1CGq0d7lR91wAe5XJa4Uw8t9ACPPnPpyJ4OcATHXmP4Tt2oqI ISog== MIME-Version: 1.0 Received: by 10.180.96.164 with SMTP id dt4mr43690958wib.10.1350988078585; Tue, 23 Oct 2012 03:27:58 -0700 (PDT) Received: by 10.223.133.194 with HTTP; Tue, 23 Oct 2012 03:27:58 -0700 (PDT) In-Reply-To: <20121023101725.6273E1A2EE@ld9781.wdf.sap.corp> References: <50866A61.3070404@bull.net> <20121023101725.6273E1A2EE@ld9781.wdf.sap.corp> Date: Tue, 23 Oct 2012 12:27:58 +0200 Message-ID: From: Erwann Abalea To: mrex@sap.com Content-Type: multipart/alternative; boundary=f46d04426e2085158b04ccb76c25 Cc: pkix@ietf.org Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 10:28:02 -0000 --f46d04426e2085158b04ccb76c25 Content-Type: text/plain; charset=UTF-8 2012/10/23 Martin Rex > Denis Pinkas wrote: > > > > The certificateHold state was not created to have certificates issued > > in a suspended state. It was created to allow a user to suspend its > > certificates rather than revoking its certificates, in case a smart > > card was temporarily lost and since after a revocation it may take > > a while to get a new smart card. > > > > Some people, then used also the certificateHold state to have > > certificates issued in a suspended state. This is legitimate since > > it complies with the semantics of the certificateHold state. > > > > We should not change/overload the meaning of CertificateHold. > > > The purpose of the CertificateHold is to convey from the CA to the RP > "you should not currently trust the certificate with this serial, > because it is not certain that the entity which is currently > in control of the associated private key is actually the entity > which the cert says it is." > RFC5280 doesn't say anything about the meaning of revocation reason codes. X.509 do, in 8.5.2.2: "A certificate may be placed on hold by issuing a CRL entry with a reason code of certificateHold. The certificate hold notice may include an optional hold instruction code to convey additional information to certificate users (see 8.5.2.3)." -- Erwann. --f46d04426e2085158b04ccb76c25 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2012/10/23 Martin Rex <= mrex@sap.com>
Denis Pinkas wrote:
>
> The certificateHold state was not created to have certificates issued<= br> > in a suspended state. It was created to allow a user to suspend its > certificates rather than revoking its certificates, in case a smart > card was temporarily lost and since after a revocation it may take
> a while to get a new smart card.
>
> Some people, then used also the certificateHold state to have
> certificates issued in a suspended state. This is legitimate since
> it complies with the semantics of the certificateHold state.
>
> We should not change/overload the meaning of CertificateHold.


The purpose of the CertificateHold is to convey from the CA to the RP=
"you should not currently trust the certificate with this serial,
because it is not certain that the entity which is currently
in control of the associated private key is actually the entity
which the cert says it is."

RFC528= 0 doesn't say anything about the meaning of revocation reason codes.
X.509 do, in 8.5.2.2:
"A certificate may be placed on hold by issuing a CRL entry with a rea= son code of certificateHold. The certificate hold
notice may incl= ude an optional hold instruction code to convey additional information to c= ertificate users (see 8.5.2.3)."

--
Erwann.
--f46d04426e2085158b04ccb76c25-- From mrex@sap.com Tue Oct 23 03:38:41 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28A2921F86B4 for ; Tue, 23 Oct 2012 03:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.208 X-Spam-Level: X-Spam-Status: No, score=-10.208 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMvtpriRe5IJ for ; Tue, 23 Oct 2012 03:38:40 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id DE40521F86BE for ; Tue, 23 Oct 2012 03:38:39 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q9NAcV82028823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 23 Oct 2012 12:38:36 +0200 (MEST) In-Reply-To: To: Erwann Abalea Date: Tue, 23 Oct 2012 12:38:29 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20121023103829.53FA01A2EE@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: Peter Rybar , pkix@ietf.org, Stefan Santesson Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 10:38:41 -0000 Erwann Abalea wrote: > >> >> CertificateHold is EXACTLY the correct ReasonCode: >> It indicates that the CA has not issued a cert with the given serial >> *YET*, but it MAY eventually issue such a cert in the future >> (sometimes even in the _very_next_future_ ... i.e. it is about >> to become visible to the OCSP responder, but not visible yet). > > > No. It indicates that the corresponding (existent) certificate has been put > on hold. > You're asking the CA to assert a status for a non-existent certificate. Where exactly does X.509 or PKIX require that a serial on a CRL will have to refer to an existing cert, i.e. one that the CA has positive proof to have issued. I (now) believe this is a completely flawed assumption. CRLs and OCSP only assert a state to a certificate serial. Infering about existance/noexistance of certs is a logical fallacy. > > What's next? Ask CAs to sign the next OCSP response with a "removeFromCRL" > code for dumb serial numbers for which they replied "certificateHold"? Why > not also add a holdInstructionCode extension to the OCSP response, and > define proper codes? removeFromCRL doesn't make sense in an OCSP response, because OCSP does not hand out CRLs. > > The number of bogus requests far outweighs the number of bad certificates. > In our case, as a public CA, it even outweighs the number of good public > certificates we produced. > > Asking for a signed response to a bogus request gives anonymous attackers > much power. Consider big CAs that receive billions of OCSP requests a week, > or even a day (that's reality). Do you really consider that asking for > billions of signatures a day for bogus requests, asserting an authoritative > status for nonexistent certificate is the right thing to do? > > With my "CA" hat, I see that OCSP is a hidden cost, and you want to make it > more costly. Having an OCSP responder look at cert issuance logs and produce an intelligible, risk-reducing response rather that an entirely useless response will be a completely optional feature! Nobody is pushing *YOU* to have your OCSP responder adopt this. But why are you so obsessed in denying others that possibility? If you're concerned about the load of creating signatures for "not issued" requests, you may want to talk to Denis first, who proposed to create signatures on errors, and in particular on "not authorized" errors (which includes requests for status of certs from other CAs). -Martin From mrex@sap.com Tue Oct 23 03:50:32 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16CE321F86D0 for ; Tue, 23 Oct 2012 03:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.209 X-Spam-Level: X-Spam-Status: No, score=-10.209 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTVv170RmGJQ for ; Tue, 23 Oct 2012 03:50:31 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 49ECD21F86CB for ; Tue, 23 Oct 2012 03:50:30 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q9NAoNrg017498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 23 Oct 2012 12:50:24 +0200 (MEST) In-Reply-To: To: Erwann Abalea Date: Tue, 23 Oct 2012 12:50:23 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20121023105023.569FB1A2EE@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: pkix@ietf.org Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 10:50:32 -0000 Erwann Abalea wrote: > > RFC5280 doesn't say anything about the meaning of revocation reason codes. > X.509 do, in 8.5.2.2: > "A certificate may be placed on hold by issuing a CRL entry with a reason > code of certificateHold. The certificate hold > notice may include an optional hold instruction code to convey additional > information to certificate users (see 8.5.2.3)." Now you're kidding me. We're talking about the semantics of the "certificateHold" status. A protocol element without semantics would be utterly useless. And the text that you quote gives a STRONG HINT that this status was intended to have a rather broad meaning, and not only the narrow meaning of two specific usage cases that you mentioned (token lost, or new token in the mail). -Martin From eabalea@gmail.com Tue Oct 23 04:24:58 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5D921F86D5 for ; Tue, 23 Oct 2012 04:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3+wE4jVNnDl for ; Tue, 23 Oct 2012 04:24:57 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id B1BB021F86CF for ; Tue, 23 Oct 2012 04:24:56 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so2596061lam.31 for ; Tue, 23 Oct 2012 04:24:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6z1PDPOQr1bI8lKYZFiKwYGZ9JyYyTxoaVVudNlGs/I=; b=sQkX1SVOeF+A3shqWrfOn0TdglYlfKt00lCpzZUnJkBnz0Tfmnyan2/aNS+zARFpEr e4JO5LK55olVt72rPAJGwtRL+jIhBGKYI5WcqmXJjHJJShWyNU591SPJTQ7kkKUDyu7+ pjSzETYw5xD2/UuScATK+GpPAxeFnant8W/iNgJiOYBis0/ePrL+nGuXl8nBBeaqCe2e VlpZxdhWUGCiP2jItSu7Cbu71U7j7TfFYYGtx06D6xBjOpMbXWHZeUek1Fd8kNKR/gZT yOtpnKdgkDI6knl0jH5ZjWW0Rq73HkCn/O2T1wW7s/QrdiaFj4uF5+z+nPtylF8F1Otd wC6A== MIME-Version: 1.0 Received: by 10.112.38.65 with SMTP id e1mr5071923lbk.15.1350991495432; Tue, 23 Oct 2012 04:24:55 -0700 (PDT) Received: by 10.114.25.74 with HTTP; Tue, 23 Oct 2012 04:24:55 -0700 (PDT) In-Reply-To: <20121023103829.53FA01A2EE@ld9781.wdf.sap.corp> References: <20121023103829.53FA01A2EE@ld9781.wdf.sap.corp> Date: Tue, 23 Oct 2012 13:24:55 +0200 Message-ID: From: Erwann Abalea To: mrex@sap.com Content-Type: multipart/alternative; boundary=e0cb4efe31182e0a2204ccb838cd Cc: Peter Rybar , pkix@ietf.org, Stefan Santesson Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 11:24:58 -0000 --e0cb4efe31182e0a2204ccb838cd Content-Type: text/plain; charset=UTF-8 2012/10/23 Martin Rex > Erwann Abalea wrote: > >> CertificateHold is EXACTLY the correct ReasonCode: > >> It indicates that the CA has not issued a cert with the given serial > >> *YET*, but it MAY eventually issue such a cert in the future > >> (sometimes even in the _very_next_future_ ... i.e. it is about > >> to become visible to the OCSP responder, but not visible yet). > > > > No. It indicates that the corresponding (existent) certificate has been > put > > on hold. > > You're asking the CA to assert a status for a non-existent certificate. > > Where exactly does X.509 or PKIX require that a serial on a CRL > will have to refer to an existing cert, i.e. one that the CA has > positive proof to have issued. I (now) believe this is a completely > flawed assumption. > X.509, 7.3 revokedCertificates identifies certificates that have been revoked. The revoked certificates are identified by their serial numbers. CRL as in "Certificate Revocation List", not as in "inexistent Certificate Revocation List". Fraudulently producing certificates is bad, but producing a CRL for nonexistent certificate is good? CRLs and OCSP only assert a state to a certificate serial. > Infering about existance/noexistance of certs is a logical fallacy. The certificate is identified by its serial number (along with its issuer name, of course). What is the meaning/value of a serial number that doesn't identify anything? > > What's next? Ask CAs to sign the next OCSP response with a > "removeFromCRL" > > code for dumb serial numbers for which they replied "certificateHold"? > Why > > not also add a holdInstructionCode extension to the OCSP response, and > > define proper codes? > > removeFromCRL doesn't make sense in an OCSP response, because OCSP does > not hand out CRLs. > But holdInstructionCode could make sense, right? > The number of bogus requests far outweighs the number of bad certificates. > > In our case, as a public CA, it even outweighs the number of good public > > certificates we produced. > > > > Asking for a signed response to a bogus request gives anonymous attackers > > much power. Consider big CAs that receive billions of OCSP requests a > week, > > or even a day (that's reality). Do you really consider that asking for > > billions of signatures a day for bogus requests, asserting an > authoritative > > status for nonexistent certificate is the right thing to do? > > > > With my "CA" hat, I see that OCSP is a hidden cost, and you want to make > it > > more costly. > > > Having an OCSP responder look at cert issuance logs and produce an > intelligible, risk-reducing response rather that an entirely useless > response will be a completely optional feature! > > Nobody is pushing *YOU* to have your OCSP responder adopt this. > > But why are you so obsessed in denying others that possibility? > > > If you're concerned about the load of creating signatures > for "not issued" requests, you may want to talk to Denis first, > who proposed to create signatures on errors, and in particular on > "not authorized" errors (which includes requests for status of > certs from other CAs). > I apologize if I offended you, I'm not pointing at you personally, just replying to the thread. I choose an anchor and it was one of your posts, nothing more. I have nothing against a "positive assertion", maybe the hash of the certificate for which the responder produces a good answer. If the responder can have access to an issuance log and pick useful authoritative information from it and optionally deliver it with the response, I'm fine. Asking for a signed response from a bogus request is different. The thread then slept into producing a revoked response for bogus requests, and discussing about what could a plausible reason code and revocation date be. I believe that a well-behaving CA shouldn't produce a CRL containing random serial numbers provided by anonymous requesters. By extension, I believe that a well-behaving OCSP responder shouldn't assert anything authoritative (either good or revoked) about a random serial number. That's a fail for the "good" response because an OCSP responder can be based on a blacklist, I don't think that changing "good" into "revoked" is the right way to solve this problem. -- Erwann. --e0cb4efe31182e0a2204ccb838cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2012/10/23 Martin Rex <= mrex@sap.com>
Erwann Abalea wrote:
>> CertificateHold is EXACTLY the correct ReasonCode:
>> It indicates that the CA has not issued a cert with the given seri= al
>> *YET*, but it MAY eventually issue such a cert in the future
>> (sometimes even in the _very_next_future_ ... i.e. it is about
>> =C2=A0to become visible to the OCSP responder, but not visible yet= ).
>
> No. It indicates that the corresponding (existent) certificate has bee= n put
> on hold.
> You're asking the CA to assert a status for a non-existent certifi= cate.

Where exactly does X.509 or PKIX require that a serial on a CRL
will have to refer to an existing cert, i.e. one that the CA has
positive proof to have issued. =C2=A0I (now) believe this is a completely flawed assumption.

X.509, 7.3
revokedCertificates identifies certificates that have been revoked. T= he revoked certificates are identified by their serial
numbers.

CRL as in "Certificate Revocation List"= , not as in "inexistent Certificate Revocation List".
F= raudulently producing certificates is bad, but producing a CRL for nonexist= ent certificate is good?

CRLs and OCSP only assert a s= tate to a certificate serial.
Infering about existance/noexistance of certs is a logical fallacy.

The certificate is identified by its serial number= (along with its issuer name, of course). What is the meaning/value of a se= rial number that doesn't identify anything?
=C2=A0
> What= 's next? Ask CAs to sign the next OCSP response with a "removeFrom= CRL"
> code for dumb serial numbers for which they replied "certificateH= old"? Why
> not also add a holdInstructionCode extension to the OCSP response, and=
> define proper codes?

removeFromCRL doesn't make sense in an OCSP response, because OCS= P does
not hand out CRLs.

But holdInstructionC= ode could make sense, right?

> The number of bogus requests far outweighs the numbe= r of bad certificates.
> In our case, as a public CA, it even outweighs the number of good publ= ic
> certificates we produced.
>
> Asking for a signed response to a bogus request gives anonymous attack= ers
> much power. Consider big CAs that receive billions of OCSP requests a = week,
> or even a day (that's reality). Do you really consider that asking= for
> billions of signatures a day for bogus requests, asserting an authorit= ative
> status for nonexistent certificate is the right thing to do?
>
> With my "CA" hat, I see that OCSP is a hidden cost, and you = want to make it
> more costly.


Having an OCSP responder look at cert issuance logs and produce an intelligible, risk-reducing response rather that an entirely useless
response will be a completely optional feature!

Nobody is pushing *YOU* to have your OCSP responder adopt this.

But why are you so obsessed in denying others that possibility?


If you're concerned about the load of creating signatures
for "not issued" requests, you may want to talk to Denis first, who proposed to create signatures on errors, and in particular on
"not authorized" errors (which includes requests for status of certs from other CAs).

I apologize if I= offended you, I'm not pointing at you personally, just replying to the= thread. I=C2=A0choose=C2=A0an anchor and it was one of your posts, nothing= more.

I have nothing against a "positive assertion"= , maybe the hash of the certificate for which the responder produces a good= answer. If the responder can have access to an issuance log and pick usefu= l authoritative information from it and optionally deliver it with the resp= onse, I'm fine.
Asking for a signed response from a bogus request is different. The th= read then slept into producing a revoked response for bogus requests, and d= iscussing about what could a plausible reason code and revocation date be.<= /div>

I believe that a well-behaving CA shouldn't p= roduce a CRL containing random serial numbers provided by anonymous request= ers.
By extension, I believe that a well-behaving OCSP responder = shouldn't assert anything authoritative (either good or revoked) about = a random serial number. That's a fail for the "good" response= because an OCSP responder can be based on a blacklist, I don't think t= hat changing "good" into "revoked" is the right way to = solve this problem.

--
Erwann.
--e0cb4efe31182e0a2204ccb838cd-- From mrex@sap.com Tue Oct 23 06:41:30 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 047BB21F8704 for ; Tue, 23 Oct 2012 06:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.21 X-Spam-Level: X-Spam-Status: No, score=-10.21 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aB+Z0g-uRsnK for ; Tue, 23 Oct 2012 06:41:29 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id DA2F921F86E4 for ; Tue, 23 Oct 2012 06:41:28 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q9NDfNXJ013092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 23 Oct 2012 15:41:24 +0200 (MEST) In-Reply-To: To: Erwann Abalea Date: Tue, 23 Oct 2012 15:41:21 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20121023134121.9FD8D1A2EE@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: Peter Rybar , pkix@ietf.org, Stefan Santesson Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 13:41:30 -0000 Erwann Abalea wrote: > Martin Rex wrote: >> >> Erwann Abalea wrote: >> >> CertificateHold is EXACTLY the correct ReasonCode: >> >> It indicates that the CA has not issued a cert with the given serial >> >> *YET*, but it MAY eventually issue such a cert in the future >> >> (sometimes even in the _very_next_future_ ... i.e. it is about >> >> to become visible to the OCSP responder, but not visible yet). >> > >> > No. It indicates that the corresponding (existent) certificate has been >> > put on hold. >> > You're asking the CA to assert a status for a non-existent certificate. >> >> Where exactly does X.509 or PKIX require that a serial on a CRL >> will have to refer to an existing cert, i.e. one that the CA has >> positive proof to have issued. I (now) believe this is a completely >> flawed assumption. > > X.509, 7.3 > revokedCertificates identifies certificates that have been revoked. The > revoked certificates are identified by their serial > numbers. It uses serial numbers (and an implied isser name) to identify certificates in order for disambiguation. This is not a requirement that the serial refers to a cert that the CA has positive proof to have consciously issued/signed with its key. > > CRL as in "Certificate Revocation List", not as in "inexistent Certificate > Revocation List". > Fraudulently producing certificates is bad, but producing a CRL for > nonexistent certificate is good? Unconvincing. The C is to clarify that the CRL does not revoke Apples and neither Oranges, but Certificates. And in order to disambiguate between certs issued by the same CA, the list identifies/disambiguates certs by their serial number. You're arguing here that DigiNotar was "breaking" the OCSP protocol and hurting RPs when they decided to respond "revoked" to requests for certs for which they had no record of issuance. I believe it was perfectly reasonable, fully conforming and actively helping RPs. Do you realize that X.509 defines a "Revoked Group of certificates" crlExtension, with a "serialNumberRange" options. There is *NO* requirement that the CA has positively created/issued all certs within the range before it can use that extension. So the idea that a CRL can contain revocations for certs for which the CA does not have records of issuance is already part of X.509 08/2005! Distinguishing why in particular a specific serial in not on the cert isse record (accidentally lost, fraudulently deleted, created by a precomputed hash collision, whathaveyou) would be splitting hairs over a total non-issue. > > > CRLs and OCSP only assert a state to a certificate serial. > > Infering about existance/noexistance of certs is a logical fallacy. > > > The certificate is identified by its serial number (along with its issuer > name, of course). What is the meaning/value of a serial number that doesn't > identify anything? When an RP sends an OCSP with a particular serial, then the OCSP responder has to assume that the OCSP requestor is serious about his request and is actually looking at a *REAL* certificate. So it is perfectly valid and reasonable for the OCSP responder to refer to that cert from the request by the very same serial and return a "revoked, certificateHold" status when it can not find this serial on the certificate issue logs. > > > > What's next? Ask CAs to sign the next OCSP response with a > > > "removeFromCRL" > > > code for dumb serial numbers for which they replied "certificateHold"? > > Why > > > not also add a holdInstructionCode extension to the OCSP response, and > > > define proper codes? > > > > removeFromCRL doesn't make sense in an OCSP response, because OCSP does > > not hand out CRLs. > > But holdInstructionCode could make sense, right? If you ignore for a moment that holdInstructionCode was removed from X.509 08/2005 _and_ rfc5280/PKIX, then id-holdinstruction-reject is another STRONG hint that certificateHold was defined intentionally with a very broad scope, even though certificateHold at early stages might have been motivated by a few, very specific use cases. Sensible protocol designers will try to provide an abstraction for initial use cases in order to remain open and easily extensible for related usage scenarios in the future. Having to retrofit agility into a protocol can otherwise be very painful. And while the original 3 basic CertStatus { good, revoked, unknown } were evidently short-sighted, the CRLEntry ReasonCode "certificateHold" does not suffer from such a limitiation - YMMV. > >>> >>> With my "CA" hat, I see that OCSP is a hidden cost, and you want to make >>> it more costly. > > I have nothing against a "positive assertion", maybe the hash of the > certificate for which the responder produces a good answer. If the > responder can have access to an issuance log and pick useful authoritative > information from it and optionally deliver it with the response, I'm fine. > Asking for a signed response from a bogus request is different. The thread > then slept into producing a revoked response for bogus requests, and > discussing about what could a plausible reason code and revocation date be. Personally, I consider the original OCSP design, where the RP rather than the certified entity obtains the OCSP response, a fairly useless protocol for online authentication. With the TLS multiple-OCSP-stapling extension, where the cert bearer can obtain&refresh the OCSP responses for his own cert chain out-of-band, OCSP may become an alternative to CRL processing. > > I believe that a well-behaving CA shouldn't produce a CRL containing random > serial numbers provided by anonymous requesters. A "CRL request" is a simple download request. The RP does not convey any serials to the CA, and given the serial number space of 160 bits, it would be unfeasible for the CA to guess what cert serials an RP, who has just requested download of a CRL, is going to check between now an the next periodical CRL download. > > By extension, I believe that a well-behaving OCSP responder shouldn't > assert anything authoritative (either good or revoked) about a random > serial number. That's a fail for the "good" response because an OCSP > responder can be based on a blacklist, I don't think that changing "good" > into "revoked" is the right way to solve this problem. A well-behaving OCSP responder is one that does not let RPs fall for fraudulent certs when it knows pretty damn well that the cert that the RP is requesting the status, for can not possibly be a bona fide certificate. An OCSP responder that lets RPs down so recklessly does not count as trustworthy on my scorecard. (Bad dog, no cookie). -Martin From piyush@ditenity.com Tue Oct 23 08:11:12 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8269C21F8644 for ; Tue, 23 Oct 2012 08:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.268 X-Spam-Level: X-Spam-Status: No, score=-3.268 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WvNsqi2czO5 for ; Tue, 23 Oct 2012 08:11:12 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id EFA9321F8602 for ; Tue, 23 Oct 2012 08:11:11 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id o25so3591054iad.31 for ; Tue, 23 Oct 2012 08:11:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=PNQp5z1NHuDlryyT2tYACdsYyoWKW46WakKB2/U6hm8=; b=Mxq5QITSiE1eMEy/HpxMvQ3skcLzYDKdWG7XMyJNDGC6dNkxeAsnhSLWA4C8fuOswU SGFc/J2/dtqbwbezrWs5Ys8MhLQoYAY+WUhVwmq/xmTODNqCznAbZRXMcOajXo3lSQSw sJshnQDtmz2M3BT0Qf8p4SxvKoMKB2Uc+5FjTMTKzqKGBQKNwc/deb6xG7BbKMBeSHNV GwsWZ1PoCPMN6JAvtXrkea7+GGXFmyFO1e+Ort46SfauOtcUXiAiCxiH7XWXrDbYjLCt 1SNd4Vqm5gOAkwU6fr6Uo5wVl1riG1K6azmO4i92fH0H4GQbOW+jqGTSLyKomzJV4717 pxOg== Received: by 10.50.193.161 with SMTP id hp1mr13222720igc.27.1351005071490; Tue, 23 Oct 2012 08:11:11 -0700 (PDT) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id ch4sm25108067igb.2.2012.10.23.08.11.08 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 23 Oct 2012 08:11:10 -0700 (PDT) From: "Piyush Jain" To: , "'Erwann Abalea'" References: <20121023134121.9FD8D1A2EE@ld9781.wdf.sap.corp> In-Reply-To: <20121023134121.9FD8D1A2EE@ld9781.wdf.sap.corp> Date: Tue, 23 Oct 2012 08:11:07 -0700 Message-ID: <02a101cdb130$a21f9de0$e65ed9a0$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQNGNV686hLxHEPm0x+ftXTlG3SOo5TV8p4Q Content-Language: en-us X-Gm-Message-State: ALoCoQnGl2AjiZ0kUGsTFUkl7Qu/npA0VF7gBSegxvqFu9uIBiC4lRSsHcpSp1d+VRgaNdC119Y3 Cc: 'Peter Rybar' , pkix@ietf.org, 'Stefan Santesson' Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 15:11:12 -0000 > A well-behaving OCSP responder is one that does not let RPs fall for > fraudulent certs when it knows pretty damn well that the cert that the RP is > requesting the status, for can not possibly be a bona fide > certificate. An OCSP responder that lets RPs down so recklessly > does not count as trustworthy on my scorecard. (Bad dog, no cookie). This is the unintended consequence that I was talking about earlier. People will actually start believing that OCSP responders certified by a compromised CA are trustworthy and authoritative if these responders issue revoked for fraudulent certificates. Martin - If the RP does not check that the payload certificate is bound to the issuing CA, OCSP response is meaningless. And if the payload certificate is cryptographically bound to the CA, and CA thinks it is not issued then the CA and as a result OCSP responder certified by the CA are compromised and hence not trustworthy. Not saying that OCSP responder should return revoked in this case, but if it does the, right reason code should be CACompromised. After all such a certificate could only be issued (or shall I say non-issued) if the CA is compromised. -Piyush From eabalea@gmail.com Tue Oct 23 11:40:12 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1831F0425 for ; Tue, 23 Oct 2012 11:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eyjtozt7b2KW for ; Tue, 23 Oct 2012 11:40:10 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 713431F042A for ; Tue, 23 Oct 2012 11:40:09 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so2911114lam.31 for ; Tue, 23 Oct 2012 11:40:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tWU5AusViMgf9/AvgDm9SNgRuRLTr1N74qD4GNyFrzQ=; b=kNrjuo73w/jz+ol8s2U3rlT6e9xIuxcOUQUyzgudWEKxFQupdikxPTkYZpKn4Iqoe/ UwElcOB5VY8uyPskn0Y7QV/LiMNuUKQGHc4CbL16XSX4DM0mEvDEu+Qsh5S0vxg/iI/j 4rmSbJD3hXbjQKkDt9xtQgvS43kNMcNimFv96Vz1O79CCSHPcwmJw57RfDegbCqb05Tf fS88a3eMGkAl4lmGWL8G1HbK2JKDYkx3lehVapKwgfHGjGtGgAox7Y0W0x6sJptzwFqi +nNL39DSLq0N2ypcaK4du42btBTCY+bDcsz0qK7LcGe0ZhthwFPHu8mryxw7IOdq1Cs2 k52Q== MIME-Version: 1.0 Received: by 10.152.148.226 with SMTP id tv2mr12069846lab.34.1351017608291; Tue, 23 Oct 2012 11:40:08 -0700 (PDT) Received: by 10.114.25.74 with HTTP; Tue, 23 Oct 2012 11:40:08 -0700 (PDT) In-Reply-To: <20121023134121.9FD8D1A2EE@ld9781.wdf.sap.corp> References: <20121023134121.9FD8D1A2EE@ld9781.wdf.sap.corp> Date: Tue, 23 Oct 2012 20:40:08 +0200 Message-ID: From: Erwann Abalea To: mrex@sap.com Content-Type: multipart/alternative; boundary=e89a8f22c889a0a55804ccbe4c16 Cc: Peter Rybar , pkix@ietf.org, Stefan Santesson Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 18:40:12 -0000 --e89a8f22c889a0a55804ccbe4c16 Content-Type: text/plain; charset=UTF-8 2012/10/23 Martin Rex > Erwann Abalea wrote: > > Martin Rex wrote: > >> > >> Erwann Abalea wrote: > >> >> CertificateHold is EXACTLY the correct ReasonCode: > >> >> It indicates that the CA has not issued a cert with the given serial > >> >> *YET*, but it MAY eventually issue such a cert in the future > >> >> (sometimes even in the _very_next_future_ ... i.e. it is about > >> >> to become visible to the OCSP responder, but not visible yet). > >> > > >> > No. It indicates that the corresponding (existent) certificate has > been > >> > put on hold. > >> > You're asking the CA to assert a status for a non-existent > certificate. > >> > >> Where exactly does X.509 or PKIX require that a serial on a CRL > >> will have to refer to an existing cert, i.e. one that the CA has > >> positive proof to have issued. I (now) believe this is a completely > >> flawed assumption. > > > > X.509, 7.3 > > revokedCertificates identifies certificates that have been revoked. The > > revoked certificates are identified by their serial > > numbers. > > It uses serial numbers (and an implied isser name) to identify > certificates in order for disambiguation. > This is not a requirement that the serial refers to a cert that the > CA has positive proof to have consciously issued/signed with its key. We disagree here, clearly. > > CRL as in "Certificate Revocation List", not as in "inexistent > Certificate > > Revocation List". > > Fraudulently producing certificates is bad, but producing a CRL for > > nonexistent certificate is good? > > Unconvincing. > > The C is to clarify that the CRL does not revoke Apples and neither > Oranges, but Certificates. And in order to disambiguate between > certs issued by the same CA, the list identifies/disambiguates > certs by their serial number. > > You're arguing here that DigiNotar was "breaking" the OCSP protocol > and hurting RPs when they decided to respond "revoked" to requests > for certs for which they had no record of issuance. I believe > it was perfectly reasonable, fully conforming and actively > helping RPs. > Wrong trial. I'm not arguing that DigiNotar broke anything by responding "revoked" for existent certificates that shouldn't have been produced. I'm arguing that responding "revoked" for a non existent certificate (that's different that a "wrongly issued certificate unknown to the CA") cannot be a CA responsibility. > Do you realize that X.509 defines a "Revoked Group of certificates" > crlExtension, with a "serialNumberRange" options. There is *NO* > requirement > that the CA has positively created/issued all certs within the range > before it can use that extension. So the idea that a CRL can contain > revocations for certs for which the CA does not have records of > issuance is already part of X.509 08/2005! > Yes. But who uses that? Public CAs are required to introduce entropy in the certificate serial number to defeat prefix-chosen collisions, so the serial number of a certificate is not sequential anymore. Distinguishing why in particular a specific serial in not on the > cert isse record (accidentally lost, fraudulently deleted, > created by a precomputed hash collision, whathaveyou) would > be splitting hairs over a total non-issue. I'm not arguing about the reason a certificate isn't known to the CA, but on existent vs non-existent (really non-existent) certificates. > > CRLs and OCSP only assert a state to a certificate serial. > > > Infering about existance/noexistance of certs is a logical fallacy. > > > > > > The certificate is identified by its serial number (along with its issuer > > name, of course). What is the meaning/value of a serial number that > doesn't > > identify anything? > > > When an RP sends an OCSP with a particular serial, then the OCSP responder > has to assume that the OCSP requestor is serious about his request > and is actually looking at a *REAL* certificate. So it is perfectly valid > and reasonable for the OCSP responder to refer to that cert from the > request by the very same serial and return a "revoked, certificateHold" > status when it can not find this serial on the certificate issue logs. Really? Do you have access to a real world OCSP responder? You'll find real dumb things in the logs. In no particular order: - wrong encoding: a '+' gets changed into a "%20" probably because it got changed into a " " somewhere in the middle - wrong encoding: somewhere in the request you'll find data probably coming from heap/stack corruption (part of environment, or other things) - unused URI elements: after the GET request you can find a '?' with a query string - requests for a real certificate serial number but issued to another CA served by the same OCSP platform (mixed issuer*Hash+serialNumber) - requests for a serial number close from a real one, differing only by a few bits; this raised alarms, required a complete audit of the issuing platform including authenticated logs, without any result - crafted requests with a lot of "/", or a lot of "A" in the base64 encoding, because it's a non authenticated web server, and surely an attractive target - good requests with additional bytes after them, probably some bad use of strlen() or similar function - requests with an unsupported hash algorithm, resulting into a non-existent issuer*Hash+serialNumber combination, yet the responder has to reply something; since july I can see some requests with GOST R34.11, all improperly encoded You find reasonable to assume that whatever is requested by any unauthenticated RP corresponds to a real certificate and is a correctly formed request. That's a wrong assumption and is contradicted by real world. Yet, additional pressure is put on OCSP producers, not on OCSP consumers. > > > What's next? Ask CAs to sign the next OCSP response with a > > > > "removeFromCRL" > > > > code for dumb serial numbers for which they replied > "certificateHold"? > > > Why > > > > not also add a holdInstructionCode extension to the OCSP response, > and > > > > define proper codes? > > > > > > removeFromCRL doesn't make sense in an OCSP response, because OCSP does > > > not hand out CRLs. > > > > But holdInstructionCode could make sense, right? > > If you ignore for a moment that holdInstructionCode was removed > from X.509 08/2005 _and_ rfc5280/PKIX, then id-holdinstruction-reject > is another STRONG hint that certificateHold was defined intentionally > with a very broad scope, even though certificateHold at early stages > might have been motivated by a few, very specific use cases. > Reading X.509 11/2008 shows that holdInstructionCode hasn't been removed, and isn't declared as deprecated. The description of this extension has been the same since the 08/1997 edition. I don't know what motivated the removal of this extension in RFC5280, as it's not even deprecated. Same as privateKeyUsagePeriod. Do RFC5280 consider these extensions as non existent? (a real question) id-holdinstruction-reject is still declared (in the ASN.1 module), and it defined a RP behavior to adopt. It's logical to consider that rejecting a certificates revoked with reason "certificateHold" is a valid behavior. But that doesn't say that "certificateHold" can be used for whatever reason you might find useful, and especially not to declare non-existent (really non-existent) certificates as revoked. > Sensible protocol designers will try to provide an abstraction for > initial use cases in order to remain open and easily extensible > for related usage scenarios in the future. Having to retrofit > agility into a protocol can otherwise be very painful. > > And while the original 3 basic CertStatus { good, revoked, unknown } > were evidently short-sighted, the CRLEntry ReasonCode "certificateHold" > does not suffer from such a limitiation - YMMV. > > > > > >>> > >>> With my "CA" hat, I see that OCSP is a hidden cost, and you want to > make > >>> it more costly. > > > > I have nothing against a "positive assertion", maybe the hash of the > > certificate for which the responder produces a good answer. If the > > responder can have access to an issuance log and pick useful > authoritative > > information from it and optionally deliver it with the response, I'm > fine. > > Asking for a signed response from a bogus request is different. The > thread > > then slept into producing a revoked response for bogus requests, and > > discussing about what could a plausible reason code and revocation date > be. > > Personally, I consider the original OCSP design, where the RP > rather than the certified entity obtains the OCSP response, > a fairly useless protocol for online authentication. > I see OCSP as a light CRL. The OCSP thisUpdate/nextUpdate have the same semantic as the CRL lastUpdate/nextUpdate, "good" can be a valid response for non-existent certificates. That's unfortunate, I agree. RFC5019 adds some balance, distributing good practice between OCSP responders and RP. With the TLS multiple-OCSP-stapling extension, where the cert bearer > can obtain&refresh the OCSP responses for his own cert chain > out-of-band, OCSP may become an alternative to CRL processing. > OCSP stapling with a blacklist based OCSP suffers the same problem. I'm not saying that multi-stapling isn't to be pushed. > > I believe that a well-behaving CA shouldn't produce a CRL containing > random > > serial numbers provided by anonymous requesters. > > A "CRL request" is a simple download request. The RP does not convey > any serials to the CA, and given the serial number space of 160 bits, > it would be unfeasible for the CA to guess what cert serials an RP, > who has just requested download of a CRL, is going to check between > now an the next periodical CRL download. > My point was that a CRL is a signed object, a commitment from the Authority. And the Authority shouldn't declare things on identities it doesn't know about. A CRL is supposed to revoke known certificates, each with a correct revocation date (and not something set at epoch 0, you can't play with revocation dates at will), and possibly with a correct reason and other extensions. > By extension, I believe that a well-behaving OCSP responder shouldn't > > assert anything authoritative (either good or revoked) about a random > > serial number. That's a fail for the "good" response because an OCSP > > responder can be based on a blacklist, I don't think that changing "good" > > into "revoked" is the right way to solve this problem. > > A well-behaving OCSP responder is one that does not let RPs fall for > fraudulent certs when it knows pretty damn well that the cert that > the RP is requesting the status, for can not possibly be a bona fide > certificate. An OCSP responder that lets RPs down so recklessly > does not count as trustworthy on my scorecard. (Bad dog, no cookie). We agree on this point, a well-behaving OCSP responder shouldn't declare that a non-existent certificate is valid. A difference lies in the "non-existent": - the serial number really corresponds to a non-existent certificate (even with a perfect CA, such requests will exist) - the serial number corresponds to an existent certificate unknown to the CA Case 1 is MUCH more frequent. Case 2 is dangerous (DigiNotar, etc). The OCSP responder cannot distinguish between the two. For me, asking for the OCSP responder (often the CA itself) to declare than a non-existent certificate (Case 1) is revoked is a bad practice, and it even doesn't solve the problem. Asking for OCSP responders to add something to "good" responses proving they have access to a list of issued certificates (like the hash of the certificate) is a better way to solve the problem. It must be backed-up with rules or recommendations applied to RP to avoid a fallback to CRLs. -- Erwann. --e89a8f22c889a0a55804ccbe4c16 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2012/10/23 Martin Rex <= mrex@sap.com>
Erwann Abalea wrote:
> Martin Rex <= mrex@sap.com> wrote:
>>
>> Erwann Abalea wrote:
>> >> CertificateHold is EXACTLY the correct ReasonCode:
>> >> It indicates that the CA has not issued a cert with the g= iven serial
>> >> *YET*, but it MAY eventually issue such a cert in the fut= ure
>> >> (sometimes even in the _very_next_future_ ... i.e. it is = about
>> >> =C2=A0to become visible to the OCSP responder, but not vi= sible yet).
>> >
>> > No. It indicates that the corresponding (existent) certificat= e has been
>> > put on hold.
>> > You're asking the CA to assert a status for a non-existen= t certificate.
>>
>> Where exactly does X.509 or PKIX require that a serial on a CRL >> will have to refer to an existing cert, i.e. one that the CA has >> positive proof to have issued. =C2=A0I (now) believe this is a com= pletely
>> flawed assumption.
>
> X.509, 7.3
> revokedCertificates identifies certificates that have been revoked. Th= e
> revoked certificates are identified by their serial
> numbers.

It uses serial numbers (and an implied isser name) to identify
certificates in order for disambiguation.
This is not a requirement that the serial refers to a cert that the
CA has positive proof to have consciously issued/signed with its key.

We disagree here, clearly.
=C2=A0
> CRL as in "Certificate Revocation List", not as in &quo= t;inexistent Certificate
> Revocation List".
> Fraudulently producing certificates is bad, but producing a CRL for > nonexistent certificate is good?

Unconvincing.

The C is to clarify that the CRL does not revoke Apples and neither
Oranges, but Certificates. =C2=A0And in order to disambiguate between
certs issued by the same CA, the list identifies/disambiguates
certs by their serial number.

You're arguing here that DigiNotar was "breaking" the OCSP pr= otocol
and hurting RPs when they decided to respond "revoked" to request= s
for certs for which they had no record of issuance. =C2=A0I believe
it was perfectly reasonable, fully conforming and actively
helping RPs.

Wrong trial. I'm not a= rguing that DigiNotar broke anything by responding "revoked" for = existent certificates that shouldn't have been produced. I'm arguin= g that responding "revoked" for a non existent certificate (that&= #39;s different that a "wrongly issued certificate unknown to the CA&q= uot;) cannot be a CA responsibility.
=C2=A0
Do you realize that X.509 d= efines a "Revoked Group of certificates"
crlExtension, with a "serialNumberRange" options. =C2=A0There is = *NO* requirement
that the CA has positively created/issued all certs within the range
before it can use that extension. =C2=A0So the idea that a CRL can contain<= br> revocations for certs for which the CA does not have records of
issuance is already part of X.509 08/2005!

<= div>Yes. But who uses that?
Public CAs are required to introduce = entropy in the certificate serial number to defeat prefix-chosen collisions= , so the serial number of a certificate is not sequential anymore.

Distinguishing why in particu= lar a specific serial in not on the
cert isse record (accidentally lost, fraudulently deleted,
created by a precomputed hash collision, whathaveyou) would
be splitting hairs over a total non-issue.

= I'm not arguing about the reason a certificate isn't known to the C= A, but on existent vs non-existent (really non-existent) certificates.

> > CRLs and OCSP = only assert a state to a certificate serial.
> > Infering about existance/noexistance of certs is a logical fallac= y.
>
>
> The certificate is identified by its serial number (along with its iss= uer
> name, of course). What is the meaning/value of a serial number that do= esn't
> identify anything?


When an RP sends an OCSP with a particular serial, then the OCSP resp= onder
has to assume that the OCSP requestor is serious about his request
and is actually looking at a *REAL* certificate. =C2=A0So it is perfectly v= alid
and reasonable for the OCSP responder to refer to that cert from the
request by the very same serial and return a "revoked, certificateHold= "
status when it can not find this serial on the certificate issue logs.

Really? Do you have access to a real world OCSP= responder? You'll find real dumb things in the logs.
In no p= articular order:
=C2=A0- wrong encoding: a '+' gets changed into a "%20&qu= ot; probably because it got changed into a " " somewhere in the m= iddle
=C2=A0- wrong encoding: somewhere in the request you'll= find data probably coming from heap/stack corruption (part of environment,= or other things)
=C2=A0- unused URI elements: after the GET request you can find a '= ;?' with a query string
=C2=A0- requests for a real certificate serial number but issued to an= other CA served by the same OCSP platform (mixed issuer*Hash+serialNumber)<= /div>
=C2=A0- requests for a serial number close from a real one, diffe= ring only by a few bits; this raised alarms, required a complete audit of t= he issuing platform including authenticated logs, without any result
=C2=A0- crafted requests with a lot of "/", or a lot of &quo= t;A" in the base64 encoding, because it's a non authenticated web = server, and surely an attractive target
=C2=A0- good requests wit= h additional bytes after them, probably some bad use of strlen() or similar= function
=C2=A0- requests with an unsupported hash algorithm, resulting into a = non-existent issuer*Hash+serialNumber combination, yet the responder has to= reply something; since july I can see some requests with GOST R34.11, all = improperly encoded

You find reasonable to assume that whatever is requeste= d by any unauthenticated RP corresponds to a real certificate and is a corr= ectly formed request. That's a wrong assumption and is contradicted by = real world. Yet, additional pressure is put on OCSP producers, not on OCSP = consumers.

> > > What'= s next? Ask CAs to sign the next OCSP response with a
> > > "removeFromCRL"
> > > code for dumb serial numbers for which they replied "ce= rtificateHold"?
> > Why
> > > not also add a holdInstructionCode extension to the OCSP res= ponse, and
> > > define proper codes?
> >
> > removeFromCRL doesn't make sense in an OCSP response, because= OCSP does
> > not hand out CRLs.
>
> But holdInstructionCode could make sense, right?

If you ignore for a moment that holdInstructionCode was removed
from X.509 08/2005 _and_ rfc5280/PKIX, then id-holdinstruction-reject
is another STRONG hint that certificateHold was defined intentionally
with a very broad scope, even though certificateHold at early stages
might have been motivated by a few, very specific use cases.

Reading X.509 11/2008 shows that holdInstructionCode = hasn't been removed, and isn't declared as deprecated. The descript= ion of this extension has been the same since the 08/1997 edition.
I don't know what motivated the removal of this extension in RFC52= 80, as it's not even deprecated. Same as privateKeyUsagePeriod. Do RFC5= 280 consider these extensions as non existent? (a real question)
id-holdinstruction-reject is still declared (in the ASN.1 module), and= it defined a RP behavior to adopt. It's logical to consider that rejec= ting a certificates revoked with reason "certificateHold" is a va= lid behavior. But that doesn't say that "certificateHold" can= be used for whatever reason you might find useful, and especially not to d= eclare non-existent (really non-existent) certificates as revoked.
=C2=A0
Sensible protocol designers= will try to provide an abstraction for
initial use cases in order to remain open and easily extensible
for related usage scenarios in the future. =C2=A0Having to retrofit
agility into a protocol can otherwise be very painful.

And while the original 3 basic CertStatus { good, revoked, unknown }
were evidently short-sighted, the CRLEntry ReasonCode "certificateHold= "
does not suffer from such a limitiation - YMMV.


>
>>>
>>> With my "CA" hat, I see that OCSP is a hidden cost, = and you want to make
>>> it more costly.
>
> I have nothing against a "positive assertion", ma= ybe the hash of the
> certificate for which the responder produces a good answer. If the
> responder can have access to an issuance log and pick useful authorita= tive
> information from it and optionally deliver it with the response, I'= ;m fine.
> Asking for a signed response from a bogus request is different. The th= read
> then slept into producing a revoked response for bogus requests, and > discussing about what could a plausible reason code and revocation dat= e be.

Personally, I consider the original OCSP design, where the RP
rather than the certified entity obtains the OCSP response,
a fairly useless protocol for online authentication.
<= br>
I see OCSP as a light CRL. The OCSP thisUpdate/nextUpdate hav= e the same semantic as the CRL lastUpdate/nextUpdate, "good" can = be a valid response for non-existent certificates.
That's unfortunate, I agree. RFC5019 adds some balance, distributi= ng good practice between OCSP responders and RP.

With the TLS multiple-OCSP-stapling extension, where the cert bearer
can obtain&refresh the OCSP responses for his own cert chain
out-of-band, OCSP may become an alternative to CRL processing.

OCSP stapling with a blacklist based OCSP suffers t= he same problem. I'm not saying that multi-stapling isn't to be pus= hed.
=C2=A0
> I believe that a well-behaving CA shouldn't produce a CRL con= taining random
> serial numbers provided by anonymous requesters.

A "CRL request" is a simple download request. =C2=A0The RP = does not convey
any serials to the CA, and given the serial number space of 160 bits,
it would be unfeasible for the CA to guess what cert serials an RP,
who has just requested download of a CRL, is going to check between
now an the next periodical CRL download.

My point was that a CRL is a signed object, a commitment from the Authori= ty. And the Authority shouldn't declare things on identities it doesn&#= 39;t know about. A CRL is supposed to revoke known certificates, each with = a correct revocation date (and not something set at epoch 0, you can't = play with revocation dates at will), and possibly with a correct reason and= other extensions.

> By extension, I believe that a well-behaving OCSP responder shoul= dn't
> assert anything authoritative (either good or revoked) about a random<= br> > serial number. That's a fail for the "good" response bec= ause an OCSP
> responder can be based on a blacklist, I don't think that changing= "good"
> into "revoked" is the right way to solve this problem.

A well-behaving OCSP responder is one that does not let RPs fall for<= br> fraudulent certs when it knows pretty damn well that the cert that
the RP is requesting the status, for can not possibly be a bona fide
certificate. An OCSP responder that lets RPs down so recklessly
does not count as trustworthy on my scorecard. (Bad dog, no cookie).

We agree on this point, a well-behaving OCSP resp= onder shouldn't declare that a non-existent certificate is valid.
A difference lies in the "non-existent":
=C2=A0- t= he serial number really corresponds to a non-existent certificate (even wit= h a perfect CA, such requests will exist)
=C2=A0- the serial numb= er corresponds to an existent certificate unknown to the CA

Case 1 is MUCH more frequent. Case 2 is dangerous (Digi= Notar, etc).
The OCSP responder cannot distinguish between the tw= o.
For me, asking for the OCSP responder (often the CA itself) to= declare than a non-existent certificate (Case 1) is revoked is a bad pract= ice, and it even doesn't solve the problem.
Asking for OCSP responders to add something to "good" respon= ses proving they have access to a list of issued certificates (like the has= h of the certificate) is a better way to solve the problem. It must be back= ed-up with rules or recommendations applied to RP to avoid a fallback to CR= Ls.

--
Erwann.
--e89a8f22c889a0a55804ccbe4c16-- From peterryb@gmail.com Mon Oct 22 05:38:41 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 633D821F87DF for ; Mon, 22 Oct 2012 05:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBysrdWJAtBd for ; Mon, 22 Oct 2012 05:38:39 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5B93B21F88F5 for ; Mon, 22 Oct 2012 05:38:39 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so3199251vbb.31 for ; Mon, 22 Oct 2012 05:38:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=K24Ts085EDJNOsAp9rgiNcfS/j91NK/2X/DZyytkVZM=; b=VvgCiwJ+BmXKzB/VRPFUeDi62Zr1XudwZNt++E+btOCLt2nN7JcFfEGvKoq68ast6l veMSf8cQ668WpR9fXy85XgCG7U0Y3hbInzNdrSE66k+ZZRguhfiJAHU9rqrymF1OD4Ou dM1ll7e5e77jZ1uPJ/vLojOVjF6d6oM9fh8Q2ODzp5g9UqVZhQwEwaU96WgzmE9gNqfo rTKbxj/dHtkBYOZUbPPcDxTV7PO/cDuh6Fv+PEc7/fTNtT9l1flDkDulx5uBtqlWY/OC 8SHCobYb0QPeR8CinLsHYRYJw292ZtQ5WlZdgs2VmxteQ6tfgxHctL3mp/ObxKznhJox VmGA== MIME-Version: 1.0 Received: by 10.220.247.140 with SMTP id mc12mr14799570vcb.0.1350909518606; Mon, 22 Oct 2012 05:38:38 -0700 (PDT) Received: by 10.58.31.230 with HTTP; Mon, 22 Oct 2012 05:38:38 -0700 (PDT) In-Reply-To: References: <201210191312.q9JDCHnw046175@mail.nbusr.sk> Date: Mon, 22 Oct 2012 14:38:38 +0200 Message-ID: From: Peter Rybar To: Stefan Santesson Content-Type: multipart/alternative; boundary=bcaec54a37bafaf1b304cca52144 X-Mailman-Approved-At: Tue, 23 Oct 2012 13:01:55 -0700 Cc: pkix@ietf.org Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 12:38:41 -0000 --bcaec54a37bafaf1b304cca52144 Content-Type: text/plain; charset=UTF-8 Stefan, You have defined in draft that certificate identified with correct (hash of issuer name, hash of issuer key) and with unknown cert serial number xyz is revoked. Correct response must also contains the value of item revocationTime. Do you know the correct value of revocationTime in situation which you have described? ... revoked [1] IMPLICIT RevokedInfo, ... RevokedInfo ::= SEQUENCE { revocationTime GeneralizedTime, revocationReason [0] EXPLICIT CRLReason OPTIONAL } Peter 2012/10/19 Stefan Santesson > Peter, > > An OCSP responder is by default a service providing information about > current certificates. > The default response you get from an OCSP responder is "good" unless the > cert is known to be bad or not a cert the responder can provide status for. > > If you need it to respond about old certificates, and as a client know > that the responder does this in a way that suits your needs, you will need > to add an extension. > Such extension will not be part of the rfc256bis effort. > > Is there any text in the current draft that you think is unclear on this? > > /Stefan > > > From: Peter Rybar > Date: Friday, October 19, 2012 3:12 PM > To: 'Carl Wallace' , 'Simon Tardell' < > simon@tardell.se> > > Cc: 'Peter Rybar' , Stefan Santesson < > stefan@aaa-sec.com>, > Subject: RE: [pkix] New draft-ietf-pkix-rfc2560bis-06 > > Well, yes, sort of. You can only be sure to validate a signature at the > moment of production. > > > > What if the signature key was compromised at the moment of production but > is not yet on a revocation list? > > [PR] According to clause 2.4 - thisUpdate: The time at which the status > being indicated is known to be correct > > It means when signature time-stamp time is X then any OCSP responses with > thisUpdate time X+y are sufficient to validate because the status is > correct. > > Y is in the interval <0, producedAt - X> > > > > At any later point in time the signature key may be compromised, or the > algorithms involved may have become to weak. (In which case the time of > revocation in the OCSP response is worth nothing to you). The risk > increases as time passes. And of course, the revocation information may not > be kept around after the expiry of the certificate. > > > > That's why you should validate signatures as soon as possible. > > > > For these archival purposes wouldn't it be better to have the final > revocation list before removed due to expiry? In any case, you'd need > verification information collected after some grace period following moment > of production. > > [PR] Grace period is not a fixed value of the time interval. > > Grace period is changeable because the first OCSP response with thisUpdate > time value > than time of signature time-stamp contains correct status. > > > > > > If you need to ascertain that a signature was valid at a later time, you > have to trust your system that it performed the validation at the time it > first received the signature. That trust must be established through some > kind of mix of policies and technical measures (such as timestamping). > > > > In the dark corner just beyond the dark corner that is SCVP, there's a > spec (RFC 5276) that defines a binding of evidence records to artifacts > that can be returned viaSCVP. This provides for timestamping. > > [PR] The validation is simplified when OCSP response with positive > statement as a hash value of requested certificate is used. > > Positive statement is evidence that OCSP know the status of certificate > and also protect the integrity of certificate with a new more secure hash > algorithm. > > > > Peter Rybar > > > > > > Simon Tardell, > > Technology Nexus. > > On Fri, Oct 19, 2012 at 1:07 PM, Peter Rybar wrote: > Stefan, > > I have a question about the present OCSP RFC and at the end of the mail > about the new situation which will happen according to your new proposal. > > The presence of the positive statement in OCSP response is important for > electronic signature validations, especially for an expired certificate. > Positive statement is the hash value of a certificate whose status is > provided in OCSP response. > > Electronic signature validation is usually about the signatures created in > the past and validated now, when the certificate is expired. > > When the certificate expires then revocation is usually removed from CRL > and the revoked certificate can be provided as "good" in OCSP response. > Is it acceptable? I think not. > > According to your new draft there is not defined a value of revocationTime. > RFC must also define the value of revocationTime when the certificate > which was never issued is as "revoked". > http://www.ietf.org/rfcdiff?url2=draft-ietf-pkix-rfc2560bis-06 > > Have you also covered the situation when the certificate is expired, > REMOVED FROM CRL and will be provided as revoked with incorrect > revocationTime e.g.with the value before or after the revocationTime which > was present in the removed record from CRL? > > Because according to sentence in your draft ""revoked" - This state SHOULD > also be returned if the responder knows that the requested certificate has > never been issued." the following situation can happen: when certificate is > removed from CRL after expiration and CA/OCSP responder is responsible for > this certificate but have not record about expired certificate and for that > reason it is identified as "never been issued". > > ... > revoked [1] IMPLICIT RevokedInfo, > ... > > RevokedInfo ::= SEQUENCE { > revocationTime GeneralizedTime, > revocationReason [0] EXPLICIT CRLReason OPTIONAL } > > As you have mentioned in the mail: > > "On the "revoked" state, the old spec did not even consider the case of a > certificate being requested where the OCSP responder knows that the > certificate was never issued." > > "It simply recommend a known to be bad certificate to result > in "revoked" in order to prevent damage as far as possible. It also opens > for definition of new extensions through which such knowledge could be > obtained." > > Peter Rybar > National Security Authority > Information Security and Electronic Signature Department > Budatinska 30, 850 07 Bratislava 57, Slovak Republic > e-mail: peter.rybar@nbusr.sk > e-mail: peterryb@gmail.com > > > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > Stefan Santesson > Sent: Monday, October 15, 2012 1:49 AM > To: pkix@ietf.org > Subject: [pkix] New draft-ietf-pkix-rfc2560bis-06 > > All, > > I have just posted an update of rfc2560bis (OCSP update) after carefully > reviewing all comments on the list. > > Some notes about the update: > > - Added the previous OCSP editors with updated affiliations. > - Added some calcifications on ResponderID as suggested by Simon Josefsson. > - Updated the clarifications on Authorized responders. The requirements > have not changed. I just tried to improve the text. > - Updated a clarification on the "revoked" state to be the preferred > response if a certificate is known by the responder to never have been > issued. > - Some minor editorial nits. > > > Regarding backwards compatibility I mean that none of the clarifications > changes RFC 2560. > > On Authorized responders it has always been the case that a responder > certificate issued with the same key as was used to issue the certificate > being checked for revocation, represents a valid Authorized responder. > There has never been an explicit requirement to support key rollover and > key rollover support has never been in the "spirit" of the original > standard as it clearly attempted to provide direct cryptographic binding > between the responder and the CA. > > On the "revoked" state, the old spec did not even consider the case of a > certificate being requested where the OCSP responder knows that the > certificate was never issued. It is clearly counterproductive to respond > good when a certificate is known to be bad. A responder must pick one > response and picking "revoked" breaks nothing, but has the desired effect, > that is, to prevent the certificate from being accepted. The current text > makes clear that there is no mechanism in the current standard by which a > client can know how a responder will respond to a request for a not issued > certificate. It simply recommend a known to be bad certificate to result > in "revoked" in order to prevent damage as far as possible. It also opens > for definition of new extensions through which such knowledge could be > obtained. > > The current updates also clearly opens a path for the CAB forum efforts to > define a suitable solution for server certificates. > > I have not, even thug suggested, added any requirements on what clients > should do with the checked cert as a result of a particular response. I > don't believe such requirements are suitable as it is policy and not > protocol. We have no right to demand that all systems MUST reject any > certificate for any reason as they may have a local policy that overrules > the OCSP response. This protocol only provides information about the cert > status, it does not mandate validation policy. > > I have not included any of the substantial changes i the Pinkas draft. I > want to wait for a list of motivation for each change before including any > of them. So there changed may be up for debate before this draft is ready > for WGLC. > > /Stefan > > > > _______________________________________________ > 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 > > > > _______________________________________________ pkix mailing list > pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix > > --bcaec54a37bafaf1b304cca52144 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Stefan,

You have defined in draft that ce= rtificate identified with correct (hash of issuer name, hash of=C2=A0 issue= r key) and with unknown=20 cert serial number xyz is revoked.
Correct response must also contains the value of ite= m revocationTime.

Do you know the correct value of= =C2=A0 revocationTime in situation which you have described?
...
revoked =C2=A0 =C2=A0 [1] =C2=A0 =C2=A0 IMPLICIT RevokedInfo,
...

=C2=A0 =C2=A0RevokedInfo ::=3D SEQUENCE {
=C2=A0 =C2=A0 =C2=A0 =C2=A0revocationTime =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0GeneralizedTime,
=C2=A0 =C2=A0 =C2=A0 =C2=A0revocationReason =C2=A0 =C2=A0[0] =C2=A0 =C2=A0 EXPLICIT CRLReason OPTIONAL }
Peter

2012/10/19 Stefan Santesson <stefan@aaa-sec.com>=
Peter,

= An OCSP responder is by default a service providing information about curre= nt certificates.
The default response you get from an OCSP responder is "good"= ; unless the cert is known to be bad or not a cert the responder can provid= e status for.

If you need it to respond about old = certificates, and as a client know that the responder does this in a way th= at suits your needs, you will need to add an extension.
Such extension will not be part of the rfc256bis effort.
Is there any text in the current draft that you think is unclea= r on this?

/Stefan


From: Peter Rybar <rybar@nbusr.sk>
Date: Friday, October 19, 2012 3:12 PM
<= span style=3D"font-weight:bold">To: 'Carl Wallace' <carl@redhoundsof= tware.com>, 'Simon Tardell' <simon@tardell.se>

Cc: 'Peter Rybar' <= peterryb@gmail.com<= /a>>, Stefan Santesson <stefan@aaa-sec.com>, <pkix@ietf.org>
Subject: RE: [pkix] New draf= t-ietf-pkix-rfc2560bis-06

Well, yes, sort o= f. You can only be sure to validate a signature at the moment of production. <= /span>

=C2=A0

What if t= he signature key was compromised at the moment of production but is not yet on a revocat= ion list?

[PR] According to clause 2.4 =C2=A0-=C2=A0 thisUpdate: The time at which the status being indicated = is known to be correct

It means when signature time-stamp time is X then any OCSP responses with thisUpdate time X+y are s= ufficient to validate because the status is correct.

Y is in the interval <0, producedAt - X>

=C2=A0

At any later p= oint in time the signature key may be compromised, or the algorithms involved may have become to weak. (In which = case the time of revocation in the OCSP response is worth nothing to you). The r= isk increases as time passes. And of course, the revocation information may not= be kept around after the expiry of the certificate.=C2=A0=

=C2=A0

That's why = you should validate signatures as soon as possible.=C2=A0

= =C2=A0<= /span>

For these= archival purposes wouldn't it be better to have the final revocation list before= removed due to expiry? =C2=A0In any case, you'd need verification information c= ollected after some grace period following moment of production.

[PR] = Grace period is not a fixed value of the time interval.

Grace period is changeable because the first OCSP response with thisUpdate time value > than time o= f signature time-stamp contains correct status.

=C2=A0

=C2=A0

If you need to ascertain that a signature was valid at a later time, you have to trust you= r system that it performed the validation at the time it first received the signature. That trust must be established through some kind of mix of polic= ies and technical measures (such as timestamping).

= =C2=A0

In = the dark corner just beyond the dark corner that is SCVP, there's a spec (RFC 5276) tha= t defines a binding of evidence records to artifacts that can be returned via= SCVP. =C2=A0This provides for timestamping. =C2=A0

[PR= ] The validation is simplified when OCSP response with positive statement as a hash value of requested certificate is used.

Positive statement is evidence that OCSP know the status of certificate and also protect the integrity of certificate with a new more secure hash algorithm.

=C2=A0

Peter Rybar

<= span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:Arial;color:navy"= >=C2=A0



Simon Tardell,=C2=A0

<= span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:Calibri">Technolo= gy Nexus.

On Fri, Oct 19, 2012 at 1:07 PM, Peter Rybar <rybar@nbusr.sk&= gt; wrote:

Stefan,

I have a question about the present OCSP RFC and at the end of the mail abo= ut the new situation which will happen according to your new proposal.

= The presence of the positive statement in OCSP response is important for electronic signature validations, especially for an expired certificate. Po= sitive statement is the hash value of a certificate whose status is provided in OC= SP response.

Electronic signature validation is usually about the signatures created in = the past and validated now, when the certificate is expired.

When the certificate expires then revocation is usually removed from CRL an= d the revoked certificate can be provided as "good" in OCSP respons= e.
Is it acceptable? I think not.

According to your new draft there is not defined a value of revocationTime.=
RFC must also define the value of revocationTime when the certificate which= was never issued is as "revoked".
http://www.i= etf.org/rfcdiff?url2=3Ddraft-ietf-pkix-rfc2560bis-06

 Have you also covered the situation when the certificate is expired, REMOVE= D FROM CRL and will be provided as revoked with incorrect revocationTime e.g.= with the value before or after the revocationTime which was present in the removed record from CRL?

Because according to sentence in your draft ""revoked" - Thi= s state SHOULD also be returned if the responder knows that the requested certificate has never been issued." the following situation can happen= : when certificate is removed from CRL after expiration and CA/OCSP responder= is responsible for this certificate but have not record about expired certific= ate and for that reason it is identified as "never been issued".
<= br> ...
revoked =C2=A0 =C2=A0 [1] =C2=A0 =C2=A0 IMPLICIT RevokedInfo,
...

=C2=A0 =C2=A0RevokedInfo ::=3D SEQUENCE {
=C2=A0 =C2=A0 =C2=A0 =C2=A0revocationTime =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0GeneralizedTime,
=C2=A0 =C2=A0 =C2=A0 =C2=A0revocationReason =C2=A0 =C2=A0[0] =C2=A0 =C2=A0 EXPLICIT CRLReason OPTIONAL }

As you have mentioned in the mail:

"On the "revoked" state, the old spec did not even consider the case of a certificate being requested where the OCSP responder knows that the certifi= cate was never issued."

"It sim= ply recommend a known to be bad certificate to result
in "revoked" in order to prevent damage as far as possible. It al= so opens
for definition of new extensions through which such knowledge could be
obtained."

Peter Rybar
National Security Authority
Information Security and = Electronic Signature Department
Budatinska 30, 850 07 Brati= slava 57, Slovak Republic
e-mail: peter.rybar@nbusr.sk
e-mail:= peterryb@gmail.com=


-----Original Message-----
From: pkix-bounc= es@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Stefan Santesson
Sent: Monday, October 15, 2012 1:49 AM
To: pkix@ietf.org Subject: [pkix] New draft-ietf-pkix-rfc2560bis-06

All,

I have just posted an update of rfc2560bis (OCSP update) after carefully reviewing all comments on the list.

Some notes about the update:

- Added the previous OCSP editors with updated affiliations.
- Added some calcifications on ResponderID as suggested by Simon Josefsson.=
- Updated the clarifications on Authorized responders. The requirements
= have not changed. I just tried to improve the text.
- Updated a clarification on the "revoked" state to be the prefer= red
response if a certificate is known by the responder to never have been
issued.
- Some minor editorial nits.


Regarding backwards compatibility I mean that none of the clarifications changes RFC 2560.

On Authorized responders it has always been the case that a responder
certificate issued with the same key as was used to issue the certificate being checked for revocation, represents a valid Authorized responder.
There has never been an explicit requirement to support key rollover and key rollover support has never been in the "spirit" of the origin= al
standard as it clearly attempted to provide direct cryptographic binding between the responder and the CA.

On the "revoked" state, the old spec did not even consider the ca= se of a
certificate being requested where the OCSP responder knows that the
certificate was never issued. It is clearly counterproductive to respond good when a certificate is known to be bad. A responder must pick one
response and picking "revoked" breaks nothing, but has the desire= d effect,
that is, to prevent the certificate from being accepted. The current text makes clear that there is no mechanism in the current standard by which a client can know how a responder will respond to a request for a not issued<= br> certificate. It simply recommend a known to be bad certificate to result in "revoked" in order to prevent damage as far as possible. It al= so opens
for definition of new extensions through which such knowledge could be
obtained.

The current updates also clearly opens a path for the CAB forum efforts to<= br> define a suitable solution for server certificates.

I have not, even thug suggested, added any requirements on what clients
= should do with the checked cert as a result of a particular response. I
= don't believe such requirements are suitable as it is policy and not protocol. We have no right to demand that all systems MUST reject any
certificate for any reason as they may have a local policy that overrules the OCSP response. This protocol only provides information about the cert status, it does not mandate validation policy.

I have not included any of the substantial changes i the Pinkas draft. I want to wait for a list of motivation for each change before including any<= br> of them. So there changed may be up for debate before this draft is ready for WGLC.

/Stefan



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

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

=C2=A0

________________________________= _______________ pkix mailing list pkix@i= etf.org https://www.ietf.org/mailman/listinfo/pkix


--bcaec54a37bafaf1b304cca52144-- From mrex@sap.com Wed Oct 24 11:10:36 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB7A021F884F for ; Wed, 24 Oct 2012 11:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.054 X-Spam-Level: X-Spam-Status: No, score=-10.054 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLtNm-I9MMyG for ; Wed, 24 Oct 2012 11:10:29 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id E9AED21F8742 for ; Wed, 24 Oct 2012 11:10:28 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q9OIAHci022590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 24 Oct 2012 20:10:22 +0200 (MEST) In-Reply-To: To: Erwann Abalea Date: Wed, 24 Oct 2012 20:10:16 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20121024181016.503F21A2F3@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: Peter Rybar , pkix@ietf.org, Stefan Santesson Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 18:10:36 -0000 Erwann Abalea wrote: > > Martin Rex wrote: >> >> It uses serial numbers (and an implied isser name) to identify >> certificates in order for disambiguation. >> This is not a requirement that the serial refers to a cert that the >> CA has positive proof to have consciously issued/signed with its key. > > We disagree here, clearly. OK. I don't see any convergence. Let's agree that we disagree. > > > > CRL as in "Certificate Revocation List", not as in "inexistent > > > Certificate Revocation List". > > > Fraudulently producing certificates is bad, but producing a CRL for > > > nonexistent certificate is good? > > > > Unconvincing. > > > > The C is to clarify that the CRL does not revoke Apples and neither > > Oranges, but Certificates. And in order to disambiguate between > > certs issued by the same CA, the list identifies/disambiguates > > certs by their serial number. > > > > You're arguing here that DigiNotar was "breaking" the OCSP protocol > > and hurting RPs when they decided to respond "revoked" to requests > > for certs for which they had no record of issuance. I believe > > it was perfectly reasonable, fully conforming and actively > > helping RPs. > > > > Wrong trial. I'm not arguing that DigiNotar broke anything by responding > "revoked" for existent certificates that shouldn't have been produced. I'm > arguing that responding "revoked" for a non existent certificate (that's > different that a "wrongly issued certificate unknown to the CA") cannot be > a CA responsibility. Once Diginotar realized that they may be fraudulent certs around of which they have no records of issuance, they very probably started replying "revoked" for *ANY* serial number not in their records, and did not require anyone to demonstrate to them that the certificate with that serial really exists. Safety first. > > > Do you realize that X.509 defines a "Revoked Group of certificates" > > crlExtension, with a "serialNumberRange" options. There is *NO* > > requirement > > that the CA has positively created/issued all certs within the range > > before it can use that extension. So the idea that a CRL can contain > > revocations for certs for which the CA does not have records of > > issuance is already part of X.509 08/2005! > > Yes. But who uses that? That doesn't matter. It was just to show you that the spec itself does not require any certs that appear on a CRL to have actually ever been issued -- just that they're unambiguously identified. > > Public CAs are required to introduce entropy in the certificate serial > number to defeat prefix-chosen collisions, so the serial number of a > certificate is not sequential anymore. Maybe you completely misunderstood that requirement. (btw. this is neither a PKIX nor an X.509 requirement). The CA /Browser Forum Baseline Requirements v1.1 (14-Sep-2012) https://www.cabforum.org/Baseline_Requirements_V1_1.pdf 9.6 Certificate Serial Number CAs SHOULD generate non-sequential Certificate serial numbers that exhibit at least 20 bits of entropy Non-sequential only means that when a CA issues certs (#n1) and (#n2) with serial (sn1) and (sn2) and n2 = n1+1 then sn2 = sn1+1 should not apply. It is, however, perfectly permissible and perfectly sensible that for n2 > n1 sn2 > sn1 still applies so that ranges will still work, i.e. to compose a SerialNumber (which is up to 160 bits), from a strictly monotonically increasing part at the beginning, followed by a cryptographically random part of at least 20 bits (Personally, I would use more like 64 random bits, but I also don't run large CAs that issue millions of certs -- because the size of the serial significantly impacts the size of the CRLs. Looking at one of the CRLs issued by one of the US DOD CAs with more than one million entries, the cert serials are 3 bytes...). > > Distinguishing why in particular a specific serial in not on the > > cert isse record (accidentally lost, fraudulently deleted, > > created by a precomputed hash collision, whathaveyou) would > > be splitting hairs over a total non-issue. > > > I'm not arguing about the reason a certificate isn't known to the CA, but > on existent vs non-existent (really non-existent) certificates. You _are_ splitting hairs. How would a CA (and its OCSP server) distinguish certs that are not on record as ever being issued from certs that are not on record as ever being issued? > >> >> When an RP sends an OCSP with a particular serial, then the OCSP responder >> has to assume that the OCSP requestor is serious about his request >> and is actually looking at a *REAL* certificate. So it is perfectly valid >> and reasonable for the OCSP responder to refer to that cert from the >> request by the very same serial and return a "revoked, certificateHold" >> status when it can not find this serial on the certificate issue logs. > > > Really? Do you have access to a real world OCSP responder? I don't use OCSP at all. We're doing online authentication on large servers, so OCSP, as it currently exists, is a total non-starter. We do not even implement it. The TLS extension for stapling multiple OCSP-response might become a reason to revisit this decision. > You'll find real dumb things in the logs. Please don't tell me that this surprised you. That had to be expected! And that MUST NOT cause problems. If a request is for a CA/issuer name which the OCSP server is not authoritative for, then an unsigned "unknown" response is just fine. OCSP doesn't have the "recursion requested" flag that DNS has. (Well, unless you count the not well thought out idea of a universal local OCSP responder). The only thing that is a real (OCSP) design flaw is the idea that each and every RP doing online authentication would perform OCSP requests. That scales nowhere and was obvious from the beginning. Switching from 1024-bit to 2048-bit RSA keys is probably going to hit OCSP servers pretty hard (because of the 6x larger CPU-cycles for the signature operation). > > You find reasonable to assume that whatever is requested by any > unauthenticated RP corresponds to a real certificate and is a correctly > formed request. That's a wrong assumption and is contradicted by real > world. Yet, additional pressure is put on OCSP producers, not on OCSP > consumers. The operational paradigm of the OCSP protocol specified in rfc2560 is that OCSP server MUST assume that the client is honest and serious about his request. A model where only the certificate holder performs OCSP requests for his forward cert chain (as with the TLS extension for stapling multiple OCSP responses) has the advantage that any such cert holder could use this very certificate to sign the OCSP request -- in case the OCSP server wants some means to recognize requests from clients that "have paid their due...". > > > > > > But holdInstructionCode could make sense, right? > > > > If you ignore for a moment that holdInstructionCode was removed > > from X.509 08/2005 _and_ rfc5280/PKIX, then id-holdinstruction-reject > > is another STRONG hint that certificateHold was defined intentionally > > with a very broad scope, even though certificateHold at early stages > > might have been motivated by a few, very specific use cases. > > > > Reading X.509 11/2008 shows that holdInstructionCode hasn't been removed, > and isn't declared as deprecated. The description of this extension has > been the same since the 08/1997 edition. X.509 08/2005 page 36: Section 8.5.2.3 Hold instruction code extension [...] This extension is always non-critical. No standard hold instruction codes are defined in this Directory Specification. X.509 11/2008 page 37: Section 8.5.2.3 Hold instruction code extension This extension is always non-critical. No standard hold instruction codes are defined in this Directory Specification. To me, that statement "No standard hold instruction codes are defined in this Directory Specification." very much says that this feature was removed from the standard (i.e. is no longer part of the spec). > > I don't know what motivated the removal of this extension in RFC5280, Maybe there are others who understand the X.509 change the way I do? > > But that doesn't say that "certificateHold" can be used for whatever > reason you might find useful, and especially not to declare non-existent > (really non-existent) certificates as revoked. That is non-sense. No CA needs *your* permission to put whatever serial it likes on its CRL. That is entirely up to the discretion of the CA. There is no requirement in X.509 and PKIX that such a serial refers to a cert that a CA has positive proof about ever having issued. And this is also entirely irrelevant for the proper operation/function of the protocol. > > > Personally, I consider the original OCSP design, where the RP > > rather than the certified entity obtains the OCSP response, > > a fairly useless protocol for online authentication. > > > > I see OCSP as a light CRL. The OCSP thisUpdate/nextUpdate have the same > semantic as the CRL lastUpdate/nextUpdate, "good" can be a valid response > for non-existent certificates. > That's unfortunate, I agree. RFC5019 adds some balance, distributing good > practice between OCSP responders and RP. OCSP isn't all flawed. What is definitely flawed is the distribution scheme for OCSP responses (RPs instead of certificate holders), and the scheme for identifying authorized OCSP responders (through information in the EE cert, rather than through a seperate key/chain hardwired into the CA cert), because the current OCSP model breaks completely for a CA compromise (which is a real pity!). > >>> I believe that a well-behaving CA shouldn't produce a CRL containing >>> random serial numbers provided by anonymous requesters. >> >> A "CRL request" is a simple download request. The RP does not convey >> any serials to the CA, and given the serial number space of 160 bits, >> it would be unfeasible for the CA to guess what cert serials an RP, >> who has just requested download of a CRL, is going to check between >> now an the next periodical CRL download. > > My point was that a CRL is a signed object, a commitment from the > Authority. And the Authority shouldn't declare things on identities it > doesn't know about. A **certificate** is a declaration (signed by the CA) about other identities. A CRL entry and an OCSP response are different, identifying only a serial plus an optional issuer/CA name. Therefore a revocation of a serial does not declare things on identities it doesn't know about -- on the contrary -- it is actually a refusal of the CA to declare things on identities it doesn't know about. A CA's OCSP responder who _has_ accessed to the logs of issued certs, and which does _not_ reply "revoked,certificateHold" on a serial that it does not find in the CA's issue logs, is _actively_ declaring things about identities as valid that it doesn't know about! So you've actually bitten yourself in the tail with that statement above. ;-) > > A CRL is supposed to revoke known certificates, each > with a correct revocation date (and not something set at epoch 0, > you can't play with revocation dates at will), and possibly with > a correct reason and other extensions. The revocation dates for serials that refer to "issued certs" on CRLs are subject to the CA's Certificate practice statement (CPS), but I'm not currently aware of any requirements by the specs. For serials of certs that the CA can no identify as having issued, the CPS does not apply, so anything goes. > > > A well-behaving OCSP responder is one that does not let RPs fall for > > fraudulent certs when it knows pretty damn well that the cert that > > the RP is requesting the status, for can not possibly be a bona fide > > certificate. An OCSP responder that lets RPs down so recklessly > > does not count as trustworthy on my scorecard. (Bad dog, no cookie). > > We agree on this point, a well-behaving OCSP responder shouldn't declare > that a non-existent certificate is valid. > A difference lies in the "non-existent": > - the serial number really corresponds to a non-existent certificate > (even with a perfect CA, such requests will exist) > - the serial number corresponds to an existent certificate unknown > to the CA > > Case 1 is MUCH more frequent. Case 2 is dangerous (DigiNotar, etc). Case 2 is dangerous because of the "Can't happen -- nuke the whole PKI if it happens" approach of X.509. For OCSP, this could be fixed by changing how an authorized OCSP signer is identified, by hardwiring a seperate trust path into the CA cert, rather than into the EE cert. > > The OCSP responder cannot distinguish between the two. Then please let's stop making this useless distinction in the discussion of the OCSP protocol! > > For me, asking for the OCSP responder (often the CA itself) to declare than > a non-existent certificate (Case 1) is revoked is a bad practice, and it > even doesn't solve the problem. > > Asking for OCSP responders to add something to "good" responses proving > they have access to a list of issued certificates (like the hash of the > certificate) is a better way to solve the problem. It must be backed-up > with rules or recommendations applied to RP to avoid a fallback to CRLs. The hard-fail option didn't work for the existing OCSP, how likely is it that it would work for a brand-new optional protocol extension? The "cert hash" option in the reply can not protect against any attacks, whereas the "revoked,certificateHold" option for serials not on the record of issued certs can at least protect against _some_ attacks. Since there are several design flaws in play, there is not going to be one single silver bullet that is going to solve all problems. Not changing anything at all would mean that we will be stuck with the known problems forever, which does not look like a sensible decision. So lets try to fix the issues one at a time. Every journey starts with a first step. -Martin From mrex@sap.com Wed Oct 24 13:22:57 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1ED921F8ACD for ; Wed, 24 Oct 2012 13:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.209 X-Spam-Level: X-Spam-Status: No, score=-10.209 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DK7cTFoPGJDQ for ; Wed, 24 Oct 2012 13:22:57 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id E994521F8A89 for ; Wed, 24 Oct 2012 13:22:56 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q9OKMret004395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 24 Oct 2012 22:22:53 +0200 (MEST) In-Reply-To: <20121024181016.503F21A2F3@ld9781.wdf.sap.corp> To: mrex@sap.com Date: Wed, 24 Oct 2012 22:22:52 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20121024202252.E840F1A2F3@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: Peter Rybar , pkix@ietf.org, Stefan Santesson Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 20:22:57 -0000 Patching a defect of my last message: Martin Rex wrote: > > > > > For me, asking for the OCSP responder (often the CA itself) to declare than > > a non-existent certificate (Case 1) is revoked is a bad practice, and it > > even doesn't solve the problem. > > > > Asking for OCSP responders to add something to "good" responses proving > > they have access to a list of issued certificates (like the hash of the > > certificate) is a better way to solve the problem. It must be backed-up > > with rules or recommendations applied to RP to avoid a fallback to CRLs. > > > The hard-fail option didn't work for the existing OCSP, how likely > is it that it would work for a brand-new optional protocol extension? > > The "cert hash" option in the reply can not protect against any attacks, > whereas the "revoked,certificateHold" option for serials not on the > record of issued certs can at least protect against _some_ attacks. The "cert hash" in the OCSP response option protects against hash-collisions and fraudulently issued without record of certs that re-use the serial of regular valid certs to appear innocent from not being detectable. So that cert hash should probably use at least SHA-256. Being a new protocol feature, that ought to be easy (we skipped SHA-1 in DANE as well). -Martin From piyush@ditenity.com Wed Oct 24 15:37:40 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA86B1F0C4C for ; Wed, 24 Oct 2012 15:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.293 X-Spam-Level: X-Spam-Status: No, score=-3.293 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLj963uiqa92 for ; Wed, 24 Oct 2012 15:37:40 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1761F0C49 for ; Wed, 24 Oct 2012 15:37:40 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id o25so925983iad.31 for ; Wed, 24 Oct 2012 15:37:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=auRHuGmoj+70J6ZfXXSMTacHZ2SlJphXr40/h8Q6oWI=; b=VxhQxMZkRpCEhmLZ9sHtZKOfrI/zt56mP/8jHVP6j3E0uxJik8wjyK5TnRw/qeMdzD zrj2TWeLcAfq2S9kPTcSdooS8MUCgIA9h6DqrgXgV52UMMJAFQimfvV44KQoYtp/qXhC rmC5ymVGNEtQrywJhYwS48uPy+BpIxAYd60AAcULXfruhinjq9gUqm88nGvTCYpthqr2 44INZsfx86kwhjZmRfjBMBrDVxAGpbN5EGr//80EPdJcXskFXEW4I5p66D9vsVa92GNb HgV33GWJjtAAgVnOying42mmdbQ0cC+mrrnONJuTJQUTZXPYcnplsgIo4d3nUI6oOdrk X6Tw== Received: by 10.50.46.226 with SMTP id y2mr4038122igm.62.1351118259681; Wed, 24 Oct 2012 15:37:39 -0700 (PDT) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id s3sm3097848igb.14.2012.10.24.15.37.37 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 24 Oct 2012 15:37:38 -0700 (PDT) From: "Piyush Jain" To: References: <20121024181016.503F21A2F3@ld9781.wdf.sap.corp> <20121024202252.E840F1A2F3@ld9781.wdf.sap.corp> In-Reply-To: <20121024202252.E840F1A2F3@ld9781.wdf.sap.corp> Date: Wed, 24 Oct 2012 15:37:25 -0700 Message-ID: <04d801cdb238$2ac3f350$804bd9f0$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFjmKQCMxFNIb8xC0cxdK32fyOSLpidPfvQ Content-Language: en-us X-Gm-Message-State: ALoCoQmXVkaYIjWo1qyTeDn/Nok/6xuaKXu2LP5oxwex5MEvxxOMBMa0Cx3VDDNxSeMroN3yN7pW Cc: 'Peter Rybar' , pkix@ietf.org, 'Stefan Santesson' Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 22:37:40 -0000 > The "cert hash" in the OCSP response option protects against hash-collisions > and fraudulently issued without record of certs that re-use the serial of > regular valid certs to appear innocent from not being detectable. > > So that cert hash should probably use at least SHA-256. Being a new protocol > feature, that ought to be easy (we skipped SHA-1 in DANE as well). [Piyush] I think you mean appears to protect. I hope people really don't start believing that this extension protects them from a CA compromise scenario. > > > -Martin > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From mrex@sap.com Wed Oct 24 15:40:42 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC8421F0C54 for ; Wed, 24 Oct 2012 15:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.211 X-Spam-Level: X-Spam-Status: No, score=-10.211 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v45KnCXPAMlE for ; Wed, 24 Oct 2012 15:40:42 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 007E51F0C49 for ; Wed, 24 Oct 2012 15:40:41 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q9OMeaBP011090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 25 Oct 2012 00:40:37 +0200 (MEST) In-Reply-To: <010201cdb06a$7a37c670$6ea75350$@ditenity.com> To: Piyush Jain Date: Thu, 25 Oct 2012 00:40:35 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20121024224035.E6D7E1A2F3@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: 'Peter Rybar' , 'Stefan Santesson' , pkix@ietf.org Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 22:40:42 -0000 Piyush Jain wrote: > > The people who are convinced that this is the way to go have not addressed > the issues raised in this WG. The little extension does not hurt anyone but > it does not provide any value in general except to a few implementations > which are compromised. But it does take you down a slippery slope when you > start promising that an OCSP responder can do much more than it is supposed > to. > > I don't think that it is unreasonable for a smart implementer to stop > signature checking if his responder claims that it checks issuance. I completely fail to follow your argument here. When you say "stop signature checking", do you mean checking the CA signature on the certificate for which you perform the OCSP request? In the exceptional case that - you exclusively use a securely preconfigured local OCSP responder, - this securely preconfigured local OCSP responder uses the optional cert hash extension in his responses and the hash returned with a good response matches the cert in question - you fully trust that securely preconfigured local OCSP responder to issue any cert it pleases like an omnipotent universal CA then you may omit the signature check on the certificate in question. In all other situations, you MUST verify the CA signature of the certificate before using any OCSP AIA in that cert to query its status -- or you misunderstand the X.509 security architecture and why it is vitally important that (a) (1) is the very first step in the certificate processing specified in PKIX/rfc5280: http://tools.ietf.org/html/rfc5280#section-6.1.3 -Martin From mrex@sap.com Wed Oct 24 15:47:27 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB21E21F8C90 for ; Wed, 24 Oct 2012 15:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.212 X-Spam-Level: X-Spam-Status: No, score=-10.212 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7ickrfLuU7N for ; Wed, 24 Oct 2012 15:47:27 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id E2F2421F8C97 for ; Wed, 24 Oct 2012 15:47:26 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q9OMlMoU011998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 25 Oct 2012 00:47:23 +0200 (MEST) In-Reply-To: <04d801cdb238$2ac3f350$804bd9f0$@ditenity.com> To: Piyush Jain Date: Thu, 25 Oct 2012 00:47:21 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20121024224721.EE2201A2F3@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: 'Peter Rybar' , pkix@ietf.org, 'Stefan Santesson' Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 22:47:27 -0000 Piyush Jain wrote: > >> The "cert hash" in the OCSP response option protects against >> hash-collisions >> and fraudulently issued without record of certs that re-use the serial of >> regular valid certs to appear innocent from not being detectable. >> >> So that cert hash should probably use at least SHA-256. Being a new >> protocol feature, that ought to be easy (we skipped SHA-1 in DANE as well). > > [Piyush] I think you mean appears to protect. > I hope people really don't start believing that this extension > protects them from a CA compromise scenario. You're confusing things. The reason why this protection currently does not work is not that there is a problem with conveying back the hash, but that the current scheme to identify an authorized OCSP responder cert is fatally flawed. Fixing the authorized OCSP responder issue is by defining a new attribute that is hardwired into the CA cert in order to establish an alternative trust path. The other thing you seem to totally discount is that not every breach of the CAs security amounts to a full and thorough compromise, i.e. that the attacker can get hold of an carry away the CA private signature key. -Martin From piyush@ditenity.com Wed Oct 24 20:56:11 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE3C1F0C7F for ; Wed, 24 Oct 2012 20:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.315 X-Spam-Level: X-Spam-Status: No, score=-3.315 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqVaIvJ-Kg8e for ; Wed, 24 Oct 2012 20:56:10 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC981F0C4A for ; Wed, 24 Oct 2012 20:56:10 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id o25so1113401iad.31 for ; Wed, 24 Oct 2012 20:56:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=6v3XlNuJ4VKhx1pyRqaq6J3/Nn8aPSduoRg/XjVXbWQ=; b=YqmIyuEKi9dgEN53T0OU5jfR7+CszA2KP2vTQCrOdM4l5OD2633rdfWs5cmtaEYHHv nH79u4aQ5HTjAEfU0zkkLMZHDD0p5QM2XhfDsaTFyZoTrgcTI4wUWcWoee5AjsCAQhAB aauDvm/XEuXKhI3sEVhOsudPwY/Y0k+iNE1lJMTHk2mUK/beX180DLqPZ1sEIJWmx1Uq zH1GP+cvphHODooGHaWZ5rJTF3dMaHEkMRWXHvFxVaWH4PBJpo3qiBE8KGyZ/FnAnWew qAL4y0mfTDQlMZqPXO0sItREGXyszpd9WXV8GbtJeJk+jJj1L9Xnm0Ks7eGOyCuxLk14 5eRA== Received: by 10.50.151.172 with SMTP id ur12mr4691078igb.44.1351137369984; Wed, 24 Oct 2012 20:56:09 -0700 (PDT) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id ex10sm3719378igc.15.2012.10.24.20.56.07 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 24 Oct 2012 20:56:09 -0700 (PDT) From: "Piyush Jain" To: References: <04d801cdb238$2ac3f350$804bd9f0$@ditenity.com> <20121024224721.EE2201A2F3@ld9781.wdf.sap.corp> In-Reply-To: <20121024224721.EE2201A2F3@ld9781.wdf.sap.corp> Date: Wed, 24 Oct 2012 20:56:05 -0700 Message-ID: <052d01cdb264$a9a32ed0$fce98c70$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHfLv9/VJ87pJZQkWKugh6d3aoOXJemZeDw Content-Language: en-us X-Gm-Message-State: ALoCoQmIBjah4tVzheg9Vv6x0hEWSX6z54IVZedzDTpHhx5WmwqZaPtzMmjkIC82YEicyblFa68M Cc: 'Peter Rybar' , pkix@ietf.org, 'Stefan Santesson' Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 03:56:11 -0000 > -----Original Message----- > From: Martin Rex [mailto:mrex@sap.com] > Sent: Wednesday, October 24, 2012 3:47 PM > To: Piyush Jain > Cc: mrex@sap.com; 'Peter Rybar'; pkix@ietf.org; 'Stefan Santesson' > Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 > > Piyush Jain wrote: > > > >> The "cert hash" in the OCSP response option protects against > >> hash-collisions and fraudulently issued without record of certs that > >> re-use the serial of regular valid certs to appear innocent from not > >> being detectable. > >> > >> So that cert hash should probably use at least SHA-256. Being a new > >> protocol feature, that ought to be easy (we skipped SHA-1 in DANE as > well). > > > > [Piyush] I think you mean appears to protect. > > I hope people really don't start believing that this extension > > protects them from a CA compromise scenario. > > > You're confusing things. The reason why this protection currently does not > work is not that there is a problem with conveying back the hash, but that > the current scheme to identify an authorized OCSP responder cert is fatally > flawed. [Piyush] I'm confused but only after your comments. What scheme are you talking about - CA delegated trust or direct trust dictated by local policy? > > Fixing the authorized OCSP responder issue is by defining a new attribute > that is hardwired into the CA cert in order to establish an alternative trust > path. > [Piyush] We are not talking about overhauling the protocol here. Are you implying that without this new attribute (whatever it is) the proposed change of returning revoked for fraudulent cert is not beneficial? If so then this discussion is moot. > > The other thing you seem to totally discount is that not every breach of the > CAs security amounts to a full and thorough compromise, i.e. that the > attacker can get hold of an carry away the CA private signature key. > [Piyush] If an attacker can issue fraudulent certificate it can issue a fraudulent certificate that points to a fraudulent OCSP responder also issued by the compromised CA. Unless you create a trust model where responder trust is independent of CA trust, these proposals just amount to hacks. Intent of OCSP is to address operational issues associated with CRL not to detect CA compromises. > > -Martin From piyush@ditenity.com Wed Oct 24 21:26:17 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8A611E80E5 for ; Wed, 24 Oct 2012 21:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.334 X-Spam-Level: X-Spam-Status: No, score=-3.334 tagged_above=-999 required=5 tests=[AWL=0.265, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DtPRBZgzplkI for ; Wed, 24 Oct 2012 21:26:16 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2A07D11E80E2 for ; Wed, 24 Oct 2012 21:26:16 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so1966936iec.31 for ; Wed, 24 Oct 2012 21:26:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=kwVvWfFABAKcKJHbekPUPEqz1KSDimX7lpQCe1lwuW4=; b=orwrE2RyQZJK8oiIW9lmw6WYOsf/v/VB+0nxYMpHzReJX3Hq7WLkJC6t1xEddoXz9n +ychaEPg+NaQi/70K29Vgyynp8IKtPj0wwmrj88smsrNszInBsYLJP1P05euBN0ufA4r DxZbny6phHQIhy3oZ59XhILotwEKDSCUbmXD5SetWh8kvHQmXIiqt6XRKFmqu7xN7grS kYLS35SiPpe9J3eTKIzLS9wTtxFMMWxGhlt4G0bHQaXJkJSfqxZJrz3HfAXqvSPwrcTC +6tdNTMavWlacMWk80Xr9//8rhBjGNUGbuNkLmo9mySMjPE1LJaluQBsCU80Wtl4XKRz 2gGA== Received: by 10.50.149.234 with SMTP id ud10mr4782075igb.12.1351139175722; Wed, 24 Oct 2012 21:26:15 -0700 (PDT) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id uz12sm3530033igb.16.2012.10.24.21.26.13 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 24 Oct 2012 21:26:14 -0700 (PDT) From: "Piyush Jain" To: References: <010201cdb06a$7a37c670$6ea75350$@ditenity.com> <20121024224035.E6D7E1A2F3@ld9781.wdf.sap.corp> In-Reply-To: <20121024224035.E6D7E1A2F3@ld9781.wdf.sap.corp> Date: Wed, 24 Oct 2012 21:26:10 -0700 Message-ID: <053201cdb268$ddf9a200$99ece600$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHr541m+Xr4o75zYM33iPWFWU2pC5eM+nJA Content-Language: en-us X-Gm-Message-State: ALoCoQkuQoLv0GO3KJbqXEE8S8xizEIPsDmCeeW6SiyCsaUZXID1dxdlfYqy68hUh5/GoRdXKZ7H Cc: 'Peter Rybar' , 'Stefan Santesson' , pkix@ietf.org Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 04:26:17 -0000 > -----Original Message----- > From: Martin Rex [mailto:mrex@sap.com] > Sent: Wednesday, October 24, 2012 3:41 PM > To: Piyush Jain > Cc: 'Stefan Santesson'; 'Peter Rybar'; 'Carl Wallace'; 'Simon Tardell'; 'Peter > Rybar'; pkix@ietf.org > Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 > > Piyush Jain wrote: > > > > The people who are convinced that this is the way to go have not > > addressed the issues raised in this WG. The little extension does not > > hurt anyone but it does not provide any value in general except to a > > few implementations which are compromised. But it does take you down a > > slippery slope when you start promising that an OCSP responder can do > > much more than it is supposed to. > > > > I don't think that it is unreasonable for a smart implementer to stop > > signature checking if his responder claims that it checks issuance. > > > I completely fail to follow your argument here. [Piyush] I think your comments below indicate that you understand the argument. > > When you say "stop signature checking", do you mean checking the CA > signature on the certificate for which you perform the OCSP request? [Piyush] Yes. > > In the exceptional case that > - you exclusively use a securely preconfigured local OCSP responder, > - this securely preconfigured local OCSP responder uses the optional > cert hash extension in his responses and the hash returned with > a good response matches the cert in question > - you fully trust that securely preconfigured local OCSP responder > to issue any cert it pleases like an omnipotent universal CA > > then you may omit the signature check on the certificate in question. [Piyush] And this is the only exceptional case where the cert hash extension and returning revoked for not-issued has any value. In every other scenario it's just a hack providing no additional security. > > In all other situations, you MUST verify the CA signature of the certificate > before using any OCSP AIA in that cert to query its status -- or you > misunderstand the X.509 security architecture and why it is vitally important > that (a) (1) is the very first step in the certificate processing specified in > PKIX/rfc5280: > > http://tools.ietf.org/html/rfc5280#section-6.1.3 > [Piyush] And yet you are arguing for an extension which enables responders to say that certificate can be non-issued even though the RP has verified that the CA issued it by performing signature verification. All this extension does is creates a paradox. If signature on the payload certificate verifies certificate is issued. If you cannot trust this cryptographic binding, you cannot trust the cryptographic binding on the responder's cert because the responder cert is also issued by the same CA. If the little extension benefits a small number of people who obviously do not have too much confidence in the security of their CA deployments, they can publish an informational RFC to accommodate this. Putting it in the standard just adds overhead for majority of vendors out there who at the minimum need to justify the reason for not including this feature in their implementation. > > -Martin From piyush@ditenity.com Fri Oct 26 09:16:52 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0600D21F863C for ; Fri, 26 Oct 2012 09:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.35 X-Spam-Level: X-Spam-Status: No, score=-3.35 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6-EyJFkOb5T for ; Fri, 26 Oct 2012 09:16:51 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE6521F8629 for ; Fri, 26 Oct 2012 09:16:51 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so4567272iec.31 for ; Fri, 26 Oct 2012 09:16:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=xpaRphAXflZpgUpwPlV/rYVeL26SUO3M3YuBKFf87Y4=; b=bq4orXEIY4LATj0/XBPHDnI+e3kU2JL4RL8hcTfjEAFWN/H78MVeZNSzsc635BB9uc BV2W3PUNKJbSMCo969so0Qw7zCA5O1HxG2Wj/nm6UGM1Qn3rU2w61qh+OUfK8YemBvTp yx0GBtKsCa9Es8vhqxWUYBw6A5HmPlxInhUxtx+7prySFzUYrSr0R3Uz5sdpjXo//Z/5 eR+BgPYs7dx86WaScCFDu3n+wLoqPHwVcSnxkKTEU+6P+f6+d1pEp8eRwSlAgkGTyxJ0 kf2nOvIJKWq9uC+YG9tACmTBJD0CSJ+jpLGHqHW8INFkbTYk23mZJn+EUJP76XmVWaaz 5VlQ== Received: by 10.50.155.193 with SMTP id vy1mr2590237igb.67.1351268210885; Fri, 26 Oct 2012 09:16:50 -0700 (PDT) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id x7sm1519351igk.8.2012.10.26.09.16.48 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 26 Oct 2012 09:16:50 -0700 (PDT) From: "Piyush Jain" To: References: <04d801cdb238$2ac3f350$804bd9f0$@ditenity.com> <20121024224721.EE2201A2F3@ld9781.wdf.sap.corp> In-Reply-To: <20121024224721.EE2201A2F3@ld9781.wdf.sap.corp> Date: Fri, 26 Oct 2012 09:16:46 -0700 Message-ID: <009301cdb395$4d4307f0$e7c917d0$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 thread-index: AQHfLv9/VJ87pJZQkWKugh6d3aoOXJeoynxw Content-Language: en-us X-Gm-Message-State: ALoCoQnd1hUrX0fXkrj6esnOIkEISe00HhfRS7kmSygdMzEVV0cj0FhJI+4yPcqf5B9B2oLmP6sU Cc: 'Peter Rybar' , pkix@ietf.org, 'Stefan Santesson' Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 16:16:52 -0000 > > The other thing you seem to totally discount is that not every breach of the > CAs security amounts to a full and thorough compromise, i.e. that the > attacker can get hold of an carry away the CA private signature key. > > [Piyush] Here is the bulletin published by NIST that pertains to this issue http://csrc.nist.gov/publications/nistbul/july-2012_itl-bulletin.pdf NIST recommends revoking the certificate in case of impersonation and RA compromise and revoking the CA in case of CA system or CA private key compromise. Let us know if/why you disagree with these recommendations and the kind of compromise in which this extension would make sense. From mrex@sap.com Fri Oct 26 19:44:41 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 556CB21F86AF for ; Fri, 26 Oct 2012 19:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.214 X-Spam-Level: X-Spam-Status: No, score=-10.214 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xu8bmlVIp7X3 for ; Fri, 26 Oct 2012 19:44:40 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id E63A721F86AC for ; Fri, 26 Oct 2012 19:44:39 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q9R2iZp3003541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 27 Oct 2012 04:44:35 +0200 (MEST) In-Reply-To: <009301cdb395$4d4307f0$e7c917d0$@ditenity.com> To: Piyush Jain Date: Sat, 27 Oct 2012 04:44:33 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20121027024433.90F6F1A301@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: 'Peter Rybar' , pkix@ietf.org, 'Stefan Santesson' Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2012 02:44:41 -0000 Piyush Jain wrote: > > > > The other thing you seem to totally discount is that not every breach of > > the CAs security amounts to a full and thorough compromise, i.e. that the > > attacker can get hold of an carry away the CA private signature key. > > [Piyush] Here is the bulletin published by NIST that pertains to this issue > http://csrc.nist.gov/publications/nistbul/july-2012_itl-bulletin.pdf > NIST recommends revoking the certificate in case of impersonation and RA > compromise and revoking the CA in case of CA system or CA private key > compromise. > > Let us know if/why you disagree with these recommendations and the kind of > compromise in which this extension would make sense. These recommendations are the longer version of "CA compromise can not possibly happen. If it happens anyhow, nuke the PKI" There are two things to do here: (1) do like NIST, openly admit that existing X.509/PKIX is defective describe the consequences for the installed base in case you're using X.509/PKIX. (2) fix the architecture of X.509 so that the CA key is no longer an unavoidable single-point-of-failure, and that the authentication can be restored to secure operation after the breach is detected for existing/deployed PKI credentials for use with RPs that use (modified) OCSP for revocation checking, _even_ when the CA signing key plus the OCSP signing key were captured by the attacker. I'm fully aware that patching/updating a huge installed base is going to be a significant effort, and drag along for quite a while. It is worthwhile and should be done. Been there, still fixing... (rfc5746, TLS secure renegotiation). I'm aware that original OCSP is limited in functionality to essentially splitting CRL checking into two tasks, and that it wasn't seen a chance to remediate the problem of a CA compromise through an independent trust path. So lets fix it. -Martin From piyush@ditenity.com Fri Oct 26 22:19:14 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4369B21F851C for ; Fri, 26 Oct 2012 22:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.365 X-Spam-Level: X-Spam-Status: No, score=-3.365 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQYOjWR4E2L6 for ; Fri, 26 Oct 2012 22:19:13 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3F621F84DF for ; Fri, 26 Oct 2012 22:19:13 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id x24so873723iak.31 for ; Fri, 26 Oct 2012 22:19:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=MYV8Ic6uQJLbdtyK2x8r9WHoUXhSOHYWCkLbgtXvoHc=; b=b+P2CY5GSGA1GwtMaTizuSy/Xuo51y2Jk0t5F0QM0UxI8ufKtfujctPrhJ8gIjGl9v 2sb63knVElMkzPl2FzNnsxdgk6Xr76DadOXox5J9FUQuQTVYNBHKG3GMuXA6P3TfUOiE orRj3ke3KxURHzIcqBVbzKRJhd3CVIh21LsLaG6mzNEwTEgEsROs6IKA65TyLYaOh0A1 WslzGxbwJALFKzWj5gaiH1n+HMKWApYkxc8hdKpAS7x5EpU8GEzFbkyJiWSKoG9LEuiw Re2grxOCLO/KoAhIT6QeNhMmJgpZ6dGPh/0rr2EN4XGlXFecZYD4nbYnUPUav9C4jjZm k/xQ== Received: by 10.50.57.169 with SMTP id j9mr4228234igq.16.1351315152828; Fri, 26 Oct 2012 22:19:12 -0700 (PDT) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id uz12sm790032igb.16.2012.10.26.22.19.10 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 26 Oct 2012 22:19:11 -0700 (PDT) From: "Piyush Jain" To: References: <009301cdb395$4d4307f0$e7c917d0$@ditenity.com> <20121027024433.90F6F1A301@ld9781.wdf.sap.corp> In-Reply-To: <20121027024433.90F6F1A301@ld9781.wdf.sap.corp> Date: Fri, 26 Oct 2012 22:19:08 -0700 Message-ID: <001201cdb402$98ab4d70$ca01e850$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGteoQecwln33ZCyYx7A2RCgqKALpgNCHcw Content-Language: en-us X-Gm-Message-State: ALoCoQle4QhhHxVRtV1+L9FF0SEDNwEJLPNfUUtQXXWlHUenoooTyVCTgOB35hAlQ2We9AuY5pbH Cc: pkix@ietf.org, 'Stefan Santesson' Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2012 05:19:14 -0000 > -----Original Message----- > From: Martin Rex [mailto:mrex@sap.com] > Sent: Friday, October 26, 2012 7:45 PM > To: Piyush Jain > Cc: mrex@sap.com; 'Peter Rybar'; pkix@ietf.org; 'Stefan Santesson' > Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 > > Piyush Jain wrote: > > > > > > The other thing you seem to totally discount is that not every > > > breach of the CAs security amounts to a full and thorough > > > compromise, i.e. that the attacker can get hold of an carry away the CA > private signature key. > > > > [Piyush] Here is the bulletin published by NIST that pertains to this > > issue > > http://csrc.nist.gov/publications/nistbul/july-2012_itl-bulletin.pdf > > NIST recommends revoking the certificate in case of impersonation and > > RA compromise and revoking the CA in case of CA system or CA private > > key compromise. > > > > Let us know if/why you disagree with these recommendations and the > > kind of compromise in which this extension would make sense. > > These recommendations are the longer version of > > "CA compromise can not possibly happen. If it happens anyhow, nuke the > PKI" > > > There are two things to do here: > > (1) do like NIST, openly admit that existing X.509/PKIX is defective > describe the consequences for the installed base in case you're using > X.509/PKIX. > [Piyush] I think that the conclusion is unfair - X.509/PKIX is defective because a few CAs get compromised. > (2) fix the architecture of X.509 so that the CA key is no longer > an unavoidable single-point-of-failure, and that the authentication > can be restored to secure operation after the breach is detected > for existing/deployed PKI credentials for use with RPs that use > (modified) OCSP for revocation checking, _even_ when the CA signing > key plus the OCSP signing key were captured by the attacker. > [Piyush] May be there is a silver bullet out there. But I have not seen one yet. None of the proposals here satisfy what you are asking. The closest one was from Phil some time ago where he informally proposed OCSP responder key should not be bound to the CA that issues EE certificate. And that one did not get any support here. BTW authentication can be restored by revoking the CA and reissuing the end entity certificates with a new key. Not saying that it is easy but it is doable, and unfortunately the only way to patch the vulnerabilities introduced by a CA compromise. > I'm fully aware that patching/updating a huge installed base is going to be a > significant effort, and drag along for quite a while. > It is worthwhile and should be done. > Been there, still fixing... (rfc5746, TLS secure renegotiation). > [Piyush] I'm all for improvement, the idea of overloading OCSP as it stands today is just a hack. I have not seen a single attack scenario where responding for so called un-issued certificates helps. People have been splitting hair by saying that even CA compromise can have different severance level. Unless you can document those and provide guidance on how this change would help, you are just adding to the confusion. > > I'm aware that original OCSP is limited in functionality to essentially splitting > CRL checking into two tasks, and that it wasn't seen a chance to remediate > the problem of a CA compromise through an independent trust path. So lets > fix it. > [Piyush] I think I fail to see the problem here. If CA is compromised, revoke the CA and reissue the ee with new CA key. If you have a proposal that allows the CA to operate securely even after a compromise, I'm all ears. > > -Martin From mrex@sap.com Mon Oct 29 16:23:39 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0873221F869F for ; Mon, 29 Oct 2012 16:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.649 X-Spam-Level: X-Spam-Status: No, score=-7.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALbKxd6OsfAq for ; Mon, 29 Oct 2012 16:23:37 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 4D79621F8674 for ; Mon, 29 Oct 2012 16:23:36 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q9TNNTcx015087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 30 Oct 2012 00:23:29 +0100 (MET) In-Reply-To: <001201cdb402$98ab4d70$ca01e850$@ditenity.com> To: Piyush Jain Date: Tue, 30 Oct 2012 00:23:28 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20121029232328.BF5D91A309@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: pkix@ietf.org, 'Stefan Santesson' Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 23:23:39 -0000 Piyush Jain wrote: > > Martin Rex wrote: >> >> These recommendations are the longer version of >> >> "CA compromise can not possibly happen. If it happens anyhow, nuke the >> PKI" >> >> >> There are two things to do here: >> >> (1) do like NIST, openly admit that existing X.509/PKIX is defective >> describe the consequences for the installed base in case you're using >> X.509/PKIX. > > I think that the conclusion is unfair - X.509/PKIX is defective > because a few CAs get compromised. X.509/PKIX is defective because it breaks badly already on fraudulent cert issuance (a weaker form of CA compromise) and can not cope at all with CA key compromise. > >> (2) fix the architecture of X.509 so that the CA key is no longer >> an unavoidable single-point-of-failure, and that the authentication >> can be restored to secure operation after the breach is detected >> for existing/deployed PKI credentials for use with RPs that use >> (modified) OCSP for revocation checking, _even_ when the CA signing >> key plus the OCSP signing key were captured by the attacker. > > May be there is a silver bullet out there. But I have not seen one yet. I don't think silver bullets exist (I wrote that previously), but one can hardly do worse that rfc2560 for online status checking of certs. OCSP was artificially limited to "as bad as CRL checking." > > None of the proposals here satisfy what you are asking. The closest one > was from Phil some time ago where he informally proposed OCSP responder key > should not be bound to the CA that issues EE certificate. And that one did > not get any support here. > > BTW authentication can be restored by revoking the CA and reissuing the end > entity certificates with a new key. Not saying that it is easy but it is > doable, and unfortunately the only way to patch the vulnerabilities > introduced by a CA compromise. If you imply revoking the compromised CA key by revoking the CA cert, then this isn't restoring authentication at all. It is nuking the old PKI and re-creating a new PKI. In case that this procedure assumes that using an audited log of issued certs can be used to automatically re-signed the public keys with the new CA cert and distribute only that cert (omitting the RA step), then this is conceptually on the right track. We do not even need to issue new certs -- if we extend OCSP to provide an independent confirmation to _others_ (RPs) right away, then we do not have to unconditionally force each PKI credential through a cert replacement _before_ it can be used again. Instead, the CA may keep the existing credential working and have PKI credentials gradually updated. Yes, Phil is right that the rfc2560 approach that the same CA key can sign valid OCSP signer keys is one of the design flaws of OCSP. > > [Piyush] I'm all for improvement, the idea of overloading OCSP as it stands > today is just a hack. I have not seen a single attack scenario where > responding for so called un-issued certificates helps. People have been > splitting hair by saying that even CA compromise can have different > severance level. Unless you can document those and provide guidance on how > this change would help, you are just adding to the confusion. rfc2560 OCSP currently delivers a poor ROI, and by extending the protocol, we could significantly improve its value. The TLS renegotiation issue was based on a completely flawed assumption (by primarily the renegotiating servers), infering from the renegotiation happening inside TLS that the remote peer will still be the same after renegotiation completes. It would have been obvious, for anyone who cared to really check, that there was *NO* cryptographic binding between the two TLS connection states. The flaw with CRLs and OCSP is that it tries to infer, from a lack of a revocation, that a certificate has been properly issued and is valid. Evidently, this turned out to be a logical fallacy with respect to real world usage scenarios. The design of CRLs is pretty much fubar, but OCSP gets at least the basic request-response semantics right, in that it is about a positive confirmation for the status of cert, rather than a flawed inference on the lack of a published revocation. In order to get rid of the CA-key-is-single-point-of-failure, a secondary trust path is necessary, one which can not be forged even when the CA cert signing key is compromised, two independent CA keys, that can be seperated and seperately protected, i.e. (1) CA-key-1 to sign EE certs (2) independent CA-key-2 to sign short-lived OCSP signer certs To issue (=sign) EE-Certs, only CA-key-1 needs to be accessible by the OnlineCA. One of the problems create by compromise of the CA-key-1 is that we can no longer trust any information in certs signed with CA-key-1 _unless_ we can obtain an independent confirmation of the certificate hash signed by an independent key. So in order to convey the necessary information in a fashion that is not affected by a CA-key-1 compromise, but still locally available to the certificate path validation function, we could convey (a) the location of the OCSP responder and (b) the CA-key-2 that is solely authorized to sign OCSP responder keys through new attributes of the CA cert that carries CA-key-1. An approach to make this mostly backwards-interoperable with rfc2560 would be to create a self-issued CA cert with CA-key-2 signed by CA-key-1, adding the certificate hash of this self-issued cert into the CA cert that carries CA-key-1, and create all OCSP responses with two path certs, the OCSP signer cert and the self-issued CA-key-2 signed by CA-key-1 cert. Vanilla rfc2560 RPs will remain unprotected from a CA key compromise, since they will continue to happily accept OCSP signer certs signed by CA-key-1. That is to be expected with a protocol design flaw. The important thing here is that you do not need two different kind of OCSP responses, but can still process value-added OCSP responses with rfc2560 RPs. (Similarly, TLS server implementations without rfc5746 will remain susceptible to the TLS renegotiation problem, but that should not stop anyone from adopting new protocol features). -Martin From stefan@aaa-sec.com Tue Oct 30 04:05:22 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E036C21F8511 for ; Tue, 30 Oct 2012 04:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.39 X-Spam-Level: X-Spam-Status: No, score=-100.39 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_SE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-goY3lyCLtp for ; Tue, 30 Oct 2012 04:05:22 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id A5E0D21F850D for ; Tue, 30 Oct 2012 04:05:21 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id D91932C8CD for ; Tue, 30 Oct 2012 11:52:48 +0100 (CET) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id eXTpDRQ8Yz-Z for ; Tue, 30 Oct 2012 11:52:48 +0100 (CET) Received: from s326.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 6B0D02C3AA for ; Tue, 30 Oct 2012 11:52:48 +0100 (CET) Received: (qmail 11014 invoked from network); 30 Oct 2012 10:52:48 -0000 Received: from 81-232-51-61-no39.business.telia.com (HELO [192.168.0.101]) (stefan@fiddler.nu@[81.232.51.61]) (envelope-sender ) by s326.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 30 Oct 2012 10:52:48 -0000 User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Tue, 30 Oct 2012 11:52:47 +0200 From: Stefan Santesson To: Message-ID: Thread-Topic: Straw-poll on OCSP responses for non-revoked certificates. In-Reply-To: <20121029232328.BF5D91A309@ld9781.wdf.sap.corp> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [pkix] Straw-poll on OCSP responses for non-revoked certificates. X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 11:05:23 -0000 Before we loose everyone engaged in this, I would like to make a straw-poll: Background: A client may do a request for a certificate that has never been issued by the CA. This request may be done deliberately, by mistake or as a consequence of a compromised CA. The OCSP protocol does not require OCSP responders to have any knowledge about issued certificates. It must only know about revoked certificates that are within it's current validity period. However, some OCSP responders closely coupled with the CA may also know if a certificate with a particular serialNumber value has been issued or not. The following is agreed: - An OCSP responder is allowed to respond "good" to a status request for a non-revoked certificate, disregarding if it has ever been issued. - A client, having no additional out-of-band knowledge about the OCSP responder, will just know that the certificate is "not revoked" when receiving a "good" response, unless the response includes one or more response extensions that provides additional information. The following is debated: - Is an OCSP responder allowed to respond "revoked" even if a requested certificate serial number is not on the list of revoked certificates, IF the OCSP responder has positive knowledge that the requested serial number does NOT represent a valid certificate issued by the identified CA? Rationale for: There are a number of reasons to allow this that has been mentioned, such as: - It breaks nothing. A legitimate request for an issued certificate will get a legitimate deterministic response. - It's safer. Responding "revoked" may not prevent a compromised CA from being exploited. But if a request for a serialNumber that is known to be bad is done nevertheless, a "revoked" response will at least be safer than responding "good". - Allowing extension definitions with further semantics. A response extension may be defined in the future that adds more information about the requested certificate. This may include a positive confirmation that the certificate has been issued as well as information that this particular OCSP responder will only respond "good" if it knows that the requested certificate has been issued, otherwise it will respond "revoked". An extension with such semantics can only be defined if the base standard allows a status other than "good" in such situation. - Supporting Web-PKI. The CAB-Forum has indicated that they will profile the OCSP protocol for use with web server authentication. In such profile they have indicated that they will NOT allow the "good" response unless the requested certificate is known to have been issued. This means that they will require OCSP responder in their infrastructure to have this knowledge. Such profile would have to break the base OCSP standard if this states that "good" MUST be returned unless the certificate has been revoked. Rationale against: The basic rationale against raised on this list has been the argument that it is wrong and confusing to allow anything but "good" as a response to a non-revoked certificate (if the cert is issued by a CA that is served by this OCSP responder). Another strong opinion is that it basically does not solve anything. A broken CA is broken and can't be fixed by responding "revoked". It would be easy to adapt an attack to circumvent such response, for example by issuing a fake certificate that duplicates a legitimate serialNumber. Please reply with either: 1. Allow "revoked" response for a certificate that has not been "revoked" but where that OCSP responder for any other reason knows the certificate to be "bad". 2. Require that the OCSP responder MUST respond "good" in this situation. 3. Neither 1 or 2 (motivate). Note: both alternatives are placed in a context where the certificate is claimed to be issued by a CA that is served by this OCSP responder. The exact meaning of "bad" is for later discussion. Please keep any motivation short and do not use this thread for long debates. From yngve@opera.com Tue Oct 30 04:22:33 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51B5F21F8545 for ; Tue, 30 Oct 2012 04:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id et1SdhDpxtht for ; Tue, 30 Oct 2012 04:22:28 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 0F74821F8458 for ; Tue, 30 Oct 2012 04:22:27 -0700 (PDT) Received: from damia.oslo.osa (oslo.jvpn.opera.com [213.236.208.46]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q9UBMOMc013959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 30 Oct 2012 11:22:24 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: pkix@ietf.org References: Date: Tue, 30 Oct 2012 12:22:21 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve Nysaeter Pettersen" Organization: Opera Software ASA Message-ID: In-Reply-To: User-Agent: Opera Mail/11.64 (Win32) Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked certificates. X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 11:22:33 -0000 Hi, I prefer Option 1: Return revoked when a certificate is not known to have been issued. On Tue, 30 Oct 2012 10:52:47 +0100, Stefan Santesson wrote: > Before we loose everyone engaged in this, I would like to make a > straw-poll: > Please reply with either: > > 1. Allow "revoked" response for a certificate that has not been "revoked" > but where that OCSP responder for any other reason knows the certificate > to be "bad". > > 2. Require that the OCSP responder MUST respond "good" in this situation. > > 3. Neither 1 or 2 (motivate). -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 96 90 41 51 Fax: +47 23 69 24 01 ******************************************************************** From ynir@checkpoint.com Tue Oct 30 04:42:39 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59B7921F843C for ; Tue, 30 Oct 2012 04:42:39 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCqMmIj0cTuh for ; Tue, 30 Oct 2012 04:42:37 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 2060D21F8440 for ; Tue, 30 Oct 2012 04:42:36 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id q9UBgZZi022820; Tue, 30 Oct 2012 13:42:35 +0200 X-CheckPoint: {508FBAD1-6-1B221DC2-2FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 30 Oct 2012 13:42:34 +0200 Received: from il-ex01.ad.checkpoint.com ([194.29.34.26]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Tue, 30 Oct 2012 13:42:34 +0200 From: Yoav Nir To: Yngve Nysaeter Pettersen Date: Tue, 30 Oct 2012 13:42:37 +0200 Thread-Topic: [pkix] Straw-poll on OCSP responses for non-revoked certificates. Thread-Index: Ac22k6bnKsZgjBWqTdC3MaELeP740w== Message-ID: <43C0F0FC-2632-44C4-9FAC-1BFCFAAA5EDD@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "pkix@ietf.org" Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked certificates. X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 11:42:39 -0000 Also #1.=20 It is wrong to assume that a compromised CA will issue any CA with any seri= al number. The compromises of Diginotar and InstantSSL.it did not allow the= attacker to choose a serial number, only to sign a particular request. Yoav On Oct 30, 2012, at 1:22 PM, Yngve Nysaeter Pettersen wrote: > Hi, >=20 > I prefer Option 1: Return revoked when a certificate is not known to have= =20 > been issued. >=20 >=20 > On Tue, 30 Oct 2012 10:52:47 +0100, Stefan Santesson = =20 > wrote: >=20 >> Before we loose everyone engaged in this, I would like to make a >> straw-poll: >=20 > >=20 >=20 >> Please reply with either: >>=20 >> 1. Allow "revoked" response for a certificate that has not been "revoked= " >> but where that OCSP responder for any other reason knows the certificate >> to be "bad". >>=20 >> 2. Require that the OCSP responder MUST respond "good" in this situation= . >>=20 >> 3. Neither 1 or 2 (motivate). >=20 >=20 >=20 > --=20 > Sincerely, > Yngve N. Pettersen > ******************************************************************** > Senior Developer Email: yngve@opera.com > Opera Software ASA http://www.opera.com/ > Phone: +47 96 90 41 51 Fax: +47 23 69 24 01 > ******************************************************************** > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix >=20 > Scanned by Check Point Total Security Gateway. From eabalea@gmail.com Tue Oct 30 05:35:19 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B581521F8582 for ; Tue, 30 Oct 2012 05:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HAcO1AESUhPN for ; Tue, 30 Oct 2012 05:35:19 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id C337F21F8554 for ; Tue, 30 Oct 2012 05:35:18 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so186115lam.31 for ; Tue, 30 Oct 2012 05:35:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2gqGemZt75CewY4vap00kt/fgwoAvah5suyC+GlOyf8=; b=BkAlJJmowLkUFF01nLxdhv8godogBy66YwTnSoxBIJJ73wDUOiseATVd/M9JLr+chf fVqpRjtKX4skU2sRzarTVJEGT9TVtAlYVoysvnCd8M4zOdU3IvRVSMHUp645K+8uLqD5 Ch4aDS9aQ8OB0hG2zZJoY9jBJOuXfk77uRfQ8YS2X2t/cJGtTSl+y3cJW+XbPPQLsLCq PqJxmFiHezMOH3+OrqMSt7C1z397G3QXuYbx/h5h8kFWuCs9ltbjMCDai4m7q/xKK25E HxG+jmtupsOA2qsl3TQbQFhM/d4u7HgOGbTr02XFAWkfqvXlTM6deb7AeIqRTnUvEyW0 ShQw== MIME-Version: 1.0 Received: by 10.152.148.226 with SMTP id tv2mr30132391lab.34.1351600511155; Tue, 30 Oct 2012 05:35:11 -0700 (PDT) Received: by 10.114.25.74 with HTTP; Tue, 30 Oct 2012 05:35:11 -0700 (PDT) In-Reply-To: References: <20121029232328.BF5D91A309@ld9781.wdf.sap.corp> Date: Tue, 30 Oct 2012 13:35:11 +0100 Message-ID: From: Erwann Abalea To: Stefan Santesson Content-Type: text/plain; charset=UTF-8 Cc: pkix@ietf.org Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked certificates. X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 12:35:19 -0000 Bonjour, Option #3, reply with an unsigned response (unauthorized), RP SHOULD have a hard-fail behavior. 2012/10/30 Stefan Santesson : [...] > Please reply with either: > > 1. Allow "revoked" response for a certificate that has not been "revoked" > but where that OCSP responder for any other reason knows the certificate > to be "bad". > > 2. Require that the OCSP responder MUST respond "good" in this situation. > > 3. Neither 1 or 2 (motivate). -- Erwann. From tmiller@mitre.org Tue Oct 30 05:41:03 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAE0221F852C for ; Tue, 30 Oct 2012 05:41:02 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zl3HIOBv+WVo for ; Tue, 30 Oct 2012 05:41:02 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3256221F8523 for ; Tue, 30 Oct 2012 05:41:02 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 66C6D1F0AED; Tue, 30 Oct 2012 08:41:01 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 286AC1F0AE5; Tue, 30 Oct 2012 08:41:01 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.132]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0318.004; Tue, 30 Oct 2012 08:41:00 -0400 From: "Miller, Timothy J." To: "mrex@sap.com" , Piyush Jain Thread-Topic: [pkix] New draft-ietf-pkix-rfc2560bis-06 Thread-Index: AQHNrgV0CIAuT0FuokKp0o24TaVmN5fBJu8AgACTr4CAAOEpAIABk0sAgAAe6wCAAAW7AIABaDuAgAAG8ICAAAydAIAAVs6AgACatwCAAAbOgIAALqKAgAAFooCAAAz5gIAAJh+AgABTegCAAYn9AIAAJQwAgAAlmICAAALHgIACt4kAgACvZoCAACsxAIAEU58AgACWuLQ= Date: Tue, 30 Oct 2012 12:40:59 +0000 Message-ID: <195DB2510AAA004391F58E28FCE21200066E1E15@IMCMBX01.MITRE.ORG> References: <001201cdb402$98ab4d70$ca01e850$@ditenity.com>, <20121029232328.BF5D91A309@ld9781.wdf.sap.corp> In-Reply-To: <20121029232328.BF5D91A309@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.52] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pkix@ietf.org" , 'Stefan Santesson' Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 12:41:03 -0000 > X.509/PKIX is defective because it breaks badly already on fraudulent > cert issuance (a weaker form of CA compromise) and can not cope at all > with CA key compromise. Do you have an alternative to the technology, because AFAICT, no PKI standa= rds recover well from a breach of trust. Even the web of trust has issues;= if a well-connected introducer is compromised, all descendent keys become = suspect--which can potentially encompass all nodes in the graph. This can = be as devestating as a CA compromise, and would likewise require a re-execu= tion of a large number of signing ceremonies. > The flaw with CRLs and OCSP is that it tries to infer, from a lack > of a revocation, that a certificate has been properly issued and is valid= . > Evidently, this turned out to be a logical fallacy with respect to > real world usage scenarios. Absent a trusted observer, there is no positive statement that can be issue= d by a CA that positively identifies only "valid" certificates. Given a tr= usted observer, why not make him the CA and be done with it? -- T= From d.w.chadwick@kent.ac.uk Tue Oct 30 06:44:06 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3802221F84E7 for ; Tue, 30 Oct 2012 06:44:06 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMPtvZm7MVq7 for ; Tue, 30 Oct 2012 06:44:05 -0700 (PDT) Received: from mx2.kent.ac.uk (mx2.kent.ac.uk [129.12.21.33]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4DD21F84DB for ; Tue, 30 Oct 2012 06:44:04 -0700 (PDT) Received: from dhcp29ca.kent.ac.uk ([129.12.41.202]) by mx2.kent.ac.uk with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72) (envelope-from ) id 1TTC6r-0006lR-BI; Tue, 30 Oct 2012 13:44:01 +0000 Message-ID: <508FD9A4.8080101@kent.ac.uk> Date: Tue, 30 Oct 2012 13:44:04 +0000 From: David Chadwick User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked certificates. X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 13:44:06 -0000 1 On 30/10/2012 09:52, Stefan Santesson wrote: > Before we loose everyone engaged in this, I would like to make a > straw-poll: > > > Background: > A client may do a request for a certificate that has never been issued by > the CA. > This request may be done deliberately, by mistake or as a consequence of a > compromised CA. > > The OCSP protocol does not require OCSP responders to have any knowledge > about issued certificates. It must only know about revoked certificates > that are within it's current validity period. However, some OCSP > responders closely coupled with the CA may also know if a certificate with > a particular serialNumber value has been issued or not. > > The following is agreed: > - An OCSP responder is allowed to respond "good" to a status request > for a non-revoked certificate, disregarding if it has ever been issued. > > - A client, having no additional out-of-band knowledge about the OCSP > responder, will just know that the certificate is "not revoked" when > receiving a "good" response, unless the response includes one or more > response extensions that provides additional information. > > > The following is debated: > - Is an OCSP responder allowed to respond "revoked" even if a requested > certificate serial number is not on the list of revoked certificates, IF > the OCSP responder has positive knowledge that the requested serial number > does NOT represent a valid certificate issued by the identified CA? > > > Rationale for: > There are a number of reasons to allow this that has been mentioned, such > as: > - It breaks nothing. A legitimate request for an issued certificate will > get a legitimate deterministic response. > - It's safer. Responding "revoked" may not prevent a compromised CA from > being exploited. But if a request for a serialNumber that is known to be > bad is done nevertheless, a "revoked" response will at least be safer than > responding "good". > - Allowing extension definitions with further semantics. A response > extension may be defined in the future that adds more information about > the requested certificate. This may include a positive confirmation that > the certificate has been issued as well as information that this > particular OCSP responder will only respond "good" if it knows that the > requested certificate has been issued, otherwise it will respond > "revoked". An extension with such semantics can only be defined if the > base standard allows a status other than "good" in such situation. > - Supporting Web-PKI. The CAB-Forum has indicated that they will profile > the OCSP protocol for use with web server authentication. In such profile > they have indicated that they will NOT allow the "good" response unless > the requested certificate is known to have been issued. This means that > they will require OCSP responder in their infrastructure to have this > knowledge. Such profile would have to break the base OCSP standard if this > states that "good" MUST be returned unless the certificate has been > revoked. > > Rationale against: > The basic rationale against raised on this list has been the argument that > it is wrong and confusing to allow anything but "good" as a response to a > non-revoked certificate (if the cert is issued by a CA that is served by > this OCSP responder). > Another strong opinion is that it basically does not solve anything. A > broken CA is broken and can't be fixed by responding "revoked". It would > be easy to adapt an attack to circumvent such response, for example by > issuing a fake certificate that duplicates a legitimate serialNumber. > > > Please reply with either: > > 1. Allow "revoked" response for a certificate that has not been "revoked" > but where that OCSP responder for any other reason knows the certificate > to be "bad". > > 2. Require that the OCSP responder MUST respond "good" in this situation. > > 3. Neither 1 or 2 (motivate). > > > > > Note: both alternatives are placed in a context where the certificate is > claimed to be issued by a CA that is served by this OCSP responder. The > exact meaning of "bad" is for later discussion. > > Please keep any motivation short and do not use this thread for long > debates. > > > > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > From aallison@nab.org Tue Oct 30 07:00:15 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACD0321F851F for ; Tue, 30 Oct 2012 07:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRFDE0pcKi6G for ; Tue, 30 Oct 2012 07:00:14 -0700 (PDT) Received: from p01c11o148.mxlogic.net (p01c11o148.mxlogic.net [208.65.144.71]) by ietfa.amsl.com (Postfix) with ESMTP id 9A10D21F8519 for ; Tue, 30 Oct 2012 07:00:13 -0700 (PDT) Received: from unknown [208.97.234.91] by p01c11o148.mxlogic.net(mxl_mta-6.15.0-1) with SMTP id c6ddf805.0.132698.00-336.283623.p01c11o148.mxlogic.net (envelope-from ); Tue, 30 Oct 2012 08:00:13 -0600 (MDT) X-MXL-Hash: 508fdd6d3783a70f-f8cd81b28a60314653d04974c0894307e5b75f9f X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CDB6A6.D8529FBF" Date: Tue, 30 Oct 2012 09:59:57 -0400 Message-ID: <71C9EC0544D1F64D8B7D91EDCC62202005EB6544@NABSREX027324.NAB.ORG> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Straw-poll on OCSP responses for non-revoked certificates. Thread-Index: Ac22jomRZ7cxvK5pRDSVUu4rutpE1wAFcyN4 References: From: "Art Allison" To: X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [208.97.234.91] X-AnalysisOut: [v=2.0 cv=Gob1DDJC c=1 sm=0 a=tFGTPFZixTZ3yCXJchW01Q==:17 a] X-AnalysisOut: [=nAQpcSRLQ4kA:10 a=BvPfnLs-15kA:10 a=BLceEmwcHowA:10 a=g0F] X-AnalysisOut: [pLpFZAAAA:8 a=ealCiPDQX5oA:10 a=48vgC7mUAAAA:8 a=xg_4MWxSH] X-AnalysisOut: [X3jaeGmQC4A:9 a=wPNLvfGTeEIA:10 a=8SgyfJxrfqYA:10 a=-9UqKS] X-AnalysisOut: [le32gA:10 a=Qd0007q6B0YA:10 a=lZB815dzVvQA:10 a=DVZLbf9Vdx] X-AnalysisOut: [5b1mPn:21 a=UsD4N9U9HuuJLKLQ:21 a=5VZhB56tODNUlkTtP_gA:9 a] X-AnalysisOut: [=_W_S_7VecoQA:10 a=xupqqEyGbST9icpr:21 a=NZrSPOWml4-bQoxp:] X-AnalysisOut: [21 a=fOMQj8Tss6DxVb_v:21] Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked certificates. X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 14:00:15 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CDB6A6.D8529FBF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 3) Neither. Add new optional response =3D unissued. The conflation of revoked and unissued that seems to be unresolvable by = the current protocol says to me the current protocol is inadequate and a = new response is needed. =20 =20 Responding revoked for an unissued cert is a lie. No RFC should ever = attempt to make implmentors lie, as some will refuse to do so and lack = of interoperablity across implementations results. And, relevant to = implementation decisions; I am responsible for a contract with a vendor = that has an OCSP function. =20 =20 Art Allison Senior Director Advanced Engineering, Science and Technology National Association of Broadcasters 1771 N Street NW Washington, DC 20036 Phone 202 429 5418 Fax 202 775 4981 www.nab.org =20 *Advocacy Education Innovation* ________________________________ From: pkix-bounces@ietf.org on behalf of Stefan Santesson Sent: Tue 10/30/2012 5:52 AM To: pkix@ietf.org Subject: [pkix] Straw-poll on OCSP responses for non-revoked = certificates. Before we loose everyone engaged in this, I would like to make a straw-poll: Background: A client may do a request for a certificate that has never been issued = by the CA. This request may be done deliberately, by mistake or as a consequence of = a compromised CA. The OCSP protocol does not require OCSP responders to have any knowledge about issued certificates. It must only know about revoked certificates that are within it's current validity period. However, some OCSP responders closely coupled with the CA may also know if a certificate = with a particular serialNumber value has been issued or not. The following is agreed: - An OCSP responder is allowed to respond "good" to a status request for a non-revoked certificate, disregarding if it has ever been issued. - A client, having no additional out-of-band knowledge about the OCSP responder, will just know that the certificate is "not revoked" when receiving a "good" response, unless the response includes one or more response extensions that provides additional information. The following is debated: - Is an OCSP responder allowed to respond "revoked" even if a = requested certificate serial number is not on the list of revoked certificates, IF the OCSP responder has positive knowledge that the requested serial = number does NOT represent a valid certificate issued by the identified CA? Rationale for: There are a number of reasons to allow this that has been mentioned, = such as: - It breaks nothing. A legitimate request for an issued certificate = will get a legitimate deterministic response. - It's safer. Responding "revoked" may not prevent a compromised CA = from being exploited. But if a request for a serialNumber that is known to be bad is done nevertheless, a "revoked" response will at least be safer = than responding "good". - Allowing extension definitions with further semantics. A response extension may be defined in the future that adds more information about the requested certificate. This may include a positive confirmation that the certificate has been issued as well as information that this particular OCSP responder will only respond "good" if it knows that the requested certificate has been issued, otherwise it will respond "revoked". An extension with such semantics can only be defined if the base standard allows a status other than "good" in such situation. - Supporting Web-PKI. The CAB-Forum has indicated that they will = profile the OCSP protocol for use with web server authentication. In such = profile they have indicated that they will NOT allow the "good" response unless the requested certificate is known to have been issued. This means that they will require OCSP responder in their infrastructure to have this knowledge. Such profile would have to break the base OCSP standard if = this states that "good" MUST be returned unless the certificate has been revoked. Rationale against: The basic rationale against raised on this list has been the argument = that it is wrong and confusing to allow anything but "good" as a response to = a non-revoked certificate (if the cert is issued by a CA that is served by this OCSP responder). Another strong opinion is that it basically does not solve anything. A broken CA is broken and can't be fixed by responding "revoked". It would be easy to adapt an attack to circumvent such response, for example by issuing a fake certificate that duplicates a legitimate serialNumber. Please reply with either: 1. Allow "revoked" response for a certificate that has not been = "revoked" but where that OCSP responder for any other reason knows the certificate to be "bad". 2. Require that the OCSP responder MUST respond "good" in this = situation. 3. Neither 1 or 2 (motivate). Note: both alternatives are placed in a context where the certificate is claimed to be issued by a CA that is served by this OCSP responder. The exact meaning of "bad" is for later discussion. Please keep any motivation short and do not use this thread for long debates. _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix ------_=_NextPart_001_01CDB6A6.D8529FBF Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [pkix] Straw-poll on OCSP responses for = non-revoked certificates.=0A= =0A= =0A= =0A=
=0A=
=0A=
3) Neither. Add new optional response =3D unissued.
=0A=
The conflation of revoked and unissued that seems to be = unresolvable by the current protocol says to me the current protocol is = inadequate and a new response is = needed.  
=0A=
 
=0A=
Responding revoked for an unissued cert is a lie.  = No RFC should ever attempt to make implmentors lie, as some will refuse = to do so and lack of interoperablity across implementations = results.  And, relevant to implementation decisions; I am = responsible for a contract with a vendor that has an OCSP = function.  
=0A=
 
=0A=
=0A=
Art Allison
=0A=
Senior Director Advanced Engineering, Science and = Technology

National Association of Broadcasters
1771 N Street = NW
Washington, DC 20036
Phone  202 429 5418
Fax  202 = 775 4981
www.nab.org
*Advocacy  = Education  Innovation*
=0A=

=0A=
=0A= From: pkix-bounces@ietf.org on = behalf of Stefan Santesson
Sent: Tue 10/30/2012 5:52 = AM
To: pkix@ietf.org
Subject: [pkix] Straw-poll on = OCSP responses for non-revoked certificates.

=0A=
=0A=

Before we loose everyone engaged in this, I would like = to make a
straw-poll:


Background:
A client may do a = request for a certificate that has never been issued by
the = CA.
This request may be done deliberately, by mistake or as a = consequence of a
compromised CA.

The OCSP protocol does not = require OCSP responders to have any knowledge
about issued = certificates. It must only know about revoked certificates
that are = within it's current validity period. However, some OCSP
responders = closely coupled with the CA may also know if a certificate with
a = particular serialNumber value has been issued or not.

The = following is agreed:
   - An OCSP responder is allowed to = respond "good" to a status request
for a non-revoked certificate, = disregarding if it has ever been issued.

   - A client, = having no additional out-of-band knowledge about the OCSP
responder, = will just know that the certificate is "not revoked" when
receiving a = "good" response, unless the response includes one or more
response = extensions that provides additional information.


The = following is debated:
   - Is an OCSP responder allowed to = respond "revoked" even if a requested
certificate serial number is = not on the list of revoked certificates, IF
the OCSP responder has = positive knowledge that the requested serial number
does NOT = represent a valid certificate issued by the identified = CA?


Rationale for:
There are a number of reasons to allow = this that has been mentioned, such
as:
 - It breaks nothing. = A legitimate request for an issued certificate will
get a legitimate = deterministic response.
 - It's safer. Responding "revoked" may = not prevent a compromised CA from
being exploited. But if a request = for a serialNumber that is known to be
bad is done nevertheless, a = "revoked" response will at least be safer than
responding = "good".
 - Allowing extension definitions with further = semantics. A response
extension may be defined in the future that = adds more information about
the requested certificate. This may = include a positive confirmation that
the certificate has been issued = as well as information that this
particular OCSP responder will only = respond "good" if it knows that the
requested certificate has been = issued, otherwise it will respond
"revoked". An extension with such = semantics can only be defined if the
base standard allows a status = other than "good" in such situation.
 - Supporting Web-PKI. The = CAB-Forum has indicated that they will profile
the OCSP protocol for = use with web server authentication. In such profile
they have = indicated that they will NOT allow the "good" response unless
the = requested certificate is known to have been issued. This means = that
they will require OCSP responder in their infrastructure to have = this
knowledge. Such profile would have to break the base OCSP = standard if this
states that "good" MUST be returned unless the = certificate has been
revoked.

Rationale against:
The basic = rationale against raised on this list has been the argument that
it = is wrong and confusing to allow anything but "good" as a response to = a
non-revoked certificate (if the cert is issued by a CA that is = served by
this OCSP responder).
Another strong opinion is that it = basically does not solve anything. A
broken CA is broken and can't be = fixed by responding "revoked". It would
be easy to adapt an attack to = circumvent such response, for example by
issuing a fake certificate = that duplicates a legitimate serialNumber.


Please reply with = either:

1. Allow "revoked" response for a certificate that has = not been "revoked"
but where that OCSP responder for any other reason = knows the certificate
to be "bad".

2. Require that the OCSP = responder MUST respond "good" in this situation.

3. Neither 1 or = 2 (motivate).




Note: both alternatives are placed in a = context where the certificate is
claimed to be issued by a CA that is = served by this OCSP responder. The
exact meaning of "bad" is for = later discussion.

Please keep any motivation short and do not use = this thread for = long
debates.






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

------_=_NextPart_001_01CDB6A6.D8529FBF-- From tmiller@mitre.org Tue Oct 30 07:07:28 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC4F821F8519 for ; Tue, 30 Oct 2012 07:07:28 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4bHxbYC34Qz for ; Tue, 30 Oct 2012 07:07:27 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id CF01921F848B for ; Tue, 30 Oct 2012 07:07:27 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 20C491F072E; Tue, 30 Oct 2012 10:07:27 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 0C60D1F05F0; Tue, 30 Oct 2012 10:07:27 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.132]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.02.0318.004; Tue, 30 Oct 2012 10:07:26 -0400 From: "Miller, Timothy J." To: 'Art Allison' , "pkix@ietf.org" Thread-Topic: [pkix] Straw-poll on OCSP responses for non-revoked certificates. Thread-Index: AQHNtqblMgNdLLPinE+jI++DAIupIpfR4djw Date: Tue, 30 Oct 2012 14:07:26 +0000 Message-ID: <195DB2510AAA004391F58E28FCE21200066E2071@IMCMBX01.MITRE.ORG> References: <71C9EC0544D1F64D8B7D91EDCC62202005EB6544@NABSREX027324.NAB.ORG> In-Reply-To: <71C9EC0544D1F64D8B7D91EDCC62202005EB6544@NABSREX027324.NAB.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked certificates. X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 14:07:28 -0000 >3) Neither. Add new optional response =3D unissued. UNKNOWN would satisfy in this case, but that wasn't a poll option. :) I disagree in re: lying. The OCSP responder can respond REVOKED and the CA= could add it to the CRL afterward, and a relying party wouldn't be able to= tell the difference. -- T From SChokhani@cygnacom.com Tue Oct 30 07:24:45 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 899B121F853B for ; Tue, 30 Oct 2012 07:24:45 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XyMHzxaEkW5B for ; Tue, 30 Oct 2012 07:24:44 -0700 (PDT) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id 6824921F84A7 for ; Tue, 30 Oct 2012 07:24:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,679,1344225600"; d="scan'208";a="2286719" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 30 Oct 2012 10:24:21 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Tue, 30 Oct 2012 10:24:21 -0400 From: Santosh Chokhani To: Stefan Santesson , "pkix@ietf.org" Date: Tue, 30 Oct 2012 10:24:19 -0400 Thread-Topic: Straw-poll on OCSP responses for non-revoked certificates. Thread-Index: Ac22jnjC7eaNdN6LRhiNwYsTgN9m6wAG7IaQ Message-ID: References: <20121029232328.BF5D91A309@ld9781.wdf.sap.corp> 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 Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked certificates. X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 14:24:45 -0000 Stefan, I vote for option 1, that is claim it to be revoked. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Ste= fan Santesson Sent: Tuesday, October 30, 2012 5:53 AM To: pkix@ietf.org Subject: [pkix] Straw-poll on OCSP responses for non-revoked certificates. Before we loose everyone engaged in this, I would like to make a straw-poll: Background: A client may do a request for a certificate that has never been issued by t= he CA. This request may be done deliberately, by mistake or as a consequence of a = compromised CA. The OCSP protocol does not require OCSP responders to have any knowledge ab= out issued certificates. It must only know about revoked certificates that = are within it's current validity period. However, some OCSP responders clos= ely coupled with the CA may also know if a certificate with a particular se= rialNumber value has been issued or not. The following is agreed: - An OCSP responder is allowed to respond "good" to a status request for= a non-revoked certificate, disregarding if it has ever been issued. - A client, having no additional out-of-band knowledge about the OCSP re= sponder, will just know that the certificate is "not revoked" when receivin= g a "good" response, unless the response includes one or more response exte= nsions that provides additional information. The following is debated: - Is an OCSP responder allowed to respond "revoked" even if a requested = certificate serial number is not on the list of revoked certificates, IF th= e OCSP responder has positive knowledge that the requested serial number do= es NOT represent a valid certificate issued by the identified CA? Rationale for: There are a number of reasons to allow this that has been mentioned, such as: - It breaks nothing. A legitimate request for an issued certificate will g= et a legitimate deterministic response. - It's safer. Responding "revoked" may not prevent a compromised CA from b= eing exploited. But if a request for a serialNumber that is known to be bad= is done nevertheless, a "revoked" response will at least be safer than res= ponding "good". - Allowing extension definitions with further semantics. A response extens= ion may be defined in the future that adds more information about the reque= sted certificate. This may include a positive confirmation that the certifi= cate has been issued as well as information that this particular OCSP respo= nder will only respond "good" if it knows that the requested certificate ha= s been issued, otherwise it will respond "revoked". An extension with such = semantics can only be defined if the base standard allows a status other th= an "good" in such situation. - Supporting Web-PKI. The CAB-Forum has indicated that they will profile t= he OCSP protocol for use with web server authentication. In such profile th= ey have indicated that they will NOT allow the "good" response unless the r= equested certificate is known to have been issued. This means that they wil= l require OCSP responder in their infrastructure to have this knowledge. Su= ch profile would have to break the base OCSP standard if this states that "= good" MUST be returned unless the certificate has been revoked. Rationale against: The basic rationale against raised on this list has been the argument that = it is wrong and confusing to allow anything but "good" as a response to a n= on-revoked certificate (if the cert is issued by a CA that is served by thi= s OCSP responder). Another strong opinion is that it basically does not solve anything. A brok= en CA is broken and can't be fixed by responding "revoked". It would be eas= y to adapt an attack to circumvent such response, for example by issuing a = fake certificate that duplicates a legitimate serialNumber. Please reply with either: 1. Allow "revoked" response for a certificate that has not been "revoked" but where that OCSP responder for any other reason knows the certificate to= be "bad". 2. Require that the OCSP responder MUST respond "good" in this situation. 3. Neither 1 or 2 (motivate). Note: both alternatives are placed in a context where the certificate is cl= aimed to be issued by a CA that is served by this OCSP responder. The exact= meaning of "bad" is for later discussion. Please keep any motivation short and do not use this thread for long debate= s. =20 _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From eabalea@gmail.com Tue Oct 30 07:26:21 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA3621F8539 for ; Tue, 30 Oct 2012 07:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVKAblgav1Pf for ; Tue, 30 Oct 2012 07:26:20 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 438A321F851A for ; Tue, 30 Oct 2012 07:26:20 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so279834lam.31 for ; Tue, 30 Oct 2012 07:26:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5hIwATJtZ4XM83W17xTkU2Ef8031LOAwlDYRUqsKQbA=; b=GWNJMwfObJyom+zWpbufOC2ONMbkRdQIns3HBWCWZokM92Wj1XSzHMcdDksmWaU4aS 6iYTizx2bEnhBvfXhGXsgZNvIlOFGp0FYc6fuSIzuhOilHvirCXDQeg69Uqu3Dqv9MWq 9ZoZBgmlH9P5QC/Qivj9pZPN1c1k1BYd9DVsb5iJLOI1kUzz1vSfFSpDg4Z3+eWZ7ofd FEIXmNWqQVZfZyjmv2caz2jZiJSFQX9DHy2pPmfuBX7BKTCuO8+QIPgUnkjEk/93ka4z 9dcMISrc91zM/LvKo311hdWvyIuY4LJ92fdqxCNUG6HntRObtDesdEBm7nJIn+9D0l1k ZvmA== MIME-Version: 1.0 Received: by 10.112.99.37 with SMTP id en5mr13396071lbb.1.1351607179140; Tue, 30 Oct 2012 07:26:19 -0700 (PDT) Received: by 10.114.25.74 with HTTP; Tue, 30 Oct 2012 07:26:19 -0700 (PDT) In-Reply-To: <195DB2510AAA004391F58E28FCE21200066E2071@IMCMBX01.MITRE.ORG> References: <71C9EC0544D1F64D8B7D91EDCC62202005EB6544@NABSREX027324.NAB.ORG> <195DB2510AAA004391F58E28FCE21200066E2071@IMCMBX01.MITRE.ORG> Date: Tue, 30 Oct 2012 15:26:19 +0100 Message-ID: From: Erwann Abalea To: "Miller, Timothy J." Content-Type: text/plain; charset=UTF-8 Cc: "pkix@ietf.org" Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked certificates. X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 14:26:21 -0000 2012/10/30 Miller, Timothy J. : [...] > I disagree in re: lying. The OCSP responder can respond REVOKED and the CA could add it to the CRL afterward, and a relying party wouldn't be able to tell the difference. You'll then have to set a revocation date to be set in the CRL, which might be different than the one defined here. Some asked for epoch, some asked for 1950, but since you can't use as a revocation date for a certificate a date earlier than the thisUpdate of a previous CRL in which that certificate wasn't revoked, a RP will be able to tell the difference (that's normative). Of course, this certificate won't be removed from the CRL since you don't know its expiration date (nice to make a CRL grow indefinitely). And if the CA has some sort of constraints in its DB (which can be considered as good practice), then a false certificate may have to be created and inserted before being able to revoke it. -- Erwann. From ynir@checkpoint.com Tue Oct 30 07:26:30 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B063521F851A for ; Tue, 30 Oct 2012 07:26:30 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hlte93abCqRL for ; Tue, 30 Oct 2012 07:26:30 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id C0F6321F8519 for ; Tue, 30 Oct 2012 07:26:29 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id q9UEQQ6J031330; Tue, 30 Oct 2012 16:26:26 +0200 X-CheckPoint: {508FE137-7-1B221DC2-2FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 30 Oct 2012 16:26:26 +0200 Received: from il-ex01.ad.checkpoint.com ([194.29.34.26]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Tue, 30 Oct 2012 16:26:26 +0200 From: Yoav Nir To: "Miller, Timothy J." Date: Tue, 30 Oct 2012 16:26:28 +0200 Thread-Topic: [pkix] Straw-poll on OCSP responses for non-revoked certificates. Thread-Index: Ac22qoq2ltprwpL0Qv6gjAZaCSvNnw== Message-ID: <819475F6-36E9-467E-8D3F-BB61CCA731F2@checkpoint.com> References: <71C9EC0544D1F64D8B7D91EDCC62202005EB6544@NABSREX027324.NAB.ORG> <195DB2510AAA004391F58E28FCE21200066E2071@IMCMBX01.MITRE.ORG> In-Reply-To: <195DB2510AAA004391F58E28FCE21200066E2071@IMCMBX01.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "pkix@ietf.org" Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked certificates. X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 14:26:30 -0000 On Oct 30, 2012, at 4:07 PM, Miller, Timothy J. wrote: >> 3) Neither. Add new optional response =3D unissued. >=20 > UNKNOWN would satisfy in this case, but that wasn't a poll option. :) >=20 > I disagree in re: lying. The OCSP responder can respond REVOKED and the = CA could add it to the CRL afterward, and a relying party wouldn't be able = to tell the difference. An OCSP query does not reveal the CDP, so the CA wouldn't know which CRL up= update. If it did work, that would be a good way to attack the CA - every request e= nds up as an entry in the CRL. How quickly can we get to gigabyte-sized CRL= s?= From prvs=0650d28ae5=rybar@nbusr.sk Tue Oct 30 08:40:15 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6BC621F85E1 for ; Tue, 30 Oct 2012 08:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.906 X-Spam-Level: * X-Spam-Status: No, score=1.906 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EqMDrjTpIQeN for ; Tue, 30 Oct 2012 08:40:15 -0700 (PDT) Received: from mail.nbusr.sk (mail.nbusr.sk [84.245.65.227]) by ietfa.amsl.com (Postfix) with ESMTP id 1D21121F85CD for ; Tue, 30 Oct 2012 08:40:14 -0700 (PDT) Message-Id: <201210301540.q9UFeCNT092240@mail.nbusr.sk> From: "Peter Rybar" To: "'Stefan Santesson'" , pkix@ietf.org Date: Tue, 30 Oct 2012 16:40:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: Thread-Index: Ac22joBvixJ6MwVlQVendyE+BLrQZgAIASAA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-NAI-Spam-Flag: NO X-NAI-Spam-Level: *** X-NAI-Spam-Threshold: 6 X-NAI-Spam-Score: 3.5 X-NAI-Spam-Version: 2.2.0.9309 : core <4387> : streams <848411> : uri <1255923> Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked certificates. X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 15:40:16 -0000 I vote for option 3, Neither (which is I hope "unknown"). Trusted services shall not cheat. Status "revoked" is untruth. RFC define: The "revoked" state indicates that the certificate has been = revoked (either permanantly or temporarily (on hold)). The status "good" shall be used with a positive statement extension like = hash of certificate otherwise we have unclear status. A client may do a request for a certificate that has "never" been issued = by the CA according to information in "old" OCSP database. This request may be done by 'extremely' quick request after issuing = certificate and for that reason OCSP database is not updated and = expectations like: deliberately, by mistake or as a consequence of a = compromised CA are in this case not correct.=20 Also deliberately created values of serialNumber which are expected that = will be included in new certificates issued at any time later can harm = validations services when "revoked" will be included in responses = because any cache or archive databases containing such untruth responses = of serialNumber marked as "revoked" with different thisUpdate values = than later issued and successively revoked real certificates with the = same serialNumber will cause unknown verification sates in many = applications. From ben@digicert.com Tue Oct 30 08:46:45 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 095DB21F85FC for ; Tue, 30 Oct 2012 08:46:45 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFPuWTNOmn16 for ; Tue, 30 Oct 2012 08:46:40 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id 96B2121F8600 for ; Tue, 30 Oct 2012 08:46:40 -0700 (PDT) Received: from BWILSONL1 (unknown [64.78.193.228]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id B9AB07FC157 for ; Tue, 30 Oct 2012 09:46:39 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1351611999; bh=Ncu08X+ZFNRznQKfc4QNhSAIhPTYWayONPb3irNRWZs=; h=Reply-To:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=rpoJwoQ3X2zOD8xuPSmgwXCnPiyO3ZXqOWt9MOeaVdWOb//h4BZFeKnZdfRZgdVzF sGNdbtaLWXpCj6hJDo/fYHs91RhKwAhg4tVrQ9SPDDj/4hO2fh8nMN/LKQ/0PGX0tU tcaxC+fkfbWK5c2fBuMknG5dgKC6kALsWt6qPAy8= From: "Ben Wilson" To: Date: Tue, 30 Oct 2012 09:46:36 -0600 Organization: DigiCert Message-ID: <006801cdb6b5$bee6b960$3cb42c20$@digicert.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0069_01CDB683.744FF2E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac22tb6nfvbR1X+OS0Spszkl0NJ6WA== Content-Language: en-us Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked certificates. X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ben@digicert.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 15:46:45 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0069_01CDB683.744FF2E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Not 2 because requiring a "good" response when a certificate has never been issued is equally equivocal to "revoked" - and we're only talking about OCSP - not CRLs. Definitely "1" because allowing a "revoked" response does no harm and in practice it provides the flexibility needed until a better solution is implemented and broadly made available. From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Art Allison Sent: Tuesday, October 30, 2012 8:00 AM To: pkix@ietf.org Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked certificates. 3) Neither. Add new optional response = unissued. The conflation of revoked and unissued that seems to be unresolvable by the current protocol says to me the current protocol is inadequate and a new response is needed. Responding revoked for an unissued cert is a lie. No RFC should ever attempt to make implmentors lie, as some will refuse to do so and lack of interoperablity across implementations results. And, relevant to implementation decisions; I am responsible for a contract with a vendor that has an OCSP function. Art Allison Senior Director Advanced Engineering, Science and Technology National Association of Broadcasters 1771 N Street NW Washington, DC 20036 Phone 202 429 5418 Fax 202 775 4981 www.nab.org *Advocacy Education Innovation* _____ From: pkix-bounces@ietf.org on behalf of Stefan Santesson Sent: Tue 10/30/2012 5:52 AM To: pkix@ietf.org Subject: [pkix] Straw-poll on OCSP responses for non-revoked certificates. Before we loose everyone engaged in this, I would like to make a straw-poll: Background: A client may do a request for a certificate that has never been issued by the CA. This request may be done deliberately, by mistake or as a consequence of a compromised CA. The OCSP protocol does not require OCSP responders to have any knowledge about issued certificates. It must only know about revoked certificates that are within it's current validity period. However, some OCSP responders closely coupled with the CA may also know if a certificate with a particular serialNumber value has been issued or not. The following is agreed: - An OCSP responder is allowed to respond "good" to a status request for a non-revoked certificate, disregarding if it has ever been issued. - A client, having no additional out-of-band knowledge about the OCSP responder, will just know that the certificate is "not revoked" when receiving a "good" response, unless the response includes one or more response extensions that provides additional information. The following is debated: - Is an OCSP responder allowed to respond "revoked" even if a requested certificate serial number is not on the list of revoked certificates, IF the OCSP responder has positive knowledge that the requested serial number does NOT represent a valid certificate issued by the identified CA? Rationale for: There are a number of reasons to allow this that has been mentioned, such as: - It breaks nothing. A legitimate request for an issued certificate will get a legitimate deterministic response. - It's safer. Responding "revoked" may not prevent a compromised CA from being exploited. But if a request for a serialNumber that is known to be bad is done nevertheless, a "revoked" response will at least be safer than responding "good". - Allowing extension definitions with further semantics. A response extension may be defined in the future that adds more information about the requested certificate. This may include a positive confirmation that the certificate has been issued as well as information that this particular OCSP responder will only respond "good" if it knows that the requested certificate has been issued, otherwise it will respond "revoked". An extension with such semantics can only be defined if the base standard allows a status other than "good" in such situation. - Supporting Web-PKI. The CAB-Forum has indicated that they will profile the OCSP protocol for use with web server authentication. In such profile they have indicated that they will NOT allow the "good" response unless the requested certificate is known to have been issued. This means that they will require OCSP responder in their infrastructure to have this knowledge. Such profile would have to break the base OCSP standard if this states that "good" MUST be returned unless the certificate has been revoked. Rationale against: The basic rationale against raised on this list has been the argument that it is wrong and confusing to allow anything but "good" as a response to a non-revoked certificate (if the cert is issued by a CA that is served by this OCSP responder). Another strong opinion is that it basically does not solve anything. A broken CA is broken and can't be fixed by responding "revoked". It would be easy to adapt an attack to circumvent such response, for example by issuing a fake certificate that duplicates a legitimate serialNumber. Please reply with either: 1. Allow "revoked" response for a certificate that has not been "revoked" but where that OCSP responder for any other reason knows the certificate to be "bad". 2. Require that the OCSP responder MUST respond "good" in this situation. 3. Neither 1 or 2 (motivate). Note: both alternatives are placed in a context where the certificate is claimed to be issued by a CA that is served by this OCSP responder. The exact meaning of "bad" is for later discussion. Please keep any motivation short and do not use this thread for long debates. _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix ------=_NextPart_000_0069_01CDB683.744FF2E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [pkix] Straw-poll on OCSP responses for = non-revoked certificates.

Not 2 because requiring a “good” response when a = certificate has never been issued is equally equivocal to = “revoked” – and we’re only talking about OCSP = – not CRLs.  Definitely “1” because allowing a = “revoked” response does no harm and in practice it provides = the flexibility needed until a better solution is implemented and = broadly made available.

 

From:= = pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of = Art Allison
Sent: Tuesday, October 30, 2012 8:00 = AM
To: pkix@ietf.org
Subject: Re: [pkix] Straw-poll = on OCSP responses for non-revoked = certificates.

 

3) Neither. Add = new optional response =3D unissued.

The conflation = of revoked and unissued that seems to be unresolvable by the = current protocol says to me the current protocol is inadequate and a new = response is needed.  

 

Responding revoked for an unissued cert is a = lie.  No RFC should ever attempt to make implmentors lie, as some = will refuse to do so and lack of interoperablity across = implementations results.  And, relevant to implementation = decisions; I am responsible for a contract with a vendor that has an = OCSP function.  

 

A= rt Allison

Senior = Director Advanced Engineering, Science and Technology

National = Association of Broadcasters
1771 N Street NW
Washington, DC = 20036
Phone  202 429 5418
Fax  202 775 4981
www.nab.org
*Advocacy  = Education  Innovation*

 

From:= = pkix-bounces@ietf.org on = behalf of Stefan Santesson
Sent: Tue 10/30/2012 5:52 = AM
To: pkix@ietf.org
Subject: = [pkix] Straw-poll on OCSP responses for non-revoked = certificates.

Before we loose everyone engaged in this, I = would like to make a
straw-poll:


Background:
A client = may do a request for a certificate that has never been issued by
the = CA.
This request may be done deliberately, by mistake or as a = consequence of a
compromised CA.

The OCSP protocol does not = require OCSP responders to have any knowledge
about issued = certificates. It must only know about revoked certificates
that are = within it's current validity period. However, some OCSP
responders = closely coupled with the CA may also know if a certificate with
a = particular serialNumber value has been issued or not.

The = following is agreed:
   - An OCSP responder is allowed to = respond "good" to a status request
for a non-revoked = certificate, disregarding if it has ever been = issued.

   - A client, having no additional out-of-band = knowledge about the OCSP
responder, will just know that the = certificate is "not revoked" when
receiving a = "good" response, unless the response includes one or = more
response extensions that provides additional = information.


The following is debated:
   - Is = an OCSP responder allowed to respond "revoked" even if a = requested
certificate serial number is not on the list of revoked = certificates, IF
the OCSP responder has positive knowledge that the = requested serial number
does NOT represent a valid certificate issued = by the identified CA?


Rationale for:
There are a number of = reasons to allow this that has been mentioned, such
as:
 - It = breaks nothing. A legitimate request for an issued certificate = will
get a legitimate deterministic response.
 - It's safer. = Responding "revoked" may not prevent a compromised CA = from
being exploited. But if a request for a serialNumber that is = known to be
bad is done nevertheless, a "revoked" response = will at least be safer than
responding "good".
 - = Allowing extension definitions with further semantics. A = response
extension may be defined in the future that adds more = information about
the requested certificate. This may include a = positive confirmation that
the certificate has been issued as well as = information that this
particular OCSP responder will only respond = "good" if it knows that the
requested certificate has been = issued, otherwise it will respond
"revoked". An extension = with such semantics can only be defined if the
base standard allows a = status other than "good" in such situation.
 - = Supporting Web-PKI. The CAB-Forum has indicated that they will = profile
the OCSP protocol for use with web server authentication. In = such profile
they have indicated that they will NOT allow the = "good" response unless
the requested certificate is known = to have been issued. This means that
they will require OCSP responder = in their infrastructure to have this
knowledge. Such profile would = have to break the base OCSP standard if this
states that = "good" MUST be returned unless the certificate has = been
revoked.

Rationale against:
The basic rationale = against raised on this list has been the argument that
it is wrong = and confusing to allow anything but "good" as a response to = a
non-revoked certificate (if the cert is issued by a CA that is = served by
this OCSP responder).
Another strong opinion is that it = basically does not solve anything. A
broken CA is broken and can't be = fixed by responding "revoked". It would
be easy to adapt an = attack to circumvent such response, for example by
issuing a fake = certificate that duplicates a legitimate serialNumber.


Please = reply with either:

1. Allow "revoked" response for a = certificate that has not been "revoked"
but where that OCSP = responder for any other reason knows the certificate
to be = "bad".

2. Require that the OCSP responder MUST respond = "good" in this situation.

3. Neither 1 or 2 = (motivate).




Note: both alternatives are placed in a = context where the certificate is
claimed to be issued by a CA that is = served by this OCSP responder. The
exact meaning of "bad" = is for later discussion.

Please keep any motivation short and do = not use this thread for = long
debates.






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

------=_NextPart_000_0069_01CDB683.744FF2E0-- From paul.hoffman@vpnc.org Tue Oct 30 08:47:48 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC90621F847C for ; Tue, 30 Oct 2012 08:47:48 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8L7s0hZ8PIa for ; Tue, 30 Oct 2012 08:47:48 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6E521F8451 for ; Tue, 30 Oct 2012 08:47:48 -0700 (PDT) Received: from [10.20.30.101] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q9UFleLB094598 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 30 Oct 2012 08:47:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: Date: Tue, 30 Oct 2012 08:47:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <28E66A6B-7CE5-472C-81A9-A8403264C3ED@vpnc.org> References: To: Stefan Santesson X-Mailer: Apple Mail (2.1499) Cc: pkix@ietf.org Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked certificates. X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 15:47:48 -0000 > 1. Allow "revoked" response for a certificate that has not been = "revoked" > but where that OCSP responder for any other reason knows the = certificate > to be "bad". 1 seems fine *as long as* the document defining this change explicitly = says "the term 'revoked' now means 'revoked or never issued'". That is, = "revoked" cannot just magically mean "bad" or "not good", it needs to = have a specific defined meaning. I have no problem with the use of the = English word "revoked" in the protocol having a real-world meaning = beyond "revoked". --Paul Hoffman= From jgcardoso@seguridata.com Tue Oct 30 08:51:51 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0475221F8451 for ; Tue, 30 Oct 2012 08:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.376 X-Spam-Level: X-Spam-Status: No, score=-0.376 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5SzdmQHhSL0E for ; Tue, 30 Oct 2012 08:51:47 -0700 (PDT) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id D14A121F84DA for ; Tue, 30 Oct 2012 08:51:47 -0700 (PDT) Received: by mail-da0-f44.google.com with SMTP id h15so175821dan.31 for ; Tue, 30 Oct 2012 08:51:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=sVYp6yADbsvNNDv7JPce5vP4mr/f75q+TZLFQI8MqDw=; b=MPuydbQIuk20iv3K1Lw1xFcHrW0TCg3cQt5iBrY9PCKYuo3PlEwBNrqf6Q6QqyXLWu e6ck8t7vLY4ecl6yxUVnwTo2cfapeq4768LX2CaSmQpphNfB7vixkNgUnJnpVEcbsW0l HhQylHbLoqvCmKIhju1DbEzzxShYLWNQi1Oi6k2kmzKE2BCktWdRvwp7/R0p4clYtFJT YR+o7+b/1OeA33dphfAhzogDdZPBp3XkD+Xng9rtcyabKRVoI5Iba05wGzG5RURlT81w N75Gp6kc2IILJFttfrVkTIRVWbnUFrTgzTIaXk4v5mUeXqP4HkArqChlmQ7xQ4WRKe2U vuWw== Received: by 10.66.77.40 with SMTP id p8mr93482358paw.78.1351612307225; Tue, 30 Oct 2012 08:51:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.148.233 with HTTP; Tue, 30 Oct 2012 08:51:27 -0700 (PDT) In-Reply-To: References: <20121029232328.BF5D91A309@ld9781.wdf.sap.corp> From: Juan Gonzalez Date: Tue, 30 Oct 2012 09:51:27 -0600 Message-ID: To: Stefan Santesson Content-Type: multipart/alternative; boundary=f46d042dfdd7723d5d04cd48c358 X-Gm-Message-State: ALoCoQnHOYTVNPwi+yJKt3h9sbxHKDEVyMfDWdqZ6EhQLm8Sv9sMaMF5vGXHOPs3PdcIG9mXG+d3 Cc: pkix@ietf.org Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked certificates. X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 15:51:51 -0000 --f46d042dfdd7723d5d04cd48c358 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Option 3) Neither 1 or 2 I agree about responding Unknown. On Tue, Oct 30, 2012 at 3:52 AM, Stefan Santesson wrote= : > Before we loose everyone engaged in this, I would like to make a > straw-poll: > > > Background: > A client may do a request for a certificate that has never been issued by > the CA. > This request may be done deliberately, by mistake or as a consequence of = a > compromised CA. > > The OCSP protocol does not require OCSP responders to have any knowledge > about issued certificates. It must only know about revoked certificates > that are within it's current validity period. However, some OCSP > responders closely coupled with the CA may also know if a certificate wit= h > a particular serialNumber value has been issued or not. > > The following is agreed: > - An OCSP responder is allowed to respond "good" to a status request > for a non-revoked certificate, disregarding if it has ever been issued. > > - A client, having no additional out-of-band knowledge about the OCSP > responder, will just know that the certificate is "not revoked" when > receiving a "good" response, unless the response includes one or more > response extensions that provides additional information. > > > The following is debated: > - Is an OCSP responder allowed to respond "revoked" even if a requeste= d > certificate serial number is not on the list of revoked certificates, IF > the OCSP responder has positive knowledge that the requested serial numbe= r > does NOT represent a valid certificate issued by the identified CA? > > > Rationale for: > There are a number of reasons to allow this that has been mentioned, such > as: > - It breaks nothing. A legitimate request for an issued certificate will > get a legitimate deterministic response. > - It's safer. Responding "revoked" may not prevent a compromised CA from > being exploited. But if a request for a serialNumber that is known to be > bad is done nevertheless, a "revoked" response will at least be safer tha= n > responding "good". > - Allowing extension definitions with further semantics. A response > extension may be defined in the future that adds more information about > the requested certificate. This may include a positive confirmation that > the certificate has been issued as well as information that this > particular OCSP responder will only respond "good" if it knows that the > requested certificate has been issued, otherwise it will respond > "revoked". An extension with such semantics can only be defined if the > base standard allows a status other than "good" in such situation. > - Supporting Web-PKI. The CAB-Forum has indicated that they will profile > the OCSP protocol for use with web server authentication. In such profile > they have indicated that they will NOT allow the "good" response unless > the requested certificate is known to have been issued. This means that > they will require OCSP responder in their infrastructure to have this > knowledge. Such profile would have to break the base OCSP standard if thi= s > states that "good" MUST be returned unless the certificate has been > revoked. > > Rationale against: > The basic rationale against raised on this list has been the argument tha= t > it is wrong and confusing to allow anything but "good" as a response to a > non-revoked certificate (if the cert is issued by a CA that is served by > this OCSP responder). > Another strong opinion is that it basically does not solve anything. A > broken CA is broken and can't be fixed by responding "revoked". It would > be easy to adapt an attack to circumvent such response, for example by > issuing a fake certificate that duplicates a legitimate serialNumber. > > > Please reply with either: > > 1. Allow "revoked" response for a certificate that has not been "revoked" > but where that OCSP responder for any other reason knows the certificate > to be "bad". > > 2. Require that the OCSP responder MUST respond "good" in this situation. > > 3. Neither 1 or 2 (motivate). > > > > > Note: both alternatives are placed in a context where the certificate is > claimed to be issued by a CA that is served by this OCSP responder. The > exact meaning of "bad" is for later discussion. > > Please keep any motivation short and do not use this thread for long > debates. > > > > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > --=20 *AVISO DE PRIVACIDAD* Los datos personales que usted nos proporcione est=E1n sujetos a los t=E9rm= inos de la Ley Federal de Protecci=F3n de Datos Personales en Posesi=F3n de los Particulares (LFPDPPP). Para mayor informaci=F3n acerca del tratamiento y d= e los derechos que puede hacer valer, usted puede acceder al Aviso de Privacidad completo a trav=E9s de la p=E1gina www.seguridata.com/privacidad= .htm. Es importante que lo lea previamente a cualquier env=EDo de informaci=F3n s= obre datos personales. SeguriData Privada S.A. de C.V., tiene su domicilio en Insurgentes Sur, 2375 tercer piso, Colonia Tizap=E1n, C.P. 01000, Delegaci= =F3n =C1lvaro Obreg=F3n, en M=E9xico, D.F., y utilizar=E1 sus datos personales =FAnicamente para la finalidad para la que sean obtenidos. --f46d042dfdd7723d5d04cd48c358 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Option 3) Neither 1 or 2

I agree about responding Unknow= n.=A0

On Tue, Oct 30, 2012 at 3:52 AM, St= efan Santesson <stefan@aaa-sec.com> wrote:
Before we loose everyone engaged in this, I = would like to make a
straw-poll:


Background:
A client may do a request for a certificate that has never been issued by the CA.
This request may be done deliberately, by mistake or as a consequence of a<= br> compromised CA.

The OCSP protocol does not require OCSP responders to have any knowledge about issued certificates. It must only know about revoked certificates
that are within it's current validity period. However, some OCSP
responders closely coupled with the CA may also know if a certificate with<= br> a particular serialNumber value has been issued or not.

The following is agreed:
=A0 =A0- An OCSP responder is allowed to respond "good" to a stat= us request
for a non-revoked certificate, disregarding if it has ever been issued.

=A0 =A0- A client, having no additional out-of-band knowledge about the OCS= P
responder, will just know that the certificate is "not revoked" w= hen
receiving a "good" response, unless the response includes one or = more
response extensions that provides additional information.


The following is debated:
=A0 =A0- Is an OCSP responder allowed to respond "revoked" even i= f a requested
certificate serial number is not on the list of revoked certificates, IF the OCSP responder has positive knowledge that the requested serial number<= br> does NOT represent a valid certificate issued by the identified CA?


Rationale for:
There are a number of reasons to allow this that has been mentioned, such as:
=A0- It breaks nothing. A legitimate request for an issued certificate will=
get a legitimate deterministic response.
=A0- It's safer. Responding "revoked" may not prevent a compr= omised CA from
being exploited. But if a request for a serialNumber that is known to be bad is done nevertheless, a "revoked" response will at least be s= afer than
responding "good".
=A0- Allowing extension definitions with further semantics. A response
extension may be defined in the future that adds more information about
the requested certificate. This may include a positive confirmation that the certificate has been issued as well as information that this
particular OCSP responder will only respond "good" if it knows th= at the
requested certificate has been issued, otherwise it will respond
"revoked". An extension with such semantics can only be defined i= f the
base standard allows a status other than "good" in such situation= .
=A0- Supporting Web-PKI. The CAB-Forum has indicated that they will profile=
the OCSP protocol for use with web server authentication. In such profile they have indicated that they will NOT allow the "good" response = unless
the requested certificate is known to have been issued. This means that
they will require OCSP responder in their infrastructure to have this
knowledge. Such profile would have to break the base OCSP standard if this<= br> states that "good" MUST be returned unless the certificate has be= en
revoked.

Rationale against:
The basic rationale against raised on this list has been the argument that<= br> it is wrong and confusing to allow anything but "good" as a respo= nse to a
non-revoked certificate (if the cert is issued by a CA that is served by this OCSP responder).
Another strong opinion is that it basically does not solve anything. A
broken CA is broken and can't be fixed by responding "revoked"= ;. It would
be easy to adapt an attack to circumvent such response, for example by
issuing a fake certificate that duplicates a legitimate serialNumber.


Please reply with either:

1. Allow "revoked" response for a certificate that has not been &= quot;revoked"
but where that OCSP responder for any other reason knows the certificate to be "bad".

2. Require that the OCSP responder MUST respond "good" in this si= tuation.

3. Neither 1 or 2 (motivate).




Note: both alternatives are placed in a context where the certificate is claimed to be issued by a CA that is served by this OCSP responder. The
exact meaning of "bad" is for later discussion.

Please keep any motivation short and do not use this thread for long
debates.






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



--

AVI= SO DE PRIVACIDAD
Los datos personales q= ue usted nos proporcione est=E1n sujetos a los t=E9rminos de la Ley Federal= de Protecci=F3n de Datos Personales en Posesi=F3n de los Particulares (LFP= DPPP). Para mayor informaci=F3n acerca del tratamiento y de los derechos qu= e puede hacer valer, usted puede acceder al Aviso de Privacidad completo a = trav=E9s de la p=E1gina www.seguridata.com/privacidad.htm. E= s importante que lo lea previamente a cualquier env=EDo de informaci=F3n so= bre datos personales. SeguriData Privada S.A. de C.V.,=A0 tiene su domicili= o en Insurgentes Sur, 2375 tercer piso, Colonia Tizap=E1n, C.P. 01000, Dele= gaci=F3n =C1lvaro Obreg=F3n, en M=E9xico, D.F.,=A0 y utilizar=E1 sus datos = personales =FAnicamente para la finalidad para la que sean obtenidos.

--f46d042dfdd7723d5d04cd48c358-- From pritikin@cisco.com Tue Oct 30 08:59:54 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 820DA21F85C1 for ; Tue, 30 Oct 2012 08:59:54 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEqpaoAmLnpE for ; Tue, 30 Oct 2012 08:59:53 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 7129E21F85A0 for ; Tue, 30 Oct 2012 08:59:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4914; q=dns/txt; s=iport; t=1351612793; x=1352822393; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=dOLdQf5vBkMiAThP5fS6ncTUonavt50h1M8OxP1gLuw=; b=BLeBytDGlmW7zZXQ0m3rkVOxVHYianhEHjCY/PKhFc4KPZvjNBL3CsXT QHG76ZzVRHKrwNGnbQjFox2qN4DINO5FbKdgIM/gbA85Lo2toRwu1pPi8 sbxCcYvuWMETidkcSox/tBrbQcqTZWRQs4JLF64mIWThD3tiqsOlsrPJU o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPH3j1CtJXG8/2dsb2JhbABEw0iBCIIeAQEBAwEBAQEPASc0CwULAgEIIhQQJwslAgQOBQgah14GC50Fj2eQOgSLd4V8YQOkTIFrgm+BWwYaAhw X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="136940557" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 30 Oct 2012 15:59:52 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9UFxq2t030104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Oct 2012 15:59:52 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.215]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.001; Tue, 30 Oct 2012 10:59:52 -0500 From: "Max Pritikin (pritikin)" To: Stefan Santesson Thread-Topic: [pkix] Straw-poll on OCSP responses for non-revoked certificates. Thread-Index: AQHNto57TRZ+yDCKBkSubPlV/ldcXZfSVemA Date: Tue, 30 Oct 2012 15:59:51 +0000 Message-ID: <53EA47528D6ACF4486AA152F92C2B6982A5F9E@xmb-rcd-x03.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.0.199] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19320.004 x-tm-as-result: No--42.702600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked certificates. X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 15:59:54 -0000 #1=20 The system should fail closed. I agree with Paul Hoffman's point that this = extends the definition of the 'revoked' response during this protocol excha= nge which must be noted. I'd also accept a new "unknown, fail closed" type = response so long as clients that don't yet understand this new response fai= l closed. - max On Oct 30, 2012, at 3:52 AM, Stefan Santesson wrote: > Before we loose everyone engaged in this, I would like to make a > straw-poll: >=20 >=20 > Background: > A client may do a request for a certificate that has never been issued by > the CA. > This request may be done deliberately, by mistake or as a consequence of = a > compromised CA. >=20 > The OCSP protocol does not require OCSP responders to have any knowledge > about issued certificates. It must only know about revoked certificates > that are within it's current validity period. However, some OCSP > responders closely coupled with the CA may also know if a certificate wit= h > a particular serialNumber value has been issued or not. >=20 > The following is agreed: > - An OCSP responder is allowed to respond "good" to a status request > for a non-revoked certificate, disregarding if it has ever been issued. >=20 > - A client, having no additional out-of-band knowledge about the OCSP > responder, will just know that the certificate is "not revoked" when > receiving a "good" response, unless the response includes one or more > response extensions that provides additional information. >=20 >=20 > The following is debated: > - Is an OCSP responder allowed to respond "revoked" even if a requested > certificate serial number is not on the list of revoked certificates, IF > the OCSP responder has positive knowledge that the requested serial numbe= r > does NOT represent a valid certificate issued by the identified CA? >=20 >=20 > Rationale for: > There are a number of reasons to allow this that has been mentioned, such > as: > - It breaks nothing. A legitimate request for an issued certificate will > get a legitimate deterministic response. > - It's safer. Responding "revoked" may not prevent a compromised CA from > being exploited. But if a request for a serialNumber that is known to be > bad is done nevertheless, a "revoked" response will at least be safer tha= n > responding "good". > - Allowing extension definitions with further semantics. A response > extension may be defined in the future that adds more information about > the requested certificate. This may include a positive confirmation that > the certificate has been issued as well as information that this > particular OCSP responder will only respond "good" if it knows that the > requested certificate has been issued, otherwise it will respond > "revoked". An extension with such semantics can only be defined if the > base standard allows a status other than "good" in such situation. > - Supporting Web-PKI. The CAB-Forum has indicated that they will profile > the OCSP protocol for use with web server authentication. In such profile > they have indicated that they will NOT allow the "good" response unless > the requested certificate is known to have been issued. This means that > they will require OCSP responder in their infrastructure to have this > knowledge. Such profile would have to break the base OCSP standard if thi= s > states that "good" MUST be returned unless the certificate has been > revoked. >=20 > Rationale against: > The basic rationale against raised on this list has been the argument tha= t > it is wrong and confusing to allow anything but "good" as a response to a > non-revoked certificate (if the cert is issued by a CA that is served by > this OCSP responder). > Another strong opinion is that it basically does not solve anything. A > broken CA is broken and can't be fixed by responding "revoked". It would > be easy to adapt an attack to circumvent such response, for example by > issuing a fake certificate that duplicates a legitimate serialNumber. >=20 >=20 > Please reply with either: >=20 > 1. Allow "revoked" response for a certificate that has not been "revoked" > but where that OCSP responder for any other reason knows the certificate > to be "bad". >=20 > 2. Require that the OCSP responder MUST respond "good" in this situation. >=20 > 3. Neither 1 or 2 (motivate). >=20 >=20 >=20 >=20 > Note: both alternatives are placed in a context where the certificate is > claimed to be issued by a CA that is served by this OCSP responder. The > exact meaning of "bad" is for later discussion. >=20 > Please keep any motivation short and do not use this thread for long > debates. >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From simon@tardell.se Tue Oct 30 09:02:02 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7521621F85FD for ; Tue, 30 Oct 2012 09:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drLafeEi38JH for ; Tue, 30 Oct 2012 09:02:02 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8D16121F85A0 for ; Tue, 30 Oct 2012 09:02:01 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so385144lbo.31 for ; Tue, 30 Oct 2012 09:02:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=5Y10VtEKP8uaZCtQy66Xz6BjpTvHg23qa5J6nAUBfUs=; b=kGVTXRo5xQdHaL1VEhLpdoYdBMCnkwMWyQd/q7IaCR0D3gXUiaf6YZgMCxhXx71ax6 lD7GJKfzBcnYoQLCKj6Kqlg7CHNWIRNDbkfh3tUvWXHtmotUv51A+s3EHr2GJ+dZm8h6 gBBg5WuJxzSk2NAZMcxHxNsJ4seV8jZQ/IGbsIoqHNJFWn9KzjE6xWjkzCjwo+63mr3m 5Q2MBhnZbMRHny9sJYdy68ozNLMYBs0/++dBuobSCU250pDLyA09DE3UbkUzj/i/5K4H Tp2yLgY39NlZClTENYBimjs34zTMCapABphvZYeTO5msqqnUyVy+tlZyZzii9AXUTRWt 5RKw== MIME-Version: 1.0 Received: by 10.112.102.196 with SMTP id fq4mr13269586lbb.125.1351612920294; Tue, 30 Oct 2012 09:02:00 -0700 (PDT) Received: by 10.112.134.102 with HTTP; Tue, 30 Oct 2012 09:02:00 -0700 (PDT) In-Reply-To: References: <20121029232328.BF5D91A309@ld9781.wdf.sap.corp> Date: Tue, 30 Oct 2012 17:02:00 +0100 Message-ID: From: Simon Tardell To: Stefan Santesson Content-Type: multipart/alternative; boundary=f46d04016ae5fcebff04cd48e78b X-Gm-Message-State: ALoCoQmgizIiEhEm/aCa+jepH3GYTU4zw6tY12TPDKMWsN7dDgGy5Gy9tF8WzBHFb5DX4w2/m0qo Cc: pkix@ietf.org Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked certificates. X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 16:02:02 -0000 --f46d04016ae5fcebff04cd48e78b Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 30, 2012 at 10:52 AM, Stefan Santesson wrote: > > Please reply with either: > > 1. Allow "revoked" response for a certificate that has not been "revoked" > but where that OCSP responder for any other reason knows the certificate > to be "bad". > > 2. Require that the OCSP responder MUST respond "good" in this situation. > > 3. Neither 1 or 2 (motivate). > > 1. I see some people saying 3/ "unknown", because "revoked" would be lying. Well, "unknown" be lying so much more, if you let it be an assertion that the certificate has never been issued. Furthermore it would open security holes by prompting some client implementations to fall back to CRLs or try later. /Simon --f46d04016ae5fcebff04cd48e78b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

They could not use this extension to include a cert hash as t= hey can't know if a particular serial number of an expired cert is asked for= .

Thus it may be wise to separate these issues and = keep it simple and just use an OID to indicate this particular behaviour wit= h regard to "revoked" response.
It may be wise therefore to allow = a separate process come up with a separate extension for positive confirmati= ons.
Not that I don't like such functionality.

The alternative is to extend this process long enough that we feel sur= e we got it right.

/Stefan


From: Tom Ritter <tom@ritter.vg>
Date: Wednesday, October 31, 2012 8:32 PM
To: Stefan Santesson <stefan@aaa-sec.com>
Cc: = IETF PKIX <pkix@ietf.org>
Subject: Re: [pkix] Proposed resolution to= non-issued certificates - 2560bis

Question:
Would it make sense to req= uire an OCSP responder that adopts the expanded
use of "revoked" to alway= s include the new extension?
It would add the benefit that someone receiv= ing "good" can know that the
OCSP responder has checked that the certific= ate in fact has been issued by
the CA.
In such cas= e it may be reasonable to add an optional data structure which
MAY contai= n a hash of the cert.
Such hash would make the positive confirmation even= stronger, adding proof
of existence of the certificate.
=
I'll register my vote for all these items also - I like the idea of prov= iding transparency into the operations of the responders.

 --B_3434567118_33060750-- From david.cooper@nist.gov Wed Oct 31 15:23:28 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 416BC21F868A for ; Wed, 31 Oct 2012 15:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.141 X-Spam-Level: X-Spam-Status: No, score=-5.141 tagged_above=-999 required=5 tests=[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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NcwQrfJ+eMVn for ; Wed, 31 Oct 2012 15:23:27 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE0321F867D for ; Wed, 31 Oct 2012 15:23:27 -0700 (PDT) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.421.2; Wed, 31 Oct 2012 18:22:46 -0400 Received: from smtp.nist.gov (129.6.16.226) by smtp-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.1.421.2; Wed, 31 Oct 2012 18:22:28 -0400 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 q9VMN2CW028766; Wed, 31 Oct 2012 18:23:02 -0400 Message-ID: <5091A4C5.9090609@nist.gov> Date: Wed, 31 Oct 2012 18:23:01 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120829 Thunderbird/15.0 MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: IETF PKIX Subject: Re: [pkix] Proposed resolution to non-issued certificates - 2560bis X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 22:23:28 -0000
Stefan,

Up until now, you have been discussing extending the revoked response as indicated in your current draft of 2560bis:

   The "revoked" state indicates that the certificate has been revoked
   (either permanently or temporarily (on hold)). This state SHOULD also
   be returned if the responder knows that the requested certificate has
   never been issued.

Does your message below mean that you now intend to extend the meaning of "revoked" even further to include certificates that were issued by CA and that were never revoked, but that are now expired?  As I explained before (http://www.ietf.org/mail-archive/web/pkix/current/msg31863.html), I believe that would be a non-backward compatible change.

Dave

On 10/31/2012 05:25 PM, Stefan Santesson wrote:
Here is my own concerns with inclusion of an optional cert hash in the extension.

There might be OCSP responders that do have access to a database of issued certs that are currently valid, but not the history of issued certs (expired).
They could not use this extension to include a cert hash as they can't know if a particular serial number of an expired cert is asked for.

Thus it may be wise to separate these issues and keep it simple and just use an OID to indicate this particular behaviour with regard to "revoked" response.
It may be wise therefore to allow a separate process come up with a separate extension for positive confirmations.
Not that I don't like such functionality.

The alternative is to extend this process long enough that we feel sure we got it right.

/Stefan


From: Tom Ritter <tom@ritter.vg>
Date: Wednesday, October 31, 2012 8:32 PM
To: Stefan Santesson <stefan@aaa-sec.com>
Cc: IETF PKIX <pkix@ietf.org>
Subject: Re: [pkix] Proposed resolution to non-issued certificates - 2560bis

Question:
Would it make sense to require an OCSP responder that adopts the expanded
use of "revoked" to always include the new extension?
It would add the benefit that someone receiving "good" can know that the
OCSP responder has checked that the certificate in fact has been issued by
the CA.
In such case it may be reasonable to add an optional data structure which
MAY contain a hash of the cert.
Such hash would make the positive confirmation even stronger, adding proof
of existence of the certificate.

I'll register my vote for all these items also - I like the idea of providing transparency into the operations of the responders.

From stefan@aaa-sec.com Wed Oct 31 15:35:05 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1305721F8869 for ; Wed, 31 Oct 2012 15:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.008 X-Spam-Level: X-Spam-Status: No, score=-101.008 tagged_above=-999 required=5 tests=[AWL=-0.156, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzaVuUf13r6b for ; Wed, 31 Oct 2012 15:35:04 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 6F51521F887D for ; Wed, 31 Oct 2012 15:35:03 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 208D32F487 for ; Wed, 31 Oct 2012 23:35:03 +0100 (CET) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ECm2hgCBWE4T for ; Wed, 31 Oct 2012 23:35:02 +0100 (CET) Received: from s376.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id DC3E22F485 for ; Wed, 31 Oct 2012 23:35:02 +0100 (CET) Received: (qmail 3194 invoked from network); 31 Oct 2012 22:35:02 -0000 Received: from 81-232-51-61-no39.business.telia.com (HELO [192.168.0.113]) (stefan@fiddler.nu@[81.232.51.61]) (envelope-sender ) by s376.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 31 Oct 2012 22:35:02 -0000 User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Wed, 31 Oct 2012 23:35:22 +0100 From: Stefan Santesson To: "David A. Cooper" Message-ID: Thread-Topic: [pkix] Proposed resolution to non-issued certificates - 2560bis In-Reply-To: <5091A4C5.9090609@nist.gov> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3434571325_33259756" Cc: IETF PKIX Subject: Re: [pkix] Proposed resolution to non-issued certificates - 2560bis X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 22:35:05 -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_3434571325_33259756 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit > Does your message below mean that you now intend to extend the meaning of > "revoked" even further to include certificates that were issued by CA and that > were never revoked, but that are now expired? No You got me wrong. Not issued = never issued. /Stefan --B_3434571325_33259756 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable

Does your mess= age below mean that you now intend to extend the meaning of "revoked" even f= urther to include certificates that were issued by CA and that were never re= voked, but that are now expired? 

No

You got me wrong.

<= div>Not issued =3D never issued.

/Stefan
= --B_3434571325_33259756-- From piyush@ditenity.com Wed Oct 31 16:13:00 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B378721F861F for ; Wed, 31 Oct 2012 16:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbibqXw8Ij3Y for ; Wed, 31 Oct 2012 16:13:00 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id E436721F8611 for ; Wed, 31 Oct 2012 16:12:59 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id x24so1682867iak.31 for ; Wed, 31 Oct 2012 16:12:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language:x-gm-message-state; bh=rfHdWirGrngo5UhqoSsyI4bBpckKi+4q9laibnAEhUA=; b=XhEVealzP5mLbYe4NgWPO1gO0tx49VWPMuU4wiW4nO8FQbQuU+2U1vECBlYDZQPlZE iV9jyAeZ39YXkAoNMahBgvC0EARtclmM88ZW8cMXSRoXLUcSejiQyxzmUuyCt//2EcA9 shq7rAoBLipU1tYr9Y9KQUuXfJsRsiCwDIw14Moydm+vHX3j3h03x8ruJcX1f/fDFKHO +WjbvpYwzRUDTpY9xsN6odT/kK1ItLWwuoVjFrTMPpbgIbFOaa/QHCbuSJvccyUDuc6s fN7hYGMHNDIE8vbrWgHWBlN6EsetKRDOAtxAn1b/dW0aI9VU6kftRgCOhGV8EUT9xgyf E+hA== Received: by 10.42.101.11 with SMTP id c11mr33201418ico.52.1351725179525; Wed, 31 Oct 2012 16:12:59 -0700 (PDT) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id xn10sm11626767igb.4.2012.10.31.16.12.57 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 31 Oct 2012 16:12:58 -0700 (PDT) From: "Piyush Jain" To: "'Stefan Santesson'" , References: In-Reply-To: Date: Wed, 31 Oct 2012 16:12:55 -0700 Message-ID: <01fc01cdb7bd$43c183b0$cb448b10$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-index: AQK/8f5r6+nRDUkghdB6fIx4xGer1ZXvi2Hw Content-Language: en-us X-Gm-Message-State: ALoCoQlpyMuILlS9wgjLZ65GBiR1i79Pm420waGbTDGQFO8MLAI8fWhftPfh2CUR2qQUiTkp23MA Subject: Re: [pkix] Proposed resolution to non-issued certificates - 2560bis X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 23:13:00 -0000 > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > Stefan Santesson > Sent: Wednesday, October 31, 2012 11:47 AM > To: pkix@ietf.org > Subject: [pkix] Proposed resolution to non-issued certificates - 2560bis > > I didn't put up an end date for the straw-poll, but the trend seems clear. > > The results so far (if I counted right) > > Supporting #1: 22 > Supporting #2: 0 > Supporting #3 using "unknown": 6 > Supporting #3 using "unauthorised: 2 > > 6 persons supporting #1 has expressed various levels of support/demand for > an explicit declaration that the OCSP responder supports the enhanced > definition of "revoked" to include "no issued". > > 1 person responded off-line supporting #1. > > > If the trend reflects the opinion of the WG. This is my proposed > resolution: > > > 1) Extend the "revoked" response to also be allowed for non-issued > certificates. Clearly stating that this is optional if and only if the OCSP > responder knows that the requested serial number has never been issued. [Piyush] This requires changing the current text for 'good'. Pasted for your reference The "good" state indicates a positive response to the status inquiry. At a minimum, this positive response indicates that the certificate is not revoked, but does not necessarily mean that the certificate was ever issued or that the time at which the response was produced is within the certificate's validity interval. Response extensions may be used to convey additional information on assertions made by the responder regarding the status of the certificate such as positive statement about issuance, validity, etc. > 2) Specify that a "revoked" status for a non-issued certificate serial number > MUST have revocationTime set to Jan 1, 1970 and MUST set the > revocationReason to certificateHold (6). [Piyush] There were some objections on using certificateHold as revocationReason for this purpose. CA compromise would be more appropriate because the only scenario where this is beneficial is when the CA is compromised. > 2) Define a new optional non-critical extension declaring that OCSP > responder returns "revoked" for non-issued certificates according to the > updated standard. This extension MUST be present in all responses where > the "revoked" response is returned as a result of a status request for a non- > issued certificate. [Piyush] Are you proposing that the specification of this extension would be part of OCSP or it would be published as a separate specification? I think that it should not be part of main OCSP specification, given that it is useful only in the exceptional scenario where CA gets compromised. > > > Rationale: > The certificateHold reason feels important for one particular reason. If a CA is > issuing certificates with sequential serial numbers, then it could be possible > to obtain a revoked response for a certificate serial number that is not yet > issued, but soon will be issued. That the certificate serial number is currently > not issued, does not mean that it never will, thus the certificateHold reason > seems more appropriate. > [Piyush] Given that a fraudulent certificate has been issued with a serial number, the CA would eventually revoke the certificate with this serial number and would not issue any newer certificate with the same serial. I think the confusion arises from the fact that we've been using 'not-issued' and 'fraudulently-issued' interchangeably. All this time I'd been thinking that we are discussing the latter. If that is indeed the case, caCompromise seems more appropriate. > The date 1 Jan, 1970 is appropriate since it is common in programming > languages to express time as milliseconds since jan 1, 1970. Selecting this > time avoids time expression as a negative integer. > > This date translates to (java): > Date revocationTime = new Date(0); //Jan 1st, 1970 > > The extension would be a simple OID with no data structure and MUST not > be set to critical. > > > Question: > Would it make sense to require an OCSP responder that adopts the > expanded use of "revoked" to always include the new extension? > It would add the benefit that someone receiving "good" can know that the > OCSP responder has checked that the certificate in fact has been issued by > the CA. > In such case it may be reasonable to add an optional data structure which > MAY contain a hash of the cert. > Such hash would make the positive confirmation even stronger, adding proof > of existence of the certificate. [Piyush] I hope that you realize that big enterprise PKI deployments use OCSP and CRLs interchangeably. And with this proposal OCSP becomes more authoritative than CRL. So I guess the next step would be to change the basic path validation algorithm to drop the use of CRLs in favor of OCSP and also drop the signature verification (off course if the RP knows that his OCSP responder issues stronger positive confirmations). > > But perhaps this will bee too much to agree on :) > [Piyush] How about a thinner profile of SCVP that could address everything you are trying to achieve in OCSP. > /Stefan > > > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From pgut001@cs.auckland.ac.nz Wed Oct 31 17:01:02 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A015E21F849A for ; Wed, 31 Oct 2012 17:01:02 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8j7k05lQkCt for ; Wed, 31 Oct 2012 17:01:01 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9A35921F88ED for ; Wed, 31 Oct 2012 17:01:00 -0700 (PDT) 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=1351728060; x=1383264060; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=OXuJavqK/dE7ei6vIHkX18pb1aW1kfuoV0qA8DMq0F8=; b=MIoOBGQFcFxNbXGkap1YVikQXFnra6dFkPcKVsefxUPSswqs1dF0XS7m ZEY9aQpO1+LJPCFcRgfMiI0rrPU3gV5Qux3y4wKkNj4zQD4nqV8M3oYTO 4XEILayzXY4wxsrpjxxsWJ7ZC2V4gJsvOUNDq4Ek9hRR2BEOtZEddW0mD M=; X-IronPort-AV: E=Sophos;i="4.80,690,1344168000"; d="scan'208";a="154299106" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 01 Nov 2012 13:00:58 +1300 Received: from UXCN10-1.UoA.auckland.ac.nz ([169.254.1.112]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.02.0318.001; Thu, 1 Nov 2012 13:00:58 +1300 From: Peter Gutmann To: "pkix@ietf.org" , "mrex@sap.com" Thread-Topic: [pkix] New draft-ietf-pkix-rfc2560bis-06 Thread-Index: Ac23w/iv+qefafmWQQGys0qHD+JItw== Date: Thu, 1 Nov 2012 00:00:58 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C732BED457C@uxcn10-1.UoA.auckland.ac.nz> Accept-Language: en-GB, en-NZ, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.11.250] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 00:01:02 -0000 Martin Rex writes:=0A= =0A= >I don't think silver bullets exist (I wrote that previously), but one can= =0A= >hardly do worse that rfc2560 for online status checking of certs. OCSP wa= s=0A= >artificially limited to "as bad as CRL checking."=0A= =0A= Could I just sort of mention in passing here that while people are voting o= n=0A= what colour to make the lipstick there's already a protocol that solves pre= tty=0A= much all of OCSP's long list of problems that was proposed as a replacement= =0A= for OCSP more than a decade ago (and has been in active use in all that tim= e):=0A= =0A= http://tools.ietf.org/html/draft-gutmann-cms-rtcs-01=0A= =0A= It'd be pretty easy to turn this into an RFC, it just needs to be published= ...=0A= =0A= Peter.=0A=
On Tue, Oct 30, 2012 at 10:52 AM, Stefan= Santesson <stefan@aaa-sec.com> wrote:

Please reply with either:

1. Allow "revoked" response for a certificate that has not been &= quot;revoked"
but where that OCSP responder for any other reason knows the certificate to be "bad".

2. Require that the OCSP responder MUST respond "good" in this si= tuation.

3. Neither 1 or 2 (motivate).


1.

I see some people saying 3/ "unknown", bec= ause "revoked" would be lying. Well, "unknown" be lying= so much more, if you let it be an assertion that the certificate has never= been issued. Furthermore it would open security holes by prompting some cl= ient implementations to fall back to CRLs or try later.

/Simon
--f46d04016ae5fcebff04cd48e78b-- From carl@redhoundsoftware.com Tue Oct 30 09:09:31 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE0721F86C4 for ; Tue, 30 Oct 2012 09:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xBt4ov5SDefw for ; Tue, 30 Oct 2012 09:09:30 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id BDFB621F868B for ; Tue, 30 Oct 2012 09:09:24 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so535915vbb.31 for ; Tue, 30 Oct 2012 09:09:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic:in-reply-to :mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=EFeL3TjGpHx3HYe4zW2zmYV7PeXnEr6g69dI0uf0GAs=; b=as0woRpv4M1kgkf6K5DnlViw+c/yRK2h+zvwE8Dy+CgrMwG0Ei+qwHaxmDSek6tefl S4zvrm3yEp45gs1+HZ6vbZXdnxjFByjHACvkHQjnyGYJ/suL5z1PyqvmBkcM/vA53Fc7 EQSvRDGeoVBAU183PJgh36z8Ara4UrYTfTktWAiZvZOD2ksx3pIeyvDMW7Mc3pfXsd0/ 0KpAD05eOh7KWstKgg3Bw5JA7CMqeQ8LbrELZrbjS9O4YNNKFq1CoH8f0qFmo/uEjmI2 wr/XPE0VCS8EnkKXW6ImFWnDzff4fj/Vba4NO4K1wdedP9l24Fq1n/RsP9vlbXl3DjpE FhJw== Received: by 10.52.94.225 with SMTP id df1mr43458933vdb.114.1351613364202; Tue, 30 Oct 2012 09:09:24 -0700 (PDT) Received: from [192.168.1.25] (pool-96-255-241-185.washdc.fios.verizon.net. [96.255.241.185]) by mx.google.com with ESMTPS id qj8sm515357veb.2.2012.10.30.09.09.21 (version=SSLv3 cipher=OTHER); Tue, 30 Oct 2012 09:09:23 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Tue, 30 Oct 2012 12:09:19 -0400 From: Carl Wallace To: Stefan Santesson , Message-ID: Thread-Topic: [pkix] Straw-poll on OCSP responses for non-revoked certificates. In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQlwEGKJNeE5i4Y9GQ2B/UPl5FBAVM4BBoeiUStJiDSLfTDNQz8Cg35+rwgTchs2r7oFhLO6 Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked certificates. X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 16:09:31 -0000 1 but would like for the responder certificate or response to include some indication that the responder is using these new semantics. On 10/30/12 5:52 AM, "Stefan Santesson" wrote: >Before we loose everyone engaged in this, I would like to make a >straw-poll: > > >Background: >A client may do a request for a certificate that has never been issued by >the CA. >This request may be done deliberately, by mistake or as a consequence of a >compromised CA. > >The OCSP protocol does not require OCSP responders to have any knowledge >about issued certificates. It must only know about revoked certificates >that are within it's current validity period. However, some OCSP >responders closely coupled with the CA may also know if a certificate with >a particular serialNumber value has been issued or not. > >The following is agreed: > - An OCSP responder is allowed to respond "good" to a status request >for a non-revoked certificate, disregarding if it has ever been issued. > > - A client, having no additional out-of-band knowledge about the OCSP >responder, will just know that the certificate is "not revoked" when >receiving a "good" response, unless the response includes one or more >response extensions that provides additional information. > > >The following is debated: > - Is an OCSP responder allowed to respond "revoked" even if a requested >certificate serial number is not on the list of revoked certificates, IF >the OCSP responder has positive knowledge that the requested serial number >does NOT represent a valid certificate issued by the identified CA? > > >Rationale for: >There are a number of reasons to allow this that has been mentioned, such >as: > - It breaks nothing. A legitimate request for an issued certificate will >get a legitimate deterministic response. > - It's safer. Responding "revoked" may not prevent a compromised CA from >being exploited. But if a request for a serialNumber that is known to be >bad is done nevertheless, a "revoked" response will at least be safer than >responding "good". > - Allowing extension definitions with further semantics. A response >extension may be defined in the future that adds more information about >the requested certificate. This may include a positive confirmation that >the certificate has been issued as well as information that this >particular OCSP responder will only respond "good" if it knows that the >requested certificate has been issued, otherwise it will respond >"revoked". An extension with such semantics can only be defined if the >base standard allows a status other than "good" in such situation. > - Supporting Web-PKI. The CAB-Forum has indicated that they will profile >the OCSP protocol for use with web server authentication. In such profile >they have indicated that they will NOT allow the "good" response unless >the requested certificate is known to have been issued. This means that >they will require OCSP responder in their infrastructure to have this >knowledge. Such profile would have to break the base OCSP standard if this >states that "good" MUST be returned unless the certificate has been >revoked. > >Rationale against: >The basic rationale against raised on this list has been the argument that >it is wrong and confusing to allow anything but "good" as a response to a >non-revoked certificate (if the cert is issued by a CA that is served by >this OCSP responder). >Another strong opinion is that it basically does not solve anything. A >broken CA is broken and can't be fixed by responding "revoked". It would >be easy to adapt an attack to circumvent such response, for example by >issuing a fake certificate that duplicates a legitimate serialNumber. > > >Please reply with either: > >1. Allow "revoked" response for a certificate that has not been "revoked" >but where that OCSP responder for any other reason knows the certificate >to be "bad". > >2. Require that the OCSP responder MUST respond "good" in this situation. > >3. Neither 1 or 2 (motivate). > > > > >Note: both alternatives are placed in a context where the certificate is >claimed to be issued by a CA that is served by this OCSP responder. The >exact meaning of "bad" is for later discussion. > >Please keep any motivation short and do not use this thread for long >debates. > > > > > > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix From paul.hoffman@vpnc.org Tue Oct 30 09:15:16 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE6421F85ED for ; Tue, 30 Oct 2012 09:15:16 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bM0khTem1Jec for ; Tue, 30 Oct 2012 09:15:16 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id E175C21F85EB for ; Tue, 30 Oct 2012 09:15:15 -0700 (PDT) Received: from [10.20.30.101] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q9UGFBlF095552 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 30 Oct 2012 09:15:12 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <53EA47528D6ACF4486AA152F92C2B6982A5F9E@xmb-rcd-x03.cisco.com> Date: Tue, 30 Oct 2012 09:15:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53EA47528D6ACF4486AA152F92C2B6982A5F9E@xmb-rcd-x03.cisco.com> To: Stefan Santesson X-Mailer: Apple Mail (2.1499) Cc: pkix@ietf.org Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked certificates. X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 16:15:16 -0000 On Oct 30, 2012, at 8:59 AM, Max Pritikin (pritikin) = wrote: > #1=20 >=20 > The system should fail closed. I agree with Paul Hoffman's point that = this extends the definition of the 'revoked' response during this = protocol exchange which must be noted. I'd also accept a new "unknown, = fail closed" type response so long as clients that don't yet understand = this new response fail closed. Max has a good point. I would say "#1, possibly followed by a new = optional extension later that would clarify which part of the new = 'revoked' is meant". --Paul Hoffman= From rick@goldbugtech.com Tue Oct 30 09:19:11 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CAFC21F8620 for ; Tue, 30 Oct 2012 09:19:11 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Id6YNBaowoaZ for ; Tue, 30 Oct 2012 09:19:08 -0700 (PDT) Received: from m1plsmtpa01-07.prod.mesa1.secureserver.net (m1plsmtpa01-07.prod.mesa1.secureserver.net [64.202.165.186]) by ietfa.amsl.com (Postfix) with ESMTP id EA1AE21F84CD for ; Tue, 30 Oct 2012 09:19:07 -0700 (PDT) Received: from Athens ([71.196.142.19]) by m1plsmtpa01-07.prod.mesa1.secureserver.net with id HUK61k00E0RK5QP01UK7xS; Tue, 30 Oct 2012 09:19:07 -0700 From: "Rick Robinson" To: References: <20121029232328.BF5D91A309@ld9781.wdf.sap.corp> In-Reply-To: Date: Tue, 30 Oct 2012 10:19:09 -0600 Organization: Goldbug Technology Consulting, LLC Message-ID: <002e01cdb6ba$4b1e9480$e15bbd80$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac22jnp5y3fOL5jSRIiGwfclr1BPnQAK8GRw Content-Language: en-us Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked certificates. X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 16:19:11 -0000 3) Neither. Add new optional response = unissued. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Stefan Santesson Sent: Tuesday, October 30, 2012 3:53 AM To: pkix@ietf.org Subject: [pkix] Straw-poll on OCSP responses for non-revoked certificates. Before we loose everyone engaged in this, I would like to make a straw-poll: Background: A client may do a request for a certificate that has never been issued by the CA. This request may be done deliberately, by mistake or as a consequence of a compromised CA. The OCSP protocol does not require OCSP responders to have any knowledge about issued certificates. It must only know about revoked certificates that are within it's current validity period. However, some OCSP responders closely coupled with the CA may also know if a certificate with a particular serialNumber value has been issued or not. The following is agreed: - An OCSP responder is allowed to respond "good" to a status request for a non-revoked certificate, disregarding if it has ever been issued. - A client, having no additional out-of-band knowledge about the OCSP responder, will just know that the certificate is "not revoked" when receiving a "good" response, unless the response includes one or more response extensions that provides additional information. The following is debated: - Is an OCSP responder allowed to respond "revoked" even if a requested certificate serial number is not on the list of revoked certificates, IF the OCSP responder has positive knowledge that the requested serial number does NOT represent a valid certificate issued by the identified CA? Rationale for: There are a number of reasons to allow this that has been mentioned, such as: - It breaks nothing. A legitimate request for an issued certificate will get a legitimate deterministic response. - It's safer. Responding "revoked" may not prevent a compromised CA from being exploited. But if a request for a serialNumber that is known to be bad is done nevertheless, a "revoked" response will at least be safer than responding "good". - Allowing extension definitions with further semantics. A response extension may be defined in the future that adds more information about the requested certificate. This may include a positive confirmation that the certificate has been issued as well as information that this particular OCSP responder will only respond "good" if it knows that the requested certificate has been issued, otherwise it will respond "revoked". An extension with such semantics can only be defined if the base standard allows a status other than "good" in such situation. - Supporting Web-PKI. The CAB-Forum has indicated that they will profile the OCSP protocol for use with web server authentication. In such profile they have indicated that they will NOT allow the "good" response unless the requested certificate is known to have been issued. This means that they will require OCSP responder in their infrastructure to have this knowledge. Such profile would have to break the base OCSP standard if this states that "good" MUST be returned unless the certificate has been revoked. Rationale against: The basic rationale against raised on this list has been the argument that it is wrong and confusing to allow anything but "good" as a response to a non-revoked certificate (if the cert is issued by a CA that is served by this OCSP responder). Another strong opinion is that it basically does not solve anything. A broken CA is broken and can't be fixed by responding "revoked". It would be easy to adapt an attack to circumvent such response, for example by issuing a fake certificate that duplicates a legitimate serialNumber. Please reply with either: 1. Allow "revoked" response for a certificate that has not been "revoked" but where that OCSP responder for any other reason knows the certificate to be "bad". 2. Require that the OCSP responder MUST respond "good" in this situation. 3. Neither 1 or 2 (motivate). Note: both alternatives are placed in a context where the certificate is claimed to be issued by a CA that is served by this OCSP responder. The exact meaning of "bad" is for later discussion. Please keep any motivation short and do not use this thread for long debates. _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From jeremy.rowley@digicert.com Tue Oct 30 09:46:05 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF8DC21F871E for ; Tue, 30 Oct 2012 09:46:05 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gJWPHTy7DZv for ; Tue, 30 Oct 2012 09:46:04 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id C911F21F872A for ; Tue, 30 Oct 2012 09:46:04 -0700 (PDT) Received: from JROWLEYL1 (unknown [64.78.193.228]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id 78FCF7FC144; Tue, 30 Oct 2012 10:46:04 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1351615564; bh=IA9JCI8VMZOF3GiGqKv1Ybi8Z5XeSeKM1eJrXY3r4nE=; h=Reply-To:From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=uQLRICMYNR7bM+f/HaDPpQ73Nf8nAxP2Fj3B7xPS9Pm2J27g1Z82NYbIQdcYM4Be4 hc92SjIjqROzvlMUXSFoITcnwvHK931vutfjpkCHhq7SMriL1dJkBG/3xFQsqltBzd cGz1aCWgFzup3/SBPxEubgQrrvdnR+ilqsgDUuv4= From: "Jeremy Rowley" To: "'Rick Robinson'" , References: <20121029232328.BF5D91A309@ld9781.wdf.sap.corp> <002e01cdb6ba$4b1e9480$e15bbd80$@com> In-Reply-To: <002e01cdb6ba$4b1e9480$e15bbd80$@com> Date: Tue, 30 Oct 2012 10:46:04 -0600 Organization: DigiCert Message-ID: <02af01cdb6be$0d677d60$28367820$@digicert.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGVV/pKG3iHd0l1fUM/6+5gHz6tmwH1lk8JAjuKqQSYIUIjUA== Content-Language: en-us Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked certificates. X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jeremy.rowley@digicert.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 16:46:05 -0000 3 - Many CAs already respond with either unknown or unauthorized. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Rick Robinson Sent: Tuesday, October 30, 2012 10:19 AM To: pkix@ietf.org Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked certificates. 3) Neither. Add new optional response = unissued. -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Stefan Santesson Sent: Tuesday, October 30, 2012 3:53 AM To: pkix@ietf.org Subject: [pkix] Straw-poll on OCSP responses for non-revoked certificates. Before we loose everyone engaged in this, I would like to make a straw-poll: Background: A client may do a request for a certificate that has never been issued by the CA. This request may be done deliberately, by mistake or as a consequence of a compromised CA. The OCSP protocol does not require OCSP responders to have any knowledge about issued certificates. It must only know about revoked certificates that are within it's current validity period. However, some OCSP responders closely coupled with the CA may also know if a certificate with a particular serialNumber value has been issued or not. The following is agreed: - An OCSP responder is allowed to respond "good" to a status request for a non-revoked certificate, disregarding if it has ever been issued. - A client, having no additional out-of-band knowledge about the OCSP responder, will just know that the certificate is "not revoked" when receiving a "good" response, unless the response includes one or more response extensions that provides additional information. The following is debated: - Is an OCSP responder allowed to respond "revoked" even if a requested certificate serial number is not on the list of revoked certificates, IF the OCSP responder has positive knowledge that the requested serial number does NOT represent a valid certificate issued by the identified CA? Rationale for: There are a number of reasons to allow this that has been mentioned, such as: - It breaks nothing. A legitimate request for an issued certificate will get a legitimate deterministic response. - It's safer. Responding "revoked" may not prevent a compromised CA from being exploited. But if a request for a serialNumber that is known to be bad is done nevertheless, a "revoked" response will at least be safer than responding "good". - Allowing extension definitions with further semantics. A response extension may be defined in the future that adds more information about the requested certificate. This may include a positive confirmation that the certificate has been issued as well as information that this particular OCSP responder will only respond "good" if it knows that the requested certificate has been issued, otherwise it will respond "revoked". An extension with such semantics can only be defined if the base standard allows a status other than "good" in such situation. - Supporting Web-PKI. The CAB-Forum has indicated that they will profile the OCSP protocol for use with web server authentication. In such profile they have indicated that they will NOT allow the "good" response unless the requested certificate is known to have been issued. This means that they will require OCSP responder in their infrastructure to have this knowledge. Such profile would have to break the base OCSP standard if this states that "good" MUST be returned unless the certificate has been revoked. Rationale against: The basic rationale against raised on this list has been the argument that it is wrong and confusing to allow anything but "good" as a response to a non-revoked certificate (if the cert is issued by a CA that is served by this OCSP responder). Another strong opinion is that it basically does not solve anything. A broken CA is broken and can't be fixed by responding "revoked". It would be easy to adapt an attack to circumvent such response, for example by issuing a fake certificate that duplicates a legitimate serialNumber. Please reply with either: 1. Allow "revoked" response for a certificate that has not been "revoked" but where that OCSP responder for any other reason knows the certificate to be "bad". 2. Require that the OCSP responder MUST respond "good" in this situation. 3. Neither 1 or 2 (motivate). Note: both alternatives are placed in a context where the certificate is claimed to be issued by a CA that is served by this OCSP responder. The exact meaning of "bad" is for later discussion. Please keep any motivation short and do not use this thread for long debates. _______________________________________________ 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 melinda.shore@gmail.com Tue Oct 30 10:31:46 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB9821F873B for ; Tue, 30 Oct 2012 10:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSt0Bd80oC-s for ; Tue, 30 Oct 2012 10:31:45 -0700 (PDT) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id DBF9521F873A for ; Tue, 30 Oct 2012 10:31:45 -0700 (PDT) Received: by mail-da0-f44.google.com with SMTP id h15so216391dan.31 for ; Tue, 30 Oct 2012 10:31:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Gi6AYh0PyD+J2KEQxM1wQLq1jxRKH2A78/9B6JnUfqk=; b=Ho88dy8jy+j2/c8SyhE1RT+y6tl01ZTGLs4HpoIO1FB4nl8FaX4vVHe8JeceUZ0aR3 7zBbJd49I4wmsgoACMIwL+iequWvq7Xv6xdlJ82qEeHPIeyKBkNbzgwb72HVqMl8Z44a f9JC10iXWNPo82rxnyHMNhJnXMSw6Re9g/WP87xffC8zB+jQTVMt0EQsh0mJnI6zwSbh O9vrtB6PvBRQSyHVNmjhhWF5ESqEcXkmzmch0yPog/t5HJ1bw8ahzYMr8oXHFSYRArjw DFgdARbYZMl7JgIHVpAz3s6Hn7nkUpiaSkuNvHjeuwMpFlKj/Vtck9TeLzd1lOVSl7cQ WxCg== Received: by 10.69.0.40 with SMTP id av8mr104729125pbd.117.1351618305732; Tue, 30 Oct 2012 10:31:45 -0700 (PDT) Received: from spandex.local (216-67-49-109-rb1.fai.dsl.dynamic.acsalaska.net. [216.67.49.109]) by mx.google.com with ESMTPS id qd3sm426348pbc.29.2012.10.30.10.31.44 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 30 Oct 2012 10:31:45 -0700 (PDT) Message-ID: <50900EFF.8060106@gmail.com> Date: Tue, 30 Oct 2012 09:31:43 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: pkix@ietf.org References: <508FD9A4.8080101@kent.ac.uk> In-Reply-To: <508FD9A4.8080101@kent.ac.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked certificates. X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 17:31:46 -0000 Option 1. Melinda From kent@bbn.com Tue Oct 30 10:38:11 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6641821F847B for ; Tue, 30 Oct 2012 10:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3NdjYm9T1Yo5 for ; Tue, 30 Oct 2012 10:38:10 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id A6BDA21F872A for ; Tue, 30 Oct 2012 10:38:10 -0700 (PDT) Received: from dhcp89-089-176.bbn.com ([128.89.89.176]:49165) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TTFlR-0005Cf-GI for pkix@ietf.org; Tue, 30 Oct 2012 13:38:09 -0400 Message-ID: <50901081.9090603@bbn.com> Date: Tue, 30 Oct 2012 13:38:09 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121005 Thunderbird/16.0 MIME-Version: 1.0 To: pkix@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked certificates. X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 17:38:11 -0000 #1 Steve From piyush@ditenity.com Tue Oct 30 11:54:30 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9EB21F85D3 for ; Tue, 30 Oct 2012 11:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rx5Wo1-d4Hc for ; Tue, 30 Oct 2012 11:54:29 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 59FF121F85B8 for ; Tue, 30 Oct 2012 11:54:27 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so1053734iec.31 for ; Tue, 30 Oct 2012 11:54:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language:x-gm-message-state; bh=P7L30eyzCUmwBwueYN720it//6WFUvwHneocCsFdxh4=; b=i7BB+3irwkb+Y9EPvw9eqs17LWUbCUsLqt41n8D3v5Ldo4BInUcqYNdwP0yYyEhXkO fjLi7bDnuQ8x7phk3VsdNcCPS7yMGSNmgl1X/Xj7KNXtP5aqEdmkHBzYjoueBjYRRDMA FuZtH99Roq1oi23IHXmWYhZ77Cz8HT+FaTzCH7OcySZFtgjAHmDbniDjqG4c42qFYglO fFwLAjzg0SVqVRbzJTmw9B1C6t2LKBrsOOKyzVrDdrGgxibcbFGb5JqQtdy4oDEPvGgO VyYKgoMBo9+EKSiTMLIEbyuViWYifInaXZCemaatI7W5OfyMvpuOou9pAGn5BfTo75ck 6tBg== Received: by 10.50.183.199 with SMTP id eo7mr2482462igc.36.1351623266642; Tue, 30 Oct 2012 11:54:26 -0700 (PDT) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id vq4sm8621876igb.10.2012.10.30.11.54.24 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 30 Oct 2012 11:54:25 -0700 (PDT) From: "Piyush Jain" To: "Stefan Santesson" , References: <50901081.9090603@bbn.com> In-Reply-To: <50901081.9090603@bbn.com> Date: Tue, 30 Oct 2012 11:54:21 -0700 Message-ID: <009b01cdb6cf$fb82ef00$f288cd00$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH7V4mRT1i3o6eF4Gwz+GJsNjIvX5d28A2A Content-Language: en-us X-Gm-Message-State: ALoCoQk2shxqzeobHg9ai07S95JkHqdpHuhIoH13320bDAB3l3h5sTD0EgAE+6zQr5EZOV0FlI7C Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked certificates. X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 18:54:30 -0000 #3. No problem with #1 either as long as it is made explicit in the security guidance that such a response is coming from a compromised CA/responder > -----Original Message----- > From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of > Stephen Kent > Sent: Tuesday, October 30, 2012 10:38 AM > To: pkix@ietf.org > Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked > certificates. > > #1 > > Steve > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From mrex@sap.com Tue Oct 30 12:00:39 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 515E521F8716 for ; Tue, 30 Oct 2012 12:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.949 X-Spam-Level: X-Spam-Status: No, score=-8.949 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYnRb3rN0Hpn for ; Tue, 30 Oct 2012 12:00:38 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id E56CA21F8712 for ; Tue, 30 Oct 2012 12:00:34 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q9UJ0VYd015186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 30 Oct 2012 20:00:31 +0100 (MET) In-Reply-To: To: Carl Wallace Date: Tue, 30 Oct 2012 20:00:29 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20121030190029.542D31A30F@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: Stefan Santesson , pkix@ietf.org Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked certificates. X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 19:00:39 -0000 Carl Wallace wrote: > > 1 but would like for the responder certificate or response to include some > indication that the responder is using these new semantics. I also choose 1, and I am not aware of any technical objection against 1, why _permitting_ (rather than requiring) OCSP responders to do this should be detrimental to the security of the peer authentication performed by the RP or to the interop between the RP and the OCSP responder. I'm OK with defining an RECOMMENDing an explicit confirmation of these semantics through a non-critical response extension. Option 2 looks like a coffin nail for *ALL* OCSP extensibility to me. It just doesn't make sense to me to add a "perfect" option on top of good and permitting only _new_ RPs to recognize it; allowing+expecting them to then fail on "good" no longer being good enough, while effectively misleading the entire installed base on the guidance to better not trust the cert (serial) in the response. Option 3 looks like a technical problem. Error responses are unsigned and (a) are supposed to cause a fallback to CRLs (but CRLs processing can not possibly detect the problem that the OCSP responder is trying to convey) and (b) can not be cached by RPs that use OCSP to determine that status of their communication peer's certificate. About RPs that retry for OCSP responses with status "revoked,certificateHold", the existing semantics of nextUpdate should be followed: http://tools.ietf.org/html/rfc2560#section-2.4 The removeFromCRL reason code is limited to delta-CRLs in order to supersede a certificateHold of the baseCRL to which the delta CRL refers. On the next regular CRL, a certificateHold crlEntry may reappear when the permanent status is still undetermined, may be dropped/missing when the hold status is lifted, or it may be replaced by a permanent revocation. -Martin From housley@vigilsec.com Tue Oct 30 12:36:15 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0DE21F8621 for ; Tue, 30 Oct 2012 12:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4pkr7Fig4tt for ; Tue, 30 Oct 2012 12:36:15 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id C833521F861F for ; Tue, 30 Oct 2012 12:36:14 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id EA3E89A4006; Tue, 30 Oct 2012 15:36:22 -0400 (EDT) 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 2SbXanLqvPf1; Tue, 30 Oct 2012 15:36:02 -0400 (EDT) Received: from [192.168.2.100] (pool-96-255-37-162.washdc.fios.verizon.net [96.255.37.162]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 23D509A4002; Tue, 30 Oct 2012 15:36:22 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <53EA47528D6ACF4486AA152F92C2B6982A5F9E@xmb-rcd-x03.cisco.com> Date: Tue, 30 Oct 2012 15:36:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <82D5728C-5DD7-4EB7-B9E4-8F9645DD9A6D@vigilsec.com> References: <53EA47528D6ACF4486AA152F92C2B6982A5F9E@xmb-rcd-x03.cisco.com> To: Stefan Santesson X-Mailer: Apple Mail (2.1085) Cc: pkix@ietf.org Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked certificates. X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 19:36:15 -0000 > #1=20 >=20 > The system should fail closed. I agree with Paul Hoffman's point that = this extends the definition of the 'revoked' response during this = protocol exchange which must be noted. I'd also accept a new "unknown, = fail closed" type response so long as clients that don't yet understand = this new response fail closed. Max and Paul have raised good points. I support #1, if and only if there = is a way for the relying party to tell wether the OCSP Responder is = using the original definition or the new and improved one. Russ= From mrex@sap.com Tue Oct 30 13:47:34 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6834421F8652 for ; Tue, 30 Oct 2012 13:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bL2NTRQot+ZS for ; Tue, 30 Oct 2012 13:47:33 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7193521F863F for ; Tue, 30 Oct 2012 13:47:28 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q9UKlN0e000973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 30 Oct 2012 21:47:24 +0100 (MET) In-Reply-To: <195DB2510AAA004391F58E28FCE21200066E1E15@IMCMBX01.MITRE.ORG> To: "Miller, Timothy J." Date: Tue, 30 Oct 2012 21:47:21 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20121030204721.E00241A311@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "pkix@ietf.org" , 'Stefan Santesson' Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 20:47:34 -0000 Miller, Timothy J. wrote: > > > X.509/PKIX is defective because it breaks badly already on fraudulent > > cert issuance (a weaker form of CA compromise) and can not cope at all > > with CA key compromise. > > Do you have an alternative to the technology, because AFAICT, > no PKI standards recover well from a breach of trust. The design flaw of PKI is that all CA keys are single points of failure. There is a complete lack of backup if one fails, or can be made to fail. Designing a technology with complete lack of a backup system seems like a bad idea to me. Like skydiving with only one single parachute, or designing a large commercial passenger jet with just a single turbo-fan engine (something which FAA might refuse to certify for good reasons). The fact that _no_ existing PKI standards provide backup facilities today is a mere technical defect that _could_ be fixed. > > Even the web of trust has issues; if a well-connected introducer is > compromised, all descendent keys become suspect--which can potentially > encompass all nodes in the graph. This can be as devestating as a > CA compromise, and would likewise require a re-execution of a large > number of signing ceremonies. I beg to differ. When a well-connected introducer is newly compromised, then this does not affect any trust relationships previously confirmed by that introducer, only precludes adoption of trust for new relationships. When a well-connected introducer turns out to have been never been trust-worthy, it affects only those trust relationships where he is the _only_ introducer (same effect as in single-key PKI models). > > > The flaw with CRLs and OCSP is that it tries to infer, from a lack > > of a revocation, that a certificate has been properly issued and is valid. > > Evidently, this turned out to be a logical fallacy with respect to > > real world usage scenarios. > > Absent a trusted observer, there is no positive statement that can > be issued by a CA that positively identifies only "valid" certificates. > Given a trusted observer, why not make him the CA and be done with it? Maybe because PKI(X) should be more about real-wold PKIs, and less about Utopia. Why should businesses and banks deal with accounting, audits and fraud prevention, if they could simply use a system where fraud is impossible. As it turns out, it is impossible to create and run a "system where fraud is impossible" in the real world (even if they wanted to), especially at a cost-level where business operation makes sense. So the second best approach is a security trade-off, a system that makes business sense and can cope reasonably with common real-world _operational_ problems, like software being subject to bugs and staff being susceptible to social engineering, bribery and threat/coercion. I could imagine why crooks, hackers and certain agencies might not like a backup scheme that makes subverting the PKI significantly harder. But why should an engineer, and in particular one who understands and cares about security, oppose addition of a backup scheme to address the susceptibility of X.509 PKI to operational problems and risks from the pesky (physical) real world? -Martin From tom@ritter.vg Tue Oct 30 19:29:59 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C71221F85EA for ; Tue, 30 Oct 2012 19:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGb3uJYGNeco for ; Tue, 30 Oct 2012 19:29:58 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D58F821F85E7 for ; Tue, 30 Oct 2012 19:29:57 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so1132773vbb.31 for ; Tue, 30 Oct 2012 19:29:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PZ/qsUeY2Pwi9yyj+kYzTvxs1ksBNMlyUK0n9vSJ5d0=; b=PSha8x7lpaGB1wABOP6bESPJ2pfYwhcWignv/YxEZMBhvhQNGJIdDdjriaEQUbjywn tMVxCDtsgiYEiCR8LixfRcfnv9DFkAMq6pZzI2A9H6DIelJwgzTxF1TgDQDgZzrxqP6C mKeKb/Huto/P/F8UJyZbwq0d06UnJ9vPxH8E4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=PZ/qsUeY2Pwi9yyj+kYzTvxs1ksBNMlyUK0n9vSJ5d0=; b=AfFdhupd8DwJ3TpFMzJMJZy6dtQcT9yXSqyadiIppqTJa0+M8C/IGG2dpXhVwHOeJi A8zAyhxujYIQ96LSI5WZKy7YOKVaQMzrNqhRVn+NJmpBmpg/LcPU1CbBlyAT42m81mBt q5vtwu8ULTulOrE3KjxlOyOhYQR32NmFVf9kuJjYLvpOFukf9VuJz44RqTp2seWXm2Tm LcJ6QuUd471nTscRqAv7g+7NROtJ3ZKb2m4rUIaggrG6jLbg0AwVnbyLOcpKMQu3a7lN dNciezJ0ouXDuAB18K9jd2pUtbFu0B5AVwTHpD5YgfcN5ibVNSBQhcEKnPmqdslS1Iyy g60g== MIME-Version: 1.0 Received: by 10.52.70.48 with SMTP id j16mr45657064vdu.1.1351650597227; Tue, 30 Oct 2012 19:29:57 -0700 (PDT) Received: by 10.58.151.178 with HTTP; Tue, 30 Oct 2012 19:29:56 -0700 (PDT) Received: by 10.58.151.178 with HTTP; Tue, 30 Oct 2012 19:29:56 -0700 (PDT) In-Reply-To: References: <20121029232328.BF5D91A309@ld9781.wdf.sap.corp> Date: Tue, 30 Oct 2012 22:29:56 -0400 Message-ID: From: Tom Ritter To: Stefan Santesson Content-Type: multipart/alternative; boundary=20cf307f3996b54c9604cd51ad1b X-Gm-Message-State: ALoCoQlTaiNMLG+dQyaImIlGLTk1YLDOWg7juJ6/0yWN1ahvRAbd32Y+siR6pUYkQKHXqrlq4hBb Cc: pkix@ietf.org Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked certificates. X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 02:29:59 -0000 --20cf307f3996b54c9604cd51ad1b Content-Type: text/plain; charset=ISO-8859-1 1 On Oct 30, 2012 7:05 AM, "Stefan Santesson" wrote: > Before we loose everyone engaged in this, I would like to make a > straw-poll: > > > Background: > A client may do a request for a certificate that has never been issued by > the CA. > This request may be done deliberately, by mistake or as a consequence of a > compromised CA. > > The OCSP protocol does not require OCSP responders to have any knowledge > about issued certificates. It must only know about revoked certificates > that are within it's current validity period. However, some OCSP > responders closely coupled with the CA may also know if a certificate with > a particular serialNumber value has been issued or not. > > The following is agreed: > - An OCSP responder is allowed to respond "good" to a status request > for a non-revoked certificate, disregarding if it has ever been issued. > > - A client, having no additional out-of-band knowledge about the OCSP > responder, will just know that the certificate is "not revoked" when > receiving a "good" response, unless the response includes one or more > response extensions that provides additional information. > > > The following is debated: > - Is an OCSP responder allowed to respond "revoked" even if a requested > certificate serial number is not on the list of revoked certificates, IF > the OCSP responder has positive knowledge that the requested serial number > does NOT represent a valid certificate issued by the identified CA? > > > Rationale for: > There are a number of reasons to allow this that has been mentioned, such > as: > - It breaks nothing. A legitimate request for an issued certificate will > get a legitimate deterministic response. > - It's safer. Responding "revoked" may not prevent a compromised CA from > being exploited. But if a request for a serialNumber that is known to be > bad is done nevertheless, a "revoked" response will at least be safer than > responding "good". > - Allowing extension definitions with further semantics. A response > extension may be defined in the future that adds more information about > the requested certificate. This may include a positive confirmation that > the certificate has been issued as well as information that this > particular OCSP responder will only respond "good" if it knows that the > requested certificate has been issued, otherwise it will respond > "revoked". An extension with such semantics can only be defined if the > base standard allows a status other than "good" in such situation. > - Supporting Web-PKI. The CAB-Forum has indicated that they will profile > the OCSP protocol for use with web server authentication. In such profile > they have indicated that they will NOT allow the "good" response unless > the requested certificate is known to have been issued. This means that > they will require OCSP responder in their infrastructure to have this > knowledge. Such profile would have to break the base OCSP standard if this > states that "good" MUST be returned unless the certificate has been > revoked. > > Rationale against: > The basic rationale against raised on this list has been the argument that > it is wrong and confusing to allow anything but "good" as a response to a > non-revoked certificate (if the cert is issued by a CA that is served by > this OCSP responder). > Another strong opinion is that it basically does not solve anything. A > broken CA is broken and can't be fixed by responding "revoked". It would > be easy to adapt an attack to circumvent such response, for example by > issuing a fake certificate that duplicates a legitimate serialNumber. > > > Please reply with either: > > 1. Allow "revoked" response for a certificate that has not been "revoked" > but where that OCSP responder for any other reason knows the certificate > to be "bad". > > 2. Require that the OCSP responder MUST respond "good" in this situation. > > 3. Neither 1 or 2 (motivate). > > > > > Note: both alternatives are placed in a context where the certificate is > claimed to be issued by a CA that is served by this OCSP responder. The > exact meaning of "bad" is for later discussion. > > Please keep any motivation short and do not use this thread for long > debates. > > > > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > --20cf307f3996b54c9604cd51ad1b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

1

On Oct 30, 2012 7:05 AM, "Stefan Santesson&= quot; <stefan@aaa-sec.com> = wrote:
Before we loose everyone engaged in this, I would like to make a
straw-poll:


Background:
A client may do a request for a certificate that has never been issued by the CA.
This request may be done deliberately, by mistake or as a consequence of a<= br> compromised CA.

The OCSP protocol does not require OCSP responders to have any knowledge about issued certificates. It must only know about revoked certificates
that are within it's current validity period. However, some OCSP
responders closely coupled with the CA may also know if a certificate with<= br> a particular serialNumber value has been issued or not.

The following is agreed:
=A0 =A0- An OCSP responder is allowed to respond "good" to a stat= us request
for a non-revoked certificate, disregarding if it has ever been issued.

=A0 =A0- A client, having no additional out-of-band knowledge about the OCS= P
responder, will just know that the certificate is "not revoked" w= hen
receiving a "good" response, unless the response includes one or = more
response extensions that provides additional information.


The following is debated:
=A0 =A0- Is an OCSP responder allowed to respond "revoked" even i= f a requested
certificate serial number is not on the list of revoked certificates, IF the OCSP responder has positive knowledge that the requested serial number<= br> does NOT represent a valid certificate issued by the identified CA?


Rationale for:
There are a number of reasons to allow this that has been mentioned, such as:
=A0- It breaks nothing. A legitimate request for an issued certificate will=
get a legitimate deterministic response.
=A0- It's safer. Responding "revoked" may not prevent a compr= omised CA from
being exploited. But if a request for a serialNumber that is known to be bad is done nevertheless, a "revoked" response will at least be s= afer than
responding "good".
=A0- Allowing extension definitions with further semantics. A response
extension may be defined in the future that adds more information about
the requested certificate. This may include a positive confirmation that the certificate has been issued as well as information that this
particular OCSP responder will only respond "good" if it knows th= at the
requested certificate has been issued, otherwise it will respond
"revoked". An extension with such semantics can only be defined i= f the
base standard allows a status other than "good" in such situation= .
=A0- Supporting Web-PKI. The CAB-Forum has indicated that they will profile=
the OCSP protocol for use with web server authentication. In such profile they have indicated that they will NOT allow the "good" response = unless
the requested certificate is known to have been issued. This means that
they will require OCSP responder in their infrastructure to have this
knowledge. Such profile would have to break the base OCSP standard if this<= br> states that "good" MUST be returned unless the certificate has be= en
revoked.

Rationale against:
The basic rationale against raised on this list has been the argument that<= br> it is wrong and confusing to allow anything but "good" as a respo= nse to a
non-revoked certificate (if the cert is issued by a CA that is served by this OCSP responder).
Another strong opinion is that it basically does not solve anything. A
broken CA is broken and can't be fixed by responding "revoked"= ;. It would
be easy to adapt an attack to circumvent such response, for example by
issuing a fake certificate that duplicates a legitimate serialNumber.


Please reply with either:

1. Allow "revoked" response for a certificate that has not been &= quot;revoked"
but where that OCSP responder for any other reason knows the certificate to be "bad".

2. Require that the OCSP responder MUST respond "good" in this si= tuation.

3. Neither 1 or 2 (motivate).




Note: both alternatives are placed in a context where the certificate is claimed to be issued by a CA that is served by this OCSP responder. The
exact meaning of "bad" is for later discussion.

Please keep any motivation short and do not use this thread for long
debates.






_______________________________________________
pkix mailing list
pkix@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/pkix
--20cf307f3996b54c9604cd51ad1b-- From lists@drh-consultancy.co.uk Tue Oct 30 19:40:32 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE0D21F85ED for ; Tue, 30 Oct 2012 19:40:32 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id baZ+0v3-A1Iq for ; Tue, 30 Oct 2012 19:40:30 -0700 (PDT) Received: from claranet-outbound-smtp02.uk.clara.net (claranet-outbound-smtp02.uk.clara.net [195.8.89.35]) by ietfa.amsl.com (Postfix) with ESMTP id 94BBB21F851E for ; Tue, 30 Oct 2012 19:40:30 -0700 (PDT) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:48807 helo=[192.168.7.8]) by relay02.mail.eu.clara.net (relay.clara.net [213.253.3.42]:10465) with esmtpa (authdaemon_plain:drh) id 1TTOED-0000ui-7T for pkix@ietf.org (return-path ); Wed, 31 Oct 2012 02:40:25 +0000 Message-ID: <50908F98.5060409@drh-consultancy.co.uk> Date: Wed, 31 Oct 2012 02:40:24 +0000 From: Dr Stephen Henson User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: pkix@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked certificates. X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 02:40:32 -0000 Option 1. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From ryan-pkix@sleevi.com Wed Oct 31 02:20:29 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8913F21F870B for ; Wed, 31 Oct 2012 02:20:29 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erVm-E9o+F5t for ; Wed, 31 Oct 2012 02:20:28 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id CF97B21F86F3 for ; Wed, 31 Oct 2012 02:20:28 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTP id 9AC94BC041; Wed, 31 Oct 2012 02:20:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=1nBLTEc3FBXp4EUB2mzeDtFwwpk=; b=Uyem3Y56ioMsDxRk6 oareb+U2FIsK4RwK+P+aiTGb6nVxtW7i/2xX5zkp05T3kMtO3ZdbiGA128s5sOkX dd7Rwjfhz9u05oqd6RinJYM4J73U9pY25cuNXFa4C37BAwnLmo3uFPzmAaRr8jEk CMEd6i5R0+iUWqp2+5vR/pzL8I= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTPA id 1DFFCBC040; Wed, 31 Oct 2012 02:20:28 -0700 (PDT) Received: from 91.217.168.220 (proxying for 91.217.168.220) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Wed, 31 Oct 2012 02:20:28 -0700 Message-ID: <029b842c4a5690b67697621aabd31dd6.squirrel@webmail.dreamhost.com> In-Reply-To: References: Date: Wed, 31 Oct 2012 02:20:28 -0700 From: "Ryan Sleevi" To: "Stefan Santesson" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pkix@ietf.org Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked certificates. X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ryan-pkix@sleevi.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 09:20:29 -0000 Option 1 From Johannes.Merkle@secunet.com Wed Oct 31 03:36:35 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35A9C21F8785 for ; Wed, 31 Oct 2012 03:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M77otcuF12CH for ; Wed, 31 Oct 2012 03:36:34 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB8F21F8775 for ; Wed, 31 Oct 2012 03:36:34 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id CEA411A006F for ; Wed, 31 Oct 2012 11:36:31 +0100 (CET) X-Virus-Scanned: by secunet Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 3F1CB1A0085 for ; Wed, 31 Oct 2012 11:36:23 +0100 (CET) Received: from [10.208.1.73] ([10.208.1.73]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 31 Oct 2012 11:36:22 +0100 Message-ID: <5090FF26.8040204@secunet.com> Date: Wed, 31 Oct 2012 11:36:22 +0100 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: pkix@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Oct 2012 10:36:22.0987 (UTC) FILETIME=[9264F1B0:01CDB753] Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked certificates. X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 10:36:35 -0000 Option 1 with strong support for Paul's request to change the name of this status (e.g. to "revoked or never issued"). While I agree to defining an extension signaling the new semantic, I deem it more important to have an extension providing positive evidence (not just indication) of the fact that a certificate has been issued, e.g. by including a hash of the certificate in question. > It would > be easy to adapt an attack to circumvent such response, for example by > issuing a fake certificate that duplicates a legitimate serialNumber. This attack would be prevented by returning in the response the hash value of the certificate. Inclusion of a new status, as suggested in some answers, would require a new protocol version number. Johannes From liaquat.khan@ascertia.com Wed Oct 31 03:45:05 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E021521F8615 for ; Wed, 31 Oct 2012 03:45:05 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eL01Yb-oxlMg for ; Wed, 31 Oct 2012 03:45:05 -0700 (PDT) Received: from mail.ascertia.com (www.ascertia.com [94.136.44.32]) by ietfa.amsl.com (Postfix) with ESMTP id 32F2821F84DF for ; Wed, 31 Oct 2012 03:45:05 -0700 (PDT) Received: from [192.168.1.64] ([86.174.165.204]) by ascertia.com with MailEnable ESMTP; Wed, 31 Oct 2012 10:47:00 +0000 User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Wed, 31 Oct 2012 10:44:10 +0000 From: Liaquat Khan To: Piyush Jain , Stefan Santesson , Message-ID: Thread-Topic: [pkix] Straw-poll on OCSP responses for non-revoked certificates. In-Reply-To: <009b01cdb6cf$fb82ef00$f288cd00$@ditenity.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked certificates. X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 10:45:06 -0000 #3 - if you need validity info beyond revocation checking then you should use SCVP. However agree with Piyush, can accept #1 as long as implications are made clear. Regards LK On 30/10/2012 18:54, "Piyush Jain" wrote: >#3. > >No problem with #1 either as long as it is made explicit in the security >guidance that such a response is coming from a compromised CA/responder > >> -----Original Message----- >> From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of >> Stephen Kent >> Sent: Tuesday, October 30, 2012 10:38 AM >> To: pkix@ietf.org >> Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked >> certificates. >> >> #1 >> >> Steve >> _______________________________________________ >> 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 i-barreira@izenpe.net Wed Oct 31 03:51:59 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 385AB21F8795 for ; Wed, 31 Oct 2012 03:51:59 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJA1VpIpv9pQ for ; Wed, 31 Oct 2012 03:51:58 -0700 (PDT) Received: from correo.euskaltel.es (ektmail2mta2.euskaltel.es [212.55.8.119]) by ietfa.amsl.com (Postfix) with ESMTP id BA73E21F87CF for ; Wed, 31 Oct 2012 03:51:56 -0700 (PDT) Received: from ejlp024.ejgv ([194.30.48.247]) by ektmail2mta2.euskaltel.es (Sun Java System Messaging Server 6.2-9.09 (built Jan 8 2008)) with ESMTP id <0MCR007IR7IIUPE0@ektmail2mta2.euskaltel.es> for pkix@ietf.org; Wed, 31 Oct 2012 11:51:54 +0100 (MET) Received: from afe01.ejsarea.net (afe01 [10.200.192.14]) by ejlp024.ejgv (8.13.1/8.13.1) with ESMTP id q9VAprg0028963; Wed, 31 Oct 2012 11:51:53 +0100 Received: from AEX06.ejsarea.net ([10.200.198.15]) by afe01.ejsarea.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 31 Oct 2012 11:51:54 +0100 Date: Wed, 31 Oct 2012 11:51:53 +0100 From: i-barreira@izenpe.net To: stefan@aaa-sec.com, pkix@ietf.org Message-id: <763539E260C37C46A0D6B340B5434C3B060ACC95@AEX06.ejsarea.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Content-class: urn:content-classes:message Thread-topic: Straw-poll on OCSP responses for non-revoked certificates. Thread-index: Ac22jn09CZenYIcCSJCkjoQfD+NaDQAxcpww X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 31 Oct 2012 10:51:54.0678 (UTC) FILETIME=[BDB9B560:01CDB755] Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked certificates. X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 10:51:59 -0000 Hi, If the CA does not know the certificate has been issued, for some = reasons explained here, the OCSP should respond "good", once is revoked, = should respond "revoked". How to automate the response that the = certificate that has been issued shouldn=B4t have ever been issued, so = in my opinion, the key question is not how the OCSP should respond, the = key question is that this option cannot ever happen and then, you can = trust on the OCSP responder. If we choose revoked for a "non issued" certificate, would mean that you = know somehow that the CA has been compromised somehow and then you have = to revoke the certificate, so a new CRL is created and the response of = the OCSP is reliable If we choose option 3, "unknown" you rely on a third party to decide = whether trust or not on you certificate and your OCSP response, so in my = opinion, this is not good for the CA nor for the RP because some can = trust and some others not. Option 2 should be the "right" answer but being the right answer will = put someone in danger because of a "rogue" certificate if the CA has = been compromised. So, as said, I think the key question should be another not about the = OCSP responder. In any case, and for the record (and the poll) I prefer option 1 for = security reasons, just in case. At least I don=B4t give a positive false = answer and wouldn=B4t let RP take the decission for me wether I=B4m a = trustable CA or not. Regards I=F1igo Barreira Responsable del =C1rea t=E9cnica i-barreira@izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta = egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada = (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, = korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial = a la que solo tiene derecho a acceder el destinatario. Si usted lo = recibe por error le agradeceriamos que no hiciera uso de la informacion = y que se pusiese en contacto con el remitente. -----Mensaje original----- De: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] En nombre de = Stefan Santesson Enviado el: martes, 30 de octubre de 2012 10:53 Para: pkix@ietf.org Asunto: [pkix] Straw-poll on OCSP responses for non-revoked = certificates. Before we loose everyone engaged in this, I would like to make a straw-poll: Background: A client may do a request for a certificate that has never been issued = by the CA. This request may be done deliberately, by mistake or as a consequence of = a compromised CA. The OCSP protocol does not require OCSP responders to have any knowledge = about issued certificates. It must only know about revoked certificates = that are within it's current validity period. However, some OCSP = responders closely coupled with the CA may also know if a certificate = with a particular serialNumber value has been issued or not. The following is agreed: - An OCSP responder is allowed to respond "good" to a status request = for a non-revoked certificate, disregarding if it has ever been issued. - A client, having no additional out-of-band knowledge about the OCSP = responder, will just know that the certificate is "not revoked" when = receiving a "good" response, unless the response includes one or more = response extensions that provides additional information. The following is debated: - Is an OCSP responder allowed to respond "revoked" even if a = requested certificate serial number is not on the list of revoked = certificates, IF the OCSP responder has positive knowledge that the = requested serial number does NOT represent a valid certificate issued by = the identified CA? Rationale for: There are a number of reasons to allow this that has been mentioned, = such as: - It breaks nothing. A legitimate request for an issued certificate = will get a legitimate deterministic response. - It's safer. Responding "revoked" may not prevent a compromised CA = from being exploited. But if a request for a serialNumber that is known = to be bad is done nevertheless, a "revoked" response will at least be = safer than responding "good". - Allowing extension definitions with further semantics. A response = extension may be defined in the future that adds more information about = the requested certificate. This may include a positive confirmation that = the certificate has been issued as well as information that this = particular OCSP responder will only respond "good" if it knows that the = requested certificate has been issued, otherwise it will respond = "revoked". An extension with such semantics can only be defined if the = base standard allows a status other than "good" in such situation. - Supporting Web-PKI. The CAB-Forum has indicated that they will = profile the OCSP protocol for use with web server authentication. In = such profile they have indicated that they will NOT allow the "good" = response unless the requested certificate is known to have been issued. = This means that they will require OCSP responder in their infrastructure = to have this knowledge. Such profile would have to break the base OCSP = standard if this states that "good" MUST be returned unless the = certificate has been revoked. Rationale against: The basic rationale against raised on this list has been the argument = that it is wrong and confusing to allow anything but "good" as a = response to a non-revoked certificate (if the cert is issued by a CA = that is served by this OCSP responder). Another strong opinion is that it basically does not solve anything. A = broken CA is broken and can't be fixed by responding "revoked". It would = be easy to adapt an attack to circumvent such response, for example by = issuing a fake certificate that duplicates a legitimate serialNumber. Please reply with either: 1. Allow "revoked" response for a certificate that has not been = "revoked" but where that OCSP responder for any other reason knows the certificate = to be "bad". 2. Require that the OCSP responder MUST respond "good" in this = situation. 3. Neither 1 or 2 (motivate). Note: both alternatives are placed in a context where the certificate is = claimed to be issued by a CA that is served by this OCSP responder. The = exact meaning of "bad" is for later discussion. Please keep any motivation short and do not use this thread for long = debates. =20 _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From denis.pinkas@bull.net Wed Oct 31 04:46:44 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 490AC21F86A6 for ; Wed, 31 Oct 2012 04:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfJK9x3OHYpC for ; Wed, 31 Oct 2012 04:46:43 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 2098621F8511 for ; Wed, 31 Oct 2012 04:46:43 -0700 (PDT) Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id 9D7491C5B1 for ; Wed, 31 Oct 2012 12:46:41 +0100 (CET) Received: from [127.0.0.1] ([129.184.39.15]) by MSGC-007.bull.fr (Lotus Domino Release 8.5.3FP1) with ESMTP id 2012103112464051-6140 ; Wed, 31 Oct 2012 12:46:40 +0100 Message-ID: <50910F9E.6000703@bull.net> Date: Wed, 31 Oct 2012 12:46:38 +0100 From: Denis Pinkas User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: pkix@ietf.org References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 31/10/2012 12:46:40, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 31/10/2012 12:46:41, Serialize complete at 31/10/2012 12:46:41 X-TNEFEvaluated: 1 Content-Type: multipart/alternative; boundary="------------080101090604090301060306" Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked certificates. X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 11:46:44 -0000 This is a multi-part message in MIME format. --------------080101090604090301060306 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed Response #3 : status : unknown Response #1 would also be acceptable, but as a second choice. Quick explanation: "unknown" is the right status. If the OCSP client verifies that the response is from an authorized responder for the CA which has issued the certificate: unknown is a definite response and is safe (no other mechanism SHALL be used). On the contrary, if the OCSP client does not verify that the response is from an authorized responder for the CA which has issued the certificate, then another mechanism will be used : either another OCSP server or CRLs. If CRLs are used, "revoked" is safer, but it is semantically incorrect. So a change in its semantics would be mandatory. The problem is that the change should be "revoked or unknown" which may be rather confusing. --------------080101090604090301060306 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=ISO-8859-1

Response #3 : status : unknown

 

Response #1 would also be acceptable, but as a second choice.

 

Quick explanation: “unknown” is the right status.


If the OCSP client verifies that the response is from an authorized responder for the CA which has issued the certificate:
unknown is a definite response and is safe (no other mechanism SHALL be used).

 

On the contrary, if the OCSP client does not verify that the response is from an authorized responder for the CA which has
issued the certificate, then another mechanism will be used : either another OCSP server or CRLs.


If CRLs are used, “revoked” is safer, but it is semantically incorrect. So a change in its semantics would be mandatory.

The problem is that the change should be "revoked or unknown" which may be rather confusing.

--------------080101090604090301060306-- From aallison@nab.org Wed Oct 31 07:39:48 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA5E21F87CA for ; Wed, 31 Oct 2012 07:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.9 X-Spam-Level: X-Spam-Status: No, score=-5.9 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgbPRWAZPV2B for ; Wed, 31 Oct 2012 07:39:46 -0700 (PDT) Received: from p01c11o149.mxlogic.net (p01c11o149.mxlogic.net [208.65.144.72]) by ietfa.amsl.com (Postfix) with ESMTP id 80A3821F8696 for ; Wed, 31 Oct 2012 07:39:38 -0700 (PDT) Received: from unknown [208.97.234.91] by p01c11o149.mxlogic.net(mxl_mta-6.15.0-1) with SMTP id 92831905.0.2667.00-115.12030.p01c11o149.mxlogic.net (envelope-from ); Wed, 31 Oct 2012 08:39:40 -0600 (MDT) X-MXL-Hash: 5091382c35884c7f-c93d0e1ea0bb0a7b2bd854485722b557df26b18d X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CDB775.794CFB74" Date: Wed, 31 Oct 2012 10:39:03 -0400 Message-ID: <71C9EC0544D1F64D8B7D91EDCC6220200CA724BB@NABSREX027324.NAB.ORG> In-Reply-To: <50910F9E.6000703@bull.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] Straw-poll on OCSP responses for non-revokedcertificates. Thread-Index: Ac23XWgPWVBIDMW0QkeKBhfQxULK5gAF7QsQ References: <50910F9E.6000703@bull.net> From: "Art Allison" To: X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [208.97.234.91] X-AnalysisOut: [v=2.0 cv=N9ye4RBB c=1 sm=0 a=tFGTPFZixTZ3yCXJchW01Q==:17 a] X-AnalysisOut: [=uM5-4mTEQPIA:10 a=BvPfnLs-15kA:10 a=BLceEmwcHowA:10 a=g0F] X-AnalysisOut: [pLpFZAAAA:8 a=ealCiPDQX5oA:10 a=48vgC7mUAAAA:8 a=xb3ZzoUmr] X-AnalysisOut: [ISC49vhtYEA:9 a=CjuIK1q_8ugA:10 a=8SgyfJxrfqYA:10 a=-9UqKS] X-AnalysisOut: [le32gA:10 a=Qd0007q6B0YA:10 a=lZB815dzVvQA:10 a=WcsbDWfkIe] X-AnalysisOut: [Ed9LKv:21 a=FU76A4KtoyhD5ZZr:21 a=yMhMjlubAAAA:8 a=SSmOFEA] X-AnalysisOut: [CAAAA:8 a=C2K8goYC9anXxbzR9uwA:9 a=gKO2Hq4RSVkA:10 a=UiCQ7] X-AnalysisOut: [L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=3L4fmkktL] X-AnalysisOut: [Sgu9vw3:21 a=RQIynhwX5I0Qbv1a:21 a=cZeU5guVsksz7qoj:21] Subject: Re: [pkix] Straw-poll on OCSP responses for non-revokedcertificates. X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 14:39:48 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CDB775.794CFB74 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am ok with the choice others suggested for option 3 - add new optional response value =3D Unknown. =20 =20 Art Allison=20 Senior Director Advanced Engineering, Technology=20 National Association of Broadcasters 1771 N Street NW Washington, DC 20036 Phone 202 429 5418 Fax 202 775 4981=20 www.nab.org =20 Advocacy Education Innovation=20 =20 From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Denis Pinkas Sent: Wednesday, October 31, 2012 7:47 AM To: pkix@ietf.org Subject: Re: [pkix] Straw-poll on OCSP responses for non-revokedcertificates. =20 Response #3 : status : unknown =20 Response #1 would also be acceptable, but as a second choice. =20 Quick explanation: "unknown" is the right status.=20 If the OCSP client verifies that the response is from an authorized responder for the CA which has issued the certificate:=20 unknown is a definite response and is safe (no other mechanism SHALL be used). =20 On the contrary, if the OCSP client does not verify that the response is from an authorized responder for the CA which has=20 issued the certificate, then another mechanism will be used : either another OCSP server or CRLs.=20 If CRLs are used, "revoked" is safer, but it is semantically incorrect. So a change in its semantics would be mandatory. The problem is that the change should be "revoked or unknown" which may be rather confusing. ------_=_NextPart_001_01CDB775.794CFB74 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am ok with = the choice others suggested for option 3 – add new optional = response value =3D Unknown.  

 

Art Allison
Senior Director Advanced Engineering, Technology
National Association of Broadcasters
1771 N Street NW
Washington, = DC 20036
Phone  202 429 5418
Fax  202 775 = 4981
www.nab.org
Advocacy  Education  Innovation

 

From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf = Of Denis Pinkas
Sent: Wednesday, October 31, 2012 7:47 = AM
To: pkix@ietf.org
Subject: Re: [pkix] Straw-poll = on OCSP responses for = non-revokedcertificates.

 

Response #3 : = status : unknown

 

Response #1 = would also be acceptable, but as a second = choice.

 

Quick = explanation: “unknown” is the right status. =


If the OCSP = client verifies that the response is from an authorized responder for = the CA which has issued the certificate:
unknown is a definite = response and is safe (no other mechanism SHALL be = used).

 

On the contrary, = if the OCSP client does not verify that the response is from an = authorized responder for the CA which has
issued the certificate, = then another mechanism will be used : either another OCSP server or = CRLs.


If CRLs are = used, “revoked” is safer, but it is semantically incorrect. = So a change in its semantics would be mandatory.

The problem is that the = change should be "revoked or unknown" which may be rather = confusing.

------_=_NextPart_001_01CDB775.794CFB74-- From ryan.hurst@globalsign.com Wed Oct 31 07:42:28 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA47E21F880E for ; Wed, 31 Oct 2012 07:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Z4WHAM0P1A6 for ; Wed, 31 Oct 2012 07:42:27 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2B321F87F6 for ; Wed, 31 Oct 2012 07:42:27 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fb11so1020904pad.31 for ; Wed, 31 Oct 2012 07:42:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=globalsign.com; s=google; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=lrykpbORj45bHoFNGdlCXugL+zD/T2T1kdy5gSoYTRw=; b=Ug7MMCulfsfH+ofcZc0dDPh4iiTsQJhgvNRczVRireIXha1/dRePjhad9u8WVgZkZC CQirxyP+9Nu/a3kftjM030C5+enVrANURa3dWb8hGu7ymY60q91k0rGgWm22pDkzk2vg gUYfWjaHW5n2zKVQbG/yoH3SOpE56h0XDVaXM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=lrykpbORj45bHoFNGdlCXugL+zD/T2T1kdy5gSoYTRw=; b=im0Z2hYhZ3dxqlsoSgX6Sw1zcbCr2oDIX6gMhv2z8Cli0bz/WdXjRXMJq1WDq8weQh YrKQK97GZVw6C4S+SPD2dcepoEAu7PN9I1OTPp+p7B52wB/J8T0P2fIQCEXpOKK1rqR1 vfu2zq4+U3fQdpFDfoAQO5bnMKGemoj88HMzPy7fUFnagCUUuAKdQ5N9cB/BF50PuqIL DcRNJ6hxzlrD5bJL+RqbFFtUzJoyVsqVWvHmJZYpBBFE7Apj65vqnCxfNq7A1RSV7GvG UrV2AKT/wy/5A+bv0YarntYdVb8+54AWA523kYNBrq1z7cv5x01H7ItEcy1/32m6LDL+ fmlw== Received: by 10.66.80.66 with SMTP id p2mr102302074pax.84.1351694546855; Wed, 31 Oct 2012 07:42:26 -0700 (PDT) Received: from [10.162.5.112] (mobile-166-147-083-089.mycingular.net. [166.147.83.89]) by mx.google.com with ESMTPS id ph7sm952787pbb.9.2012.10.31.07.42.24 (version=SSLv3 cipher=OTHER); Wed, 31 Oct 2012 07:42:25 -0700 (PDT) References: <50910F9E.6000703@bull.net> Mime-Version: 1.0 (1.0) In-Reply-To: <50910F9E.6000703@bull.net> Content-Type: multipart/alternative; boundary=Apple-Mail-ECB7D4B5-8ABE-4533-9202-F2DDE393B0E9 Content-Transfer-Encoding: 7bit Message-Id: <4C120EAB-B95B-4DEE-8DE7-9CDC45089C34@globalsign.com> X-Mailer: iPhone Mail (10A403) From: Ryan Hurst Date: Wed, 31 Oct 2012 07:42:22 -0700 To: Denis Pinkas X-Gm-Message-State: ALoCoQk1DsH+nEvdFoHFEfH+MboQ9mEXpafIEWk/V2aVw/vbLlpl0j/j0qjgwO0SXUOvNGryZ+U9 Cc: "pkix@ietf.org" Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked certificates. X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 14:42:28 -0000 --Apple-Mail-ECB7D4B5-8ABE-4533-9202-F2DDE393B0E9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Same as Dennis. Sent from my iPhone On Oct 31, 2012, at 4:46 AM, Denis Pinkas wrote: > Response #3 : status : unknown > =20 > Response #1 would also be acceptable, but as a second choice. > =20 > Quick explanation: =E2=80=9Cunknown=E2=80=9D is the right status.=20 >=20 > If the OCSP client verifies that the response is from an authorized respon= der for the CA which has issued the certificate:=20 > unknown is a definite response and is safe (no other mechanism SHALL be us= ed). > =20 > On the contrary, if the OCSP client does not verify that the response is f= rom an authorized responder for the CA which has=20 > issued the certificate, then another mechanism will be used : either anoth= er OCSP server or CRLs.=20 >=20 > If CRLs are used, =E2=80=9Crevoked=E2=80=9D is safer, but it is semantical= ly incorrect. So a change in its semantics would be mandatory. > The problem is that the change should be "revoked or unknown" which may be= rather confusing. > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --Apple-Mail-ECB7D4B5-8ABE-4533-9202-F2DDE393B0E9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Same as Dennis.

Sent from my iP= hone

On Oct 31, 2012, at 4:46 AM, Denis Pinkas <denis.pinkas@bull.net> wrote:

=20 =20 =20

Response #3 : status&nb= sp;: unknown

 

=

Response #1 would also be acceptable, but as a second choice.

 

Quick explanation: =E2=80=9Cunknown=E2=80=9D is the right status.


If the OCSP client verifies that the response is from an authorized responder for the= CA which has issued the certificate:
unknown is a definite response and is safe (no other mechanism SHALL be used).<= /font>

 

On the contrary, if the OCSP client does not verify that the response is from an authorized responder for the CA which has
issued the certificate, then another mechanism will be used : either another OCSP server or CRLs.


If CRLs are used, =E2=80=9Crevoked=E2=80=9D is safer, but it is se= mantically incorrect. So a change in its semantics would be mandatory.

The problem is that the change should be "revoked or unknown" which may be rather confusing.

=20
____________________= ___________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman= /listinfo/pkix
= --Apple-Mail-ECB7D4B5-8ABE-4533-9202-F2DDE393B0E9-- From ben@digicert.com Wed Oct 31 08:35:54 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C6621F8792 for ; Wed, 31 Oct 2012 08:35:54 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CS81iQJUHb6c for ; Wed, 31 Oct 2012 08:35:53 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA8721F8716 for ; Wed, 31 Oct 2012 08:35:43 -0700 (PDT) Received: from BWILSONL1 (unknown [64.78.193.228]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id C9B937FC05F for ; Wed, 31 Oct 2012 09:35:42 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1351697742; bh=dyHhNpYsaX5kwnEJfdKP2EdALsNTM8eL3gGpBdYRnTw=; h=Reply-To:From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=VqlEHQ8Im8JSSyVckdbew37FtYcplApEuNdbOcjnVDeZtZARfafghDnWMj4G2kZu7 Xxv/lXK5lH9BehjsLRSO776f/d51RLE1x1jtkMmwN8H4fdp9+L5+P+x1ngWyIpIhhN 25R7lOqQpe+BGsw/VqSfotoRVWoHWbbLSzwlvWIQ= From: "Ben Wilson" To: References: <50910F9E.6000703@bull.net> <4C120EAB-B95B-4DEE-8DE7-9CDC45089C34@globalsign.com> In-Reply-To: <4C120EAB-B95B-4DEE-8DE7-9CDC45089C34@globalsign.com> Date: Wed, 31 Oct 2012 09:35:40 -0600 Organization: DigiCert Message-ID: <00b701cdb77d$61d29c80$2577d580$@digicert.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B8_01CDB74B.1738EFD0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH1lk8JvbcDsEaFAmhBI+dpk+GPywH7Y6+AAkWmwayXYcTjMA== Content-Language: en-us Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked certificates. X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ben@digicert.com List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 15:35:54 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00B8_01CDB74B.1738EFD0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I don=E2=80=99t think the original ballot changed. #1 was to allow = revoked. #3 was do nothing. So, a vote that they favor =E2=80=9C3 = =E2=80=93 unknown=E2=80=9D is out of scope, but hopefully everyone = understands that this is the nature of a straw poll? =20 From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of = Ryan Hurst Sent: Wednesday, October 31, 2012 8:42 AM To: Denis Pinkas Cc: pkix@ietf.org Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked = certificates. =20 Same as Dennis. Sent from my iPhone On Oct 31, 2012, at 4:46 AM, Denis Pinkas wrote: Response #3 : status : unknown =20 Response #1 would also be acceptable, but as a second choice. =20 Quick explanation: =E2=80=9Cunknown=E2=80=9D is the right status.=20 If the OCSP client verifies that the response is from an authorized = responder for the CA which has issued the certificate:=20 unknown is a definite response and is safe (no other mechanism SHALL be = used). =20 On the contrary, if the OCSP client does not verify that the response is = from an authorized responder for the CA which has=20 issued the certificate, then another mechanism will be used : either = another OCSP server or CRLs.=20 If CRLs are used, =E2=80=9Crevoked=E2=80=9D is safer, but it is = semantically incorrect. So a change in its semantics would be mandatory. The problem is that the change should be "revoked or unknown" which may = be rather confusing. _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix ------=_NextPart_000_00B8_01CDB74B.1738EFD0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I don=E2=80=99t think the original ballot changed.=C2=A0 #1 was to = allow revoked.=C2=A0 #3 was do nothing.=C2=A0 So, a vote that they favor = =E2=80=9C3 =E2=80=93 unknown=E2=80=9D is out of scope, but hopefully = everyone understands that this is the nature of a straw = poll?

 

From:= = pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of = Ryan Hurst
Sent: Wednesday, October 31, 2012 8:42 = AM
To: Denis Pinkas
Cc: = pkix@ietf.org
Subject: Re: [pkix] Straw-poll on OCSP responses = for non-revoked certificates.

 

Same as = Dennis.

Sent from my iPhone


On Oct 31, 2012, at = 4:46 AM, Denis Pinkas <denis.pinkas@bull.net> = wrote:

Response #3 : = status : unknown

 

Response #1 = would also be acceptable, but as a second = choice.

 

Quick = explanation: =E2=80=9Cunknown=E2=80=9D is the right status. =


If the OCSP = client verifies that the response is from an authorized responder for = the CA which has issued the certificate:
unknown is a definite = response and is safe (no other mechanism SHALL be = used).

 

On the contrary, = if the OCSP client does not verify that the response is from an = authorized responder for the CA which has
issued the certificate, = then another mechanism will be used : either another OCSP server or = CRLs.


If CRLs are = used, =E2=80=9Crevoked=E2=80=9D is safer, but it is semantically = incorrect. So a change in its semantics would be = mandatory.

The problem is that the = change should be "revoked or unknown" which may be rather = confusing.

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

<= /html> ------=_NextPart_000_00B8_01CDB74B.1738EFD0-- From eabalea@gmail.com Wed Oct 31 09:30:33 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C006421F858E for ; Wed, 31 Oct 2012 09:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TAX8e5w4ObSE for ; Wed, 31 Oct 2012 09:30:33 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id DFCAC21F8567 for ; Wed, 31 Oct 2012 09:30:27 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so1322488lbo.31 for ; Wed, 31 Oct 2012 09:30:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=/z1w1owVHImUR5J7x7gXLWsoO3/1tuT9loDuJNHv6h4=; b=Oy77Adwm4UwSvuG7S5u/MDexFIS1dIBeR7kzkMzIrTmHIRpybsQdg5KGepYhBvfkmA UnhO3dCbM0+SK4BBVXnIwa3oe+6cSAHpP9siHevmoypfrh/8AXv8L2qgFw+72BvSgTKd tamtJp11MqUItUdVWCHIcmZYA846rprwZxVSFvenn86R8tJpGkNGFrLO0a0hgwNXRL8/ 0cCb+yRDERY24v54DFAS1jssZe1cIntXYBzFpOBchRX9SW9G1gVEol/XMSkU9+Z7U3LR ihQbthqhicLdFC5sJJoXlDwqRXgvLlX84rX+oKfhLXNsdjMxhQVTmJGIIg+0+ohmmOrp G4Bg== MIME-Version: 1.0 Received: by 10.152.105.236 with SMTP id gp12mr34458067lab.35.1351701026891; Wed, 31 Oct 2012 09:30:26 -0700 (PDT) Received: by 10.114.25.74 with HTTP; Wed, 31 Oct 2012 09:30:26 -0700 (PDT) In-Reply-To: <00b701cdb77d$61d29c80$2577d580$@digicert.com> References: <50910F9E.6000703@bull.net> <4C120EAB-B95B-4DEE-8DE7-9CDC45089C34@globalsign.com> <00b701cdb77d$61d29c80$2577d580$@digicert.com> Date: Wed, 31 Oct 2012 17:30:26 +0100 Message-ID: From: Erwann Abalea To: ben@digicert.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: pkix@ietf.org Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked certificates. X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 16:30:33 -0000 #3 is "neither 1 or 2 (motivate)". It can be fulfilled by anything else. 2012/10/31 Ben Wilson : > I don=E2=80=99t think the original ballot changed. #1 was to allow revok= ed. #3 was > do nothing. So, a vote that they favor =E2=80=9C3 =E2=80=93 unknown=E2= =80=9D is out of scope, but > hopefully everyone understands that this is the nature of a straw poll? --=20 Erwann. From piyush@ditenity.com Wed Oct 31 09:41:56 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF9B721F8713 for ; Wed, 31 Oct 2012 09:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZzTH73JtS5Y for ; Wed, 31 Oct 2012 09:41:56 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1603321F870F for ; Wed, 31 Oct 2012 09:41:56 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so2704120iec.31 for ; Wed, 31 Oct 2012 09:41:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=hMKZgGo1u+Q83qDgHPDFpOUv3FzyRghF6R7g7vmPRVA=; b=Bq/ynF8c/QFTQMdM8T+ByudsYZ4HA1jIv7MZAML+Z/VzQQ301bvf1SmqBEBGgmTxcG UYj5z9kqNn1RNWMP2Mhaf5+gwOd2aOJQOGWtbhx2paVA+g9PUrI2QZcbp6TmExq/tKDJ Y1hp9ucAoVs17EeBjn00wCbnYwvVtDb+OnAeAdg8hJ0LAkvK3Mm91lqdDpY6Qn+A6T0t eW2jjId0d8bqqmBCER3v+LxeO9tWBdvMYGlQmSp7GcN/2ZkUeJT5j70t0ddzfAVaFkYz psMOFN049IGlXXx/VPbH4t8LtpTsNqqtirucDc2wjwwEP00jAaCfTGzaLZ4R6zYoH9LF Aq7g== Received: by 10.50.236.6 with SMTP id uq6mr2196225igc.50.1351701715577; Wed, 31 Oct 2012 09:41:55 -0700 (PDT) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id s20sm3515987igs.10.2012.10.31.09.41.53 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 31 Oct 2012 09:41:54 -0700 (PDT) From: "Piyush Jain" To: , "'Miller, Timothy J.'" References: <195DB2510AAA004391F58E28FCE21200066E1E15@IMCMBX01.MITRE.ORG> <20121030204721.E00241A311@ld9781.wdf.sap.corp> In-Reply-To: <20121030204721.E00241A311@ld9781.wdf.sap.corp> Date: Wed, 31 Oct 2012 09:41:51 -0700 Message-ID: <011901cdb786$a24f7770$e6ee6650$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-index: AQKSyAb371GiNyHa1uzfV8CWB+vJNZZJcT5w Content-Language: en-us X-Gm-Message-State: ALoCoQmiuywGB3eWGTuWkNB2EHfGkrM1gHcaOhmfnip5p3pElVCDCCcBDJo+hhJ7+K6vnOYF6IIj Cc: pkix@ietf.org, 'Stefan Santesson' Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 16:41:57 -0000 > -----Original Message----- > From: Martin Rex [mailto:mrex@sap.com] > Sent: Tuesday, October 30, 2012 1:47 PM > To: Miller, Timothy J. > Cc: mrex@sap.com; Piyush Jain; pkix@ietf.org; 'Stefan Santesson' > Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 > > Miller, Timothy J. wrote: > > > > > X.509/PKIX is defective because it breaks badly already on > > > fraudulent cert issuance (a weaker form of CA compromise) and can > > > not cope at all with CA key compromise. > > > > Do you have an alternative to the technology, because AFAICT, no PKI > > standards recover well from a breach of trust. > > The design flaw of PKI is that all CA keys are single points of failure. There is a > complete lack of backup if one fails, or can be made to fail. > > Designing a technology with complete lack of a backup system seems like a > bad idea to me. Like skydiving with only one single parachute, or designing a > large commercial passenger jet with just a single turbo-fan engine > (something which FAA might refuse to certify for good reasons). > [Piyush] Technology is what it is. You can always design you system that uses the technology in a way that makes it fault tolerant. In your example above engine is the technology and jet is the system. You can always have a system where you provide secondary method for authentication (may be certs issued of a bakup CA) while you recover from main CA compromise. > > The fact that _no_ existing PKI standards provide backup facilities today is a > mere technical defect that _could_ be fixed. > > > > > > > Even the web of trust has issues; if a well-connected introducer is > > compromised, all descendent keys become suspect--which can potentially > > encompass all nodes in the graph. This can be as devestating as a CA > > compromise, and would likewise require a re-execution of a large > > number of signing ceremonies. > > I beg to differ. > > When a well-connected introducer is newly compromised, then this does not > affect any trust relationships previously confirmed by that introducer, only > precludes adoption of trust for new relationships. > > When a well-connected introducer turns out to have been never been trust- > worthy, it affects only those trust relationships where he is the _only_ > introducer (same effect as in single-key PKI models). > > > > > > > The flaw with CRLs and OCSP is that it tries to infer, from a lack > > > of a revocation, that a certificate has been properly issued and is valid. > > > Evidently, this turned out to be a logical fallacy with respect to > > > real world usage scenarios. > > [Piyush] Why call it a flaw. My car does not have a flaw just because it cannot fly. OCSP and CRLs make simple statement - Is the certificate in question revoked by the issuing authority, nothing more, and nothing less. If you want more out of you server, deploy SCVP. What real world usage scenario? My car fell off the cliff. It would've been nice if it could fly, but unfortunately my poor driving habits (or faulty brakes in my car) are no reason to change the design of cars. The scenarios that you mention are exceptions rather than norms. > > Absent a trusted observer, there is no positive statement that can be > > issued by a CA that positively identifies only "valid" certificates. > > Given a trusted observer, why not make him the CA and be done with it? > > > Maybe because PKI(X) should be more about real-wold PKIs, and less about > Utopia. > > Why should businesses and banks deal with accounting, audits and fraud > prevention, if they could simply use a system where fraud is impossible. As it > turns out, it is impossible to create and run a "system where fraud is > impossible" in the real world (even if they wanted to), especially at a cost- > level where business operation makes sense. So the second best approach > is a security trade-off, a system that makes business sense and can cope > reasonably with common real-world _operational_ problems, like software > being subject to bugs and staff being susceptible to social engineering, > bribery and threat/coercion. > > > I could imagine why crooks, hackers and certain agencies might not like > a backup scheme that makes subverting the PKI significantly harder. > But why should an engineer, and in particular one who understands and > cares about security, oppose addition of a backup scheme to address > the susceptibility of X.509 PKI to operational problems and risks > from the pesky (physical) real world? > [Piyush] Crooks would actually love the schemes that are being proposed here. Let the victims continue to operate with the illusion of security. Your argument would've been meaningful in this discussion if - trust model is changes so that RP trusts the responder and CA independently (CA compromise should not imply responder compromise) - OCSP is the only way to check revocation status of the certificate. (RPs should not arrive at different conclusion if the use CRLs instead of OCSP) But I've not seen above being recommended in any of the proposals. And I think the reason is obvious. You can deploy SCVP in DPV mode to address the points that you raised above. > > -Martin From aallison@nab.org Wed Oct 31 11:15:39 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6934E21F8868 for ; Wed, 31 Oct 2012 11:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYBQBPtNIhWa for ; Wed, 31 Oct 2012 11:15:38 -0700 (PDT) Received: from p01c11o145.mxlogic.net (p01c11o145.mxlogic.net [208.65.144.68]) by ietfa.amsl.com (Postfix) with ESMTP id 2970621F888B for ; Wed, 31 Oct 2012 11:15:31 -0700 (PDT) Received: from unknown [208.97.234.91] (EHLO NABSREX027324.NAB.ORG) by p01c11o145.mxlogic.net(mxl_mta-6.15.0-1) with ESMTP id 2ca61905.0.13758.00-319.33344.p01c11o145.mxlogic.net (envelope-from ); Wed, 31 Oct 2012 12:15:32 -0600 (MDT) X-MXL-Hash: 50916ac43597bc09-b5b11f3d274c1c747af1da36ef6c6159032a5b3b X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CDB793.B5ED130A" Date: Wed, 31 Oct 2012 14:15:30 -0400 Message-ID: <71C9EC0544D1F64D8B7D91EDCC6220200CA725BD@NABSREX027324.NAB.ORG> In-Reply-To: <00b701cdb77d$61d29c80$2577d580$@digicert.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [pkix] Straw-poll on OCSP responses fornon-revoked certificates. Thread-Index: AQH1lk8JvbcDsEaFAmhBI+dpk+GPywH7Y6+AAkWmwayXYcTjMIAAK0GA References: <50910F9E.6000703@bull.net><4C120EAB-B95B-4DEE-8DE7-9CDC45089C34@globalsign.com> <00b701cdb77d$61d29c80$2577d580$@digicert.com> From: "Art Allison" To: X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [208.97.234.91] X-AnalysisOut: [v=2.0 cv=Y/pPRGiN c=1 sm=0 a=tFGTPFZixTZ3yCXJchW01Q==:17 a] X-AnalysisOut: [=ISpR88XC1-QA:10 a=BvPfnLs-15kA:10 a=BLceEmwcHowA:10 a=g0F] X-AnalysisOut: [pLpFZAAAA:8 a=ealCiPDQX5oA:10 a=48vgC7mUAAAA:8 a=R93Jy7f2A] X-AnalysisOut: [AAA:8 a=1ce2OFdlJGcH_mduuQMA:9 a=QEXdDO2ut3YA:10 a=8SgyfJx] X-AnalysisOut: [rfqYA:10 a=-9UqKSle32gA:10 a=Qd0007q6B0YA:10 a=lZB815dzVvQ] X-AnalysisOut: [A:10 a=O16jHPwEaCsA:10 a=Xst4EYqqeAMlhu9J:21 a=3CqetUEhMF3] X-AnalysisOut: [xFuuR:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=-7lmGnbMd0Gsx] X-AnalysisOut: [9hNXrgA:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K] X-AnalysisOut: [0A:10 a=frz4AuCg-hUA:10 a=0fFHKXHiQ9QxBp5c:21 a=LCkIwZW6E8] X-AnalysisOut: [PTQmGl:21 a=Ml2Iap5TzBBK9BQq:21] Subject: Re: [pkix] Straw-poll on OCSP responses fornon-revoked certificates. X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 18:15:39 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CDB793.B5ED130A Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SSBhbnN3ZXJlZCB0aGUgYWN0dWFsIHF1ZXN0aW9uIGFza2VkLiAoSSBkbyBub3Qgb3BpbmUgb24g d2hhdCBtaWdodCBoYXZlIGJlZW4gaW50ZW5kZWQgdG8gYmUgYXNrZWQuKQ0KDQogDQoNCklmIHRo ZSBjdXJyZW50IHNjb3BlIHByZXZlbnRzIGZpeGluZyB0aGUgc2l0dWF0aW9uLCBleHBlY3QgbGFj ayBvZiBpbnRlcm9wZXJhYmlsaXR5IHRvIGNvbnRpbnVlLiANCg0KQ2hhbmdpbmcgdGhlIHNjb3Bl IGhhcyBhIHRpbWUgbGluZSBhbmQsIHByb3Blcmx5LCBzaG91bGQgYmUganVzdGlmaWVkLg0KDQpV c2luZyB0aGUgc2NvcGUgdG8gaWdub3JlIGEgcHJvYmxlbSBoYXMgYmVlbiBkb25lIG1hbnkgdGlt ZXMgaW4gdGhlIHBhc3QsIG5vdCBqdXN0IGluIElFVEYgYnV0IGVsc2V3aGVyZS4gIENvbnRyYXN0 IHdpdGggYWxsb3dpbmcgc2NvcGUgY3JlZXAgd2hpY2ggcHJldmVudHMgdGltZWx5IHJlc29sdXRp b24gb2YgYSBwcm9ibGVtLiAgQ2hvb3NlIGNhcmVmdWxseS4NCg0KIA0KDQpBcnQNCg0KIA0KDQpB cnQgQWxsaXNvbiANClNlbmlvciBEaXJlY3RvciBBZHZhbmNlZCBFbmdpbmVlcmluZywgVGVjaG5v bG9neSANCk5hdGlvbmFsIEFzc29jaWF0aW9uIG9mIEJyb2FkY2FzdGVycw0KMTc3MSBOIFN0cmVl dCBOVw0KV2FzaGluZ3RvbiwgREMgMjAwMzYNClBob25lICAyMDIgNDI5IDU0MTgNCkZheCAgMjAy IDc3NSA0OTgxIA0Kd3d3Lm5hYi5vcmcgPGJsb2NrZWQ6Omh0dHA6Ly93d3cubmFiLm9yZz4gIA0K QWR2b2NhY3kgIEVkdWNhdGlvbiAgSW5ub3ZhdGlvbiANCg0KIA0KDQpGcm9tOiBwa2l4LWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzpwa2l4LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBC ZW4gV2lsc29uDQpTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMzEsIDIwMTIgMTE6MzYgQU0NClRv OiBwa2l4QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3BraXhdIFN0cmF3LXBvbGwgb24gT0NTUCBy ZXNwb25zZXMgZm9ybm9uLXJldm9rZWQgY2VydGlmaWNhdGVzLg0KDQogDQoNCkkgZG9u4oCZdCB0 aGluayB0aGUgb3JpZ2luYWwgYmFsbG90IGNoYW5nZWQuICAjMSB3YXMgdG8gYWxsb3cgcmV2b2tl ZC4gICMzIHdhcyBkbyBub3RoaW5nLiAgU28sIGEgdm90ZSB0aGF0IHRoZXkgZmF2b3Ig4oCcMyDi gJMgdW5rbm93buKAnSBpcyBvdXQgb2Ygc2NvcGUsIGJ1dCBob3BlZnVsbHkgZXZlcnlvbmUgdW5k ZXJzdGFuZHMgdGhhdCB0aGlzIGlzIHRoZSBuYXR1cmUgb2YgYSBzdHJhdyBwb2xsPw0KDQogDQoN CkZyb206IHBraXgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnBraXgtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIFJ5YW4gSHVyc3QNClNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAzMSwg MjAxMiA4OjQyIEFNDQpUbzogRGVuaXMgUGlua2FzDQpDYzogcGtpeEBpZXRmLm9yZw0KU3ViamVj dDogUmU6IFtwa2l4XSBTdHJhdy1wb2xsIG9uIE9DU1AgcmVzcG9uc2VzIGZvciBub24tcmV2b2tl ZCBjZXJ0aWZpY2F0ZXMuDQoNCiANCg0KU2FtZSBhcyBEZW5uaXMuDQoNClNlbnQgZnJvbSBteSBp UGhvbmUNCg0KDQpPbiBPY3QgMzEsIDIwMTIsIGF0IDQ6NDYgQU0sIERlbmlzIFBpbmthcyA8ZGVu aXMucGlua2FzQGJ1bGwubmV0PiB3cm90ZToNCg0KCVJlc3BvbnNlICMzIDogc3RhdHVzIDogdW5r bm93bg0KDQoJIA0KDQoJUmVzcG9uc2UgIzEgd291bGQgYWxzbyBiZSBhY2NlcHRhYmxlLCBidXQg YXMgYSBzZWNvbmQgY2hvaWNlLg0KDQoJIA0KDQoJUXVpY2sgZXhwbGFuYXRpb246IOKAnHVua25v d27igJ0gaXMgdGhlIHJpZ2h0IHN0YXR1cy4gDQoNCgkNCglJZiB0aGUgT0NTUCBjbGllbnQgdmVy aWZpZXMgdGhhdCB0aGUgcmVzcG9uc2UgaXMgZnJvbSBhbiBhdXRob3JpemVkIHJlc3BvbmRlciBm b3IgdGhlIENBIHdoaWNoIGhhcyBpc3N1ZWQgdGhlIGNlcnRpZmljYXRlOiANCgl1bmtub3duIGlz IGEgZGVmaW5pdGUgcmVzcG9uc2UgYW5kIGlzIHNhZmUgKG5vIG90aGVyIG1lY2hhbmlzbSBTSEFM TCBiZSB1c2VkKS4NCg0KCSANCg0KCU9uIHRoZSBjb250cmFyeSwgaWYgdGhlIE9DU1AgY2xpZW50 IGRvZXMgbm90IHZlcmlmeSB0aGF0IHRoZSByZXNwb25zZSBpcyBmcm9tIGFuIGF1dGhvcml6ZWQg cmVzcG9uZGVyIGZvciB0aGUgQ0Egd2hpY2ggaGFzIA0KCWlzc3VlZCB0aGUgY2VydGlmaWNhdGUs IHRoZW4gYW5vdGhlciBtZWNoYW5pc20gd2lsbCBiZSB1c2VkIDogZWl0aGVyIGFub3RoZXIgT0NT UCBzZXJ2ZXIgb3IgQ1JMcy4gDQoNCgkNCglJZiBDUkxzIGFyZSB1c2VkLCDigJxyZXZva2Vk4oCd IGlzIHNhZmVyLCBidXQgaXQgaXMgc2VtYW50aWNhbGx5IGluY29ycmVjdC4gU28gYSBjaGFuZ2Ug aW4gaXRzIHNlbWFudGljcyB3b3VsZCBiZSBtYW5kYXRvcnkuDQoNCglUaGUgcHJvYmxlbSBpcyB0 aGF0IHRoZSBjaGFuZ2Ugc2hvdWxkIGJlICJyZXZva2VkIG9yIHVua25vd24iIHdoaWNoIG1heSBi ZSByYXRoZXIgY29uZnVzaW5nLg0KDQoJX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCglwa2l4IG1haWxpbmcgbGlzdA0KCXBraXhAaWV0Zi5vcmcNCglodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BraXgNCg0K ------_=_NextPart_001_01CDB793.B5ED130A Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KaDENCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgMSBDaGFyIjsNCgltYXJnaW4t dG9wOjI0LjBwdDsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1h cmdpbi1sZWZ0OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLWFkZC1zcGFjZTph dXRvOw0KCWZvbnQtc2l6ZToxNC4wcHQ7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJp ZiI7fQ0KaDEuQ3hTcEZpcnN0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1s aW5rOiJIZWFkaW5nIDEgQ2hhciI7DQoJbXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbWFy Z2luLXRvcDoyNC4wcHQ7DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsN CgltYXJnaW4tbGVmdDowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCW1zby1hZGQtc3Bh Y2U6YXV0bzsNCglmb250LXNpemU6MTQuMHB0Ow0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMt c2VyaWYiO30NCmgxLkN4U3BNaWRkbGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0 eWxlLWxpbms6IkhlYWRpbmcgMSBDaGFyIjsNCgltc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN CgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgltc28tYWRkLXNwYWNlOmF1 dG87DQoJZm9udC1zaXplOjE0LjBwdDsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm Ijt9DQpoMS5DeFNwTGFzdA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGlu azoiSGVhZGluZyAxIENoYXIiOw0KCW1zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCW1zby1hZGQtc3BhY2U6YXV0bzsNCglm b250LXNpemU6MTQuMHB0Ow0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO30NCmgy DQoJe21zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1saW5rOiJIZWFkaW5nIDIgQ2hh ciI7DQoJbWFyZ2luLXRvcDoxMC4wcHQ7DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90 dG9tOjBpbjsNCgltYXJnaW4tbGVmdDowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMy4wcHQ7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7fQ0KaDMN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgMyBDaGFy IjsNCgltYXJnaW4tdG9wOjEwLjBwdDsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0 b206MGluOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbGlu ZS1oZWlnaHQ6MTEyJTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJBcmlhbCIs InNhbnMtc2VyaWYiO30NCmg0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1s aW5rOiJIZWFkaW5nIDQgQ2hhciI7DQoJbWFyZ2luLXRvcDoxMC4wcHQ7DQoJbWFyZ2luLXJpZ2h0 OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwi c2Fucy1zZXJpZiI7DQoJZm9udC1zdHlsZTppdGFsaWM7fQ0KaDUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgNSBDaGFyIjsNCgltYXJnaW4tdG9wOjEw LjBwdDsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1s ZWZ0OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojN0Y3RjdGO30NCmg2DQoJ e21zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1saW5rOiJIZWFkaW5nIDYgQ2hhciI7 DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbGluZS1oZWlnaHQ6MTEy JTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiM3RjdGN0Y7DQoJZm9udC1zdHlsZTppdGFsaWM7fQ0KcC5Nc29IZWFkaW5nNywg bGkuTXNvSGVhZGluZzcsIGRpdi5Nc29IZWFkaW5nNw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTsN Cgltc28tc3R5bGUtbGluazoiSGVhZGluZyA3IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkFyaWFs Iiwic2Fucy1zZXJpZiI7DQoJZm9udC1zdHlsZTppdGFsaWM7fQ0KcC5Nc29IZWFkaW5nOCwgbGku TXNvSGVhZGluZzgsIGRpdi5Nc29IZWFkaW5nOA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTsNCglt c28tc3R5bGUtbGluazoiSGVhZGluZyA4IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwi c2Fucy1zZXJpZiI7fQ0KcC5Nc29IZWFkaW5nOSwgbGkuTXNvSGVhZGluZzksIGRpdi5Nc29IZWFk aW5nOQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoiSGVhZGluZyA5 IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQoJbGV0dGVyLXNw YWNpbmc6LjI1cHQ7DQoJZm9udC1zdHlsZTppdGFsaWM7fQ0KcC5Nc29UaXRsZSwgbGkuTXNvVGl0 bGUsIGRpdi5Nc29UaXRsZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6MTA7DQoJbXNvLXN0eWxlLWxp bms6IlRpdGxlIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CW1zby1hZGQtc3BhY2U6YXV0bzsNCglib3JkZXI6bm9uZTsNCglwYWRkaW5nOjBpbjsNCglmb250 LXNpemU6MjYuMHB0Ow0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWxldHRl ci1zcGFjaW5nOi4yNXB0O30NCnAuTXNvVGl0bGVDeFNwRmlyc3QsIGxpLk1zb1RpdGxlQ3hTcEZp cnN0LCBkaXYuTXNvVGl0bGVDeFNwRmlyc3QNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjEwOw0KCW1z by1zdHlsZS1saW5rOiJUaXRsZSBDaGFyIjsNCgltc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN CgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgltc28tYWRkLXNwYWNlOmF1 dG87DQoJYm9yZGVyOm5vbmU7DQoJcGFkZGluZzowaW47DQoJZm9udC1zaXplOjI2LjBwdDsNCglm b250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCglsZXR0ZXItc3BhY2luZzouMjVwdDt9 DQpwLk1zb1RpdGxlQ3hTcE1pZGRsZSwgbGkuTXNvVGl0bGVDeFNwTWlkZGxlLCBkaXYuTXNvVGl0 bGVDeFNwTWlkZGxlDQoJe21zby1zdHlsZS1wcmlvcml0eToxMDsNCgltc28tc3R5bGUtbGluazoi VGl0bGUgQ2hhciI7DQoJbXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLWFkZC1zcGFjZTphdXRvOw0KCWJvcmRlcjpu b25lOw0KCXBhZGRpbmc6MGluOw0KCWZvbnQtc2l6ZToyNi4wcHQ7DQoJZm9udC1mYW1pbHk6IkFy aWFsIiwic2Fucy1zZXJpZiI7DQoJbGV0dGVyLXNwYWNpbmc6LjI1cHQ7fQ0KcC5Nc29UaXRsZUN4 U3BMYXN0LCBsaS5Nc29UaXRsZUN4U3BMYXN0LCBkaXYuTXNvVGl0bGVDeFNwTGFzdA0KCXttc28t c3R5bGUtcHJpb3JpdHk6MTA7DQoJbXNvLXN0eWxlLWxpbms6IlRpdGxlIENoYXIiOw0KCW1zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCW1zby1hZGQtc3BhY2U6YXV0bzsNCglib3JkZXI6bm9uZTsNCglwYWRkaW5nOjBpbjsN Cglmb250LXNpemU6MjYuMHB0Ow0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0K CWxldHRlci1zcGFjaW5nOi4yNXB0O30NCnAuTXNvU3VidGl0bGUsIGxpLk1zb1N1YnRpdGxlLCBk aXYuTXNvU3VidGl0bGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjExOw0KCW1zby1zdHlsZS1saW5r OiJTdWJ0aXRsZSBDaGFyIjsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1hcmdpbi1ib3R0b206MzAuMHB0Ow0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWxldHRlci1zcGFjaW5n Oi42NXB0Ow0KCWZvbnQtc3R5bGU6aXRhbGljO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmVtDQoJe21zby1zdHlsZS1wcmlvcml0eToyMDsNCglsZXR0ZXItc3BhY2luZzou NXB0Ow0KCWJvcmRlcjpub25lOw0KCWZvbnQtd2VpZ2h0OmJvbGQ7fQ0KcC5Nc29BY2V0YXRlLCBs aS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9t YSIsInNhbnMtc2VyaWYiO30NCnAuTXNvTm9TcGFjaW5nLCBsaS5Nc29Ob1NwYWNpbmcsIGRpdi5N c29Ob1NwYWNpbmcNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjE7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBh cmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0K CW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47 DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLWFkZC1z cGFjZTphdXRvOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsInNlcmlmIjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGhDeFNwRmlyc3QsIGxpLk1zb0xpc3RQ YXJhZ3JhcGhDeFNwRmlyc3QsIGRpdi5Nc29MaXN0UGFyYWdyYXBoQ3hTcEZpcnN0DQoJe21zby1z dHlsZS1wcmlvcml0eTozNDsNCgltc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltYXJnaW4t dG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdp bi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCW1zby1hZGQtc3BhY2U6YXV0 bzsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJz ZXJpZiI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoQ3hTcE1pZGRsZSwgbGkuTXNvTGlzdFBhcmFncmFw aEN4U3BNaWRkbGUsIGRpdi5Nc29MaXN0UGFyYWdyYXBoQ3hTcE1pZGRsZQ0KCXttc28tc3R5bGUt cHJpb3JpdHk6MzQ7DQoJbXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbWFyZ2luLXRvcDow aW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVm dDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgltc28tYWRkLXNwYWNlOmF1dG87DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCnAuTXNvTGlzdFBhcmFncmFwaEN4U3BMYXN0LCBsaS5Nc29MaXN0UGFyYWdyYXBoQ3hTcExh c3QsIGRpdi5Nc29MaXN0UGFyYWdyYXBoQ3hTcExhc3QNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0 Ow0KCW1zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLWFkZC1zcGFjZTphdXRvOw0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwLk1zb1F1 b3RlLCBsaS5Nc29RdW90ZSwgZGl2Lk1zb1F1b3RlDQoJe21zby1zdHlsZS1wcmlvcml0eToyOTsN Cgltc28tc3R5bGUtbGluazoiUXVvdGUgQ2hhciI7DQoJbWFyZ2luLXRvcDoxMC4wcHQ7DQoJbWFy Z2luLXJpZ2h0Oi4yNWluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi4yNWlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJZm9udC1zdHlsZTppdGFsaWM7fQ0KcC5N c29JbnRlbnNlUXVvdGUsIGxpLk1zb0ludGVuc2VRdW90ZSwgZGl2Lk1zb0ludGVuc2VRdW90ZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6MzA7DQoJbXNvLXN0eWxlLWxpbms6IkludGVuc2UgUXVvdGUg Q2hhciI7DQoJbWFyZ2luLXRvcDoxMC4wcHQ7DQoJbWFyZ2luLXJpZ2h0Oi44aW47DQoJbWFyZ2lu LWJvdHRvbToxNC4wcHQ7DQoJbWFyZ2luLWxlZnQ6LjdpbjsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7 DQoJYm9yZGVyOm5vbmU7DQoJcGFkZGluZzowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWZvbnQtd2VpZ2h0OmJvbGQ7DQoJ Zm9udC1zdHlsZTppdGFsaWM7fQ0Kc3Bhbi5Nc29TdWJ0bGVFbXBoYXNpcw0KCXttc28tc3R5bGUt cHJpb3JpdHk6MTk7DQoJZm9udC1zdHlsZTppdGFsaWM7fQ0Kc3Bhbi5Nc29JbnRlbnNlRW1waGFz aXMNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjIxOw0KCWZvbnQtd2VpZ2h0OmJvbGQ7fQ0Kc3Bhbi5N c29TdWJ0bGVSZWZlcmVuY2UNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjMxOw0KCWZvbnQtdmFyaWFu dDpzbWFsbC1jYXBzO30NCnNwYW4uTXNvSW50ZW5zZVJlZmVyZW5jZQ0KCXttc28tc3R5bGUtcHJp b3JpdHk6MzI7DQoJZm9udC12YXJpYW50OnNtYWxsLWNhcHM7DQoJbGV0dGVyLXNwYWNpbmc6LjI1 cHQ7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLk1zb0Jvb2tUaXRsZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6MzM7DQoJZm9udC12YXJpYW50OnNtYWxsLWNhcHM7DQoJbGV0dGVy LXNwYWNpbmc6LjI1cHQ7DQoJZm9udC1zdHlsZTppdGFsaWM7fQ0KcC5Nc29Ub2NIZWFkaW5nLCBs aS5Nc29Ub2NIZWFkaW5nLCBkaXYuTXNvVG9jSGVhZGluZw0KCXttc28tc3R5bGUtcHJpb3JpdHk6 Mzk7DQoJbWFyZ2luLXRvcDoyNC4wcHQ7DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90 dG9tOjBpbjsNCgltYXJnaW4tbGVmdDowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCW1z by1hZGQtc3BhY2U6YXV0bzsNCglmb250LXNpemU6MTQuMHB0Ow0KCWZvbnQtZmFtaWx5OiJBcmlh bCIsInNhbnMtc2VyaWYiOw0KCWZvbnQtd2VpZ2h0OmJvbGQ7fQ0KcC5Nc29Ub2NIZWFkaW5nQ3hT cEZpcnN0LCBsaS5Nc29Ub2NIZWFkaW5nQ3hTcEZpcnN0LCBkaXYuTXNvVG9jSGVhZGluZ0N4U3BG aXJzdA0KCXttc28tc3R5bGUtcHJpb3JpdHk6Mzk7DQoJbXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJbWFyZ2luLXRvcDoyNC4wcHQ7DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90 dG9tOjBpbjsNCgltYXJnaW4tbGVmdDowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCW1z by1hZGQtc3BhY2U6YXV0bzsNCglmb250LXNpemU6MTQuMHB0Ow0KCWZvbnQtZmFtaWx5OiJBcmlh bCIsInNhbnMtc2VyaWYiOw0KCWZvbnQtd2VpZ2h0OmJvbGQ7fQ0KcC5Nc29Ub2NIZWFkaW5nQ3hT cE1pZGRsZSwgbGkuTXNvVG9jSGVhZGluZ0N4U3BNaWRkbGUsIGRpdi5Nc29Ub2NIZWFkaW5nQ3hT cE1pZGRsZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6Mzk7DQoJbXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLWFkZC1z cGFjZTphdXRvOw0KCWZvbnQtc2l6ZToxNC4wcHQ7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fu cy1zZXJpZiI7DQoJZm9udC13ZWlnaHQ6Ym9sZDt9DQpwLk1zb1RvY0hlYWRpbmdDeFNwTGFzdCwg bGkuTXNvVG9jSGVhZGluZ0N4U3BMYXN0LCBkaXYuTXNvVG9jSGVhZGluZ0N4U3BMYXN0DQoJe21z by1zdHlsZS1wcmlvcml0eTozOTsNCgltc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgltc28tYWRkLXNwYWNlOmF1dG87DQoJ Zm9udC1zaXplOjE0LjBwdDsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCglm b250LXdlaWdodDpib2xkO30NCnNwYW4uSGVhZGluZzFDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJI ZWFkaW5nIDEgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6 IkhlYWRpbmcgMSI7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQoJZm9udC13 ZWlnaHQ6Ym9sZDt9DQpzcGFuLkhlYWRpbmcyQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSGVhZGlu ZyAyIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1saW5rOiJIZWFk aW5nIDIiOw0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWZvbnQtd2VpZ2h0 OmJvbGQ7fQ0Kc3Bhbi5IZWFkaW5nM0NoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhlYWRpbmcgMyBD aGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoiSGVhZGluZyAz IjsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCglmb250LXdlaWdodDpib2xk O30NCnNwYW4uSGVhZGluZzRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIZWFkaW5nIDQgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgNCI7DQoJ Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQoJZm9udC13ZWlnaHQ6Ym9sZDsNCglm b250LXN0eWxlOml0YWxpYzt9DQpzcGFuLkhlYWRpbmc1Q2hhcg0KCXttc28tc3R5bGUtbmFtZToi SGVhZGluZyA1IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1saW5r OiJIZWFkaW5nIDUiOw0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWNvbG9y OiM3RjdGN0Y7DQoJZm9udC13ZWlnaHQ6Ym9sZDt9DQpzcGFuLkhlYWRpbmc2Q2hhcg0KCXttc28t c3R5bGUtbmFtZToiSGVhZGluZyA2IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1z by1zdHlsZS1saW5rOiJIZWFkaW5nIDYiOw0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOiM3RjdGN0Y7DQoJZm9udC13ZWlnaHQ6Ym9sZDsNCglmb250LXN0eWxlOml0 YWxpYzt9DQpzcGFuLkhlYWRpbmc3Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiSGVhZGluZyA3IENo YXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1saW5rOiJIZWFkaW5nIDci Ow0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWZvbnQtc3R5bGU6aXRhbGlj O30NCnNwYW4uSGVhZGluZzhDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIZWFkaW5nIDggQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgOCI7DQoJ Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5IZWFkaW5nOUNoYXINCgl7 bXNvLXN0eWxlLW5hbWU6IkhlYWRpbmcgOSBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTsN Cgltc28tc3R5bGUtbGluazoiSGVhZGluZyA5IjsNCglmb250LWZhbWlseToiQXJpYWwiLCJzYW5z LXNlcmlmIjsNCglsZXR0ZXItc3BhY2luZzouMjVwdDsNCglmb250LXN0eWxlOml0YWxpYzt9DQpz cGFuLlRpdGxlQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiVGl0bGUgQ2hhciI7DQoJbXNvLXN0eWxl LXByaW9yaXR5OjEwOw0KCW1zby1zdHlsZS1saW5rOlRpdGxlOw0KCWZvbnQtZmFtaWx5OiJBcmlh bCIsInNhbnMtc2VyaWYiOw0KCWxldHRlci1zcGFjaW5nOi4yNXB0O30NCnNwYW4uU3VidGl0bGVD aGFyDQoJe21zby1zdHlsZS1uYW1lOiJTdWJ0aXRsZSBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3Jp dHk6MTE7DQoJbXNvLXN0eWxlLWxpbms6U3VidGl0bGU7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwi c2Fucy1zZXJpZiI7DQoJbGV0dGVyLXNwYWNpbmc6LjY1cHQ7DQoJZm9udC1zdHlsZTppdGFsaWM7 fQ0Kc3Bhbi5RdW90ZUNoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlF1b3RlIENoYXIiOw0KCW1zby1z dHlsZS1wcmlvcml0eToyOTsNCgltc28tc3R5bGUtbGluazpRdW90ZTsNCglmb250LXN0eWxlOml0 YWxpYzt9DQpzcGFuLkludGVuc2VRdW90ZUNoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkludGVuc2Ug UXVvdGUgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5OjMwOw0KCW1zby1zdHlsZS1saW5rOiJJ bnRlbnNlIFF1b3RlIjsNCglmb250LXdlaWdodDpib2xkOw0KCWZvbnQtc3R5bGU6aXRhbGljO30N CnNwYW4uRW1haWxTdHlsZTQ0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkJhbGxv b25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250 LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlNDcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxh bmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkkgYW5zd2VyZWQgdGhlIGFjdHVhbCBxdWVzdGlvbiBhc2tl ZC4gKEkgZG8gbm90IG9waW5lIG9uIHdoYXQgbWlnaHQgaGF2ZSBiZWVuIGludGVuZGVkIHRvIGJl IGFza2VkLik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5JZiB0aGUgY3Vy cmVudCBzY29wZSBwcmV2ZW50cyBmaXhpbmcgdGhlIHNpdHVhdGlvbiwgZXhwZWN0IGxhY2sgb2Yg aW50ZXJvcGVyYWJpbGl0eSB0byBjb250aW51ZS4gPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+Q2hhbmdpbmcgdGhlIHNjb3BlIGhhcyBhIHRpbWUgbGluZSBhbmQs IHByb3Blcmx5LCBzaG91bGQgYmUganVzdGlmaWVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPlVzaW5nIHRoZSBzY29wZSB0byBpZ25vcmUgYSBwcm9ibGVtIGhh cyBiZWVuIGRvbmUgbWFueSB0aW1lcyBpbiB0aGUgcGFzdCwgbm90IGp1c3QgaW4gSUVURiBidXQg ZWxzZXdoZXJlLsKgIENvbnRyYXN0IHdpdGggYWxsb3dpbmcgc2NvcGUgY3JlZXAgd2hpY2ggcHJl dmVudHMgdGltZWx5IHJlc29sdXRpb24gb2YgYSBwcm9ibGVtLsKgIENob29zZSBjYXJlZnVsbHku PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1p bHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+QXJ0PG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFs Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkFydCBBbGxp c29uPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi QXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4gPGJyPjwvc3Bhbj48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz5TZW5pb3IgRGlyZWN0b3IgQWR2YW5jZWQgRW5naW5lZXJpbmcsIFRlY2hub2xv Z3k8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFs Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+IDxicj48L3NwYW4+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+TmF0aW9uYWwgQXNzb2NpYXRpb24gb2YgQnJvYWRjYXN0ZXJzPGJyPjE3NzEgTiBTdHJl ZXQgTlc8YnI+V2FzaGluZ3RvbiwgREMgMjAwMzY8YnI+UGhvbmUmbmJzcDsgMjAyIDQyOSA1NDE4 PGJyPkZheCZuYnNwOyAyMDIgNzc1IDQ5ODE8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+IDxi cj48YSBocmVmPSJibG9ja2VkOjpodHRwOi8vd3d3Lm5hYi5vcmciPjxiPnd3dy5uYWIub3JnPC9i PjwvYT4gPGJyPjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojRkY4MDAwJz5BZHZvY2FjeSAmbmJzcDtF ZHVjYXRpb24mbmJzcDsgSW5ub3ZhdGlvbjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz48cCBj bGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gcGtpeC1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86cGtpeC1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhh bGYgT2YgPC9iPkJlbiBXaWxzb248YnI+PGI+U2VudDo8L2I+IFdlZG5lc2RheSwgT2N0b2JlciAz MSwgMjAxMiAxMTozNiBBTTxicj48Yj5Ubzo8L2I+IHBraXhAaWV0Zi5vcmc8YnI+PGI+U3ViamVj dDo8L2I+IFJlOiBbcGtpeF0gU3RyYXctcG9sbCBvbiBPQ1NQIHJlc3BvbnNlcyBmb3Jub24tcmV2 b2tlZCBjZXJ0aWZpY2F0ZXMuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz5JIGRvbuKAmXQgdGhpbmsgdGhlIG9yaWdpbmFsIGJhbGxvdCBj aGFuZ2VkLiZuYnNwOyAjMSB3YXMgdG8gYWxsb3cgcmV2b2tlZC4mbmJzcDsgIzMgd2FzIGRvIG5v dGhpbmcuJm5ic3A7IFNvLCBhIHZvdGUgdGhhdCB0aGV5IGZhdm9yIOKAnDMg4oCTIHVua25vd27i gJ0gaXMgb3V0IG9mIHNjb3BlLCBidXQgaG9wZWZ1bGx5IGV2ZXJ5b25lIHVuZGVyc3RhbmRzIHRo YXQgdGhpcyBpcyB0aGUgbmF0dXJlIG9mIGEgc3RyYXcgcG9sbD88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1z b05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFo b21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiA8YSBocmVmPSJtYWls dG86cGtpeC1ib3VuY2VzQGlldGYub3JnIj5wa2l4LWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFs8YSBo cmVmPSJtYWlsdG86cGtpeC1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86cGtpeC1ib3VuY2VzQGll dGYub3JnPC9hPl0gPGI+T24gQmVoYWxmIE9mIDwvYj5SeWFuIEh1cnN0PGJyPjxiPlNlbnQ6PC9i PiBXZWRuZXNkYXksIE9jdG9iZXIgMzEsIDIwMTIgODo0MiBBTTxicj48Yj5Ubzo8L2I+IERlbmlz IFBpbmthczxicj48Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpwa2l4QGlldGYub3JnIj5wa2l4 QGlldGYub3JnPC9hPjxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IFtwa2l4XSBTdHJhdy1wb2xsIG9u IE9DU1AgcmVzcG9uc2VzIGZvciBub24tcmV2b2tlZCBjZXJ0aWZpY2F0ZXMuPG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpw PjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5TYW1lIGFzIERlbm5pcy48YnI+PGJyPlNlbnQg ZnJvbSBteSBpUGhvbmU8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxicj5PbiBPY3QgMzEsIDIwMTIsIGF0IDQ6 NDYgQU0sIERlbmlzIFBpbmthcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRlbmlzLnBpbmthc0BidWxs Lm5ldCI+ZGVuaXMucGlua2FzQGJ1bGwubmV0PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9J21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCc+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6 IkFyaWFsIiwic2Fucy1zZXJpZiInPlJlc3BvbnNlICMzJm5ic3A7OiBzdGF0dXMmbmJzcDs6IHVu a25vd248L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5 bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9u dC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPlJlc3BvbnNlICMxIHdvdWxkIGFsc28gYmUg YWNjZXB0YWJsZSwgYnV0IGFzIGEgc2Vjb25kIGNob2ljZS48L3NwYW4+PG86cD48L286cD48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1mYW1pbHk6 IkFyaWFsIiwic2Fucy1zZXJpZiInPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvJz48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwi LCJzYW5zLXNlcmlmIic+UXVpY2sgZXhwbGFuYXRpb246IOKAnHVua25vd27igJ0gaXMgdGhlIHJp Z2h0IHN0YXR1cy4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxz cGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz48 YnI+SWYgdGhlIE9DU1AgY2xpZW50IHZlcmlmaWVzIHRoYXQgdGhlIHJlc3BvbnNlIGlzIGZyb20g YW4gYXV0aG9yaXplZCByZXNwb25kZXIgZm9yIHRoZSBDQSB3aGljaCBoYXMgaXNzdWVkIHRoZSBj ZXJ0aWZpY2F0ZTogPGJyPnVua25vd24gaXMgYSBkZWZpbml0ZSByZXNwb25zZSBhbmQgaXMgc2Fm ZSAobm8gb3RoZXIgbWVjaGFuaXNtIFNIQUxMIGJlIHVzZWQpLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LWZhbWls eToiQXJpYWwiLCJzYW5zLXNlcmlmIic+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8nPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlh bCIsInNhbnMtc2VyaWYiJz5PbiB0aGUgY29udHJhcnksIGlmIHRoZSBPQ1NQIGNsaWVudCBkb2Vz IG5vdCB2ZXJpZnkgdGhhdCB0aGUgcmVzcG9uc2UgaXMgZnJvbSBhbiBhdXRob3JpemVkIHJlc3Bv bmRlciBmb3IgdGhlIENBIHdoaWNoIGhhcyA8YnI+aXNzdWVkIHRoZSBjZXJ0aWZpY2F0ZSwgdGhl biBhbm90aGVyIG1lY2hhbmlzbSB3aWxsIGJlIHVzZWQgOiBlaXRoZXIgYW5vdGhlciBPQ1NQIHNl cnZlciBvciBDUkxzLiA8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+ PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiIn Pjxicj5JZiBDUkxzIGFyZSB1c2VkLCDigJxyZXZva2Vk4oCdIGlzIHNhZmVyLCBidXQgaXQgaXMg c2VtYW50aWNhbGx5IGluY29ycmVjdC4gU28gYSBjaGFuZ2UgaW4gaXRzIHNlbWFudGljcyB3b3Vs ZCBiZSBtYW5kYXRvcnkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQnPjxzcGFu IHN0eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+VGhlIHByb2JsZW0gaXMg dGhhdCB0aGUgY2hhbmdlIHNob3VsZCBiZSAmcXVvdDtyZXZva2VkIG9yIHVua25vd24mcXVvdDsg d2hpY2ggbWF5IGJlIHJhdGhlciBjb25mdXNpbmcuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2 PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSBzdHlsZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Jz48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5wa2l4IG1haWxpbmcgbGlzdDxicj48YSBo cmVmPSJtYWlsdG86cGtpeEBpZXRmLm9yZyI+cGtpeEBpZXRmLm9yZzwvYT48YnI+PGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wa2l4Ij5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BraXg8L2E+PG86cD48L286cD48L3A+PC9kaXY+PC9i bG9ja3F1b3RlPjwvZGl2PjwvYm9keT48L2h0bWw+ ------_=_NextPart_001_01CDB793.B5ED130A-- From stefan@aaa-sec.com Wed Oct 31 11:46:39 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC43B21F888F for ; Wed, 31 Oct 2012 11:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.32 X-Spam-Level: X-Spam-Status: No, score=-101.32 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HELO_EQ_SE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1iKvnKMpko9 for ; Wed, 31 Oct 2012 11:46:39 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 34ADE21F8864 for ; Wed, 31 Oct 2012 11:46:38 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id B3AD12675A for ; Wed, 31 Oct 2012 19:46:36 +0100 (CET) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ZwegDlhN5SLA for ; Wed, 31 Oct 2012 19:46:36 +0100 (CET) Received: from s331.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 63472229DEBA for ; Wed, 31 Oct 2012 19:46:36 +0100 (CET) Received: (qmail 19275 invoked from network); 31 Oct 2012 18:46:35 -0000 Received: from 81-232-51-61-no39.business.telia.com (HELO [192.168.0.113]) (stefan@fiddler.nu@[81.232.51.61]) (envelope-sender ) by s331.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 31 Oct 2012 18:46:35 -0000 User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Wed, 31 Oct 2012 19:46:46 +0100 From: Stefan Santesson To: Message-ID: Thread-Topic: Proposed resolution to non-issued certificates - 2560bis In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [pkix] Proposed resolution to non-issued certificates - 2560bis X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 18:46:40 -0000 I didn't put up an end date for the straw-poll, but the trend seems clear. The results so far (if I counted right) Supporting #1: 22 Supporting #2: 0 Supporting #3 using "unknown": 6 Supporting #3 using "unauthorised: 2 6 persons supporting #1 has expressed various levels of support/demand for an explicit declaration that the OCSP responder supports the enhanced definition of "revoked" to include "no issued". 1 person responded off-line supporting #1. If the trend reflects the opinion of the WG. This is my proposed resolution: 1) Extend the "revoked" response to also be allowed for non-issued certificates. Clearly stating that this is optional if and only if the OCSP responder knows that the requested serial number has never been issued. 2) Specify that a "revoked" status for a non-issued certificate serial number MUST have revocationTime set to Jan 1, 1970 and MUST set the revocationReason to certificateHold (6). 2) Define a new optional non-critical extension declaring that OCSP responder returns "revoked" for non-issued certificates according to the updated standard. This extension MUST be present in all responses where the "revoked" response is returned as a result of a status request for a non-issued certificate. Rationale: The certificateHold reason feels important for one particular reason. If a CA is issuing certificates with sequential serial numbers, then it could be possible to obtain a revoked response for a certificate serial number that is not yet issued, but soon will be issued. That the certificate serial number is currently not issued, does not mean that it never will, thus the certificateHold reason seems more appropriate. The date 1 Jan, 1970 is appropriate since it is common in programming languages to express time as milliseconds since jan 1, 1970. Selecting this time avoids time expression as a negative integer. This date translates to (java): Date revocationTime = new Date(0); //Jan 1st, 1970 The extension would be a simple OID with no data structure and MUST not be set to critical. Question: Would it make sense to require an OCSP responder that adopts the expanded use of "revoked" to always include the new extension? It would add the benefit that someone receiving "good" can know that the OCSP responder has checked that the certificate in fact has been issued by the CA. In such case it may be reasonable to add an optional data structure which MAY contain a hash of the cert. Such hash would make the positive confirmation even stronger, adding proof of existence of the certificate. But perhaps this will bee too much to agree on :) /Stefan From tom@ritter.vg Wed Oct 31 12:17:31 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4ADD21F866D for ; Wed, 31 Oct 2012 12:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8Ev1roHddvI for ; Wed, 31 Oct 2012 12:17:28 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1415F21F85E1 for ; Wed, 31 Oct 2012 12:17:27 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so2129853vbb.31 for ; Wed, 31 Oct 2012 12:17:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=OZ4NdXTkM4V8qIxrlsYJt6rH7Tnqa2+wPrra2mXR93Y=; b=fnPhtIabgS2APcMlqSszcBGuP209BJXXqvurDSBE8pfdHmPmdCmdLeP0YCbLLMea6R wwcHHRDoZay6M72xiusA+u/d8LJcs4Fx56dePciy2DBQGMfz1xtNIFiSC+/GBD0AEEmT FZF3SwsKuVaYscy17oLjzx3AQ21UI8quqPwAc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=OZ4NdXTkM4V8qIxrlsYJt6rH7Tnqa2+wPrra2mXR93Y=; b=nCubkEm6c7KZpfjKp0F8l7/8PwV7n0RpDSut/pkPVnI8uUua5eTQBlO/5Lv67/yAGM iRQICqpXlKPvgQhfaqyITi9yfMJaLkZ9MXLryUiOib5gp+8g/pguGDsxmg5Tn09rimZa VCx15SuEvXW4QauauxL2UUtsL5cvCCNzNdiGL2d6pjJ86WVV23nQNlBaimo+COf39DoG UGmFN/mPbxY4yKjKm9S4KDlfOCCWMdYcDMqjiU8XHHPBY6Gs1Lfe9sDsqsqzWpQ3XFoh zR1SXz2xQSr1OMUCQkqDJzXDJ5YO+RP5arAXHJ0b8A+P77iLU7JNXVq3GdHwz0o9EfJE LUQg== Received: by 10.52.70.48 with SMTP id j16mr48515551vdu.1.1351711047213; Wed, 31 Oct 2012 12:17:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.151.178 with HTTP; Wed, 31 Oct 2012 12:17:07 -0700 (PDT) In-Reply-To: References: <20121029232328.BF5D91A309@ld9781.wdf.sap.corp> From: Tom Ritter Date: Wed, 31 Oct 2012 15:17:07 -0400 Message-ID: To: Stefan Santesson Content-Type: multipart/alternative; boundary=20cf307f3996cee24a04cd5fc002 X-Gm-Message-State: ALoCoQl9VuiW0GWzudU+ZbV+s190gkJmSt1g7izUYd3+pvPEyqhCs045Fd/p+Lsryd9UCeznl2OA Cc: IETF PKIX Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked certificates. X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 19:17:31 -0000 --20cf307f3996cee24a04cd5fc002 Content-Type: text/plain; charset=ISO-8859-1 On Oct 30, 2012 7:05 AM, "Stefan Santesson" wrote: > Before we loose everyone engaged in this, I would like to make a > straw-poll: > > Please reply with either: > > 1. Allow "revoked" response for a certificate that has not been "revoked" > but where that OCSP responder for any other reason knows the certificate > to be "bad". > > 2. Require that the OCSP responder MUST respond "good" in this situation. > > 3. Neither 1 or 2 (motivate). > #1. -tom --20cf307f3996cee24a04cd5fc002 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Oct 30, 2012 7:05 AM, "Stefan Santesson" <stefan@aaa-sec.com> wrote:

Before we loose everyone engaged in this, I would like to make a
straw-poll:

Please reply with either:

1. Allow "revoked" response for a certificate that has not been &= quot;revoked"
but where that OCSP responder for any other reason knows the certificate to be "bad".

2. Require that the OCSP responder MUST respond "good" in this si= tuation.

3. Neither 1 or 2 (motivate).


#1. =A0

-tom=A0
--20cf307f3996cee24a04cd5fc002-- From tom@ritter.vg Wed Oct 31 12:32:45 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4E521F8821 for ; Wed, 31 Oct 2012 12:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BegoSolRDwjI for ; Wed, 31 Oct 2012 12:32:44 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 92E7021F85CE for ; Wed, 31 Oct 2012 12:32:44 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so2147137vbb.31 for ; Wed, 31 Oct 2012 12:32:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=FYuWCO0StKohiV1FUd5nYZ1gx8i+0rHpY+wGP9jbvzk=; b=VIT2OXsyJeGr1RJjJpya0vKaDfO/58awPzxhCF9d4DSzlXj32xrUoa2H1z3l4sZ2Jc lDXMbJlDFGAsFi+UZ1T9NxU9yjjTPU/9wofBzBKA1JWgluJwJTTOYhBfDIfnxXiNiX49 akaH6bYvNXQZlAd9VyUPgWcFtxsIUTnwdfJqA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=FYuWCO0StKohiV1FUd5nYZ1gx8i+0rHpY+wGP9jbvzk=; b=NXz6DL7frIn9TBrkoksZpZ/C6MBRefIHY9H3F69Ctmut7e8jHqKeKOfWoSwX/oW9bu JsKS7We7JBynGPW0wMEuWOji/eHzvxIEb/dYRyYVvz8r3rXg1hgR3OpAvE2DeT1BQJhp fRaQP7Lz9xAXHzge7CQcnzwaehVo77nTL9++anBWA5mbXMD/1pQddXFCUXit9ZU6GG7b yV7dIJUtNPUzA+bGVf9zzrHuPamC8e0bsmBhioL5oIV4M9GzKdyZTBlQDSINaUlUkuw8 Q/OC//X5nToDQBUUNSxHQmWg9Dl9tTpDwM8up793AVhG8D0oO/KXQ6Qyh27fuB5WQkjr bItA== Received: by 10.52.96.6 with SMTP id do6mr48651600vdb.84.1351711963925; Wed, 31 Oct 2012 12:32:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.151.178 with HTTP; Wed, 31 Oct 2012 12:32:23 -0700 (PDT) In-Reply-To: References: From: Tom Ritter Date: Wed, 31 Oct 2012 15:32:23 -0400 Message-ID: To: Stefan Santesson Content-Type: multipart/alternative; boundary=20cf307abe3d72cded04cd5ff7ef X-Gm-Message-State: ALoCoQmyqKFY0JresHOvbnE0d9e8/elQ0YnGZbpstI1WdEhzod3igA8n6nynbNyVQheQSrdkjOrK Cc: IETF PKIX Subject: Re: [pkix] Proposed resolution to non-issued certificates - 2560bis X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 19:32:45 -0000 --20cf307abe3d72cded04cd5ff7ef Content-Type: text/plain; charset=ISO-8859-1 Think I missed this email while sending in my vote, sorry. On 31 October 2012 14:46, Stefan Santesson wrote: > 1) Extend the "revoked" response to also be allowed for non-issued > certificates. Clearly stating that this is optional if and only if the > OCSP responder knows that the requested serial number has never been > issued. > Cool. > 2) Specify that a "revoked" status for a non-issued certificate serial > number MUST have revocationTime set to Jan 1, 1970 and MUST set the > revocationReason to certificateHold (6). > Is the 0 unix epoch overloaded/used in other contexts? Have CAs set this date as the revocation date in other situations/for legacy reasons? Would it be better to use something similar like Jan 2, 1970? It's another magic value which is crappy but... > 2) Define a new optional non-critical extension declaring that OCSP > responder returns "revoked" for non-issued certificates according to the > updated standard. This extension MUST be present in all responses where > the "revoked" response is returned as a result of a status request for a > non-issued certificate. > Cool. > Question: > Would it make sense to require an OCSP responder that adopts the expanded > use of "revoked" to always include the new extension? > It would add the benefit that someone receiving "good" can know that the > OCSP responder has checked that the certificate in fact has been issued by > the CA. > In such case it may be reasonable to add an optional data structure which > MAY contain a hash of the cert. > Such hash would make the positive confirmation even stronger, adding proof > of existence of the certificate. > I'll register my vote for all these items also - I like the idea of providing transparency into the operations of the responders. -tom. --20cf307abe3d72cded04cd5ff7ef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Think I missed this email while sending in my vote, sorry.

On 31 October 2012 14:46, Ste= fan Santesson <stefan@aaa-sec.com> wrote:
1) Extend the "revoked" response to also be allo= wed for non-issued
certificates. Clearly stating that this is optional if and only if the
OCSP responder knows that the requested serial number has never been
issued.

Cool.
=A0
= 2) Specify that a "revoked" status for a non-issued certificate s= erial
number MUST have revocationTime set to Jan 1, 1970 and MUST set the
revocationReason to certificateHold (6).

Is the 0 unix epoch overloaded/used in other contexts? =A0Have CAs set th= is date as the revocation date in other situations/for legacy reasons? =A0W= ould it be better to use something similar like Jan 2, 1970? =A0It's an= other magic value which is crappy but...=A0
=A0
2) Define a new optional non-critical extension declaring that OCSP
responder returns "revoked" for non-issued certificates according= to the
updated standard. This extension MUST be present in all responses where
the "revoked" response is returned as a result of a status reques= t for a
non-issued certificate.

Cool.=A0
<= div class=3D"gmail_extra">

= =A0
Question:
Would it make sense to require an OCSP responder that adopts t= he expanded
use of "revoked" to always include the new extensi= on?
It would add the benefit that someone receiving "good" can= know that the
OCSP responder has checked that the certificate in fact has been issued by<= br>the CA.
In such case it may be reasonable to add an optional data structure whichMAY contain a hash of the cert.
Such hash would make the positive conf= irmation even stronger, adding proof
of existence of the certificate.

I'll register my vote for all these it= ems also - I like the idea of providing transparency into the operations of= the responders.

-tom.=A0
--20cf307abe3d72cded04cd5ff7ef-- From stefan@aaa-sec.com Wed Oct 31 14:25:00 2012 Return-Path: X-Original-To: pkix@ietfa.amsl.com Delivered-To: pkix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7C221F87E0 for ; Wed, 31 Oct 2012 14:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.086 X-Spam-Level: X-Spam-Status: No, score=-101.086 tagged_above=-999 required=5 tests=[AWL=-0.234, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQSOsR0Vwhud for ; Wed, 31 Oct 2012 14:24:59 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 40A1021F87DF for ; Wed, 31 Oct 2012 14:24:59 -0700 (PDT) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id ECC1B2F107 for ; Wed, 31 Oct 2012 22:24:57 +0100 (CET) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id RdC3W9RD54cU for ; Wed, 31 Oct 2012 22:24:57 +0100 (CET) Received: from s376.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 8A2BA2F10C for ; Wed, 31 Oct 2012 22:24:57 +0100 (CET) Received: (qmail 44784 invoked from network); 31 Oct 2012 21:24:57 -0000 Received: from 81-232-51-61-no39.business.telia.com (HELO [192.168.0.113]) (stefan@fiddler.nu@[81.232.51.61]) (envelope-sender ) by s376.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 31 Oct 2012 21:24:57 -0000 User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Wed, 31 Oct 2012 22:25:15 +0100 From: Stefan Santesson To: IETF PKIX Message-ID: Thread-Topic: [pkix] Proposed resolution to non-issued certificates - 2560bis In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3434567118_33060750" Subject: Re: [pkix] Proposed resolution to non-issued certificates - 2560bis X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 21:25:00 -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_3434567118_33060750 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Here is my own concerns with inclusion of an optional cert hash in the extension. There might be OCSP responders that do have access to a database of issued certs that are currently valid, but not the history of issued certs (expired). They could not use this extension to include a cert hash as they can't know if a particular serial number of an expired cert is asked for. Thus it may be wise to separate these issues and keep it simple and just use an OID to indicate this particular behaviour with regard to "revoked" response. It may be wise therefore to allow a separate process come up with a separate extension for positive confirmations. Not that I don't like such functionality. The alternative is to extend this process long enough that we feel sure we got it right. /Stefan From: Tom Ritter Date: Wednesday, October 31, 2012 8:32 PM To: Stefan Santesson Cc: IETF PKIX Subject: Re: [pkix] Proposed resolution to non-issued certificates - 2560bis >> Question: >> Would it make sense to require an OCSP responder that adopts the expanded >> use of "revoked" to always include the new extension? >> It would add the benefit that someone receiving "good" can know that the >> OCSP responder has checked that the certificate in fact has been issued by >> the CA. >> In such case it may be reasonable to add an optional data structure which >> MAY contain a hash of the cert. >> Such hash would make the positive confirmation even stronger, adding proof >> of existence of the certificate. > > I'll register my vote for all these items also - I like the idea of providing > transparency into the operations of the responders. > --B_3434567118_33060750 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Here is my own concerns with= inclusion of an optional cert hash in the extension.

There might be OCSP responders that do have access to a database of issue= d certs that are currently valid, but not the history of issued certs (expir= ed).