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

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

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