Hi Adam,
> From: Adam Back <[EMAIL PROTECTED]>
> Date: Fri, 30 Jul 2004 17:54:56 -0400
> To: Aram Perez <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], Cryptography <[EMAIL PROTECTED]>, Adam
> Back <[EMAIL PROTECTED]>
> Subject: Re: should you
Aram Perez <[EMAIL PROTECTED]> writes:
>I agree with Michael H. If you trust the CA to issue a cert, it's not that
>much more to trust them with generating the key pair.
Trusting them to safely communicate the key pair to you once they've generated
it is left as an exercise for the reader :-).
P
At 02:09 PM 7/28/04 -0400, Adam Back wrote:
>The difference is if the CA does not generate private keys, there
>should be only one certificate per email address, so if two are
>discovered in the wild the user has a transferable proof that the CA
>is up-to-no-good. Ie the difference is it is detect
On Wed, Jul 28, 2004 at 10:00:01PM -0700, Aram Perez wrote:
> As far as I know, there is nothing in any standard or "good security
> practice" that says you can't multiple certificate for the same email
> address. If I'm willing to pay each time, Verisign will gladly issue me a
> certificate with m
Hi Adam,
> The difference is if the CA does not generate private keys, there
> should be only one certificate per email address, so if two are
> discovered in the wild the user has a transferable proof that the CA
> is up-to-no-good. Ie the difference is it is detectable and provable.
As far as
At 12:09 PM 7/28/2004, Adam Back wrote:
The difference is if the CA does not generate private keys, there
should be only one certificate per email address, so if two are
discovered in the wild the user has a transferable proof that the CA
is up-to-no-good. Ie the difference is it is detectable and
The difference is if the CA does not generate private keys, there
should be only one certificate per email address, so if two are
discovered in the wild the user has a transferable proof that the CA
is up-to-no-good. Ie the difference is it is detectable and provable.
If the CA in normal operatio
For what it's worth, last week, I had the chance to eat dinner with
Carlisle Adams (author of the PoP RFC), and he commented that he didn't
know of any CA that did PoP any other way than have the client sign
part of a CRM.
Clearly, this seems to contradict Peter's experience.
I'd REALLY love to
At 05:37 AM 7/22/2004, Amir Herzberg wrote:
Most (secure) signature schemes actually include the randomization as part
of their process, so adding nonces to the text before signing is not
necessary. OTOH, I don't see any problem in defining between the parties
(in the `meta-contract` defining th
Barney Wolff wrote:
Pardon a naive question, but shouldn't the signing algorithm allow the
signer to add two nonces before and after the thing to be signed, and
make the nonces part of the signature? That would eliminate the risk
of ever signing something exactly chosen by an attacker, or at least
> attempt to address this area; rather than simple "i agree"/"disagree"
> buttons ... they put little checkmarks at places in scrolled form you
> have to at least scroll thru the document and click on one or more
> checkmarks before doing the "i agree" button. a digital signature has
> so
| note that some of the online click-thru "contracts" have been making
| attempt to address this area; rather than simple "i agree"/"disagree"
| buttons ... they put little checkmarks at places in scrolled form you
| have to at least scroll thru the document and click on one or more
| checkmar
About using a signature key to only sign contents presented in a meaningful
way that the user supposedly read, and not random challenges:
The X.509 PoP (proof-of-possession) doesn't help things out, since a public
key certificate is given to a user by the CA only after the user has
demonstrated t
At 08:25 AM 7/19/2004, Jerrold Leichter wrote:
A traditional "notary public", in modern terms, would be a tamper-resistant
device which would take as inputs (a) a piece of text; (b) a means for
signing (e.g., a hardware token). It would first present the actual text
that is being signed to the par
| the issue in the EU FINREAD scenario was that they needed a way to
| distinguish between (random) data that got signed ... that the key owner
| never read and the case were the key owner was actually signing to
| indicate agreement, approval, and/or authorization. They specified a
| FINREAD
At 08:08 PM 7/18/2004, Sean Smith wrote:
Why isn't it sufficient? (Quick: when was the last time anyone on this
list authenticated by signing unread random data?)
The way the industry is going, user keypairs live in a desktop keystore,
and are used for very few applications. I'd bet the vast
it isn't sufficient that you show there is some specific
authentication protocol with unread, random data ... that has
countermeasures against a dual-use attack ... but you have to
exhaustively show that the private key has never, ever signed any
unread random data that failed to contain dual-u
there is a variation on the EU FINREAD terminal that sort of provides a
chain of trust/evidence (that has almost nothing at all to do with the
traditional trusted third party certification authorities and their
certificates)(
1) there ae a certain class of certified terminals with security modu
At 10:36 AM 7/18/2004, Sean Smith wrote:
In SSL and TLS, the client isn't signing random data provided by the
adversary. Rather, the client is signing a value derived from data both
the client and server provide as part of the handshake. I do not believe
it is feasible for a malicious server t
at the NIST PKI workshop a couple months ago there were a number
of infrastructure presentations where various entities in the
infrastructure were ...signing random data as part of authentication
protocol
I believe our paper may have been one of those that Lynn objected to.
We used the sam
the fundamental issue is that there are infrastructures using the same
public/private key pair to digital sign
1) random authentication data that signer never looks at and believe is of
low value ... if they connect to anybody at all ... and are asked to
digitally sign some random data for aut
At 01:33 AM 7/18/2004, Amir Herzberg wrote:
I don't see here any problem or attack. Indeed, there is difference
between signature in the crypto sense and legally-binding
signatures. The later are defined in one of two ways. One is by the
`digital signature` laws in different countries/states; that
Anne & Lynn Wheeler wrote:
ok, this is a long posting about what i might be able to reasonable assume
if a digital signature verifies (posting to c.p.k newsgroup):
... skipped (it was long :-)
the dual-use comes up when the person is 'signing" random challenges as
purely a means of authentication
ok, this is a long posting about what i might be able to reasonable assume
if a digital signature verifies (posting to c.p.k newsgroup):
http://www.garlic.com/~lynn/2004h.html#14
basically the relying-party has certified the environment that houses the
private key and the environment that the digi
24 matches
Mail list logo
