Re: [pkix] Proposed resolution to non-issued certificates - 2560bis
Stefan Santesson <stefan@aaa-sec.com> Thu, 01 November 2012 15:39 UTC
Return-Path: <stefan@aaa-sec.com>
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 39DA021F8E27 for <pkix@ietfa.amsl.com>; Thu, 1 Nov 2012 08:39:54 -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 o7kbtco8lQ6Z for <pkix@ietfa.amsl.com>; Thu, 1 Nov 2012 08:39:53 -0700 (PDT)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 16F9221F8E24 for <pkix@ietf.org>; Thu, 1 Nov 2012 08:39:52 -0700 (PDT)
Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 9344A326C0 for <pkix@ietf.org>; Thu, 1 Nov 2012 16:39:51 +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 igAWQQXYUd-A for <pkix@ietf.org>; Thu, 1 Nov 2012 16:39:50 +0100 (CET)
Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 85498326CD for <pkix@ietf.org>; Thu, 1 Nov 2012 16:39:50 +0100 (CET)
Received: (qmail 7502 invoked from network); 1 Nov 2012 15:39:50 -0000
Received: from host-95-192-12-180.mobileonline.telia.com (HELO [192.168.43.205]) (stefan@fiddler.nu@[95.192.12.180]) (envelope-sender <stefan@aaa-sec.com>) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <piyush@ditenity.com>; 1 Nov 2012 15:39:50 -0000
User-Agent: Microsoft-MacOutlook/14.2.4.120824
Date: Thu, 01 Nov 2012 16:39:55 +0100
From: Stefan Santesson <stefan@aaa-sec.com>
To: Piyush Jain <piyush@ditenity.com>, pkix@ietf.org
Message-ID: <CCB85537.52953%stefan@aaa-sec.com>
Thread-Topic: [pkix] Proposed resolution to non-issued certificates - 2560bis
In-Reply-To: <028f01cdb844$ca049fc0$5e0ddf40$@ditenity.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
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 <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pkix>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Nov 2012 15:39:54 -0000
As a short reply. No, the good response is still true from a very practical perspective. It is exactly as written. Secondly, Even if the major reason for allowing revoked for non-ussued certs is to detect/react to compromised CA situations, this does NOT mean that any request for a non-issued cert is caused by a compromised CA. It can simply be caused by a bug in the requesting client or a deliberate false request. It's therefore wrong to reply that the CA is compromised, unless you know that the CA is compromised. /Stefan On 11/1/12 4:23 PM, "Piyush Jain" <piyush@ditenity.com> wrote: > > >> -----Original Message----- >> From: Stefan Santesson [mailto:stefan@aaa-sec.com] >> Sent: Thursday, November 01, 2012 6:11 AM >> To: Piyush Jain; pkix@ietf.org >> Subject: Re: [pkix] Proposed resolution to non-issued certificates - >2560bis >> >> In-line; >> >> On 11/1/12 12:12 AM, "Piyush Jain" <piyush@ditenity.com> wrote: >> >> > >> > >> >> -----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. >> >> This is still true. >[Piyush]It is tree in theoretical sense, but incomplete and confusing. The >meaning of 'good' changes, if the responder returns revoked for >'fraudulently-issued' certificates. > In such cases, a positive proof implies that the certificate was issued. >Also, the last sentence in the above paragraph does not apply for such >responders. >> >> > >> >> 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. >> >> Absolutely not. The CA is not compromised just because I ask for a >>serial >> number that was never issued. > >[Piyush] All this time, the reason to propose this change has been that it >helps the situation where certificates are fraudulently issued. If the RP >is >not doing signature checking than this discussion is moot. If RP has >verified that signature is correct and CA thinks it is not issued, it is >caCompromise. >CA may be compromised or not. But this response is telling the RP that if >he >thinks that certificate is signed by the CA, then it implies that 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. >> >> Proposing to include it in the base standard. It can also be used to >measure >> whether an OCSP responder adopts this response behaviour even if the CA >>is >> not compromised. >> >[Piyush] This is something new. So what are the benefits of this if the CA >is not compromised? What value does it add over signature checking? >And I thought that in one of you previous emails you said that there was a >WG decision to limit changes to RFC 2560 to what is necessary to resolve >previous ambiguity. Don't know if that is still the case. >> >> >> >> >> >> >> 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. >> >> No, for reason above. >> >> > >> >> 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). >> >> It is not part of this work to update CRL processing or path validation. >[Piyush] Are you saying that there is no need to evaluate how this work >affects other standards created by pkix. >> >> >> >> >> 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. >> >> It is neither part of this work to update SCVP. Just to update OCSP. >[Piyush] SCVP does not need to be updated. It already has provisions for >what you are trying to duplicate in OCSP. >> >> /Stefan >> > > >_______________________________________________ >pkix mailing list >pkix@ietf.org >https://www.ietf.org/mailman/listinfo/pkix
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Stefan Santesson
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Piyush Jain
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Stefan Santesson
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Piyush Jain
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Stefan Santesson
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Piyush Jain
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Stefan Santesson
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Stefan Santesson
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Denis Pinkas
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Simon Tardell
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Denis Pinkas
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Denis Pinkas
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Piyush Jain
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Stefan Santesson
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Simon Tardell
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Simon Tardell
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Martin Rex
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Stefan Santesson
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Erwann Abalea
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Martin Rex
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Denis Pinkas
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Martin Rex
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Erwann Abalea
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Erwann Abalea
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Martin Rex
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Martin Rex
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Erwann Abalea
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Martin Rex
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Piyush Jain
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Erwann Abalea
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Peter Rybar
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Martin Rex
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Martin Rex
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Piyush Jain
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Martin Rex
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Martin Rex
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Piyush Jain
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Piyush Jain
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Piyush Jain
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Martin Rex
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Piyush Jain
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Martin Rex
- [pkix] Straw-poll on OCSP responses for non-revok… Stefan Santesson
- Re: [pkix] Straw-poll on OCSP responses for non-r… Yngve Nysaeter Pettersen
- Re: [pkix] Straw-poll on OCSP responses for non-r… Yoav Nir
- Re: [pkix] Straw-poll on OCSP responses for non-r… Erwann Abalea
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Miller, Timothy J.
- Re: [pkix] Straw-poll on OCSP responses for non-r… David Chadwick
- Re: [pkix] Straw-poll on OCSP responses for non-r… Art Allison
- Re: [pkix] Straw-poll on OCSP responses for non-r… Miller, Timothy J.
- Re: [pkix] Straw-poll on OCSP responses for non-r… Santosh Chokhani
- Re: [pkix] Straw-poll on OCSP responses for non-r… Erwann Abalea
- Re: [pkix] Straw-poll on OCSP responses for non-r… Yoav Nir
- Re: [pkix] Straw-poll on OCSP responses for non-r… Peter Rybar
- Re: [pkix] Straw-poll on OCSP responses for non-r… Paul Hoffman
- Re: [pkix] Straw-poll on OCSP responses for non-r… Juan Gonzalez
- Re: [pkix] Straw-poll on OCSP responses for non-r… Max Pritikin (pritikin)
- Re: [pkix] Straw-poll on OCSP responses for non-r… Simon Tardell
- Re: [pkix] Straw-poll on OCSP responses for non-r… Carl Wallace
- Re: [pkix] Straw-poll on OCSP responses for non-r… Paul Hoffman
- Re: [pkix] Straw-poll on OCSP responses for non-r… Rick Robinson
- Re: [pkix] Straw-poll on OCSP responses for non-r… Jeremy Rowley
- Re: [pkix] Straw-poll on OCSP responses for non-r… Melinda Shore
- Re: [pkix] Straw-poll on OCSP responses for non-r… Martin Rex
- Re: [pkix] Straw-poll on OCSP responses for non-r… Russ Housley
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Martin Rex
- Re: [pkix] Straw-poll on OCSP responses for non-r… Tom Ritter
- Re: [pkix] Straw-poll on OCSP responses for non-r… Dr Stephen Henson
- Re: [pkix] Straw-poll on OCSP responses for non-r… Ryan Sleevi
- Re: [pkix] Straw-poll on OCSP responses for non-r… Johannes Merkle
- Re: [pkix] Straw-poll on OCSP responses for non-r… Denis Pinkas
- Re: [pkix] Straw-poll on OCSP responses for non-r… Art Allison
- Re: [pkix] Straw-poll on OCSP responses for non-r… Ryan Hurst
- Re: [pkix] Straw-poll on OCSP responses for non-r… Ben Wilson
- Re: [pkix] Straw-poll on OCSP responses for non-r… Erwann Abalea
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Piyush Jain
- Re: [pkix] Straw-poll on OCSP responses fornon-re… Art Allison
- [pkix] Proposed resolution to non-issued certific… Stefan Santesson
- Re: [pkix] Straw-poll on OCSP responses for non-r… Tom Ritter
- Re: [pkix] Proposed resolution to non-issued cert… Tom Ritter
- Re: [pkix] Proposed resolution to non-issued cert… Stefan Santesson
- Re: [pkix] Proposed resolution to non-issued cert… David A. Cooper
- Re: [pkix] Proposed resolution to non-issued cert… Stefan Santesson
- Re: [pkix] Proposed resolution to non-issued cert… Piyush Jain
- Re: [pkix] New draft-ietf-pkix-rfc2560bis-06 Peter Gutmann
- Re: [pkix] Proposed resolution to non-issued cert… Stefan Santesson
- Re: [pkix] Straw-poll on OCSP responses for non-r… Phillip Hallam-Baker
- Re: [pkix] Proposed resolution to non-issued cert… David A. Cooper
- Re: [pkix] Proposed resolution to non-issued cert… Stefan Santesson
- Re: [pkix] Proposed resolution to non-issued cert… Piyush Jain
- Re: [pkix] Proposed resolution to non-issued cert… Stefan Santesson
- Re: [pkix] Proposed resolution to non-issued cert… Piyush Jain
- Re: [pkix] Proposed resolution to non-issued cert… Stefan Santesson
- Re: [pkix] Proposed resolution to non-issued cert… Piyush Jain
- Re: [pkix] Proposed resolution to non-issued cert… Peter Rybar
- Re: [pkix] Proposed resolution to non-issued cert… Simon Tardell
- Re: [pkix] Proposed resolution to non-issued cert… Stefan Santesson
- Re: [pkix] Proposed resolution to non-issued cert… Stefan Santesson
- Re: [pkix] Proposed resolution to non-issued cert… David A. Cooper
- Re: [pkix] Proposed resolution to non-issued cert… Piyush Jain
- Re: [pkix] Proposed resolution to non-issued cert… Peter Rybar
- Re: [pkix] Proposed resolution to non-issued cert… Simon Tardell
- Re: [pkix] Proposed resolution to non-issued cert… Stefan Santesson
- Re: [pkix] Proposed resolution to non-issued cert… Piyush Jain
- Re: [pkix] Proposed resolution to non-issued cert… Martin Rex
- Re: [pkix] Proposed resolution to non-issued cert… Martin Rex
- Re: [pkix] Proposed resolution to non-issued cert… Piyush Jain
- Re: [pkix] Proposed resolution to non-issued cert… Martin Rex
- Re: [pkix] Proposed resolution to non-issued cert… Piyush Jain
- Re: [pkix] Straw-poll on OCSP responses for non-r… Tom Gindin
- Re: [pkix] Straw-poll on OCSP responses for non-r… Phillip Hallam-Baker