- From: Tom Gindin <tgindin@us.ibm.com>
- Date: Thu, 7 Jun 2001 13:13:55 -0400
- To: Saroop Mathur <saroop@saroop.com>
- Cc: "Dournaee, Blake" <bdournaee@rsasecurity.com>, w3c-ietf-xmldsig@w3.org
If the document is sent in the context of an authenticated session and signed with the authentication key, checking the public key used for signing against the one in the authentication certificate is more secure than simply validating a certificate without checking that it's the same one as used for session establishment, and no less secure than sending the authentication certificate inside the document - after all, the RP already has seen and validated that certificate during authentication. Under most other conditions, an uncertified public key for signing is a bad idea, including cases where a user is signing with a separate NR certificate or QC certificate distinct from the one used for authentication. As for encryption public keys (not that DSA keys are really usable for encryption), the trust decision is made when the symmetric encryption key is encrypted under a user's public key, and the presence of a certificate in the message format adds little. Tom Gindin Saroop Mathur <saroop@saroop.com>@w3.org on 06/07/2001 12:28:14 PM Sent by: w3c-ietf-xmldsig-request@w3.org To: "Dournaee, Blake" <bdournaee@rsasecurity.com>, w3c-ietf-xmldsig@w3.org cc: Subject: RE: DSAKeyValue text 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 13:14:51 UTC