On Monday 23 May 2005 22:31, Julien Pierre wrote:
> Ian G wrote:
> >>Revocation checks cannot be done at the root level, by definition. The
> >>standards don't allow support for revocation checking of self-signed
> >> certs.
> >
> > Oh... so it's written in the standard. Are you
> > saying that the standard defines no way to revoke
> > a lost CA root? Or that it is impossible to revoke
> > a CA root? They are two entirely different things.
>
> I'm saying the standard defines no way to revoke a lost CA root,
OK, got it.
> because
> it doesn't make sense. When a root is compromised, there is no PKI
> standard that can fix this.
OK, so I understand that the standards do not address
this. The question then is why not?
It makes no sense to me. I come from a more financial
background when it comes to use of crypto systems
(I build payment systems and trading systems) and I
can state with very high confidence that any system
that has a single point of failure is not going to go far.
This would seem to be a perfect case of a single point
of failure. Lynn Wheeler, who possibly knows more
about the finance / crypto / payments / reliance /
governance world than any other person on the
planet (including any three writers of any three
standards) seems to agree.
So there's the motive - no single point of failure.
But why doesn't it make sense? A root cert can sign
itself a revocation cert, and that can be distro'd any
of a dozen ways. Once seen, that revocation is
sticky, obviously, and it really doesn't matter what
the other holders of the root sign, the revocation
overrides any other statement. So we are in a race
against the other holders, but life's not perfect, and
we already gave up the perfection in this case.
Further, the revocation could be from a particular
date. I'm not sure if this is in the PKI standards or
not, but if I lose my root on tuesday, I simply sign
and date the revocation from tuesday. Which means
that any cert signed after that is invalid, and any
cert before that retains validity.
To me this sounds like common sense.
(You intimate above that *self-signed certs* cannot
be checked for revocation. Maybe the standards
just thought to exclude self-signed certs for whatever
reason of disliking them and root keys got caught up
in that. But root keys and their root self-signed certs
would have to be an exception to the general case
of self-signed certs.)
(A lot of what you've written makes sense, so I've
snipped it for brevity.)
> > Please explain why a self-signed certificate cannot
> > sign a revocation of itself? It's not as if you care if
> > a thief does it to you...
>
> Because that statement would offer no assurance if it came out as
> negative (not revoked response).
That just means you haven't received the revocation
as yet. We are asking in the wrong place. So we
have a distro issue - which is well recognised. But
it's the same distro issue as for other revocations,
it is exactly the same as for CRL/OCSP. No?
> If the root is compromised, then the root key thief is always going to
> make that statement come out as not revoked, unless he is incompetent.
Sure, but that is implying that the root thief takes
total control over _all channels of access_ as
well as just a copy of the root key. This seems
implausible, or an indication that we are looking
at a complete meltdown of the company, not just
the compromise of the special floppy disk. In
which case the root is not compromised but the
company is. That's a competely different story,
because then the root is still valid, it's the company
that is compromised.
Or it means that a revocation itself can be over-
ridden. To me, that makes no sense.
> Thus, checking for that statement is useless. It offers no benefit over
> not making a check at all, because a negative is no guarantee of
> anything whatsoever.
No, we only need to get that one revocation. If
a root is compromised, then it seems reasonable
to expect that there are many channels to deliver
the recovation by.
> You need to check for the state with another party that you trust. But
> there is no one above the root.
What you say is a simplification. There is someone
above the root key and that is the identity themselves. In
all forms of commerce, in all legal senses, in all systems
of communication, the individual can generally override
the system by simply declaring "stop." A signed and
notarised statement from the issuer themselves has legal
effect, and will sit above the root key.
Which is to say, in the PKI there is no mechanism for
an external statement to be fed in manually to override
the root key. Seen in this context, this is not common
sense, not theory or practice, but more a shortfall or a
bug in PKI.
(To be honest, in the systems I have built, the roots
could not be revoked either. But that's because we
never got around to it. It was a shortfall, a feature to
be added later, when we ran out of more important
things to do.)
> Thus, you need to resort to external
> mechanisms, such as manual user revocation / disabling of roots, or a
> software update (you trust the manufacturer of the client ...).
Right, and this is an important observation. There are
many channels to get the information out:
* manual revocation - put an advert in the Times
* drive-by website revocation - put the revocation
in every major website, deliver it with new certs.
* peers' CRLs and OCSPs - ask the other CAs to
include the revocation
* software updates and patches - use the emergency
bug fix channels for the browser
* viral - shove it in an email and send it out with
a suggestion to forward this to everyone :-)
All with their associated pros and cons.
> The reasons probably had to do with liability, as they were a business.
(Just on this one point.)
I'm afraid we have to model Mozilla as a business
as well. Just because it is incorporated as a not-
for-profit doesn't mean it isn't a business, and doesn't
take on liability. Mozilla takes on revenues for doing
commercial activities and to all intents and purposes
competes in the market place for advertising revenues,
so the fig leaf of not-for-profit is not really sufficient.
Also, the politely different facade of not-for-profits is
practically eroded these days in the US due to various
tricks and scams that have been played to abuse the
people's perception of not-for-profits (cite: debt
consolidation industry).
Sorry for the length. It sounds like an important issue.
iang
--
Advances in Financial Cryptography:
https://www.financialcryptography.com/mt/archives/000458.html
_______________________________________________
Mozilla-security mailing list
Mozilla-security@mozilla.org
http://mail.mozilla.org/listinfo/mozilla-security
