Peter Gutmann wrote:
> Consider for example a system that uses two
> authentication algorithms in case one fails, or that
> has an algorithm-upgrade/rollover capability, perhaps
> via downloadable plugins. At some point a device
> receives a message authenticated with algorithm A
> saying "Algori
Ben Laurie wrote:
> If the problem you are trying to solve is client
> authentication then client certs have some obvious
> value.
But if client certs are Certificate Authority centric,
then they prove that so and so's true name is so and so.
They don't prove that so and so is one of our gang,
wh
Ben Laurie writes:
>It seems to me protocol designers get all excited about this because they
>want to design the protocol once and be done with it. But software authors
>are generally content to worry about the new algorithm when they need to
>switch to it - and since they're going to have to up
On Aug 25, 2009, at 4:44 AM, Ben Laurie wrote:
Perry E. Metzger wrote:
Yet another reason why you always should make the crypto algorithms
you
use pluggable in any system -- you *will* have to replace them some
day.
In order to roll out a new crypto algorithm, you have to roll out new
sof
> This at least suggests that the v1.7 readers need to check *all*
> hashes that are offered and raise an alarm if some verify and others
> don't. Is that good enough?
Isn't that what SSL/TLS does?
/r$
--
STSM, DataPower CTO
WebSphere Appliance Architect
http://www.ibm.com/software/in
There is an approach to this that currently is being standardized in the
IETF PKIX group. The certificate image work
(draft-ietf-pkix-certimage-01.txt)
The current draft is available from:
tools.ietf.org/html/draft-ietf-pkix-certimage-01
The technical idea behind this is very simple. Instead of t
Folks:
My brother Nathan Wilcox asked me in private mail about protocol
versioning issues. (He was inspired by this thread on
cryptography@metzdowd.com [1, 2, 3]). After rambling for a while
about my theories and experiences with such things, I remembered this
vexing "future-compatibili
On Mon, Aug 10, 2009 at 6:35 PM, Peter Gutmann wrote:
> More generally, I can't see that implementing client-side certs gives you much
> of anything in return for the massive amount of effort required because the
> problem is a lack of server auth, not of client auth. If I'm a phisher then I
> set
