[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**

*From*:**Tim Moses <tim.moses@entrust.com>***To*: "'Scott Cantor'" <cantor.2@osu.edu>, Tim Moses <tim.moses@entrust.com>, security-services@lists.oasis-open.org*Date*: Fri, 11 Jul 2003 16:06:43 -0400

Update ... It seems the PKIX draft on the topic of authority public-key digests expired. Good job. Below is a description of the procedure defined by WAP. Their data-entry device is a numerical keypad (a constraint that - happily - we don't have to contend with). They chose to apply a check digit to each block. This seems like an unnecessary precaution in our situation, because the most error-prone step is likely to be reciting or recording the digest, not entering it at a computer keyboard. Their TBHTrustedCAInfo structure is the equivalent of SAML's IDPDescriptor. I advocate the solving of this problem by SAML, because without it, the Metadata specification is incomplete (unworkable?). All the best. Tim. WAP procedure ... Let "hash" be the SHA-1 hash of the encoding of a TBHTrustedCAInfo structure. This consists of 160 bits (h0,.h159, in network byte order, h0 being the leftmost bit). The display form of the hash consists of 30 decimal digits, constructed of 5 blocks of 6 digits. The leftmost 5 digits of each block represent 16 bits of the effective hash, (i.e. can take the value '00000' to '65535' decimal), the sixth digit of each block is a check digit for the block. Block zero consists of h0 to h15 (with h0 being the most significant bit), followed by the associated check digit; block one consists of h16 to h31; followed by the associated check digit etc. That is if h0 is '1'B and h1 to h15 are all '0'B, then the sixteen bits have the value '8000'H or '32678' decimal, and the check digit is '5' decimal (see below for the check digit calculation method). The check digit is calculated using the same mechanism as used for credit card numbers, that is, the LUHN formula (mod 10) as described below. The following steps are required to validate a 6 digit group: Step 1: Double the value of alternate digits of the number beginning with the second digit from the right (the first right--hand digit is the check digit.) Step 2: Add the individual digits comprising the products obtained in Step 1 to each of the unaffected digits in the original number. Step 3: The total obtained in Step 2 must be a number ending in zero (30, 40, 50, etc.) for the number to be validated. Example 1: to validate the group 398719, corresponding to '9BBF'H as the sixteen bits of hash: Step 1: 3 9 8 7 1 9 x2 x2 x2 ------------ 6 16 2 Step 2: (6) + 9 +(1+6) + 7 + (2) + 9 Step 3: Sum is 40 = 0 (mod 10): group is validated Example 2: to validate the group 326785, corresponding to '8000'H as the sixteen bits of hash: Step 1: 3 2 6 7 8 5 x2 x2 x2 ------------ 6 12 16 Step 2: (6) + 2 +(1+2) + 7 + (1+6) + 5 Step 3: Sum is 30 = 0 (mod 10): group is validated -----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]