Re: [TLS] [pkix] Previous attempt to update OCSP

"Kyle Hamilton" <aerowolf@gmail.com> Tue, 10 August 2010 21:44 UTC

Return-Path: <aerowolf@gmail.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 136F628C0D9; Tue, 10 Aug 2010 14:44:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.918
X-Spam-Level:
X-Spam-Status: No, score=-0.918 tagged_above=-999 required=5 tests=[AWL=-0.072, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7vPq2KMulvv; Tue, 10 Aug 2010 14:44:38 -0700 (PDT)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 15D953A6AE3; Tue, 10 Aug 2010 14:44:37 -0700 (PDT)
Received: by ewy22 with SMTP id 22so4694739ewy.31 for <multiple recipients>; Tue, 10 Aug 2010 14:45:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:date:message-id :subject:in-reply-to:references:mime-version:content-type; bh=/F/Ibzq9CI5skYo1gfz6tT2R3onlqbqVOBTUuIufOqI=; b=N3YEQU9JRM9p19T9iUMqk5hDm7NZSy0xrlbvWYPuAnK7HABgBXinKwhVnBT5I1qQJp LtZz8NTopcceSTU5dSHtpgkxLsBpUaagCRPQKF0RN+bRul/6auYFEK/vVYBpsRi65tS4 xPzGqdRDVuwM6bhg532Z2LHsXNG6OBnZ6tuT0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:date:message-id:subject:in-reply-to:references :mime-version:content-type; b=MUgiS2AkfR/ISmLWFvrn5yr2sPg1PigCTgQ28UgZFkjrzra90IlVzNXc6sBBoQwRHc 26kNg6NaP8FMX5F1C4CgyVB4xmFQmpRhQWRNNyT6c6GxaXCYVmD5AZ4BQK1CQmv36C1I qAV2GRLUmgsotjK+Lzg7YfqzJPvqki49Ex9jk=
Received: by 10.213.4.145 with SMTP id 17mr4873500ebr.17.1281476712853; Tue, 10 Aug 2010 14:45:12 -0700 (PDT)
Received: from [127.0.0.1] (c-76-103-146-6.hsd1.ca.comcast.net [76.103.146.6]) by mx.google.com with ESMTPS id v8sm10487867eeh.20.2010.08.10.14.45.09 (version=SSLv3 cipher=RC4-MD5); Tue, 10 Aug 2010 14:45:11 -0700 (PDT)
From: "Kyle Hamilton" <aerowolf@gmail.com>
To: "Kemp, David P." <DPKemp@missi.ncsc.mil>
Date: Tue, 10 Aug 2010 14:45:07 -0700 (PST)
Message-ID: <gcpa57emw0794q0kx3jezwJv4X.penango@mail.gmail.com>
In-Reply-To: <4C573E09.1060700@nist.gov>
References: <4C573E09.1060700@nist.gov>
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; charset=x-user-defined; boundary=gmsm1.4.5eqgcpa57m7fs9dxwqvxr2
Cc: pkix@ietf.org, tls@ietf.org
Subject: Re: [TLS] [pkix] Previous attempt to update OCSP
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Aug 2010 21:44:40 -0000


On Tue, Aug 10, 2010 at 7:06 AM, Kemp, David P. <DPKemp@missi.ncsc.mil> wrote:
> -----Original Message-----
> From: Tomas Gustavsson
>
>> On 08/10/2010 08:44 AM, Peter Gutmann wrote:
>>>
>>> OCSP isn't that simple, it's actually quite complicated for what it
> does.  The
>>> reason it gets used is because it's not CRLs.
>>>
>> I totally buy that OCSP is used because there is nothing worse than
> CRLs.
>
> Nothing is worse than 10 MB CRLs over LDAP.  But nothing, including OCSP
> or RTCS, could be better or simpler than 10 KB CRLs over HTTP, thus
> taking advantage of the entire web caching infrastructure.  The fact
> that CRLs have been poorly deployed throughout their entire existence is
> not an indictment of the CRL's elegant (for PKI) data structure; both
> OCSP and any CMS-protected data are far more bloated.

If the CRL actually included semantics as to "was a particular certificate valid at a particular date/time", I'd agree with you about their elegant data structure; as it is, though, there's at least two problems I see:

1) CRLs allow expired certificates to "fall off", which prevents anything but the first CRL after the expiration of the certificate from being a time-based authority as to the status of the certificate during its nominal notBefore/notAfter timeframe.  (If I had the ability to specify the "next generation" of CRLs, I'd ensure that there was an 'archive' mechanism, where someone could query for the CRL of a given time.)
2) CRLs suffer a particular issue called "misrevocation".  i.e., the wrong certificate gets added to the CRL with keyCompromise as the reason, someone downloads it, the error is corrected (and the serial number of the incorrect certificate removed and the correct one added), and now any client that didn't get the mis-issued CRL will work properly with the mis-revoked certificate, but the clients that implement strict CRL semantics will never work properly with the mis-revoked certificate again.  This can't be fixed by adding the incorrect serial number with 'removeFromRevocationList' as the reason code, as rFRL is only specified as valid with delta CRLs.

