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

From: "Kyle Hamilton" <[email-masked]>
Date: Tue, 10 Aug 2010 14:45:07 -0700 (PST)

On Tue, Aug 10, 2010 at 7:06 AM, Kemp, David P. <[email-masked]> 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

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 10 Aug 2010 19:13:13 -0400

-----Original Message-----
From: Kyle Hamilton [mailto:[email-masked]] 

> 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.)

What does this have to do with CRLs or PKIX?  You could stand up a
repository right now (or just use the wayback machine) that responds to
queries by date/time for anything you wish to archive, including CRLs.

> 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.

Can you point to the RFC 5280 section that calls for Relying Parties to
behave as you describe?

Section 6.3.3 says "This algorithm begins by assuming that the
certificate is not revoked."
Section 6.3.3 (a) (1) (ii) says: "Update the local CRL cache with a
current complete CRL, verify that the current time is before the next
update value in the new CRL, and continue processing with the new CRL."

What I don't see is any text that requires or suggests that RPs preserve
state from previous CRLs, and any such text would be in conflict with
the initialization process.

A CA that removes a serial number from a CRL before the certificate
expires is not PKIX-compliant.  But an RP that received such a
non-compliant "corrected" CRL would assume that the certificate is not
revoked.

> 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.

Certificates can be used both offline and online, unlike mechanisms that
can be used only online (i.e. that require interaction with a server
before a user can be authenticated).  If an authentication server has
high latency or is not 5 9's reliable, certificate-based authentication
can proceed immediately whereas interactive authentication would stall
waiting for the server to respond or come back up.

> If you need real-time status, you cannot rely on certificates.

This is both a non-sequitur and patently false.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 11 Aug 2010 15:12:40 +1200

"Kyle Hamilton" <[email-masked]> writes:

>DQoNCk9uIFR1ZSwgQXVnIDEwLCAyMDEwIGF0IDc6MDYgQU0sIEtlbXAsIERhdmlkIFAuIDxEUEtl
>bXBAbWlzc2kubmNzYy5taWw+IHdyb3RlOg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K
>PiBGcm9tOiBUb21hcyBHdXN0YXZzc29uDQo+DQo+PiBPbiAwOC8xMC8yMDEwIDA4OjQ0IEFNLCBQ
>ZXRlciBHdXRtYW5uIHdyb3RlOg0KPj4+DQo+Pj4gT0NTUCBpc24ndCB0aGF0IHNpbXBsZSwgaXQn
>cyBhY3R1YWxseSBxdWl0ZSBjb21wbGljYXRlZCBmb3Igd2hhdCBpdA0KPiBkb2VzLiCgVGhlDQo+
>Pj4gcmVhc29uIGl0IGdldHMgdXNlZCBpcyBiZWNhdXNlIGl0J3Mgbm90IENSTHMuDQo+Pj4NCj4+

Interesting, I'd never considered the misrevocation issue.  Is this a real
problem though, or just (one of many) conceptual issues with periodic-
blacklist-based validity checks?

(Given that fact that revocation checking barely works anyway - I'm still
waiting for the Realtek malware cert to be regarded as revoked by software a
month after the CA declared it revoked - I'd say that it's not such a big
concern, but only because of the nonfunctionality of the revocation mechanism
as a whole).

>IHRoZSBDUkwgd2l0aCBrZXlDb21wcm9taXNlIGFzIHRoZSByZWFzb24sIHNvbWVvbmUgZG93bmxv
>YWRzIGl0LCB0aGUgZXJyb3IgaXMgY29ycmVjdGVkIChhbmQgdGhlIHNlcmlhbCBudW1iZXIgb2Yg
>dGhlIGluY29ycmVjdCBjZXJ0aWZpY2F0ZSByZW1vdmVkIGFuZCB0aGUgY29ycmVjdCBvbmUgYWRk

Drifting rather off topic here, but I think attribute certs are a lost cause,
and have been for years.  If you really want a PMI, use your X.509 cert to
sign some SAML, which is well-supported and gives you what you need (and far
more than an attribute cert ever can).

Peter.

---

From: Matt McCutchen <[email-masked]>
Date: Wed, 11 Aug 2010 01:28:01 -0700

On Tue, 2010-08-10 at 14:45 -0700, Kyle Hamilton wrote:
> 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).

Cookies do some things that TLS sessions don't: they can persist for
years and be scoped to domains.  They also got to market first.  I have
a hard time blaming PKIX for not winning webmasters away from them.

> 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.  [...]

Is it really PKIX's job as a technical working group to define OV?

> 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.

<tangent>
This is unfair to the browser makers.  I'll refer to Mozilla since I'm
most familiar with them.  Given current technology, they are doing the
best they can, trying to admit CAs according to a consistent set of
criteria.  They must assess the costs and benefits of recognizing more
CAs differently than you, given their broad user population.  As always,
you're welcome to remove some or all CAs.
</tangent>

> There is no reason for this, other than that PKIX fails to address the
> real problems underlying the Internet's lack-of-identity-authenticity.

> There *is* no Universal Font of Trust.

I would welcome work to design and implement system that doesn't require
a set of universally trusted public CAs.  SPKI looks like the right
approach.  In the meantime, there are benefits to using the public CA
system for all but one's most sensitive communications.

> 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.

That's unfair.  TLS with server-only authentication has some significant
uses, including anonymous integrity-protected retrieval of information.
The prefix-injection attack was the result of an oversight in the design
of TLS, which was corrected in a straightforward way.

> (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?

Nonsense.  With PKIs at the organizational level, standardizing the
technology still means that each organization doesn't have to reinvent
it for themselves (possibly insecurely) and that a user can use the same
client software to interact with many organizations and have it just
work.  For that matter, HTTP is only practiced by pairs of machines at a
time.

-- 
Matt

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 12 Aug 2010 10:54:10 -0700

> work.  For that matter, HTTP is only practiced by pairs of machines at a

Since (unlike most X.509) most Kerberos service is deployed at the organizational level, can I interpret this as an argument in favor of KX509?  ;-)

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]