[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
I'll look at the language of this draft and make the necessary corrections once we all agree (it seems that we do). Tim - can you point to specific line numbers in draft 06? Thanks, Jahan ---------------- Jahan Moreh Chief Security Architect 310.286.3070 > -----Original Message----- > From: Tim Moses [mailto:tim.moses@entrust.com] > Sent: Wednesday, July 09, 2003 12:28 PM > To: 'Scott Cantor'; 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 > > > 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 > > You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/security-services/members/leave _workgroup.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]