Re: [dss] DSS profiles Overview document

[Trevor Perrin <trevp@trevp.net>]

At 12:04 AM 1/26/2004 +0100, Andreas Kuehne wrote:

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

You're right - profiles like XAdES and SigG will have both protocol and 
processing aspects.  So it doesn't make sense to try to pigeonhole the 
abstract profiles as "protocol profiles", or "processing profiles".

So I guess we'll just have abstract/meta-profiles that can profile whatever 
they want (transport/security bindings, the protocol, signature format, 
processing rules), and then a "concrete profile" can inherit from some of 
these (and add more profiling if it needs to).  That's what we were moving 
towards on the con call too, I think.


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

I take that back - a concrete profile might have some of its processing 
rules inherited from the SigG profile, and some inherited from the XAdES 
profile, etc., so it can't just indicate a single processing profile.  For 
the same reason, adding a single <dss:ProfileVersion> optional input into 
core would be hard, cause you'd have to specify which of the abstract 
profiles it was meant for.

I think it would be better for each abstract profile to simply define any 
optional inputs it needs for extensibility/versioning.  For example, SigG 
could add an optional input:
<sigG:BitLength>1024</sigG:BitLength>, or
<sigG:Version>2.0</sigG:Version>

We could recommend that if profiles need a version, they call their 
optional input <xyz:Version>.  But I don't think we need to put anything 
into the core to support this?

Trevor