[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
Jahan - I would like to encourage debate of a standard technique for validating metadata exchanged over an untrusted channel. As an initial step, could you add the following description as an appendix to the metadata draft? I hope this will spark an informed and valuable debate on the list and/or in subsequent teleconferences. Thanks a lot. All the best. Tim. Out-of-band validation Introduction In the case that the metadata is not communicated between the source and destination over an authentic channel, the destination's copy of the metadata is not trustworthy. Yet, the trustworthiness of all subsequent communications between the source and destination depends upon the trustworthiness of the metadata. Therefore, a technique is required to validate the destination's copy of the metadata. Metadata validation MUST be performed using an alternative authentic channel, such as a telephone call or facsimile transmission, company letterhead, business card or face-to-face exchange. In order to minimize the cost of communicating and validating metadata, it MUST be possible to validate metadata verbally and reliably in a telephone call. Procedure The following procedure is RECOMMENDED. 1. The source SHALL calculate a validation string for the metadata according to the procedure described below. 2. The source SHALL communicate the validation string over an authentic channel to the destination. 3. The source SHALL communicate the metadata over an untrusted channel to the destination. 4. The destination SHALL calculate the validation string for the received metadata according to the procedure described below. 5. If the validation string calculated by the destination is identical to the validation string received from the source, then the destination MAY install and rely upon the metadata, otherwise it MUST NOT rely on the metadata. Validation string calculation The validation string SHALL be calculated from the binary form of the authority's self-signed certificate by operating upon it with the SHA-1 hash algorithm. The right-most 4 bytes of the resulting digest are discarded. The left-most 3 bits of each of the remaining 16 bytes are discarded. The remaining sixteen 5-bit values are represented as alphanumeric characters according to the following table. 00000 > A 00001 > B ... omitting I 11000 > Z 11001 > 3 11010 > 4 ... 11111 > 9 Finally, the alphanumeric string is divided into four sub-strings, each of four characters, and the sub-strings are separated by hyphens. For example: A4HY-8KLN-9T3M-7GK4 Note that hyphens are inserted to assist in dictation. Note also that the ambiguities between I and 1, O and 0 and Z and 2 are eliminated. Also, note that the ambiguity between upper and lower-case letters is eliminated. -----Original Message----- From: Jahan Moreh [mailto:jmoreh@sigaba.com] Sent: Thursday, July 10, 2003 11:16 AM To: Frederick.Hirsch@nokia.com; tim.moses@entrust.com; cantor.2@osu.edu; security-services@lists.oasis-open.org Subject: RE: [security-services] Metadata for 1.1 Web Browser SSO Profile, Draft 06, 1 May 2003 Fredrick - I think the correct and accurate language is: "That is, the public key in the metadata document, as described in Section 2.1.5.5 SHOULD only be used for verifying assertions, requests, and responses." Thanks, Jahan ---------------- Jahan Moreh Chief Security Architect 310.286.3070 > -----Original Message----- > From: Frederick.Hirsch@nokia.com [mailto:Frederick.Hirsch@nokia.com] > Sent: Thursday, July 10, 2003 7:22 AM > To: tim.moses@entrust.com; jmoreh@sigaba.com; cantor.2@osu.edu; > security-services@lists.oasis-open.org > Subject: RE: [security-services] Metadata for 1.1 Web Browser SSO > Profile, Draft 06, 1 May 2003 > > > Shouldn't it say at line [279] private key instead of public? > > "That is, the private key corresponding to the public key in the > metadata document, > as described in Section 2.1.5.5 SHOULD only be used for signing > assertions, requests, and responses." > > > > regards, Frederick > > Frederick Hirsch > Nokia Mobile Phones > > > > > > -----Original Message----- > > From: ext Tim Moses [mailto:tim.moses@entrust.com] > > Sent: Wednesday, July 09, 2003 4:14 PM > > To: 'jmoreh@sigaba.com'; Tim Moses; 'Scott Cantor'; > > security-services@lists.oasis-open.org > > Subject: RE: [security-services] Metadata for 1.1 Web Browser SSO > > Profile, Draft 06, 1 May 2003 > > > > > > Jahan - I am thinking of lines 277-281. From a quick glance, > > I don't see > > any other reference to this topic. All the best. Tim. > > > > PS. Also look on lines 103, 138 and 164 for typos. > > > > -----Original Message----- > > From: Jahan Moreh [mailto:jmoreh@sigaba.com] > > Sent: Wednesday, July 09, 2003 3:36 PM > > To: Tim Moses; 'Scott Cantor'; security-services@lists.oasis-open.org > > 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 > > You may leave a Technical Committee at any time by visiting > http://www.oasis-open.org/apps/org/workgroup/security-services/mem bers/leave_workgroup.php 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]