Jean-Marc Desperrier wrote:
Ian G wrote:
[...]
OK, that's good to know that there is no number
involved. That just leaves us with determining
what information *is* in this cert, and how it is
that it needs to be presented to the user, and
what the legal and contractual ramifications of
all this information is.
We should refer directly to the documentation about that :
http://portal.etsi.org/docbox/EC_Files/EC_Files/ts_101862v010201p.pdf
(also http://www.ietf.org/rfc/rfc3039.txt for more generic qualified
certificate information)
(Thanks for the reference. I should read that, but
won't have time, unfortunately.)
The fact that it might be easy to parse doesn't
make it easy to present. How do you envisage
presenting this information?
[...]
What are the contractual ramifications for the
parties? What happens if it goes wrong?
(And, I don't think the answer to the above is
"nothing" as if it was, there would be no need
for a law and no need for a critical bit.)
In the case of the hungarian CA, I'm not sure "nothing" is such a bad
answer. To be more precise, the qualified CA cert is just one step
toward producing a qualified signature, which would be present only if
all components were qualified. So as long as Mozilla is not qualified,
it's not a qualified signature, and the use of a qualified CA changes
very little.
What would seem to me adequate to present this information would be a
text saying "this certificates claims to be a qualified certicate" in
the certificat details. Nothing more.
(OK, my wording is wrong, as the certificate is not a living being and
can't claim anything)
So, would we be agreed that it is certainly not
obvious nor clear what Mozilla should do?
Actually, for the monetary limit, I'd just add another text at the
same place : "this certificate can be used as a qualified certificate
for transactions restricted to a maximum value of _Amount_
_CurrencyCode_".
That would open the way for Mozilla to have that
liability.
Now, this is tempered by for example the lack
of a contract between Mozilla and the user. But,
this is an open question, and the Florida bank
case is being looked on to decide this issue; so
until things like that are cleared up, I'd say that
Mozilla should play that one cautiously.
http://searchsecurity.techtarget.com/columnitem/0,294698,sid14_gci1062440,00.html
About the can of worms, the one opened by those extensions does not
really makes the situation worse for X509 certificates.
We've had the "Non Repudiation" usage bit for a long time, and nobody
agrees on what it means exactly to assert it.
Right. My own view is to ignore them. Especially
non-repudation as that is actually a legal nonsense.
But, crits as well should probably be ignored as a
first approximation; as they have no clear meaning,
the system should not then try and impute their
meaning, as to do so results in taking an active
part.
If you concerns were fully justified, the current Mozilla could
already be considered liable by not showing in a very visible way that
this flag is asserted.
I believe that to be the case. Mozilla follows the
docs, so it has raised the possibility of it being
liable. It tries to do the right thing. So a relying
party can say, "Mozilla set the standard of doing
the right thing, and I relied up on that."
Whereas IE raises no liability, simply because it
doesn't do the right thing. It just prints out the
info and lets the user do whatever it likes. It
simply declines to do the right thing and thus
specifically says "Not my problem, here's the
info, you deal with it."
This is a case of "doing the right thing" being
"the wrong thing to do."
iang
--
News and views on what matters in finance+crypto:
http://financialcryptography.com/
_______________________________________________
Mozilla-security mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-security
