Re: [dss] DSS profiles Overview document

[Andreas Kuehne <kuehne@klup.de>]

Hi Trevor !

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

In the old days before XML I spent my time doing object modelling. So I remembered the 'decorator pattern',one of my favorites !

 
> 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.
> 
Yes, I agree that it will be a comman way to aggregate several different profiles. But I guess you can't separate the different profiles in this two categories. Dtmo the XAdES profile defines both protocol and processing aspects.



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


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

Hmm, is the 'urn:sigG:1024bits' a fine grained profile, just to denote the key length ? Or a full SigG profile just named by the key length ?


Greetings

Andreas