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

[Dale Moberg <dmoberg@cyclonecommerce.com>]

Oops, I omitted a Negation element when editing.
Corrected version follows. Sorry.


"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
may not embed an actual certificate. Here is what the XKMS note
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>