RE: [dss] Use cases and requirements input

[Nick Pope <pope@secstan.com>]

I support the suggestion of using a profile / policy identifier.

Nick

-----Original Message-----
From: Pieter Kasselman [mailto:pkasselman@baltimore.com]
Sent: 17 January 2003 09:22
To: 'Robert Zuccherato'; 'Gregor Karlinger'; 'dss@lists.oasis-open.org'
Subject: RE: [dss] Use cases and requirements input


Hi Robert, one comment below.

Cheers

Pieter

> > 2.2.4 Allow for configuration profiles
> >
> > - Trust
> >
> > The requester should be able to specify the trust settings
> > (accepted root certificates, accuracy of CRL checking, ...)
> > to be applied by the service when validating a signature.
> >
> > Since this trust-related information can be quite bulky, the
> > requester should alternatively identify this information by
> > a named profile.
>
> I'm not opposed to allowing requesters to specify the trust settings, but
> not at the expense of producing a protocol that is more complicated that
> necessary.  I'm guessing that this feature would not be required in the
> majority of signature validation server environments.  The trust settings
> would be implicitly defined by the service.  At least in our first
> iteration I would like to produce something that is simple, usable and
> works.  We can then build upon that.
>
	[Pieter Kasselman]  One way to meet this requirement is to allow for
a configuration profile or policy to be specified (as remarked in the
original post it can be as simple as a URL that is included). This could be
a optional (non-mandatory) parameter. For a first iteration we do not need
to define exactly how such a policy or configuration profile is expressed.

>         Robert.
>


----------------------------------------------------------------------------
-
The information contained in this message is confidential and is intended
for the addressee(s) only.  If you have received this message in error or
there are any problems please notify the originator immediately.  The
unauthorised use, disclosure, copying or alteration of this message is
strictly forbidden. Baltimore Technologies plc will not be liable for
direct, special, indirect or consequential damages arising from alteration
of the contents of this message by a third party or as a result of any
virus being passed on.

This footnote confirms that this email message has been swept for Content
Security threats, including computer viruses.
http://www.baltimore.com


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>