[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dss] DSS profiles Overview document
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]