----- Original Message -----
Sent: Thursday, February 21, 2002
11:09 AM
Subject: [ebxml-cppa] RE:
Questions and comments about latest CPPA examples
Saito San:
Please see my embedded
comments.
Regards,
-Arvola
-----Original
Message-----
From: Yukinori Saito [mailto:y-saito@ecom.jp]
Sent: Wednesday,
February 20, 2002 5:22 PM
To: CPPA TC)Dale Moberg; Arvola Chan
Cc: ebxml-cppa@lists.oasis-open.org;
EDIgr)H.Sugamata; EDIgr)K.Mizoguchi; EDIgr)K.Wakaizumi
Subject: Questions
and comments about latest CPPA examples
Dear Dale Moberg,
Dear
Alvola Chan,
As I said before, I explained latest CPPA specification
and related
specifications (MSG and BPSS) to XML/EDI Standardization
Committee and
XML/EDI Promotion Committee in Japan by presenting following
full-line or
full-fledged examples.
-3a4.XML (Business-Process
Document of RosettaNet
PIP3A4)
-draft-cpp-example-companyA-012.xml
-draft-cpp-example-companyB-012.xml
-draft-cpa-example-012.xml
And
I presented supplementary document (Microsoft PPT) named 'Explanation
of
Example of CPPA V1.05', which I posted before.
I think many experts
of IT venders and business experts promoting EDI in
industries in Japan
generally understood structure and functions of CPPA
specification and
relationship with Process-Specification Document based on
BPSS
specification, and MSG Header based on MSG specification.
In these
procedures of studying these latest examples, I have following
questions
and comments about examples of CPPA V1.08.
Please give me some
comments.
1. About 3A4.xml
There is description about Business
document under BusinessDocument element
as
follows.
<BusinessDocument name="Puchase Order
Request"
nameID="Pip3A4PurchaseOrderRequest"
specificationLocation="%SYSTEM
/XMLPIPVALIDATION/3A4/PurchaseOrderRequest.xsd">
There
is specificationLocation attribute that specifies this
Business
document.
I cannot understand the contents of the document
specified by
specificationLocation
attribute.
BPSS specification says
'specificationLocation is Reference to an external
source of the schema
definition'
Is the 'schema definition' definitions of components or terms
in this
Business Document?
Is there some example of this kind of schema
definition?
If there is, please let me know.
The specificationLocation is a pointer to
an actual schema definition (DTD or XSD) for the BusinessDocument. RosettaNet
is currently using DTDs to describe the structure of business documents but
will be migrating to XSDs for next generation PIPs. You can go to www.rosettanet.org and download the PIP
3A4 package. It should include DTDs for the request and response actions.
Alternatively, do the following navigation from www.rosettanet.org:
Foundational Programs ->
Next Generation Architecture -> NextGen PIP Review
to see an example of a
next generation RosettaNet PIP.
2. About
draft-cpp-example-companyA-014a.XML
(1) About CanSend element
The
third CanSend element in this CPP example has one
ThisPartyActionBinding
element
and two CanReceive elements.
I don't
know whether this structure is correct or not correct.
I think this
structure may be mistaken. Because CPPA specification says 'The
CanSend
element identifies an action message that a Party is capable of
sending. It
has two sub-elements: ThisPartyActionBinding and
OtherPartyActionBinding.'.
This definition means CanSend element is not
allowed to have CanReceive
element.
The example is a little bit ahead of the
spec. Dale and I discussed last week about the idea of having CanSend elements
nested under CanReceive elements to indicate that a receiver can return one or
more types of response synchronously. (Similarly CanReceive elements can be
nested under CanSend elements to indicate that a sender expects to receive one
or more types of response synchrnously.) This concept was incorporated
into the schema, the examples, and the appendix on CPA composition.
Unfortunately, both Dale and I both assumed the other person would supply the
necessary changes to main body of the specification, thus no change got
incorporated into the 1.08 draft. This should be fixed in the 1.09
draft.
(2) About Certificate element
In the latest example of
CPPA (draft-cpp-example-companyA-014a.xml), there
is contents in ds:Keyinfo
element as follows.
<tp:Certificate
tp:certId="CompanyA_AppCert">
<ds:KeyInfo>
<ds:KeyName>CompanyA_AppCert_Key</ds:KeyName>
</ds:KeyInfo>
</tp:Certificate>
There is KeyName
information under ds:KeyInfo element.
-Is this example, which specifies
KeyName as KeyInfo, typical usage of
Certificate element?
-There is
no description about ds:KeyName element in the latest CPPA
specification
V1.08.
I think some description of ds:KeyName element is necessary in
the
specification.
The following information
is in the 1.08 draft:
The TrustAnchors element eventually
resolves into XMLDsig KeyInfo elements These elements may
contain several certificates (a chain), and may refer to those certificates
using the RetrievalMethod element. When there is a chain, the
trust anchor is the “leaf” certificate with respect to the “root” issuing
Certificate Authority (CA) certificate. The root CA will be a self-issued and
self-signed certificate, and using the Issuer information and perhaps key
usage attributes, the leaf certificate (“issued but not issuing” within the
chain) can be determined. The chain is included for convenience in that
validity checks typically will chain to a “root” CA. Please note that the
inclusion of a root CA in a chain does not mean that the root CA is being announced as a trust
anchor. It is possible for there to be a PKI policy in which some, but not
all, intermediate CAs are trusted. If a root CA were accepted as a trust
anchor, all of its intermediate CAs, and all the certificates they issue,
would be validated. That might not be what was intended.
We are mostly talking about the
ds:X509Data element which can appear as a sub-element under ds:KeyInfo. The
following is an excerpt from the XMLDSIG specification:
4.4.4 The X509Data
Element
- Identifier
Type="http://www.w3.org/2000/09/xmldsig#X509Data
"
(this can be used within a RetrievalMethod
or
Reference
element to identify the referent's type)
An X509Data
element within KeyInfo
contains one
or more identifiers of keys or X509 certificates (or certificates' identifiers
or a revocation list). The content of X509Data
is:
- At least one element, from the following set of element types; any of
these may appear together or more than once iff (if and only if) each
instance describes or is related to the same certificate:
-
- The
X509IssuerSerial
element, which contains an X.509
issuer distinguished name/serial number pair that SHOULD be compliant with
RFC2253 [LDAP-DN],
- The
X509SubjectName
element, which contains an X.509
subject distinguished name that SHOULD be compliant with RFC2253 [LDAP-DN],
- The
X509SKI
element, which contains the base64 encoded
plain (i.e. non-DER-encoded) value of a X509 V.3 SubjectKeyIdentifier
extension.
- The
X509Certificate
element, which contains a
base64-encoded [X509v3]
certificate, and
- Elements from an external namespace which accompanies/complements any
of the elements above.
- The
X509CRL
element, which contains a base64-encoded
certificate revocation list (CRL) [X509v3].
Any X509IssuerSerial
, X509SKI
, and
X509SubjectName
elements that appear MUST refer to the
certificate or certificates containing the validation key. All such elements
that refer to a particular individual certificate MUST be grouped inside a
single X509Data
element and if the certificate to which they
refer appears, it MUST also be in that X509Data
element.
Any X509IssuerSerial
, X509SKI
, and
X509SubjectName
elements that relate to the same key but
different certificates MUST be grouped within a single KeyInfo
but MAY occur in multiple X509Data
elements.
All certificates appearing in an X509Data
element MUST relate
to the validation key by either containing it or being part of a certification
chain that terminates in a certificate containing the validation key.
No ordering is implied by the above constraints. The comments in the
following instance demonstrate these constraints:
<KeyInfo>
<X509Data> <!-- two pointers to certificate-A -->
<X509IssuerSerial>
<X509IssuerName>CN=TAMURA Kent, OU=TRL, O=IBM,
L=Yamato-shi, ST=Kanagawa, C=JP</X509IssuerName>
<X509SerialNumber>12345678</X509SerialNumber>
</X509IssuerSerial>
<X509SKI>31d97bd7</X509SKI>
</X509Data>
<X509Data><!-- single pointer to certificate-B -->
<X509SubjectName>Subject of Certificate B</X509SubjectName>
</X509Data>
<X509Data> <!-- certificate chain -->
<!--Signer cert, issuer CN=arbolCA,OU=FVT,O=IBM,C=US, serial 4-->
<X509Certificate>MIICXTCCA..</X509Certificate>
<!-- Intermediate cert subject CN=arbolCA,OU=FVT,O=IBM,C=US
issuer CN=tootiseCA,OU=FVT,O=Bridgepoint,C=US -->
<X509Certificate>MIICPzCCA...</X509Certificate>
<!-- Root cert subject CN=tootiseCA,OU=FVT,O=Bridgepoint,C=US -->
<X509Certificate>MIICSTCCA...</X509Certificate>
</X509Data>
</KeyInfo>
Regards,
Yukinori
Saito
---------------------------------------------------
Yukinori
Saito
Electronic Commerce Promotion Council of Japan (ECOM)
E-mail:
y-saito@ecom.jp
Tel: +81-3-3436-7542 Fax:
+81-3-3436-7570
---------------------------------------------------