RE: [dss] DSS profiles Overview document

["Nick Pope" <pope@secstan.com>]

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.
>
>
> 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.


> - 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 german sig law requires that restrictions that apply to the
> signature or the used certificates have to be 'shown' at
> verification time.
> These restrictions usually are attached to the signature as an
> attribute certificate. Does any other profile has such a
> requirement so that it
> would make sense to include such a 'restrictions' element within
> the core schema ?
>
This could be indicated by the XAdES Signature Policy attribute.

Nick