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] | [List Home]


Subject: Re: [ebxml-cppa] Proposed language for clarification on the SenderNonRepudiation and ReceiverNonRepudiation elements in CPP and CPA contexts.


The cardinality of SignatureAlgorithm must be stated to be "one or  more" in both places to agree with the schema.  The explanation should also explicitly say that there is exactly one SignatureAlgorithm element in the CPA. See the corrections below (red).

Previously, I had pointed out that until now, in all cases where the CPA rules differ from the CPP rules, the CPA rules are spelled out in the CPA section. It would be best to maintain this pattern. I had proposed that the following text go in both sections in the CPP section and that the detailed explanation go in the CPA section:
"...one or more SignatureAlgorithm elements.  See the discussion in (cross reference to section 9.X) on the differences between the cardinality in the CPP and CPA."
A SignatureAlgorithm subsection would then be added to the CPA section that would contain the detailed discussion (as given below) and refer back to 8.4.43 and 8.4.54. Alternatively, to match the pattern in the CPP section, separate SenderNonrepudiationElement and ReceiverNonrepudiationElement sections can be added to the CPA section, each containing the explanation given below and referring back to 8.4.43 or 8.4.54.

Regards,
Marty


At 11:57 AM 6/8/2004, Dale Moberg wrote:
Hi

I have been preparing version 2.1 that "rolls up" both errata and the
extensibility changes in schema version 2.1.

I noticed that I did not send the final errata language we had discussed
in May. I propose that we add the same
comment in two sections (8.4.43 and 8.4.54) to explain why
SignatureAlgorithm is repeatable in CPPs. Please comment
on the list or in this week's teleconference on Friday June 11 at 8 AM
PDT.

I think this is the last fix. I hope to have a draft of 2.1 available
for inspection around the end of June.

Thanks,
Dale Moberg



8.4.43

The SenderNonRepudiation element is comprised of the following child
elements:
*       a REQUIRED NonRepudiationProtocol element,
*       a REQUIRED HashFunction (e.g. SHA1, MD5) element,
*       one or more REQUIRED SignatureAlgorithm elements,
*       a REQUIRED SigningCertificateRef element

When used within a CPP, the SignatureAlgorithm element can be repeated
to indicate supported capabilities. The order within a repeated list of
elements indicates comparative preference. A CPA shall have exactly one
SignatureAlgorithm element whose value is the agreed upon signature algorithm.


8.4.54

The ReceiverNonRepudiation element is comprised of the following child
elements:
*       a REQUIRED NonRepudiationProtocol element (see Section 8.4.44),
*       a REQUIRED HashFunction (e.g. SHA1, MD5) element (see Section
8.4.45),
*       one or more REQUIRED SignatureAlgorithm elements (see Section 8.4.46),
*       zero or one SigningSecurityDetailsRef element

When used within a CPP, the SignatureAlgorithm element can be repeated
to indicate supported capabilities. The order within a repeated list of
elements indicates comparative preference. A CPA shall have exactly one
SignatureAlgorithm element whose value is the agreed upon signature algorithm.

To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ebxml-cppa/members/leave_workgroup.php.

*************************************
Martin Sachs
standards architect
Cyclone Commerce
msachs@cyclonecommerce.com



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