- From: <Frederick.Hirsch@nokia.com>
- Date: Mon, 11 Nov 2002 17:00:23 -0500
- To: <spouliot@motus.com>, <www-xkms@w3.org>
Sébastien
Good point. Changing the name of the sub-element to PKIXOCSP is an improvement.
It is still an X509Data sub-element, ok since the intent is to put under X509Data
information related to traditional PKI, regardless of the detail, I believe.
---------------------------------------
Frederick Hirsch
Technology Architect
Nokia Mobile Phones
5 Wayside Rd., Burlington, MA 01803 USA
frederick.hirsch@nokia.com
+1 781-993-3735
-----Original Message-----
From: ext spouliot@motus.com [mailto:spouliot@motus.com]
Sent: Monday, November 11, 2002 4:49 PM
To: www-xkms@w3.org
Subject: Réf. : XKMS OCSP issue
(oops - I forgot to c.c. the list)
OCSP is a PKIX protocol - it's not part of X.509.
So maybe the element name should be "PKIXOCSP" instead of "X509OCSP".
Regards,
--------------------------------------------------------------
Sébastien Pouliot
Architecte Sécurité / Security Architect
Motus Technologies
tel: 418 521 2100 ext 307
fax: 418 521 2101
courriel / email: spouliot@motus.com
Frederick.Hirsch
@nokia.com Pour : <www-xkms@w3.org>
Envoyé par : cc :
www-xkms-request Objet : XKMS OCSP issue
@w3.org
2002-11-11 09:25
XKMS Requirement 2.5.4 states (Editors draft
http://www.w3.org/2001/XKMS/Drafts/xkms-req.html) :
"The following KeyInfo formats MUST be supported: KeyName, KeyValue,
RetrievalMethod and MgmtData.
The X509Certificate KeyInfo format MUST be supported by a trust server if
the service claims interoperability with PKIX X.509. Additional KeyInfo
formats such as X509Chain, OCSP, and X509CRL MAY be supported. X509Chain
and OCSP MUST be defined in the XKMS specifications. X509CRL is defined in
the XML Signature recommendation.
The XKMS registration Private format MUST be supported if the service
supports either service generated key pairs or key recovery.[List(Sebastien
Pouliot)]"
---
The XKMS spec (
http://www.w3.org/2001/XKMS/Drafts/XKMS20021017/xkms-part-1.html) defines a
RespondWith value for OCSP as (section 2.8.6), line 75):
identifier: xkms:OCSP
ds:KeyInfo Element: <ds:X509Data>
Description: PKIX OCSP token that validates an X509v3 certificate that
authenticates the key
The X509Data element is defined in the XML Digital Signature Rec (
http://www.w3.org/TR/xmldsig-core/#sec-X509Data ) and specifies different
meanings for the element, such as X509IssuerSerial, X509SubjectName,
X509SKI, X509Certificate, and X509CRL. OCSP is not defined.
Thus to meet the requirement and to address the issue list item #86 in
Other Issues I propose that the following definition be added to the XKMS
specification part 1:
<element name="X509OCSP" type="base64Binary"/> in the XKMS namespace
This can be a child of the ds:X509Data type. which is already extensible.
The value returned in response to the OCSP respondWith should be
a <ds:X509Data><xkms:X509OCSP>...<</xkms:X509OCSP></ds:X509Data> element.
Defining this sub-element makes the data self-describing and consistent
with the other definitions in XML Digital Signature.
We agreed in the conference call that the meaning of the content of this
element does not need further definition.
I believe this would close the issue - does this make sense?
For clarification, if RespondWith xkms:X509CRL is used, the response is
<ds:X509Data> <ds:X509CRL>...
Should this be stated in the spec line 75?
br, Frederick
---------------------------------------
Frederick Hirsch
Technology Architect
Nokia Mobile Phones
5 Wayside Rd., Burlington, MA 01803 USA
frederick.hirsch@nokia.com
+1 781-993-3735
Received on Monday, 11 November 2002 17:00:41 UTC