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

[<Frederick.Hirsch@nokia.com>]

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/members/leave_workgroup.php