Certificate Purpose

MS> Well, naturally language is somewhat ambigous. Since you're hopefully
MS> the only one holding the accompanying private key it's true that *you*
MS> are proving your identity to the recipient.

My concern is this: should the recipient trust the proof of identity that
comes on the medium (certificate) that does not say it's good for the
purpose of proving the identity?

Two examples:

1. a reporter is interviewing a government official. The official is
believed to issue only truthful official statements. But now he says
something "off the record". Should reporter assume that this is true, or
not? I guess not. He _might_, but he does not guarantee that he just _did_.

2. I buy a CD that says it has high fidelity sound recording of performance
X. I know that this studio has good equipment, so I trust their word that
this is indeed high fidelity. I also know that the studio has good
photographers who can make very good pictures. The CD also has the picture
of the performer, but there's no statement that it's accurate. Should I
trust that the picture is accurate as well? I guess not. They _might_, but
they don't guarantee that they just _did_.

Same here: even if the recipient is in consensus with Thawte about what is
identity, and even though Thawte _might_ prove the identity of the sender in
a certificate, if there's no statement that _this_ certificate is good for
proving it, the statement about the identity should not be trusted.

Specifically, even if the original certificate did have the purpose of
proving the identity (or more generally, had statement A and purpose of
stating A), but on the way to recipient's mailbox it was dropped for some
reason, I think this means that A now should not be trusted - because at or
after the point where the purpose of stating A was dropped, A might be
altered.

Vadim Rapp

"Vadim Rapp" <vr@nospam.myrealbox.com> writes:
> My concern is this: should the recipient trust the proof of identity that
> comes on the medium (certificate) that does not say it's good for the
> purpose of proving the identity?

re:
http://www.garlic.com/~lynn/2008i.html#80 Certificate Purpose
http://www.garlic.com/~lynn/2008i.html#83 Certificate Purpose
http://www.garlic.com/~lynn/2008i.html#90 Certificate Purpose
http://www.garlic.com/~lynn/2008i.html#91 Certificate Purpose
http://www.garlic.com/~lynn/2008i.html#92 Certificate Purpose

recipient is a relying party ... typically in *trusted* 3rd party
certification authority paradigm ... why do you thing the word *trusted*
appears in the press so much?

*trusted* 3rd party certification authorities have been typically
disclaiming responsibility/liability for ages.

so there are actually a number of *trust* problems.

for a technical *trust* deficiency, most certification authorities
aren't the authoritative agency for the information they are certifying
(which is embodied in the digital certificate they issue).

in the case of email, the authoritative agency for email address is
typically the associated ISP. so if that ISP doesn't provide any
security for passwords ... then some attacker could obtain access to the
email. they could then apply for a different digital certificate (with a
different public/private key) for the same email address. Now, there is
a situation where there may be two (or more) different *trusted* valid
accepted digital certificates for the same email address.

a recipient's countermeasure for this sort of threat is to maintain
local repository of the *correct* digital certificate. however, that
actually becomes the PGP model ... which only requires the recipient to
maintain local repository of the *correct* public key ... where digital
certificates are redundant and superfluous.
http://www.garlic.com/~lynn/subpubkey.html#certless

for a business *trust* deficiency ... parties have
responsibility/liability obligations based on explicit or implicit
contract. in the *trusted* 3rd party certification authority business
model the *contract* is between the certification authority and the
entity that the digital certificate is issued to. there typically is no
implicit, explicit, and/or implied contract between *trusted* 3rd party
certificaiton authorities and the relying parties that *rely* on the
validity of the issued digital certificates ... and therefor no reason
for relying parties to trust the digital certificates.

basically the *trusted* 3rd party certification authority business model
doesn't correspond to long established business practices. this is
actually highlighted in the federal PKI program ... which has the GSA
.... acting as an agent for all federal relying party entities
.... signing explicit contracts with the authorized certification
authorities ... creating explicit contractual obligation between the
relying parties and the *trusted* 3rd party certification authorities
.... providing basis on which trust/reliance can be based.

another approach is the "relying-party-only" certification authority
information (i.e. the relying party actually issuing the digital
certificate).
http://www.garlic.com/~lynn/subpubkey.html#rpo

the issue here is the certification authority has as part of the
business process something frequently referred to as registration ...
where the public key is registered (prior to issuing a digital
certificate). The original design point for digital certificates is
first time communication between two strangers. However, in all the
relying-party-only scenarios is normally trivial to also show that the
digital certificates are redundant and superfluous ... since the public
key is typically registered in the same repository that other
information about the subject entity is being kept ... and which is
normally accessed in any dealings that the relying party will have with
that entity.

as mentioned previously the early 90s, saw work on generalized x.509
identity digital certificates ... but by the mid-90s, most institutions
realized that this "identity" digital certificates (frequently becoming
overloaded with personal information) represented significant privacy
and liability issue. The retrenchment was to relying-party-only digital
certificates which would only contain some sort of record locator
.... where all the actual information resided. Again it was trivial to
show that digital certificates were redundant and superfluous since this
record would also contain the associated public key.

Hi David:

"David H. Lipman" <DLipman~nospam~@Verizon.Net> wrote in message

> http://www.infosec.gov.hk/english/it...blic_main.html
> "Digital signature is the means to ensure integrity, authenticity, and
> non-repudiation. A
> digital signature is derived by applying a mathematical function to
> compute the message
> digest of an electronic message or document, and then encrypting the
> result of the
> computation with the use of the signer's private key. Recipient can verify
> the digital
> signature with the use of the sender's public key."


Digital signature is required, but is not sufficient, to facilitate
non-repudiation.


--
Svyatoslav Pidgorny, MS MVP - Security, MCSE
-= F1 is the key =-

* http://sl.mvps.org * http://msmvps.com/blogs/sp *