RE: Draft attached this time. RE: [ebxml-cppa] Proposed schemachanges,plus illustrative example

[Dale Moberg <dmoberg@cyclonecommerce.com>]

Arvola, responses in-line.
I will probably need to achieve
a more "final version" mode
of expression to clarify
some of the points that bother you.

 Dale. 

-----Original Message-----
From: Arvola Chan [mailto:arvola@tibco.com]
Sent: Tuesday, October 23, 2001 2:03 PM
To: ebxml-cppa@lists.oasis-open.org
Subject: Re: Draft attached this time. RE: [ebxml-cppa] Proposed
schemachanges, plus illustrative example


 I am somewhat confused by the element hierarchy you are using here,
with
TrustAnchor, SecurityPolicy, and AuthenticationCredential as children
elements of SecurityDetails. In the ebXML Technical Architecture
Security
document, the SecurityPolicy element is the parent of TrustAnchors,
Profiles, WillUse, and WillAccept.

<Dale>
The short answer is that the new SecurityDetails 
is the new container element that more or less 
takes over some aspects of the TA proposal. The
TA proposal leaves a number of issues unresolved.
The WillUse and WillAccept elements are not yet used and
may be replaced by some other elements to mark
a list of acceptable policies.
However, we need to understand
how to reference Policies, and even what they are. Messaging
now has appendix C that list policies. Are these the policies
we should be referencing? Are there others? For these
reasons, I am not following the TA Security 
proposal in spirit if not in letter.
SecurityPolicy is broken out differently 
than in the TA Risk document.
AuthenticationCredential is something new that is to reflect, initially,
probably just a type that is required for access (basic auth or digest
auth)
eventually it can be expanded to carry credentials for access
Etc.
</Dale>

 Why are you defining a complex type as opposed to another element that
can
be referenced, in place of CertificateRef? If you really want to define
a
complexType, can you explicitly name this type?

<Dale>
I am not particularly concerned with the contrast you make here. It
seemed
worthwhile to conserve the existing element, CertificateRef, and allow
it to occur in a sequence along with a new reference element, pointing
out to SecurityDetails. Pick how to best do that and I will be happy.
</Dale>

 Why are you showing the attribute certId here? Since you are
referencing
another top-level element, I don't think you need to explicitly identify
the
attributes of the referenced element.

<Dale>
Unsure what question is, but IDREFs are used to refer to either
the Certificates or to the SecurityDetails. The attributes, in
other words, have values that match ID-type attributes on Certificates
or SecurityDetails. Correct any cut and paste error as necessary.
</Dale>


 Similar comment to [a3].

 If you add a keypairUsage attribute to CertificateRef, you would not be
imposing any constraint on the expected value of this attribute, to
correspond to the context where the CertificateRef element is used. 

<Dale>
The idea here is that the value of the keypairUsage attribute would
indicate
how the Certificate being referred to is used.  So, for example, if we
are
in a DigitalEnvelope element environment, the keypairUsage attribute's
value of for example "keyExchange" would indicate that 
this certificate is the one to be used for
the key exchange, that is, it supplies the public key that is used in
encrypting the symmetric key used in "enveloping" the data. 

Looking at your proposal, you have chosen to mark the semantics by
creating new element tags for the references. That is another way
to mark the distinctions needed, and would probably work. 

I guess I find the enumerated range of values for an attribute approach
to
be easier to add to if we need to support some new cryptographic
function
that needs PKI infrastructure.
</Dale>

Since you have defined a complex type that encompasses CertificateRef
and
SecurityRef, is it possible to name subelements under CollaborationRole,
TransportSecurity, NonRepudiation, and DocumentEnvelope that are of this
complex type in such a way that the key usage information is conveyed in
the
element name? 


 This assumes that the possible values of keypairUsage are enumerated.

<Dale>
This was what was intended. I mentioned a few values. Looking over your
proposal, I guess
I just left CertificateRef as a single repeated element, but added the
attribute
value (over an enumeration) to mark the usage. You appear to add new
element tags.
If that is so, I guess the difference may be somewhat aesthetic. I guess
I thought
it would be easier to expand an enumeration than add new element tags.
More below. 
</Dale>

 This conflicts with the assumption that keypairUsage values are
enumerated.

<Dale>Not sure I gather what the antecedent to "This" is. The idea is
that the attribute value on CertificateRef
marks the flavor of certificate usage, and the value used for this
semantic marking comes from an enumerated range. </Dale>

 It is possible to name the element in such a way that the multiple
keypair
usages at an existing CertificateRef location is conveyed.

<Dale> I don't actually think that there will be multiple uses
at any locations where we now have CertificateRefs or at any that
are currently being considered to be added. That is, the enum
values used will be distinct. (If not, that would be a reason
to not use an attribute.) However, one and the same certificate may
be used for both signature and for keyexchange. That is why the
attribute should go on the CertificateRef and not on the
Certificate.</Dale>

 The ebXML Technical Architecture Security paper proposes a TrustAnchors
element but not a TrustAnchor element. Your proposal is the other way
round.

<Dale>Might be a typo! Pick the noun quantity you prefer.  But it
must be possible to have a sequence of CertificateRef elements under
this element. Plural sounds fine to me.</Dale>

 Need both ClientSide and ServerSide certificates.

 Would this be redundant? Is the CertificateRef under NonRepudiation
already
used for this purpose?

 Hasn't this been mentioned earlier? Why is this an addition?

<Dale>clientSide and serverSide were possibly values
for an enumeration to indicate that a certificate was
used for transport-security clientSide or serverSide authentication
(for SSL or TLS) NonRepudiation, hmmh, I think this has always and
only been a property to be implemented by means of
signatures over the message or
payload and not at the transport layer.
That is, these are XMLDsig or SMIME or similar
styles of authentication. Right? </Dale>

-----Original Message-----
From: Dale Moberg <dmoberg@cyclonecommerce.com>
To: Arvola Chan <arvola@tibco.com>; ebxml-cppa@lists.oasis-open.org
<ebxml-cppa@lists.oasis-open.org>
Date: Tuesday, October 23, 2001 8:17 AM
Subject: Draft attached this time. RE: [ebxml-cppa] Proposed schema
changes,
plus illustrative example


Omitted in reply



----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>