[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: key recovery options for PKIX-3 CAs?
In this thread, there seems to be (by some) an assumption that if a "private" key is used to identify an individual by signing a session or key or during an exchange, then one "automatically" has non-repudiation with regard to all said in the encrypted electronic conversation. The follow-on to this is that the "courts" could always be called upon to sort things out in the end.
I posit that one does not have non-repudiation unless explicated during the conversation with transaction integrity and user authentication tied to the actual transaction in a (computationally unfeasible) secure manner (i.e., by use of a "traditional" digital signature of the encrypted hash of the object). Furthermore, I posit that, if "key usage" is not set to digital signature with non-repudiation, then courts will not automatically accept such claims.
Knowing who is in a conversation and what was said does not constitute a contract or agreement - even under common law - unless the "intent" to commit to an agreement is made. "Non-repudiation" comes in if it is accepted that every entity that made the commitment was known and their intent was noted (in writing, electronically or verbally) and that what they committed to was unalterable after the fact by any of the parties involved or a third party.
If asked to sign a contract in the real world, everything said before, during and after a contract signing does not enter into the contract that was signed by implication, unless the "intent" to add verbally committed items is specifically acknowledged. Use of encryption would bring all the conversation into discussion, not the specific transaction (i.e., authorization to Broker to buy "x" shares of stock)
Digital signatures are an attempt, I believe, to reduce litigation and explicate what acceptance of an agreement could be, with integrity and non-repudiation. As the ABA discussions about common law and signatures says (my interpretation), any mark or no mark can imply a "signature" or acceptance of an agreement, written or not. The digital signature process and usage was designed to explicate the acceptance and unalteration of the object signed (agreement entered).
Example: One establishes an encrypted session wherein the originating party (or both parties) has "signed" (encrypted) the session's crypto key with a "private" key of some sort and this is validated by the "other" party. Any contesting party should then be able to state that "my key was not set to usage = non-repudiation and/or digital signature, so that you should not be able to enforce any transactions inside that encrypted session. You may know who began the conversation, but can not prove what either of us did during that session, since no integrity checks were done (e.g., your representative could have "forged" a transaction in the record that was hidden from me or that was said to have originated with me". One would not get any integrity checks (encrypted transaction hash or "signature") on each transaction consummated during that session. Resolution would come only for a contested session after court review or arbitration.
I do not feel that even if both parties recorded all the activity during that session under the "signed" session key would constitute "non-repudiation" and would lead to or even necessitate court intervention even where law or administrative rules defined digital signatures for non-repudiation. Also, if this usage is "allowed" via PKIX, then shouldn't this record keeping be required for any potential non-repudiation process wherein the intent is to use this session key as a "signature"?
The PKIX public key infrastructure is being designed to support multiple objectives, including some of the shared secret systems (no "public" keys), asymmetric cryptographic and digital signature systems, and I agree with those inclusions for completion, but keep them separate within the overall framework
Thanks for your patience on this rant.
>>> Peter Williams <firstname.lastname@example.org> 08/18/97 05:36AM >>>
Stephen Kent wrote:
> If I understand Peter's comments re escrow of encryption keys, I
> don't agree with his conclusion. Yes, legally, one can use encryption or
> MAC technology and have it be considered equivalent to signing. However,
> we all know that this is technically inappropriate, and the inclusion of
> usage bits in X.509 certificates allows us to make explicit just how
> inappropriate this is.
I do not know that it is wholly inappropriate, technically.
Do you agree that, as you use of the world "legally" might imply, that
a court, presumably operating under common law, would likely not fail
to recognise the authentication value of a ciphered stream identifying the
originator of the stream (with no digital signature), given
the labelling of the stream with id, categories and sensitivity
markings derived from those same markings
attached to the (encryption) certificate assigned to the
duely authorised originating party?
(I'm thinking here precisely of MSP3 protocol as currently
deployed by DoD and NSA for ensuring access control
via cryptographic separation, originator identity, and label
The X.509 usage bits in a cert are intended for use by the relying party.
They signal the CA's intention for use of the key in association
with a trusted security mechanism. Nothing more.
They do not convey commerce or legal semantics; that
is the function of policy extensions. Should a policy
choose to explicitely enable the legal validity of
encryption-derived authentication, there is
no basis in X.509 (v3) for disallowing this that
I can see.
I can see no basis in PKIX scope or requirements
to deny authentication-only-semantics, when applying
PKIX-certs, over digital-signature semantics,
or confidentiality-semantics - once such are
expressed clearly via policy.
One can imagine one day seeing the
"ABA Authentication Guidelines" emerging
alongside the ABA Digital Signature Guidelines,
and the "ABA Confidentiality Guidelines", as
frameworks for legalistic policy expression
in support of PKIX CA operators providing
third-party assurances in those spheres.