Certificate Purpose
Vadim Rapp
I have a personal email signing certificate from Thawte. The certificate is
issued in my name. The certificate is installed in the system.
If I look at the certificate from Internet Explorer
Options/Content/Certificates, or from MMC, I see two purposes of the
certificate: "proves your identity to a remote computer" and "Protects email
messages".
But if I send an email signed with this certificate, and then look at the
certificate already in the email (sent or received - same thing), I see only
purpose "Protects email messages". Same in Outlook and in Outlook Express.
Why I don't see "proves your identity" purpose in the certificate in email?
--
Vadim Rapp
Polyscience
www.polyscience.com
Brian Komar (MVP)
to sign the email
You use the secure email apploication, you did not use the certificate for
authentication
Brian
"Vadim Rapp" <nos...@sbcglobal.net> wrote in message
news:eGUbwsXz...@TK2MSFTNGP04.phx.gbl...
David H. Lipman
| Because the application is filtering on the actualy application policy used
| to sign the email
| You use the secure email apploication, you did not use the certificate for
| authentication
| Brian
|
Aka; non-repudiation
--
Dave
http://www.claymania.com/removal-trojan-adware.html
Multi-AV - http://www.pctipp.ch/downloads/dl/35905.asp
Vadim Rapp
BKM> used to sign the email
BKM> You use the secure email apploication, you did not use the certificate
BKM> for authentication
I see. I was thinking that the main purpose of singing an email with digital
id is in ensuring that the email has indeed come from the individual who
signed it, kinda digital notarizing. Thawte gives away free certificates
issued to "thawte email user", which only ensure that email message is
intact; but they also have a procedure where you meet their notary, present
your papers, and the notary then enables Thawte to issue you your personal
certificate - already in your name, and having the purpose "proves your
identity" - which is what I did. If this still can't be used in email
communication, then what's the point, and where can it be used is not in
email? how can such certificate be used for authentication?
thanks,
Vadim Rapp
VanguardLH
So are you saying that you went through their WOT (Web of Trust) notary
scheme to get more information added to your Thawte e-mail cert? All
you get with the initial free one is that it is tied to a particular
e-mail address, not who owns (actually leases) that e-mail address.
When you look at the attributes of your Thawte cert (run certmgr.msc),
do you see anything more of you identified in the cert than just your
e-mail address?
Vadim Rapp
V> do you see anything more of you identified in the cert than just your
V> e-mail address?
It's issued in my real name. Without WOT, it would be issued to "email user"
or something like that.
Vadim Rapp
Hello, VanguardLH!
You wrote on Sat, 14 Jun 2008 02:07:45 -0500:
V> "Vadim Rapp" wrote in <news:#6VsT4Zz...@TK2MSFTNGP06.phx.gbl>:
BKM>>> Because the application is filtering on the actualy application
BKM>>> policy used to sign the email You use the secure email apploication,
BKM>>> you did not use the certificate for authentication
??>>
??>> I see. I was thinking that the main purpose of singing an email with
??>> digital id is in ensuring that the email has indeed come from the
??>> individual who signed it, kinda digital notarizing. Thawte gives away
??>> free certificates issued to "thawte email user", which only ensure
??>> that email message is intact; but they also have a procedure where you
??>> meet their notary, present your papers, and the notary then enables
??>> Thawte to issue you your personal certificate - already in your name,
??>> and having the purpose "proves your identity" - which is what I did.
??>> If this still can't be used in email communication, then what's the
??>> point, and where can it be used is not in email? how can such
??>> certificate be used for authentication?
??>>
??>> thanks,
??>> Vadim Rapp
V> So are you saying that you went through their WOT (Web of Trust) notary
V> scheme to get more information added to your Thawte e-mail cert? All
V> you get with the initial free one is that it is tied to a particular
V> e-mail address, not who owns (actually leases) that e-mail address.
V> When you look at the attributes of your Thawte cert (run certmgr.msc),
V> do you see anything more of you identified in the cert than just your
V> e-mail address?
With best regards, Vadim Rapp. E-mail: v...@nospam.myrealbox.com
VanguardLH
According to
https://www.thawte.com/secure-email/web-of-trust-wot/index.html?click=main-nav-products-wot,
you need to visit enough WOT registrars to accumulate 50 trust points to
get your name added to the cert. Each notary can assign from 10 to 35
points to your trust rating depending on the notaries own trust rating,
so it takes 2, or more, notaries to authenticate your cert (although
their FAQ says 3, or more, notaries are required).
You say that your name is now in the cert. So now your e-mail address
and name are in your cert. This is the extent of proving who you are in
their cert. I have heard of no national or international registry to
which you are added which can trace back to sufficient personal details
to guarantee who you are in your cert used to digitally sign your
e-mails. The WOT registrar may require identification to prove who you
are to them but that information is not recorded in some publicly
available registry for proving your identity. Name and e-mail address
are it, but obviously that really doesn't identify you to anyone who has
never received e-mails from you before and done so repeatedly to
recognize that the content matches up with who you are.
Perhaps a subpoena issued to the WOT registrars to have them divulge
their records regarding what was used as proof of your identity (which
will NOT be in the cert) could be used in court to prove a digitally
signed e-mail came from you (or someone using your computer where the
cert was stored). It is doubtful that YOU can ever prove who signed an
e-mail without that subpoena to get those validation records released.
The e-mail cert binds your digital signature to an e-mail identity.
Adding your name is extra (and a bit superfluous if your name is already
in the username portion of your e-mail address) but does show you were
willing to prove to someone as to who you are (but which is not recorded
in the cert).
You can get free e-mail certs from both Thawte and Comodo. All they
really do is show that you really do own (actually lease) the e-mail
address that you say you own (lease) via a challenge sent to the
professed e-mail address that you own (lease). Getting your name added
is beyond that challenge, shows that some proof was presented to
someone, and gets your name added to your cert. Okay, so now you get an
e-mail from Joh...@ISPdomain.com which has the John Doe name in it.
You've never received a John Doe and do not personally know anyone named
John Doe. So what do you know about this John Doe that sent you e-mail?
That they have control over the e-mail account that they used to get the
cert and managed to prove to someone that their name is John Doe for
whatever was used as such evidence to a registrar.
All certs assume trust from a 3rd party rather than trust between the
1st and 2nd parties. Each party assumes the 3rd party is trustworthy.
This 3rd party trust model can be thwarted. From what I've seen of the
paid personal certs, they don't add any more info to the cert. With
their cert, free or paid, you know (or assume):
- The e-mail address to register for the cert is under control of the
person claiming ownership of that e-mail address (but control is not the
same as legal ownership as e-mail accounts have been hacked).
- If the cert owner's name is added, you are trusting the 3rd party's
validation of that owner's identity. The name being added is the
notaries seal that they accepted proof of identity from the professed
owner of the e-mail account.
- That the CA (certificate authority) specified in the cert is who you
expect gets queried to validate the cert and that they can be trusted.
Presumably you are asking about Thawte's freemail certs used to validate
your identity when digitally signing an e-mail. Well, that' is why the
purpose of the cert says "protects e-mail messages". That is the only
purpose of that cert. You are not using a SSL site cert to "prove your
identity to a remote computer". Your computer was never connected to
their computer, so you could never prove it was your computer that
created the message. You sent your e-mail through someone else's mail
host. That's why you need the digital signature to tag along with the
e-mail. You aren't connecting to the recipient's host to prove it was
your computer that connected to them. You could go buy a site cert but
that won't help with digitally signing your e-mails that are delivered
by someone else's host to the recipient's mailbox.
The e-mail cert tries to show some level of proof of who sent the
e-mail, not of the computer used to compose it. In fact, you can
install your e-mail cert on multiple hosts and compose e-mail from each
and digitally sign it. You are attempting to prove you YOU are, not the
host you happened to use to write up the message.
Anne & Lynn Wheeler
asymmetric key cryptography is technology where a pair of keys are
required for encoding and decoding (vis-a-vis symmetric key where
the same key is used for both encoding and decoding).
public(/private) key cryptography is business process where one key (of
asymmetric key pair) is kept confidential and never divulged (private
key) and the other key (public) is freely distributed.
digital signature is a business process that provides authentication and
integrity. the hash of a message is encoded with a private
key. subsequently the hash of the message is recalculated and compared
with the "digital signature" hash that has been decoded with the
corresponding public key. if they are equal, then the message is
presumed to not have been modified and was "signed" by the entity in
possession of the specific "private key". If the hashes are not equal,
then the message has been altered (since "signing") and/or originated
from a different entity.
over the years there has been some amount of semantic confusion
involving the terms "digital signature" and "human signature"
... possibly because they both contain the word "signature". A "human
signature" implies that the person has read, understood, and aggrees,
approves, and/or authorizes what has been signed. A "digital signature"
frequently may be used where a person never even has actually examined
the bits that are digitally signed.
a digital certificate is a business process that is the electronic
analogy to the letters of introduction/credit for first time
communication between two strangers (from sailing ship days and earlier)
... where the strangers have no direct knowledge of each other and/or
don't have recourse to information sources about the other entity.
there was work on generalized x.509 identity digital certificates nearly
two decades ago. the issues, by the middle 90s, was that most
organizations realized that such identity digital certificates,
represented significant privacy and liability issues. As a result, there
was significant retrenching from the paradigm.
In part, the original scenario was electronic mail from the early 80s,
where somebody dialed up their electronic post office, exchanged email
and then hung up. There could be significant problem authenticating
first time email from total stranger (in this mostly "offline"
environment).
Digital certificates had started out with a fairly narrowly defined
market ... first time communication between strangers w/o direct
knowledge of each other (and/or recourse to information about the other
party). Realizing that generalized identity certificates represented
significant privacy and liability issues, resulted in retrenching and
further narrowing of the target market. The increasing pervasivensss of
the internet and online information sources further narrowed their
target market and usefulness (since there became lots of alternatives
for information about total strangers).
Michael Ströder
> You say that your name is now in the cert. So now your e-mail address
> and name are in your cert. This is the extent of proving who you are in
> their cert. I have heard of no national or international registry to
> which you are added which can trace back to sufficient personal details
> to guarantee who you are in your cert used to digitally sign your
> e-mails. The WOT registrar may require identification to prove who you
> are to them but that information is not recorded in some publicly
> available registry for proving your identity. Name and e-mail address
> are it, but obviously that really doesn't identify you to anyone who has
> never received e-mails from you before and done so repeatedly to
> recognize that the content matches up with who you are.
Mainly this boils down to:
A name is not an identity. The name can only be used to look up an
identity within a certain identity context. You will run into issues
when names are not unique within the given context.
> Perhaps a subpoena issued to the WOT registrars to have them divulge
> their records regarding what was used as proof of your identity (which
> will NOT be in the cert) could be used in court to prove a digitally
> signed e-mail came from you (or someone using your computer where the
> cert was stored).
As a WOT digital notary I have to keep paper copies of the identity
cards / passports used when doing the identity check in a face-to-face
meeting for a period of at least 10 years. After this meeting I'm
issuing this user (referenced by e-mail address) the trust points.
> All certs assume trust from a 3rd party rather than trust between the
> 1st and 2nd parties.
Yupp.
But the digital signatures most times are not used without a business
context. So in real life there is already a trust link between 1st and
2nd party (subscriber and relying participant).
> Presumably you are asking about Thawte's freemail certs used to validate
> your identity when digitally signing an e-mail. Well, that' is why the
> purpose of the cert says "protects e-mail messages". That is the only
> purpose of that cert. You are not using a SSL site cert to "prove your
> identity to a remote computer". Your computer was never connected to
> their computer, so you could never prove it was your computer that
> created the message.
This is not true since the challenge-response is most times a
combination of both: Challenge is sent via e-mail, response is sent from
the client via HTTP.
Ciao, Michael.
VanguardLH
> VanguardLH wrote:
>> Presumably you are asking about Thawte's freemail certs used to validate
>> your identity when digitally signing an e-mail. Well, that' is why the
>> purpose of the cert says "protects e-mail messages". That is the only
>> purpose of that cert. You are not using a SSL site cert to "prove your
>> identity to a remote computer". Your computer was never connected to
>> their computer, so you could never prove it was your computer that
>> created the message.
>
> This is not true since the challenge-response is most times a
> combination of both: Challenge is sent via e-mail, response is sent from
> the client via HTTP.
The purpose of the e-mail cert is bound to the use of e-mail. It is NOT
used to identify a host, as is, say, an SSL cert used when connecting to
a server host. When the sender composes an e-mail, NOTHING of the host
on which it was composed is in the cert used to sign the e-mail. That
same cert could be used on a completely different host to also compose a
digitally signed e-mail. When the recipient gets a digitally signed
e-mail, nothing in the *cert* will identify on which host the e-mail was
composed.
Are you claiming that a digitally signed e-mail will hash up the value
of the Received headers in the e-mail to identify from which host the
e-mail was composed? If so, that would be impossible because the
Received headers are added AFTER the e-mail was signed because those
headers are added by the mail hosts, not by the user's e-mail client
that signed their e-mail.
A site cert's purpose is different than an e-mail cert's purpose. One
provides identification (via a trusted 3rd party) of the server to which
the user connects an application and the other identifies WHO composed
an e-mail regardless of on which host the e-mail was composed.
David H. Lipman
|
| The purpose of the e-mail cert is bound to the use of e-mail. It is NOT
| used to identify a host, as is, say, an SSL cert used when connecting to
| a server host. When the sender composes an e-mail, NOTHING of the host
| on which it was composed is in the cert used to sign the e-mail. That
| same cert could be used on a completely different host to also compose a
| digitally signed e-mail. When the recipient gets a digitally signed
| e-mail, nothing in the *cert* will identify on which host the e-mail was
| composed.
|
< snip >
Yes... as I stated earlier for non-repudiation.
Michael Ströder
> The purpose of the e-mail cert is bound to the use of e-mail. It is NOT
> used to identify a host, as is, say, an SSL cert used when connecting to
> a server host.
You can also use the cert for SSL client authentication. And if the
e-mail address is used as user name then there's nothing wrong with that
approach.
> When the sender composes an e-mail, NOTHING of the host
> on which it was composed is in the cert used to sign the e-mail.
It does not need to be.
> That
> same cert could be used on a completely different host to also compose a
> digitally signed e-mail. When the recipient gets a digitally signed
> e-mail, nothing in the *cert* will identify on which host the e-mail was
> composed.
Yes.
> Are you claiming that a digitally signed e-mail will hash up the value
> of the Received headers in the e-mail to identify from which host the
> e-mail was composed?
No.
BTW: It's not necessary.
Ciao, Michael.
VanguardLH
> VanguardLH wrote:
>> The purpose of the e-mail cert is bound to the use of e-mail. It is NOT
>> used to identify a host, as is, say, an SSL cert used when connecting to
>> a server host.
>
> You can also use the cert for SSL client authentication. And if the
> e-mail address is used as user name then there's nothing wrong with that
> approach.
When connecting to a mail server and using SSL, the cert comes from the
server, not from the client. After the SSL session is established, the
client authenticates to the server still using it login credentials.
The SSL simply protected those login credentials from being sniffed from
the network.
For a web browser, the client is not proving who they are. The site is
providing prove of their identity. The client doesn't prove their
identity. You don't need ANY local certs owned by the host owner to
connect to a site that requires an SSL connection. The site's cert is
the only one used. Same when you connect your e-mail client using SSL
to a mail host.
In fact, I've read several security articles where the suggestion is to
immediately delete all locally stored certs on the user's host. That
will NOT bar them from connecting to an SSL-enabled web site or mail
host because it is the host that needs to prove its identity to
establish the connection, not the client.
Please indicate in what scenario a client would need to first obtain a
cert to then use to identify itself to a target web or mail host. I
haven't seen that scenario. I have seen encrypted "keys" used by some
VPN programs to validate that the client's host is allowed to connect to
the corporate network but those keys were not certs. They were keys
generated by the VPN setup, usually by the IT folks, so they know that
key is in their database of allowed outside hosts that are allowed to
connect to their network.
Michael Ströder
> Please indicate in what scenario a client would need to first obtain a
> cert to then use to identify itself to a target web or mail host.
I started using SSL client authentication (additional to the required
server authentication) for HTTPS, IMAPS and SMTP/STARTTLS with
client-side user certs 10 years ago (using Netscape Communicator 4.5 and
Apache/mod_ssl, stunnel to imapd and postfix with starttls patch).
Most people still prefer passwords but sometimes the security policy
might require stronger authentication.
Another example: My web server (stock Apache with mod_ssl configured)
trusts my customer's PKI. So customer's staff can authenticate at my web
server with their authentication cert. With private keys stored on a
PIN-protected smartcard this is even 2-factor authentication. The user
name is in the subject-DN and is used for authorization. In this
scenario I'm correctly authenticating the user. I'm not interested in
from which host the HTTPS request is coming from.
> I haven't seen that scenario.
Well, the fact that you don't know examples does not mean that it's
unfeasible or even unsecure. ;-)
> I have seen encrypted "keys" used by some
> VPN programs to validate that the client's host is allowed to connect to
> the corporate network but those keys were not certs.
You can also use end user certs for client authentication in a VPN. Have
already used this with IPsec/IKE and SSL-based VPNs where appropriate.
Ciao, Michael.
Brian Komar (MVP)
Non-reupdiation is more of an assertion of the measures used to link the
holder of the private key to the subject of the certificate *and* the
mechanisms used to protect that private key to prevent unauthorized access.
Brian
"David H. Lipman" <DLipman~nospam~@Verizon.Net> wrote in message
news:eBShdnyz...@TK2MSFTNGP05.phx.gbl...
Vadim Rapp
V> and name are in your cert. This is the extent of proving who you are in
V> their cert. I have heard of no national or international registry to
V> which you are added which can trace back to sufficient personal details
V> to guarantee who you are in your cert used to digitally sign your
V> e-mails. The WOT registrar may require identification to prove who you
V> are to them but that information is not recorded in some publicly
V> available registry for proving your identity. Name and e-mail address
V> are it, but obviously that really doesn't identify you to anyone who has
V> never received e-mails from you before and done so repeatedly to
V> recognize that the content matches up with who you are.
This is not different from the "paper" situation. Compare: A applies for a
loan. The bank will request the ID.
A presents the ID issued by secretary of state. The bank trusts that
secretary of state has sufficiently verified A's papers when the ID was
given, so with this presumption, the bank assumes that this application is
indeed coming from A.
If the application was done by email, then
secretary of state -> certification authority
driver's license -> certificate
So, if the bank trusts that certification authority has sufficiently
verified A's papers when the certificate was given (Thawte did that in the
process of WOT), then the bank assumes that this email application is indeed
coming from A.
V> Presumably you are asking about Thawte's freemail certs used to validate
V> your identity when digitally signing an e-mail. Well, that' is why the
V> purpose of the cert says "protects e-mail messages". That is the only
V> purpose of that cert.
No; as I said, if I look at the certificate in MMC/Certificates, it shows
two purposes: "protects email message" and also "proves your identity to a
remote computer". So the purpose of proving the identity is in the
certificate. The question is why it does not propagate to the receiver of
the email with this certificate, and he does not see that this certificate
also proves the identity.
The only thing I can think of is indeed the fact that the purpose is to
prove identity to remote computer rather than to the recipient; and since I
indeed did not connect directly to their computer, this did not occur. But
then, what's the point of Thawte's issuing certificate that is supposed to
confirm my identity, but does not have that purpose and instead is using the
purpose that appears to be irrelevant for this?
Vadim Rapp
Michael Ströder
> if I look at the certificate in MMC/Certificates, it shows
> two purposes: "protects email message" and also "proves your identity to a
> remote computer". So the purpose of proving the identity is in the
> certificate. The question is why it does not propagate to the receiver of
> the email with this certificate, and he does not see that this certificate
> also proves the identity.
Well, looking at messages shown by the MMC snap-in is not really a
viable debugging method. You should rather try to look what's exactly
the X.509v3 cert extensions keyUsage and extendedKeyUsage.
Maybe export this cert and let OpenSSL display it:
openssl x509 -in <certfile>.pem -noout -text
or for the binary form
openssl x509 -inform der -in <certfile>.pem -noout -text
Ciao, Michael.
Vadim Rapp
it showed the following (with values after the headers)
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
1d:92:4a:ba:9c:f0:e9:d9:57:d0:96:21:46:c4:ba:09
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=ZA, O=Thawte Consulting (Pty) Ltd., CN=Thawte Personal
Freemail Issuing CA
Validity
Not Before: Jun 10 15:14:43 2008 GMT
Not After : Jun 10 15:14:43 2009 GMT
Subject: SN=Rapp, GN=Vadim, CN=Vadim Rapp/emailAddress=<my email
address>
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:b1:14:f2:76:b3:c4:fc:19:81:f8:d3:54:80:71:
(...)
b5:e0:34:c4:3d:fd:cf:57:e3:50:3d:9f:c7:e2:43:
42:68:5e:54:50:15:0b:ef:ad
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Alternative Name:
email:<my email address>
X509v3 Basic Constraints: critical
CA:FALSE
Signature Algorithm: sha1WithRSAEncryption
70:f1:67:49:41:4d:a6:15:86:0c:5b:59:11:3e:bb:ad:3a:3b:
(...)
9f:4b:3b:5e:06:0e:c3:e7:06:95:00:60:9e:17:05:0d:57:d3:
72:fe
==========================================
Didn't notice extensions keyUsage and extendedKeyUsage in the above..
Looking at the certificate details in MMC at the machine where it's
installed:
Enhanced key usage (property)
Secure Email
Client Authentication
Vadim Rapp
"Michael Ströder" <mic...@stroeder.com> wrote in message
news:akdii5-...@nb2.stroeder.com...
David H. Lipman
| Except that non-repudiation is not needed for client authentication either.
| Non-reupdiation is more of an assertion of the measures used to link the
| holder of the private key to the subject of the certificate *and* the
| mechanisms used to protect that private key to prevent unauthorized access.
| Brian
|
And that's what an email certificate is all about.
We aren't talking about a Smart Card here where we have; email, encryption and
authentication certificates.
VanguardLH
> VanguardLH wrote:
>> Please indicate in what scenario a client would need to first obtain a
>> cert to then use to identify itself to a target web or mail host.
>
> I started using SSL client authentication (additional to the required
> server authentication) for HTTPS, IMAPS and SMTP/STARTTLS with
> client-side user certs 10 years ago (using Netscape Communicator 4.5 and
> Apache/mod_ssl, stunnel to imapd and postfix with starttls patch).
>
> Most people still prefer passwords but sometimes the security policy
> might require stronger authentication.
>
> Another example: My web server (stock Apache with mod_ssl configured)
> trusts my customer's PKI. So customer's staff can authenticate at my web
> server with their authentication cert. With private keys stored on a
> PIN-protected smartcard this is even 2-factor authentication. The user
> name is in the subject-DN and is used for authorization. In this
> scenario I'm correctly authenticating the user. I'm not interested in
> from which host the HTTPS request is coming from.
Yep, after I checked, client authentication can be provided via a
certificate. However, I sincerely doubt that a cert obtained for e-mail
use is usable for a site's authentication of clients that connect to it.
Where do these clients get those certs to authenticate themself to your
site? Aren't they issued by your site? The e-mail certs are coming
from a trusted 3rd party. In your scenario where you want to regulate
who can connect to your server and have them authenticate when to do so,
aren't you the one issuing the cert?
> > I haven't seen that scenario.
>
> Well, the fact that you don't know examples does not mean that it's
> unfeasible or even unsecure. ;-)
>
>> I have seen encrypted "keys" used by some
>> VPN programs to validate that the client's host is allowed to connect to
>> the corporate network but those keys were not certs.
>
> You can also use end user certs for client authentication in a VPN. Have
> already used this with IPsec/IKE and SSL-based VPNs where appropriate.
I checked with a guy from IT during lunch. The brief discussion was,
yes, they do issue a cert (they issue it, not some 3rd party). That
cert really only gets used during the encryption phase to protect the
traffic and only partially to verify the client connecting to their
network. A cert could be moved to another host. They don't want just
any host connecting to their corporate network even if their cert is on
that client host. They want their own specific laptops connecting from
the outside (for contractors) or to regulate exactly which desktops (for
their full-time employees) can connect to their network. So they have
you install their VPN software which requires negotiation with an IT rep
to generate a secret key that is encrypted in the registry and which
snapshots that laptop so the secret key isn't usable on another host.
So when you use their VPN software, it needs the secret key to check
that host is allowed to connect to their network along with THEIR cert
to authenticate that host on their network. And even then you come into
a special "zone" in their network that has further restrictions than a
host sitting in their building. I knew about the VPN setup and key
because I had to input the generated key provided by a code generated by
their program on my host, giving it to the IT guy, and getting back
another code. I wasn't aware that the process also connected to their
cert server to get a special trusted one installed on the host that I
must use to connect from outside. I can't just move their trusted cert
to another host to get it to connect to their network although in a much
less restrictive environment that does seem doable and fits with what
you mention.
Still, I really doubt an e-mail cert from a 3rd party is being used in
this situation to validate the client host is authorized to connect to
the corporate network. The IT guy said it must be THEIR cert used on
the client host. Another reason this setup is used (where their cert
gets installed) is something the IT guy alluded to: man-in-the-middle
"attack" but which is their proxy being able to intercept and
interrogate SSL traffic (so any employee's traffic can be investigated
for policy or company violation). They are the CA for the trusted cert
they installed on your host to validate themself as whatever site was
originally targeted for an SSL connect. Since their cert is trusted,
and since they are their own CA, there is no prompt from the web
browser. He didn't want to go into details, and lunchtime was over,
other than to mention they can look at anyone's SSL traffic going
through their network, in or out or internal. He mentioned a name for
this proxy or appliance but I didn't hear it when we were dumping our
lunch trays. I didn't catch everything he said. Tough to get in half a
hour what he was saying and with not wanting to be too specific in their
implementation.
VanguardLH
You sure the recipient is able to connect to the CA to validate the cert
used in your signed e-mails? As I recall from playing around with
e-mail certs maybe a couple years ago, Outlook had problems connecting
to the CA to get an updated copy of their certificate revocation list
(CRL). As I recall, it really wasn't in the method that Outlook used to
retrieve the CRL but in how Thawte implemented it (maybe the path to the
CRL was wrong). I don't remember the specifics anymore as to why
Outlook couldn't get at Thawte's CRL. Because of this problem, Thawte
had their process to manually download the CRL (don't have the URL to
their FAQ anymore) so you could manually update - but it highly unlikely
that recipients of e-mail are going to bother with manual CRL updates.
I found one of their FAQs at http://tinyurl.com/67f79w but that
describes getting their root cert installed on your host as a trusted
cert. What I recall having to do is described at their FAQ at
http://tinyurl.com/69z4u9.
I don't know if Outlook finally abandoned the CRL scheme (of checking a
"bad certs" list) with the OSCP scheme; see RFC 2560, ratified in June
1999, http://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol
which mentions IE7 - but only on Vista - supports OSCP. I don't know if
that then translates into OSCP support for any e-mail client on the same
Vista host (which already has IE7), like for Outlook 2003 or 2007 (won't
be in Outlook 2002).
If the cert cannot be validated, there should be a message that the
recipient could read to see why it couldn't be validated, like it
expired, was revoked, or a problem contacting the CA (if the sender's
cert wasn't previously saved locally). There might not be an obvious
popup alert about the problem. As I recall, the user would see in
Outlook a "quality seal" icon at the right-side of the header pane in
the preview pane when viewing the e-mail. If there was a problem, the
icon looked broken and the user clicked on it to get more information.
No information was given as to what e-mail clients the recipients are
using. If something other than Outlook then they'll have to ask in a
newsgroup that discusses their e-mail client and how it shows good/bad
status on a digital cert used in an e-mail. Tough to tell why they
don't get a good status on your cert when nothing of their error
regarding that cert is known.
Michael Ströder
> "Michael Ströder" wrote in <news:9q0ii5-...@nb2.stroeder.com>:
>
>> VanguardLH wrote:
>>> Please indicate in what scenario a client would need to first obtain a
>>> cert to then use to identify itself to a target web or mail host.
>> I started using SSL client authentication (additional to the required
>> server authentication) for HTTPS, IMAPS and SMTP/STARTTLS with
>> client-side user certs 10 years ago (using Netscape Communicator 4.5 and
>> Apache/mod_ssl, stunnel to imapd and postfix with starttls patch).
>
> certificate. However, I sincerely doubt that a cert obtained for e-mail
> use is usable for a site's authentication of clients that connect to it.
Whether it does make sense to use e-mail certs also for client
authentication depends on the security policy in effect and the
enrollment process.
> Where do these clients get those certs to authenticate themself to your
> site? Aren't they issued by your site?
They were issued by a CA in a well-defined enrollment process with
client-side key generation.
> The e-mail certs are coming
> from a trusted 3rd party. In your scenario where you want to regulate
> who can connect to your server and have them authenticate when to do so,
> aren't you the one issuing the cert?
In former times I were the CA (I've implemented the open source solution
was http://www.pyca.de back in 1998). But I see no problem to use my
Thawte e-mail cert also for SSL client authc. Whether one trusts a 3rd
party to properly do the identity checking is a question everybody has
to answer himself.
For me the important key point is the client-side key generation done
over a web interface and the authc done when submitting the
certification service request (CSR) containing my public key.
>>> I have seen encrypted "keys" used by some
>>> VPN programs to validate that the client's host is allowed to connect to
>>> the corporate network but those keys were not certs.
>> You can also use end user certs for client authentication in a VPN. Have
>> already used this with IPsec/IKE and SSL-based VPNs where appropriate.
>
> I checked with a guy from IT during lunch. The brief discussion was,
> yes, they do issue a cert (they issue it, not some 3rd party). That
> cert really only gets used during the encryption phase to protect the
> traffic and only partially to verify the client connecting to their
> network.
Sorry, please have a closer look at the cryptographic protocols used.
Checking with a IT guy during lunch is not enough to fully understand
things.
There is no distinction between using the client cert "only for
encryption". There is no proper authorization (here allowing to use a
connection key) without proper authentication.
> A cert could be moved to another host.
How to keep private keys secret is another issue. Smartcards usually
help. Well, a user can pass his smartcard to another user telling him
also the PIN. There is no technical solution to prevent this from happening.
> They want their own specific laptops connecting from
> the outside (for contractors) or to regulate exactly which desktops (for
> their full-time employees) can connect to their network.
Use smartcards which people need all the time (accessing the building,
buying lunch) so it's a loss for them to give it to others.
> So they have
> you install their VPN software which requires negotiation with an IT rep
> to generate a secret key that is encrypted in the registry and which
> snapshots that laptop so the secret key isn't usable on another host.
Is this Cisco VPN? Then SCEP is used. But skilled people can surely
extract the private key from the registry.
> So when you use their VPN software, it needs the secret key to check
> that host is allowed to connect to their network along with THEIR cert
> to authenticate that host on their network.
I think this is flawed because they are reyling on a host-based private
key which they assume cannot be exported and reimported on another
system. I would not do it like this.
> And even then you come into
> a special "zone" in their network that has further restrictions than a
> host sitting in their building.
This does not have anything to do with PKI and certs. That's network
infrastructure.
> I knew about the VPN setup and key
> because I had to input the generated key provided by a code generated by
> their program on my host, giving it to the IT guy, and getting back
> another code.
Sounds like SCEP.
> I wasn't aware that the process also connected to their
> cert server to get a special trusted one installed on the host that I
> must use to connect from outside.
Well, you need a trusted root CA cert.
> I can't just move their trusted cert
> to another host to get it to connect to their network
I think you could if having enough skills. ;-)
> Still, I really doubt an e-mail cert from a 3rd party is being used in
> this situation to validate the client host is authorized to connect to
> the corporate network. The IT guy said it must be THEIR cert used on
> the client host.
Well, that might be true in their configuration. But that does not mean
that it's impossible or insecure to do it otherwise.
The key point with X.509 certs is that the user or system is the only
holder of the secret key. The public-key certs have to be validated
against a public-key cert of a (root) CA cert marked trusted.
> Another reason this setup is used (where their cert
> gets installed) is something the IT guy alluded to: man-in-the-middle
> "attack" but which is their proxy being able to intercept and
> interrogate SSL traffic (so any employee's traffic can be investigated
> for policy or company violation).
Well, that's another point.
> He didn't want to go into details, and lunchtime was over,
> other than to mention they can look at anyone's SSL traffic going
> through their network, in or out or internal.
I know that technique. There are off-the-shelf products implementing
something like this.
Ciao, Michael.
Michael Ströder
> exported and ran openssl x509 -inform der -in <certfile>.pem -noout -text ;
> it showed the following (with values after the headers)
>
> X509v3 extensions:
> X509v3 Subject Alternative Name:
> email:<my email address>
> X509v3 Basic Constraints: critical
> CA:FALSE
> Didn't notice extensions keyUsage and extendedKeyUsage in the above..
Well, obviously these extensions aren't in your cert.
> Looking at the certificate details in MMC at the machine where it's
> installed:
>
> Enhanced key usage (property)
> Secure Email
> Client Authentication
Are you sure you're looking at the *exactly* same cert? If yes, then
welcome to the wonderful world of certificate profiles and the
differences in interpretation of X.509v3 extensions. ;-) It's always
recommended to look up what's actually in a cert and not simply trust a
UI interpreting what's (not) in there.
Whether a particular S/MIME implementation decides that you can use a
cert for S/MIME encryption/signing depends on their interpretation of
keyUsage and extendedKeyUsage.
Therefore I recommend to set in your cert profile for S/MIME certs:
keyUsage = digitalSignature,keyEncipherment
extendedKeyUsage = emailProtection (OID 1.3.6.1.5.5.7.3.4)
Ciao, Michael.
Michael Ströder
> You sure the recipient is able to connect to the CA to validate the cert
> used in your signed e-mails? As I recall from playing around with
> e-mail certs maybe a couple years ago, Outlook had problems connecting
> to the CA to get an updated copy of their certificate revocation list
> (CRL). As I recall, it really wasn't in the method that Outlook used to
> retrieve the CRL but in how Thawte implemented it (maybe the path to the
> CRL was wrong).
Well, that's a matter of well-planned deployment and how to correctly
set up the infrastructure.
> I don't remember the specifics anymore as to why
> Outlook couldn't get at Thawte's CRL. Because of this problem, Thawte
> had their process to manually download the CRL (don't have the URL to
> their FAQ anymore) so you could manually update
Unfortunately Thawte does not add the cRLDistributionPoint extensions to
the e-mail certs. So clients cannot automatically derive where to
retrieve the accompanying CRL for a cert. You have to manually retrieve
it. But once you did the client should be able to memorize the URL of
the CRL and automatically update the CRLs (Mozilla-based clients do this
way).
> I don't know if Outlook finally abandoned the CRL scheme
I hope not!
> (of checking a
> "bad certs" list) with the OSCP scheme; see RFC 2560, ratified in June
> 1999, http://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol
> which mentions IE7 - but only on Vista - supports OSCP.
In Windows you need a so-called revocation provider for OCSP. Don't know
Vista but until Windows XP you have to buy a third-party software for
OCSP. But OCSP is not the overall solution to the problem. The client
has to locate the OCSP responder, OCSP responder asked has to know about
a particular CA to return the correct revocation status of certs issued
by that CA...
> There might not be an obvious
> popup alert about the problem. As I recall, the user would see in
> Outlook a "quality seal" icon at the right-side of the header pane in
> the preview pane when viewing the e-mail. If there was a problem, the
> icon looked broken and the user clicked on it to get more information.
> No information was given as to what e-mail clients the recipients are
> using.
No doubt there are still a lot of deficiencies in the UI of PKI-enabled
applications. I'm fighting with this since 10 years now.
Ciao, Michael.
S. Pidgorny <MVP>
"VanguardLH" <V...@nguard.LH> wrote in message
> Yep, after I checked, client authentication can be provided via a
> certificate. However, I sincerely doubt that a cert obtained for e-mail
> use is usable for a site's authentication of clients that connect to it.
Sometimes can be used for something better. My original "anyone to
subordinate CA": http://seclists.org/bugtraq/2002/May/0178.html
A variation of the method will work, still, today.
--
Svyatoslav Pidgorny, MS MVP - Security, MCSE
-= F1 is the key =-
* http://sl.mvps.org * http://msmvps.com/blogs/sp *
Vadim Rapp
totally irrelevant replies, here's what they say: "Yes, the certificate
proves your identity however that does not need to been included in the
certificate properties. When you send a signed email you are proving your
identity to the recipient. "
It does not seem accurate to me, but maybe I'm wrong?
Vadim Rapp
Anne & Lynn Wheeler
> In Windows you need a so-called revocation provider for OCSP. Don't
> know Vista but until Windows XP you have to buy a third-party software
> for OCSP. But OCSP is not the overall solution to the problem. The
> client has to locate the OCSP responder, OCSP responder asked has to
> know about a particular CA to return the correct revocation status of
> certs issued by that CA...
re:
http://www.garlic.com/~lynn/2008i.html#80 Certificate Purpose
basically public key operation is "something you have" authentication
... i.e. business process that keeps the corresponding private key
confidential and never divulged to anybody. verifying digital signature
(created by a specific private key) with the corresponding public key
... demonstrates the entity has possession of that "private key" (kept
confidential and never divulged to anybody).
as mentioned, digital certificate is the electronic version of the
ancient letters of credit/introduction ... indicating something about
the entity associated with "something you have" authentication for first
time communication between two strangers (who have no other access to
information about each other, either locally and/or in an online
environment).
we had been called in to consult with a small client/server startup that
wanted to do payment transactions on their server and they had invented
this thing called SSL that they wanted to use as part of the process. as
a result we had to do detailed business walkthru of the SSL process as
well as these new operations calling themselves certification
authorities ... and these things they were calling digital certificates.
we had signoff/approval authority on the operation between the server
and this new thing called payment gateway
http://www.garlic.com/~lynn/subnetwork.html#gateway
and were able to mandate some compensating procedures. We only had
advisory capacity between the servers and clients ... and almost
immediately most deployments violated basic SSL assumptions to meet
necessary security (which continues up to current day).
In those early days, we were getting comments from certain factions that
digital certificates were necessary to bring payment transactions into
the modern age. We observed that the use of digital certificates (with
their offline design point) actually set online payment transactions
back decades (not made them more modern). It was somewhat after a whole
series of those interchanges that saw the advent of work on (rube
goldberg) OCSP ... which has the facade of providing some of the
benefits of online, timely operation while still preserving the archaic
offline digital certificate paradigm. The problem with OCSP is that it
doesn't go the whole way and just make things a real online, timely
operation (and eliminate the facade of needing digital certificates for
operation in offline environment). In a online payment transaction
scenario, not only is it possible to do real-time lookup of
corresponding public key for real-time ("something you have")
authentication, but also do real-time authorization ... looking at
things like current account balance and/or do other analysis based on
current account characteristic and/or account transaction
activity/patterns.
There were other incidental problems trying to apply digital
certificates (specifically) to payment transactions (other than
reverting decades of real real-time, online operation to a archaic
offline paradigm). After we worked on what is comingly referred to
electronic commerce today (including the SSL domain name digital
certificate part) ... there was some number of efforts to apply digital
certificates to payment transactins ... at the same time we had been
called in to work in the x9a10 financial standard working group (that
had been given the requirement to preserve the integrity of the payment
infrastructure for all retail payments). we came up with x9.59 financial
standard which could use digital signature authentication w/o the need
for digital certificates (i.e. use digital signatures in a real online
mode of operation w/o the trying to maintain any fiction of digital
certificates and offline operation).
http://www.garlic.com/~lynn/x959.html#x959
we would periodically ridiculed the digital certificates based efforts
(besides noting that it was attempt to revert the decades of online
operation to an offline paradigm). some of that presumably sparked the
OCSP effort. However, the other thing we noted was that the addition of
digital certificates to payload transaction increased the typical
payload size by a factor of 100* times along with increase in processing
by a factor of 100* times. This was enormous bloat (both payload and
processing) for no incremental value (digital certificates were
redundant and superfluous compared to having public key on file in the
account record ... which turns out was necessary for other purposes
anyway). misc. past references
http://www.garlic.com/~lynn/subpubkey.html#bloat
we also noted that the primary purpose of SSL in the world today is in
the electronic commerce application and used to hide the account number
and transaction details (as a countermeasure to account fraud flavor of
identity theft). we pointed out that the work on x9.59 had also slightly
tweaked the payment transaction paradigm and eliminated the need to
"hide" the transaction details. From the security acronym PAIN
P ... privacy (sometimes CAIN, confidential)
A ... authentication
I ... integrity
N ... non-repudiation
... in effect, x9.59 substitutes strong authentication and integrity for
privacy as countermeasure to account fraud (flavor of identity theft).
We noted that not only did the x9.59 standard eliminate the major use of
SSL in the world today (hiding the account number and transaction
details) ... but no longer needing to hide that information ... also
eliminates the threats and vulnerability with the majority of the data
breaches that have been in the news (doesn't eliminate the breaches,
just eliminated the ability of the attackers to use the information for
fraudulent purposes).
Michael Ströder
Well, naturally language is somewhat ambigous. Since you're hopefully
the only one holding the accompanying private key it's true that *you*
are proving your identity to the recipient. But "identity" is quite a
broad term since one is using a name as address of an identity. But a
name is not an identity
A nice presentation about identity by Dick Hardt:
http://identity20.com/media/OSCON2005/
Ciao, Michael.
VanguardLH
> VanguardLH wrote:
>>
>> I don't remember the specifics anymore as to why
>> Outlook couldn't get at Thawte's CRL. Because of this problem, Thawte
>> had their process to manually download the CRL (don't have the URL to
>> their FAQ anymore) so you could manually update
>
> Unfortunately Thawte does not add the cRLDistributionPoint extensions to
> the e-mail certs. So clients cannot automatically derive where to
> retrieve the accompanying CRL for a cert. You have to manually retrieve
> it. But once you did the client should be able to memorize the URL of
> the CRL and automatically update the CRLs (Mozilla-based clients do this
> way).
That sounds very familiar. I remember that Outlook couldn't find the
CRL and that either the path was wrong in the cert or Thawte didn't have
it in that path (or in some default path that would be assumed to be
used by CAs as to where to find their CRL). That Thawte's cert doesn't
even specify the path to the CRL would account for why Outlook cannot
find the CRL. So, there is no default path for CRLs from CAs (if not
specified within the cert)?
Michael Ströder
> So, there is no default path for CRLs from CAs (if not
> specified within the cert)?
Yes, PKIX does not define standard URLs for CRLs. The client
implementation should maintain a cache of the URLs if the user once
downloaded a CRL manually.
Ciao, Michael.
Paul Adare
> From: "Brian Komar (MVP)" <brian...@nospam.identit.ca>
>
>| Because the application is filtering on the actualy application policy used
>| to sign the email
>| You use the secure email apploication, you did not use the certificate for
>| authentication
>| Brian
>|
>
> Aka; non-repudiation
No, and actually non-repudiation is very difficult to implement. A signed
email is more typically signed to indicate that the contents have not been
tampered with during transit than to assert non-repudiation.
--
Paul Adare
http://www.identit.ca
The determined programmer can write a FORTRAN program in any language.
Paul Adare
> From: "Brian Komar (MVP)" <brian...@nospam.identit.ca>
>
>| Except that non-repudiation is not needed for client authentication either.
>| Non-reupdiation is more of an assertion of the measures used to link the
>| holder of the private key to the subject of the certificate *and* the
>| mechanisms used to protect that private key to prevent unauthorized access.
>| Brian
>|
>
> And that's what an email certificate is all about.
No it is not what an email certificate is all about.
>
> We aren't talking about a Smart Card here where we have; email, encryption and
> authentication certificates.
Wrong again. When we're talking about email certificates, whether they be
signing or encryption certificates, and smart cards, the smart card is
simply a more secure storage method for the issued certificates.
--
Paul Adare
http://www.identit.ca
%As far as we know, our computer has never had an undetected error. --
Weisert
Anne & Lynn Wheeler
> Wrong again. When we're talking about email certificates, whether they be
> signing or encryption certificates, and smart cards, the smart card is
> simply a more secure storage method for the issued certificates.
re:
http://wwwg.garlic.com/~lynn/2008i.html#80 Certificate Purpose
http://wwwg.garlic.com/~lynn/2008i.html#83 Certificate Purpose
... the chip is more secure storage method for the "private key". for
digital signatures to represent "something you have" authentication, an
established business process has to provide that the "private key" has
never been divulged, kept confidential and any specific "private key" is
only in the possession of a single individual (the chip storage
supposedly provides for high integrity and additional assurance that
only a single entity has access to & use of the private key).
The public/private key process provides for the "public key" to be
published and widely distributed. Digital certificates are a specific
business process for the distribution of "public keys".
From a "something you have" authentication business process requirement
for "private key" ... the chip provides for a confidential storage
method for the private key. The chip may also be used as a *convenient*
storage method for the corresponding public key and any associated
digital certificate (but there isn't a security requirement to keep the
public key and associated digital certificates confidential ... just
the reverse ... the objective is to make copies of them generally
available).
Anne & Lynn Wheeler
Anne & Lynn Wheeler <ly...@garlic.com> writes:
> re:
> http://wwwg.garlic.com/~lynn/2008i.html#80 Certificate Purpose
> http://wwwg.garlic.com/~lynn/2008i.html#83 Certificate Purpose
oops ... finger slip that should be
http://www.garlic.com/~lynn/2008i.html#80 Certificate Purpose
http://www.garlic.com/~lynn/2008i.html#83 Certificate Purpose
i.e. re:
http://www.garlic.com/~lynn/2008i.html#90 Certificate Purpose
oh and for a little topic drift ... some recent posts/comments about PGP
which makes use of public/private key infrastructure for secure email
but w/o digital certificates
http://www.garlic.com/~lynn/2008i.html#86 Own a piece of crypto wars
http://www.garlic.com/~lynn/2008i.html#87 Historical copy of PGP 5.0i for sale -- reminder of the ware we lost
it also mentions/references this old email from '81
http://www.garlic.com/~lynn/2006w.html#email810515
in this post
http://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network
proposing a PGP-like "certificateless" public/private key operation for
the internal network.
David H. Lipman
>> Aka; non-repudiation
|
| No, and actually non-repudiation is very difficult to implement. A signed
| email is more typically signed to indicate that the contents have not been
| tampered with during transit than to assert non-repudiation.
|
Tell that to the *very large* organization that I belong to where I have to sign email using
my specifically for purposes of non-repudiation.
David H. Lipman
| On Fri, 13 Jun 2008 16:22:20 -0400, David H. Lipman wrote:
|
>> From: "Brian Komar (MVP)" <brian...@nospam.identit.ca>
>>
>|> Because the application is filtering on the actualy application policy used
>|> to sign the email
>|> You use the secure email apploication, you did not use the certificate for
>|> authentication
>|> Brian
>|>
>> Aka; non-repudiation
|
| No, and actually non-repudiation is very difficult to implement. A signed
| email is more typically signed to indicate that the contents have not been
| tampered with during transit than to assert non-repudiation.
|
http://www.infosec.gov.hk/english/itpro/public_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."
http://www.pcmag.com/encyclopedia_term/0,2542,t=nonrepudiation&i=48067,00.asp
"Definition of: nonrepudiation
Not denying or reneging. Digital signatures and certificates provide nonrepudiation because
they guarantee the authenticity of a document or message. As a result, the sending parties
cannot deny that they sent it (they cannot repudiate it). Nonrepudiation can also be used to
ensure that an e-mail message was opened (see e-mail tracker). "
http://iase.disa.mil/pki/faq-pki-pke-may-2004.doc
Anne & Lynn Wheeler
> Tell that to the *very large* organization that I belong to where I
> have to sign email using my specifically for purposes of
> non-repudiation.
in the 90s there was quite a bit of wide-spread confusion about digital
signatures being equated to human signatures (possibly because of
semantic confusion because both terms contain the word "signature")
and/or digital signatures (directly) provided for non-repudiation.
since then several organizations have effectively moved to the position
that various kinds of additional business processors &/or services need
be used to provide for non-repudiation about *something*.
from my merged security taxonomy and glossary
http://www.garlic.com/~lynn/index.html#glosnote
... a (90s) "GSA" definition for non-repudiation:
Assurance that the sender is provided with proof of delivery and that
the recipient is provided with proof of the sender's identity so that
neither can later deny having processed the data. Technical
non-repudiation refers to the assurance a relying party has that if a
public key is used to validate a digital signature, that signature had
to have been made by the corresponding private signature key. Legal
non-repudiation refers to how well possession or control of the private
signature key can be established.
... snip ...
more recent definition from NIST 800-60:
Assurance that the sender of information is provided with proof of
delivery and the recipient is provided with proof of the sender's
identity, so neither can later deny having processed the information.
... snip ...
or FFIEC:
Ensuring that a transferred message has been sent and received by the
parties claiming to have sent and received the message. Non-repudiation
is a way to guarantee that the sender of a message cannot later deny
having sent the message and that the recipient cannot deny having
received the message.
... snip ...
The current scenarios regarding non-repudiation involve additional
business processes and/or services (other than entity "something you
have" digital signatures).
For additional topic drift, one of the "non-repudiation" vulnerabilities
for digital signatures can be a dual-use problem. Digital signatures can
be used used in a purely (possibly challenge/response) "something you
have" authentication (say in place of password). The server sends
random data (as a countermeasure to replay attack), which the client is
expected to digital sign (with the appropriate private key). The server
then verifies the returned digital signature with the onfile public key
(for that account). These scenarios never have the client actually
examining the data being digital signed. If the same public/private key
pair is also ever used in scenario where the entity is assumed to have
actually read (understood, approves, agrees, and/or authorizes) what is
being digitally signed ... then an attack is to include other than
random data in some challenge/response, "something you have"
authentication (say some sort of payment transaction).
The countermeasure is to guarantee that it is only possible to use a
private key for digitally signing of specific kind and that it is
physical impossible for a private key to be used for making any other
kind of digital signature (for instance, a private key will have
knowledge that the hash that is being encoded to form a digital
signature is guarenteed to have been of text that has been read &
understood by you ... and w/o that knowledge, the private key will
refuse to perform the encoding operation).
Paul Adare
> From: "Paul Adare" <pka...@gmail.com>
>
>
>>> Aka; non-repudiation
>|
>| No, and actually non-repudiation is very difficult to implement. A signed
>| email is more typically signed to indicate that the contents have not been
>| tampered with during transit than to assert non-repudiation.
>|
>
> Tell that to the *very large* organization that I belong to where I have to sign email using
> my specifically for purposes of non-repudiation.
Just because your org is attempting to use the certs to assert
non-repudiation does not mean they will be successful in a court of law
when it comes down to brass tacks.
I do this for a living and I can assure you that asserting non-repudiation
is difficult at best.
Oh, and I do this for *extremely large* and security conscious orgs.
--
Paul Adare
http://www.identit.ca
The world will end in 5 minutes. Please log out.
Paul Adare
> "Digital signature is the means to ensure integrity, authenticity, and non-repudiation.
<snip>
I'm well aware of the various definitions here. What you're painfully
unaware of is the onerous process requirements and other requirements for
successfully asserting non-repudiation. A definition of it does not mean it
is easy to implement in practice. It isn't.
--
Paul Adare
http://www.identit.ca
The Geeks shall inherit the earth!
David H. Lipman
|
| Just because your org is attempting to use the certs to assert
| non-repudiation does not mean they will be successful in a court of law
| when it comes down to brass tacks.
| I do this for a living and I can assure you that asserting non-repudiation
| is difficult at best.
| Oh, and I do this for *extremely large* and security conscious orgs.
Tell that to the US DoJ. They ARE the Lawyers and yes, it is true for all branches of the
US Gov't. through PKE. What's good for the goose is good for the gander. If the US Gov't.
does it... it will pass the muster for corporate America.
Let's just end this with my stating...
I beg to differ and I value your input, opinions and information.
Brian Komar (MVP)
the certificate, easy to implement.
Non-repudiation as you are defining it has everything to do with the
issuance process and the tying of the certificate's private key to the
subject of the certificate.
The better the workflow and management of that workflow, the more likely you
are to achieve non-repudiation.
Personally, I do not believe that it is possible to achieve non-repudiation
without hardware protection of key material
Software key protection is too easily defeated.
Brian
"David H. Lipman" <DLipman~nospam~@Verizon.Net> wrote in message
news:ugoq1jZ0...@TK2MSFTNGP06.phx.gbl...
Vadim Rapp
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
Anne & Lynn Wheeler
> 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.
S. Pidgorny <MVP>
"David H. Lipman" <DLipman~nospam~@Verizon.Net> wrote in message
> http://www.infosec.gov.hk/english/itpro/public_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.
sigehereco
Posted as a reply to:
Certificate Purpose
Hello,
I have a personal email signing certificate from Thawte. The certificate is
issued in my name. The certificate is installed in the system.
If I look at the certificate from Internet Explorer
Options/Content/Certificates, or from MMC, I see two purposes of the
certificate: "proves your identity to a remote computer" and "Protects email
messages".
But if I send an email signed with this certificate, and then look at the
certificate already in the email (sent or received - same thing), I see only
purpose "Protects email messages". Same in Outlook and in Outlook Express.
Why I don't see "proves your identity" purpose in the certificate in email?
--
Vadim Rapp
Polyscience
www.polyscience.com
EggHeadCafe - Software Developer Portal of Choice
WCF Workflow Services Using External Data Exchange
http://www.eggheadcafe.com/tutorials/aspnet/3d49fa0d-a120-4977-842a-6dafb17b6d74/wcf-workflow-services-usi.aspx