>> RTCS sounds quite reasonable though, I like the re-use
>> of CMS and the high speed/high volume design. Do you see any
>> chance of actually promoting a new protocol and get it widely adopted?

If we need real-time credential status, why are we using certificates?  They were *specifically* created by the ITU nee CCITT as a means to provide *offline* -- that is, *no available connection to the recorder* -- reliable credentials.  If you need real-time status, you cannot rely on certificates.  You must do the "verify with privilege management authority" thing; the only reason why PKIX has to be implemented is because TLS requires it as the only mandatory authentication scheme.

Otherwise, if you need real-time identity and privilege status, the only thing that should exist is an empty X.509 structure with nothing more than the key and the Issuer therein.  You can get the rest of the data associated with the key from the Issuer by using the key as an index into the Issuer's record, without having to clog up the rest of the system.

(I'll note that I've gotten my head chomped by Nelson Bolyard of NSS for having the temerity to suggest that TLS should allow for PEM/base64-encoded certificates in the protocol -- because it causes a 33% data size increase, and the ease of traffic content analysis for a sysadmin who's trying to understand why a given server is failing.  I'm now suggesting dropping at least 3/4 of the information in the certificate, because it can be obtained online much more easily and authoritatively than via a data structure which was designed for offline, no-real-time-status-availability use.)

PKIX fails to meet many (and, it could be argued, even 'most') of its stated goals.  More "patchy protocols" have grown around PKIX than anything else, including HTTP (which has the 'cookie protocol' to try to make up for its lack of pure session support).  There is no support for Attribute Certificates in PKIX, and PKIX grants extendedKeyUsage capability far too liberally to be anything other than an extremely efficient means for public CAs to extort more money from an unsuspecting populace.  ($450 for a certificate to sign PDF files?!)

Also, PKIX's lack of prescribing minimum standards for verification has led to a problem where neither Penango (an in-browser S/MIME client with certificate verification capability) nor Qualys's SSLLabs Server Certificate Survey can determine from a technical standpoint that anything more than a domain or an email address has been verified.  Because these products _only_ display what they can absolutely know, the absolute minimum which can be certified by a CA, there is no benefit at all to increasing the Class of certificate one obtains.  To provide an example of this, I have had state taxing authorities use domain-validated certificates (instead of Organization-Validated) on their websites, to save taxpayer money.  There's no differentiation in the UI, so why should they bother with OV?

(In my case, I have a Class 2 validation through StartCom.  The benefits I'm provided with are my name and city in my email certificate, a 2-year code-signing certificate and wildcard, multi-domain server certificates.  The code-signing certificate is just another example of "extendedKeyUsage" abuse; the last is only slightly less damaging to think about.)

Just because I know who CA A says EE B is doesn't mean that I automatically grant access to B, and I don't necessarily trust A's assertion as to B's identity anyway.  That decision is taken out of my hands by the people who make browser software, and add trust by default to organizations that I have no knowledge of.  There is no reason for this, other than that PKIX fails to address the real problems underlying the Internet's lack-of-identity-authenticity.

Essentially, PKIX is a failure.  It failed to create mutual-authentication systems that were widely deployed, which led to the prefix-injection attack against TLS on the public Internet to be exploited.

(When -- if ever -- is the PKIX WG going to realize that the spec it has created has no place on the open Internet, and only has appropriate scope to be deployed in a particular administrative domain -- and thus is outside of the scope of Internet standards organizations?  There *is* no Universal Font of Trust.  The ITU operates a CA, and they don't even certify people or organizations they can't verify above and beyond a simple email or domain validation check -- and their CA is *not* PKIX-profiled.)

In fact: X.509 is primarily about an identity infrastructure.  The PKI must exist before the Privilege Management Infrastructure, but the PKI is NOT any kind of PMI.  Until the PMI is defined -- which is exceptionally out-of-scope for the IETF -- no privileges should be able to be granted due to flags set by a CA on a particular certificate.

-Kyle H