RE: [security-services] Metadata for 1.1 Web Browser SSO Profile, Draft 06, 1 May 2003

["Jahan Moreh" <jmoreh@sigaba.com>]

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