OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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


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





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC