OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[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


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]