RE: [dss] DSS profiles Overview document

[Trevor Perrin <trevp@trevp.net>]

At 07:04 PM 1/25/2004 +0000, Nick Pope wrote:

>Andreas,
>
>See below for my personal views:
>
> > -----Original Message-----
> > From: Andreas Kuehne [mailto:kuehne@klup.de]
> > Sent: 25 January 2004 13:37
> > To: Nick Pope
> > Cc: OASIS DSS TC
> > Subject: Re: [dss] DSS profiles Overview document
> >
> >
> >
> > Hi Nick !
> >
> > > Juan Carlos and myself have been discussing about how to
> > coordination the
> > > work on the profiles and suggest that the group produces a document
> > > including an overview of scope and approach of each profile.
> > This document
> > > could be an input to a working document to cordinate the profiles
> > > and their relationships and general issues, and finally provide
> > users with
> > > a roadmap of how to select and use the appropriate profile.
> >
> > I just finished the discussion with my collegues, so attached
> > you'll find the outline of a 'German signature law' profile.

Interesting - like code-signing and policy-wise, this is an abstract 
profile (or meta, or "decorative" - good word!).

However, this profile mostly describes the server's processing, not the 
protocol itself.  Maybe instead of having a single <ServiceProfile> 
optional input, we should have separate <ProtocolProfile> and 
<ProcessingProfile> inputs, so that a client can simultaneously say:
  - I want a code-signing signature (or XAdES signature; or time-stamp; etc.)
  - I want it produced in compliance with sigG

We could also separate our documents into protocol profiles, and processing 
profiles.  Something to think about, at least.


> >
> >
> > Some open issues came up, so I would like to known the opinion of
> > the group :
> >
> > -  There are some aspects of the profile that aren't necessarely
> > reflected in signature request input structure. E.g. the DSS
> > server has to use
> > a high security key store. Should we introduce an additional
> > optional element ( like
> > <usesSecureKeyStore>true</usesSecureKeyStore> ) for
> > clarification or should we rely on the explanatory text of the profile ?
> >
>I presume that this is not a dynamic aspect of the profile, and so does not
>need any signal to the server of the requirement.  So I would suggest that
>thid is defined as part of the procedure for the profile.

I agree with Nick - this behavior would be implied by the profile.




> > - Does anyone has an idea of profile versioning ? Do we want
> > version aspects of the profile ( e.g. until 31.12.2006 1024 bit
> > key length is
> > sufficient, from 01.01.2007 1536 bit keys are mandatory ) or do
> > we create a complete new version of the profile ?
> >
>I would suggest that things that need to be regularly reviewed such as key
>lengths should not be in the profile but managed as part of the policy.
>Also, key lengths depend on other factors such as lifetime of certificates
>etc.
>Finally, in the EU there is already guidance on algorithms and key lengths.
>
>The general issue of versioning of the profiles vis-a-vis the Core, however,
>warrents some consideration - Any thoughts Trevor?

The approach above might give a solution, in this specific case - a single 
<ProtocolProfile> could support multiple different <ProcessingProfile>s, like -

<ProcessingProfile>urn:sigG:1024bits<ProcessingProfile>
<ProcessingProfile>urn:sigG:1536bits<ProcessingProfile>
<ProcessingProfile>urn:sigG:2048bits<ProcessingProfile>


Trevor