Re: [pkix] New draft-ietf-pkix-rfc2560bis-06
"Piyush Jain" <piyush@ditenity.com> Fri, 19 October 2012 17:34 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 1309E21F870C for <pkix@ietfa.amsl.com>; 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 <pkix@ietfa.amsl.com>; 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 <pkix@ietf.org>; Fri, 19 Oct 2012 10:34:35 -0700 (PDT)
Received: by mail-ia0-f172.google.com with SMTP id o25so594066iad.31 for <pkix@ietf.org>; 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 <piyush@ditenity.com>
To: 'Stefan Santesson' <stefan@aaa-sec.com>, 'Peter Rybar' <rybar@nbusr.sk>, 'Carl Wallace' <carl@redhoundsoftware.com>, 'Simon Tardell' <simon@tardell.se>
References: <201210191312.q9JDCHnw046175@mail.nbusr.sk> <CCA72D90.51884%stefan@aaa-sec.com>
In-Reply-To: <CCA72D90.51884%stefan@aaa-sec.com>
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' <peterryb@gmail.com>, 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 <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: Fri, 19 Oct 2012 17:34:42 -0000
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
- 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