[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Metadata for 1.1 Web Browser SSO Profile, Draft 06, 1 May 2003
Scott - We agree. The current draft makes it mandatory to use a different key. I am arguing that the same key should be permitted. I am also arguing that a non-keyed digest procedure that results in a string that can be unambiguously recited over the telephone is called for. This means that it should have only upper-case letters and numbers, be separated into chunks of 3 or 4 characters (like a North American phone number) and be no longer than (say) 16 characters. All the best. Tim. -----Original Message----- From: Scott Cantor [mailto:cantor.2@osu.edu] Sent: Wednesday, July 09, 2003 11:20 AM To: 'Tim Moses'; security-services@lists.oasis-open.org Subject: RE: [security-services] Metadata for 1.1 Web Browser SSO Profile, Draft 06, 1 May 2003 > In the case where the key distributed with the metadata is a > public signature-verification key, it is acceptable, > desirable and conventional to sign the metadata using the > corresponding private key. This is common practice for X.509 > certificates. In addition, it allows the integrity of the > metadata to be confirmed using an out-of-band "digest". It shouldn't be mandatory to use the same key, since that basically only permits point to point trust. > As currently required, the integrity of the metadata has to > be protected with a separate key. Presumably, it too has > associated metadata that has to be distributed, protected > with another key, which (in-turn) has metadata. Allowing the > enclosed key to confirm the integrity of the metadata, breaks > this cycle. PKI always has an arbitrary stopping point somewhere. It's ok to allow it to be self-signed, but we shouldn't insist on it. > Here is a suggestion for a digest procedure: Umm, why not XML signature? -- Scott
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]