Re: [pkix] Proposed resolution to non-issued certificates - 2560bis
"Piyush Jain" <piyush@ditenity.com> Thu, 01 November 2012 15:23 UTC
Return-Path: <piyush@ditenity.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 ACC3621F8AA2 for <pkix@ietfa.amsl.com>; Thu, 1 Nov 2012 08:23:09 -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 5xFVcra6chbO for <pkix@ietfa.amsl.com>; Thu, 1 Nov 2012 08:23:08 -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 AD74A21F8A91 for <pkix@ietf.org>; Thu, 1 Nov 2012 08:23:08 -0700 (PDT)
Received: by mail-ie0-f172.google.com with SMTP id 9so4252897iec.31 for <pkix@ietf.org>; Thu, 01 Nov 2012 08:23:08 -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=1pFAqVGLxrF/6SxAVNMA37m441/Pn0n98bqH7eGPEc8=; b=HwoAECAU8T7SvpiT0TUYPz4hNdUl0+y1W1L0y7PmxFk5AFYjFcS74z0AFxpXlknaLE 0Umay1rD7L4p5hTZKd5IwaEagWundSQ1nst2hcBX6nmpGsBRtcycgRtDLHXG//cDMeTs ToxWvgdtDW1B5y1rIkolm8Pd8psHoiuJvf0S9xVWP+KcR7zKN468R8jSRrnfs4iNoNmA i4E/wdeh8uBILngR9MtbNo+shKLBworm3zuja/XgrWH4sMmtxRAL5sZKGpg2TZFGWF0f vc3A63QjBcFraTqzYtEKk1cjUO5D+ifz+hjjSxxzm/KixXAtBn7oWt5RBknOsdvSw5ex KFlg==
Received: by 10.50.104.230 with SMTP id gh6mr1674343igb.13.1351783387975; Thu, 01 Nov 2012 08:23:07 -0700 (PDT)
Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id c3sm13196397igj.1.2012.11.01.08.23.05 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Nov 2012 08:23:06 -0700 (PDT)
From: Piyush Jain <piyush@ditenity.com>
To: 'Stefan Santesson' <stefan@aaa-sec.com>, pkix@ietf.org
References: <01fc01cdb7bd$43c183b0$cb448b10$@ditenity.com> <CCB8316E.52919%stefan@aaa-sec.com>
In-Reply-To: <CCB8316E.52919%stefan@aaa-sec.com>
Date: Thu, 01 Nov 2012 08:23:02 -0700
Message-ID: <028f01cdb844$ca049fc0$5e0ddf40$@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: AQLU4WFp3f163IB454sKDouJC1jNhZXGvLOw
Content-Language: en-us
X-Gm-Message-State: ALoCoQnV3SDiK/G0qAIjBDtszzENqYLDgDNYO4AvV8VyKvhAqKDjXoDXiHQOoF0AbdZpoeK5bgKK
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:23:09 -0000
> -----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 >
- 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