[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ebxml-cppa-negot] SecurityDetails and Certificate Alignment: Draftabout negotiation range and options.
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC