Nelson,
That is a doozy!
Some points. I don't really feel I've fully got to the
bottom of this issue, in the brief scanning, so these
are all highly debatable points. Just to warn in
advance, they are primarily negative in direction.
1. Critical bits are a can of worms. They introduce
complexities that may be used against the software.
From my pov as a security guy, I see them as an
option to break security in the future. I view them
distrust. (All I really know about them is the debate
years back in the OpenPGP group where they decided
to discuss adding them, and there were no good
answers to concerns then.)
2. Legislated crypto is probably bad law. I'm not
really inclined to jump on the Larry Lessig "code
is law" bandwaggon here, but that's sort of where
this goes. One has to establish that the law writers
knew what they were doing, and that's really hard.
And one has to establish that what they wrote made
sense, and that's even harder. Not to mention, if
it made sense, why didn't we do it anyway, without
them making it law? Anglo countries quite rightly
(IMO) ignored all the digsig laws, but the European
tradition is ... less humourous.
3. If one country writes a law, this critical bit then
"becomes code." That's the starting proposition.
But what happens if another country writes a law?
And another and another? Can critical bits interfere
with each other?
Not only do critical bits allow anyone who issues certs
to raise all sorts of dilemmas, they at a minimum raise
a complexity issue that probably isn't justified by
their benefit to users.
4. Some examples, ranging in ludicrosity (!):
4. a. What happens if the FBI asks and Congress passes
a law that says that all certs now have to be escrowed,
and the critical bit set for all new escrowed certs?
4. b. What happens if Verisign
decides that it is going to reissue all its certs according
to some law it found that said it should be paid extra?
4. c. Does this mean that CACert can go trawling thru
aussie law and find something to justify a critical bit?
4. d. Does this mean I can become a CA, and issue
certs with critical bits that insist that my certs not
be used unless the user is shown the logo?
Obviously ludicrous examples! But ... that's where this
thing might head.
5. If you take *any* action at all .. that means you are
following the protocol or attempting to follow the
protocol. If you get it wrong, you are now negligent.
Alternatively, if you take no action at all, then you
are not negligent, you just don't accept the contract.
As this involves money, and as the liability is clearly
present, this could get messy. If a browser mucks it
up, and the CA gets sued, it could pass that across
to the browser manufacturer.
Having said all that, I'd say that you seriously think
about putting the "null" option on the table. And
some variants of that.
The null option is to do nothing. Leave it as it is.
So this cert with its critical bit gets rejected. That's
actually the safest thing to do until all the angles are
analysed. I think given the "Frank Hecker" sized
project here of figuring out all the angles here, that
might be the sensible short term course of action.
The near-null option would be to accept the cert,
and ignore totally the critical bits. The rational for
this is that users want to see these certs, and the
law writers simply haven't paid you to write the code.
As a *thought* excercise by me, I might integrate
the critical bits into my branding CA notions this
way: the cert is accepted, and the CA logo is shown
on the chrome. Along side the CA logo is a hard red
warning sign like an (X). Clicking on that brings up
a dialog (or changes the logo) to show the critical
bit markings. No special code, just a read out of
what the critical bits are. No active action, just a
hard red warning button beside the logo that the
user can click to see what it says.
I don't envy you guys on this one!
iang
--
News and views on what matters in finance+crypto:
http://financialcryptography.com/
_______________________________________________
Mozilla-security mailing list
Mozilla-security@mozilla.org
http://mail.mozilla.org/listinfo/mozilla-security
