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


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]