OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [dss] DSS profiles Overview document


Trevor,

...


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

I would suggest that the profile is neutral to the key lengths etc.  If
there was a need to signal algorithm and key length requirements I would
suggest that this is done using a separate attribute.  Key lengths,
algorithms, certificate lifetime strength signature lifetime should be all
interrelated under a coherent policy which will change significantly from
application to application.  I would suggest that the profile is concerned
with more static protocol implementation issues.

Nick




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]