[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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:
X509Data
ElementType="http://www.w3.org/2000/09/xmldsig#X509Data
"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:
X509IssuerSerial
element, which contains an X.509
issuer distinguished name/serial number pair that SHOULD be compliant with
RFC2253 [LDAP-DN],
X509SubjectName
element, which contains an X.509
subject distinguished name that SHOULD be compliant with RFC2253 [LDAP-DN],
X509SKI
element, which contains the base64 encoded
plain (i.e. non-DER-encoded) value of a X509 V.3 SubjectKeyIdentifier
extension.
X509Certificate
element, which contains a
base64-encoded [X509v3] certificate,
and
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC