Re: [ebxml-cppa] Proposed disposition of Security related issue number9: close it and open a more specific issue in its place.

[Christopher Ferris <chris.ferris@sun.com>]

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