Re: An alternative proposal Was: Fwd: New Version Notification for draft-hamilton-cmr-00.txt
Kyle Hamilton <kyanha <at> kyanha.net>
2011-11-01 22:22:14 GMT
Again, please: Do not let perfection become the enemy of any improvement at all.
On Thu, Oct 27, 2011 at 12:59 PM, Peter Sylvester <peter.sylvester <at> gmail.com> wrote:
> you just can add an extension that says "when I said revoked, it really
> means more, it doesn't even exist"
True. I suggest something like this elsewhere in the thread.
(At least there are some discussions going on now.)
>> The OSCP responder does not need access to the CA, just a list or set of
>> lists for all the issued certificates.
...such as my proposal...
> It needs some information that can be used to verify if a cert had been
> issued.
> a strong one way function (in oder to avoid the word hash) towards that info
> to see
> whether a cert is valid for example.
I like the 'for example', as it implies that there are other ways to approach the problem. (I prefer the term 'digest'.)
As I said, I propose what I do simply so that an extremely easy-to-implement (copy+paste with minimal
editing) incremental improvement can be made. I believe that reducing the threat space[1] with a
mechanism that enforces desirable semantics[2] in a way that people already understand[3] is
preferable to requiring a major version bump at the least, much less additional debugging time before
being ready to roll out to the public... and that only after PKIX finally standardizes something it hasn't
been able to in the past decade, with additional mandates that don't address what the applications need
and can implement /right now/.
I believe that it's more desirable to get people in the mood to improve things at all with small,
easily-understandable engineering steps, than to demand that they accept yet another overblown
"standard" that achieves at best the zero security effect of no implementation and at worst the negative
security effect of immature technology failure during its roll out. Once we get the implementers in the
mode of looking for a whitelist, we can improve it with strong ID data for issued certificates and provided
as a CRL/CMR extension. Maybe something like:
-- contains one entry for each certificate
CertificateIssuanceList ::= SEQUENCE (0..MAX) of CertificateIssuanceEntry;
-- contains multiple algorithm/digest tuples for one certificate
CertificateIssuanceEntry ::= SEQUENCE (0..MAX) of CertificateIssuanceAtom;
-- individual algorithm/digest tuple
CertificateIssuanceAtom ::= SEQUENCE {
DigestAlgorithmOid OBJECT IDENTIFIER,
DigestValue OCTET STRING }
This would permit the same certificate to be identified strongly with multiple digest algorithms, which
would permit stronger verification by a wider variety of clients than provided by a single algorithm. RPs
would ignore hashes with algorithms they don't trust, and the CA could provide multiple hash values for
diverse consumers with the same semantics in the same structure. (Personally, I'd check all of them,
under the theory that they will all test true even if I can't rely on the security of any one or more of them. If
there's any mismatch at all, even in the broken digests, then something's wrong.) Notably, it wouldn't
disclose the serial number of the matching certificate.
In the meantime, though, there's no reason that the CRL couldn't be usefully extended with 'removeFromCrl'.
The DigiNotar sleepwalk attack is going to become a much larger problem unless we take action now to stop it,
and Mozilla will not do anything without standards body backing. Please, I know that this isn't optimal or
ideal, but it's an important first step to improving the infrastructure as a whole.
Incremental improvement, not perfection or bust. PKIX-WG was wrong 10 years ago about what it thought the
perfect and ideal system would be, and there's no chance that any new monolithic standard will correctly
predict the future 10 years from now. There are major problems which prevent the PKIX standards from
taking root, and the body's inflexibility and unwillingness to accept that its standards are broken in
fundamental ways is the reason they have remained unaddressed. That self-reverential "reality should
be this way" view prevents it from considering or accepting incremental changes to help address -- as
stopgap measures -- the security holes which permitted the compromise of a CA to cause a person's death.
PKIX-WG was warned about this vector in the past, and did nothing to defe
nd it.
Let's look at the costs of a public CA distrust:
- the CA's death, thus the deprivation of a taxpayer and lower tax revenues from its newly-unemployed
employees, and thus a Gross Domestic Product hit for the entire state.
- the costs to every site enrolled in the CA's PKI of having to get recertified immediately, which is an
instant priority given that browser users (presumably and hopefully) won't go to uncertified sites.
They can't make sales during the time they're uncertified, and each will instantly lose a portion of their
customer bases as a result.
- the costs to every other CA which must have enrollment channels sufficient to handle the influx of new enrollees.
- the costs to everyone who uses or shops at the sites newly uncertified. Imagine if Thawte SGC CA or Equifax
Secure CA were compromised. (Not familiar with Thawte SGC CA? That's the one that issues to
mail.google.com. Equifax Secure CA issues to docs.google.com.)
- the costs to the entire CA/Browser trust model and consumer confidence.
We cannot sit back and say "that's the cost the certified party pays for choosing a poorly-run CA". There are
simply far too many people who are affected, with far too much cost to each one. (Besides, even audited CAs
make mistakes. The only thing that consumers have to rely upon are audits, and those audits obviously
don't catch everything. We should allow them to continue to do their job, and provide them a means to help
end entities/relying parties protect themselves.)
-Kyle H
[1] Implementations MUST be able to handle serial numbers up to 160 bits, or 20 bytes. (Notably, a serial
number might require a 21-byte encoding, since it's an integer and not a bit string or octet string.) This
means that the threat space for CAs which enforce random serial numbers is (exp(2,160) - count(CRL)), or
(with 65,536 entries on the CRL) around 2**146. The threat space for CAs which alter their CRLs to this spec
is becomes (count(CRL,entriesRemoved)), which instantly removes 2**152 or so possibilities.
[2] Desirable semantics include "if a particular serial number on this list is found to have an invalid
certificate associated with it, the CA can instantly and decisively take action by revoking and
reissuing where appropriate", and "the CA knows that this list is more accurate than providing simple
revocation data." Additional desirable semantics are the capacity for internal OCSP to answer for
serial numbers[4] known to not be in the list as "never issued". If the generation of this list were
periodically entry-by-entry verified in a process completely separate from the technical operation of
the CA, it could provide an extra, affirmative, records-based and thus not easily technically defeated
approach to increase the probability of detecting CA compromise, and for both the enrollee an
d the RP successfully defending against CA compromise.
[3] People understand the CRL. More importantly, implementors understand the CRL. We should build on what
we've got. Once one gets past idealistic preconceived notions of "this is what this is for and never
anything more because it just is" and starts looking toward making it all work, one understands that the
best changes are the least changes in an already overly-complex and over-budget system of dubious actual utility.
[4] Once a spec comes out (still waiting for I-Ds) that will permit the stronger authentication of
certificates, it will be a major implementation task for an immature technology. In the meantime, some
protection -- and it is protection, for both the CA and the end entities involved -- is better than none. Do
not let the perfect become the enemy of the good.
_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
RSS Feed