[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-cppa] Proposed disposition of Security related issue number9: close it and open a more specific issue in its place.
+1 to keeping things as they are. Dale Moberg wrote: > "Replace ds:keyinfo element by a definition that does not embed the > actual > ceritficate in the CPP or CPA." > > I believe that this recommendation rests on overlooking that ds:keyinfo > must embed an actual certificate. Here is what the XKMS specification > says, for example: > > http://www.w3.org/TR/2001/NOTE-xkms-20010330/ > > "A <ds:KeyInfo> element may include a <ds:RetrievalMethod> > element which is a means to convey information available from > a remote location. The <ds:RetrievalMethod> element is a feature > of and is defined by the XML Signature Specification. Since it is > the most basic means of resolving a <ds:KeyInfo> element it is described > > here as the 'Tier 0' Key Information service." > > Therefore, those who wish to point at certificates rather than > include them may already do so. Hence no change is needed, IMO. > I do not think that we should preclude including certificates > in the actual CPPs and CPAs within the KeyInfo. We might note > that by doing so, the CPA would need modification when > the certificate expires. We _might_ point out that it is > advisable to expire the CPA (do we expire CPPs? CPA templates? > I don't think we do yet. A CPA template might include a validity period, > but does it mean the propsed CPA validity or the CPA template validity?) > when the essential certificates expire ( or at > the earliest expiration date of the referenced or included > essential certificates). > > I suggest we close the specific issue number 9 > out, and replace it by a new issue devoted to reaching consensus > on what needs to be said about CPA expiration and certificate > expiration when certificates are included. > > Therefore I would also favor that we reject the proposal: > > "From Security Issues 01-08-26.doc (via Tim Collier): Depending on how > it is > used, the ds:keyinfo element can contain an actual base-64-encoded > certificate. Except for signing of the CPP or CPA, there is no need for > actual > certificates to be embedded in the CPP or CPA. The Certificate element > should > be changed to point to information at a key-management service instead" > > as overly restrictive. This would mean that people _must_ have > implemented > a key-management service with a URL in ds:RetrievalMethod. I think the > state of PKI is such that we don't want to place barriers on people > setting up their certificate caches so that they work even if they > lack the latest bells and whistles. I do not dispute that there > is a way to use key-management services (like XKMS) instead of > putting keys inside the CPPs or CPAs. But transitionally speaking, I > am uncomfortable requiring use of a key management service. > > > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC