[ebxml-cppa-negot] SecurityDetails and Certificate Alignment: Draftabout negotiation range and options.

[Dale Moberg <dmoberg@cyclonecommerce.com>]

What kinds of negotiation might take 
place for aligning SecurityDetails/TrustAnchors
with various CertificateRefs?

First, there are 3 major levels for
aligments in PKI infrastructure.
(Alignments of other security credentials
are not discussed here yet.)

Application Level Security
Messaging Level Security
Transport Level Security

For Transport Level Security, (transient)
encryption and authentication alignment can be needed.
Both server-side and client-side SSL or TLS need
to have the trust anchors synchronize with corresponding
certificates.

For Messaging Level (persistent),
digital envelopes and non-repudiation 
(of origin and/or receipt) by means
of  digital signatures can
need alignment. 

For Application Level (persistent),
digital envelopes and non-repudiation 
(of origin and/or receipt) by means
of  digital signatures can
need alignment. 

We note within the CPA formation appendix:
"Failure to validate a certificate may not 
prevent formation of a draft CPA. First, 
the sender's signing certificate can be a 
self-signed certificate. If so, a reference 
to this self-signed certificate may be added 
to the receiver's TrustAnchors/AnchorCertificateRef 
list. This proposal amounts to proposing to agree 
to a direct trust model, rather than a hierarchical 
model involving Certificate Authorities. Second, 
a proposal to add a trusted root may be made, 
again by appropriate revision of the TrustAnchors."

Let us begin by focusing on what might be up for
negotiation as a result of the draft CPA formation
process. Other details about algorithms or strengths
will be taken up in an entirely distinct document.

First, a change to the PKI might be proposed. What
might be negotiable here? For the self-signed
certificate addition option, the negotiatee
might want to:

1. reject adding a self-signed and
indicate rejection of the security function
resting on this PKI alignment
2. insist on the proposer getting a
certificate from an existing CA.
3. propose issuing another certificate signed by an
acceptable authority.

For case 1, the negotiation "space" would involve
a change in the value of an
attribute under BusinessTransactionCharacteristics.

For case 2, I think we would have to indicate rejection
of the draft CPA and indicate that until the CPP 
certificate value changes, no forward progress. The
proposer would have to go out and get a new certificate.

For case 3, the negotiatee would propose a different
certificate issued by its own CA. The negotiatee would
have to install it and use it for this transaction.
This is not yet a common practice, and though it is
logically possible, I am checking out whether it would
meet any customer needs. (This would involve one side
being a CA for the business process and the ability
of the other side to use more than one certificate
for its existing key-pair). The CPA proposed to
do this would go outside of anything strictly derivable
from the CPP (only the old X.509 would be used to
put together an new X.509 from a new issuer).

Next, for the PKI trust anchor
certificate addition option, the negotiatee
might want to:

1. reject adding a new CA to its trust anchors and
indicate rejection of the security function
resting on this PKI alignment. 
2. insist on the proposer getting a
certificate from some already trusted existing CA.
3. propose accepting another certificate signed by an
its own signing authority, and placed into a 
proposed counter draft CPA.
4. Propose a different trust anchor either higher
or lower in the validation chain than the one
proposed by the other side.

Again as for adding a self-signed certficate,
for case 1, the negotiation "space" would involve
a change in the value of an
attribute under BusinessTransactionCharacteristics.
For case 2, I think the response would have to 
be rejection with a call for a change in CPP.
For case 3, as before. 

For the new case 4, this is logically  possible
but still exotic. In effect, the negotiation
should not matter to the other side, because
it is just an adjustment to which trust anchor
is added to one side's PKI trust list and
the certificate used would still validate to
the alternative trust anchor. Yet it would reflect
a slight change in security details.

That is all for next week's call.