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] RE: Questions and comments about latest CPPA examples


Title:

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:

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




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


Powered by eList eXpress LLC