W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > April to June 2001

Re: DSAKeyValue text

From: merlin <merlin@baltimore.ie>
Date: Thu, 07 Jun 2001 23:46:56 +0100
To: "Dournaee, Blake" <bdournaee@rsasecurity.com>
Cc: Saroop Mathur <saroop@saroop.com>, w3c-ietf-xmldsig@w3.org
Message-Id: <20010607224657.0CD8344497@yog-sothoth.ie.baltimore.com>

If I write my public key (or its fingerprint) down on a beermat
and you receive a document that contains that key (and was signed
by the corresponding private key) then, subject to our trust
relationship and the quantity of beer, you may be able to infer
that I signed the document. Or, you can use the key fingerprint
to look up a cert in a database. Beer or certs, your choice.

Merlin

r/bdournaee@rsasecurity.com/2001.06.07/10:01:09
>Merlin,
>
>Can you be more specific on the mechanism(s) for inferring trust from just a
>public key? 
>
>Blake Dournaee
>Toolkit Applications Engineer
>RSA Security
> 
>"The only thing I know is that I know nothing" - Socrates
> 
> 
>
>
>-----Original Message-----
>From: merlin [mailto:merlin@baltimore.ie]
>Sent: Thursday, June 07, 2001 9:53 AM
>To: Saroop Mathur
>Cc: w3c-ietf-xmldsig@w3.org
>Subject: Re: DSAKeyValue text 
>
>
>
>It is quite reasonable to assert trust over a public key, independent
>of any certification scheme, and thus to assert trust over documents
>signed by that key. Certificates are only one of many options available
>for trust and authentication management.
>
>Merlin
>
>r/saroop@saroop.com/2001.06.07/09:28:14
>>Blake,
>>
>>If the sender is already authenticated, then you don't need the
>>certificate for authentication. However, that is not sufficient to
>>gurantee integrity of the document. What is to prevent somebody from
>>changing the document, generating a new signature with his own private
>>key and replacing the public key in the document?
>>
>>If your implementation supports using public keys without certificates,
>>then you have an insecure product.
>>
>>-Saroop
>>--- "Dournaee, Blake" <bdournaee@rsasecurity.com> wrote:
>>> Saroop,
>>> 
>>> I think I can answer at least part of your question. 
>>> 
>>> Certain applications might already have authenticated the sender of
>>> the
>>> signature through some other means that is not explicitly part of the
>>> <Signature> element.
>>> 
>>> In this case the public key can be used to verify the integrity of
>>> the data.
>>> It would be inefficient to only allow certificates to be sent - they
>>> are
>>> much larger and contain additional information that is redundant if
>>> the
>>> sender has already been properly authenticated.
>>> 
>>> Can anyone out there add to this?
>>> 
>>> Blake Dournaee
>>> Toolkit Applications Engineer
>>> RSA Security
>>>  
>>> "The only thing I know is that I know nothing" - Socrates
>>>  
>>>  
>>> 
>>> 
>>> -----Original Message-----
>>> From: Saroop Mathur [mailto:saroop@xpressent.com]
>>> Sent: Thursday, June 07, 2001 6:49 AM
>>> To: w3c-ietf-xmldsig@w3.org
>>> Subject: Re: DSAKeyValue text
>>> 
>>> 
>>> This is somewhat offtopic and may already have been discussed
>>> previous.
>>> If so, I apologize.
>>> 
>>> What is the value of sending RSA/DSA public keys outside of
>>> certificates? Without certificates, the public keys cannot be
>>> trusted.
>>> Unless I am missing something, I would suggest that the XMLDSIG
>>> should
>>> discourage implementations from sending public keys without
>>> certificates. Currently, section 4.4.2 section specifies that support
>>> for DSAKeyValue element is REQUIRED. Doesn't this lead to
>>> implementations that are insecure?
>>> 
>>> -Saroop
>>> 
>>> __________________________________________________
>>> Do You Yahoo!?
>>> Get personalized email addresses from Yahoo! Mail - only $35 
>>> a year!  http://personal.mail.yahoo.com/
>>> 
>>
>>
>>__________________________________________________
>>Do You Yahoo!?
>>Get personalized email addresses from Yahoo! Mail - only $35 
>>a year!  http://personal.mail.yahoo.com/
>>
>
Received on Thursday, 7 June 2001 18:48:23 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:13 GMT