Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15
Sean Turner <turners@ieca.com> Mon, 08 April 2013 20:22 UTC
Return-Path: <turners@ieca.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 38FCB21F89DB for <pkix@ietfa.amsl.com>; Mon, 8 Apr 2013 13:22:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.225
X-Spam-Level:
X-Spam-Status: No, score=-102.225 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mddRLKVAxFl1 for <pkix@ietfa.amsl.com>; Mon, 8 Apr 2013 13:22:41 -0700 (PDT)
Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com [67.18.21.25]) by ietfa.amsl.com (Postfix) with ESMTP id BC35A21F8887 for <pkix@ietf.org>; Mon, 8 Apr 2013 13:22:38 -0700 (PDT)
Received: by gateway14.websitewelcome.com (Postfix, from userid 5007) id E479FBB6549D9; Mon, 8 Apr 2013 15:22:34 -0500 (CDT)
Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway14.websitewelcome.com (Postfix) with ESMTP id D2D3ABB65498A for <pkix@ietf.org>; Mon, 8 Apr 2013 15:22:34 -0500 (CDT)
Received: from [108.45.16.214] (port=53217 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from <turners@ieca.com>) id 1UPIaL-0002vt-Lh; Mon, 08 Apr 2013 15:22:37 -0500
Message-ID: <5163270C.20300@ieca.com>
Date: Mon, 08 Apr 2013 16:22:36 -0400
From: Sean Turner <turners@ieca.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Piyush Jain <piyush@ditenity.com>
References: <003e01ce3077$5b6329f0$12297dd0$@ditenity.com> <20130403160532.EB4FD1A68A@ld9781.wdf.sap.corp> <00a401ce3092$0a1415d0$1e3c4170$@ditenity.com>
In-Reply-To: <00a401ce3092$0a1415d0$1e3c4170$@ditenity.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) [108.45.16.214]:53217
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 7
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20=
Cc: ambarish@gmail.com, slava.galperin@gmail.com, cadams@eecs.uottawa.ca, 'Stefan Santesson' <stefan@aaa-sec.com>, "'Black, David'" <david.black@emc.com>, sts@aaa-sec.com, pkix@ietf.org, gen-art@ietf.org
Subject: Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15
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: Mon, 08 Apr 2013 20:22:47 -0000
Piyush, (David's on the "to:" line because the text in question showed up as a result of the gen-art review and it's now in -16) I've been following this thread trying to figure out what if anything needs to be changed to address your concerns in -17. (Note the thread forked later, but I'm addressing the "times" issue in another thread.) The sentence in questions was added to address the gen-art review is the following (it's in a "note" paragraph and there's actually more to it): The "revoked" status is still optional in this context in order to maintain backwards compatibility with deployments of RFC 2560. 1) The first bit I'd like to discuss is this part of your concern: And it gives the impression that best course of action for 2560bis responders is to start issuing revoked for "not-issued", which is far from the originally stated goal to provide a way for CAs to be able to return revoked for such serial numbers. and: I believe that Stefan is trying to convey that requiring servers to return revoked in this context will make them non-compliant with 2560 and 5019 as opposed to breaking interoperability with legacy clients. I honestly don't see how you get to your impression, because the 2119 language about when a responder might used revoked for not-issued is: This state MAY also be returned if the associated CA has no record of ever having issued a certificate with the certificate serial number in the request, using any current or previous issuing key (referred to as a "non-issued" certificate in this document). MAY being the operable word here. That's clear to implementers because if you read 2119 for MAY it says: This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. ... For me this seems clear because the 2119 language trumps any note. Even Stefan's response to David a couple of days earlier than when you posted this concerns includes: In theory we could possibly say that responding revoked is optional, but if you choose between revoked and unknown then you SHOULD favour revoked over unknown. But such nested requirements just feels bad and impossible to test compliance against. I'd much rather just leave it optional. I'm not sure what else could be added to alliveate your concern on this point. Maybe this one got over taken by events? 2) The second bit of your concern is that this is not an accurate characterization of the WG's rationale for the choices made. This concern is easier to evaluate and I agree that it is important to capture the actual rationale. I think you've suggested that the following: "maintain backwards compatibility with deployments of RFC 2560" be replaced with: "maintain compliance with RFC 2560 and RFC 5019" Using the word "compliance" might set of an entirely new debate. Servers/clients can claim compliance if they want to but I'm not sure that the primary goal was for a document to claim compliance with another set of RFCs. These drafts for interoperability and that would lead me to compatibility and not conformance. spt On 4/3/13 1:38 PM, Piyush Jain wrote: >> No, it does not make any sense at all. An error code is unsigned and can > be >> easily inserted into the communication by an attacker. > > [Piyush] Funny that you make this argument. How does returning a signed > revoked address this? Attacker can still replace signed revoked with an > UNSIGNED TRY_LATER. > >> These kinds of argument are based on two very flawed premises: >> >> (1) the premise that there exist only two possible states for a CA: >> (a) safe and pristine >> (b) full and thorough compromise of each and everything > [Piyush] NIST has addressed RA compromise and CA key compromise separately > so this is not true. > And you have not listed what other breaches you are trying to address > offering revoked for non-issued as the silver bullet for all those unknown > security breaches. > You tendency to allude to vague problems to justify a particular solution, > couple with a reluctance to engage in a discussion regarding the security > implications continues to amuse me. List the other states and have a > discussion around how this solution solves those problems.> >> (2) that a huge PKI (100k+ entities) can be nuked and >> re-personalized after a CA compromise at close to zero cost and >> within the blink of an eye > > and both premises exhibit a throrough cluelessness about security, risk >> management and the real world. > > Let's get this right. > Only possible benefit of revoked for non-issued exists when there are CA > SIGNED certificates floating in the wild and CA has no clue that it has > issued it and therefore cannot revoke it. > > Now, to say that clients are secure and CA can continue to operate if it > issues revoked OCSP response for such certificate indicates cluelessness > about security. > > Customers pay a lot of money for certificates for which the marginal cost of > issuance is almost 0. CAs obligation is to make sure that they are secure > and to address any breach securely. > To say that customers will tolerate a CA security breach just because it > issues revoked for non-issued and continues to publish CRLs that imply > fraudulent certificates as good indicates cluelessness about risk management > and real world. > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix >
- [pkix] Gen-ART review of draft-ietf-pkix-rfc2560b… Black, David
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Stefan Santesson
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Sean Turner
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Black, David
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Stefan Santesson
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Stefan Santesson
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Stefan Santesson
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Black, David
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Black, David
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Black, David
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Stefan Santesson
- Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15 Piyush Jain
- [pkix] Gen-ART review of draft-ietf-pkix-rfc2560b… Black, David
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Piyush Jain
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Stefan Santesson
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Piyush Jain
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Piyush Jain
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Stefan Santesson
- Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15 Martin Rex
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Piyush Jain
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Stefan Santesson
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Piyush Jain
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Stefan Santesson
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Piyush Jain
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Black, David
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Black, David
- [pkix] review of draft-ietf-pkix-rfc2560bis-15 Peter Rybar
- Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15 Stefan Santesson
- Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15 Piyush Jain
- Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15 Martin Rex
- Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15 Martin Rex
- Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15 Piyush Jain
- Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15 Martin Rex
- Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15 Andris Berzins
- Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15 Piyush Jain
- Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15 Andris Berzins
- Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15 Martin Rex
- Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15 Piyush Jain
- Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15 Stefan Santesson
- Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15 Martin Rex
- Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15 Peter Rybar
- Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15 Martin Rex
- Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15 Peter Rybar
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Martin Rex
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Piyush Jain
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Martin Rex
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Piyush Jain
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Sean Turner
- Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15 Sean Turner
- Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15 Martin Rex
- Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15 Peter Rybar
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Piyush Jain
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Piyush Jain
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Sean Turner
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Piyush Jain
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Black, David
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Stefan Santesson
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Piyush Jain
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Black, David
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Piyush Jain
- Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2… Stefan Santesson