If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#16
|
|||
|
|||
Certificate Purpose
V You say that your name is now in the cert. So now your e-mail address
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. Compa 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 |
Ads |
#17
|
|||
|
|||
Certificate Purpose
Vadim Rapp wrote:
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. |
#18
|
|||
|
|||
Certificate Purpose
exported and ran openssl x509 -inform der -in certfile.pem -noout -text ;
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 Befo 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" wrote in message ... Vadim Rapp wrote: 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. |
#19
|
|||
|
|||
Certificate Purpose
From: "Brian Komar (MVP)"
| 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. -- Dave http://www.claymania.com/removal-trojan-adware.html Multi-AV - http://www.pctipp.ch/downloads/dl/35905.asp |
#20
|
|||
|
|||
Certificate Purpose
"Michael Ströder" wrote in :
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. |
#21
|
|||
|
|||
Certificate Purpose
VanguardLH wrote:
"Michael Ströder" wrote in : 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). 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. 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. |
#22
|
|||
|
|||
Certificate Purpose
Vadim Rapp wrote:
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. |
#23
|
|||
|
|||
Certificate Purpose
VanguardLH wrote:
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_...tatus_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. |
#24
|
|||
|
|||
Certificate Purpose
G'day:
"VanguardLH" 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 * |
#25
|
|||
|
|||
Certificate Purpose
Besides this thread, I also asked this question to Thawte support. After two
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 |
#26
|
|||
|
|||
Certificate Purpose
Michael Ströder writes:
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... 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). |
#27
|
|||
|
|||
Certificate Purpose
Vadim Rapp wrote:
Besides this thread, I also asked this question to Thawte support. After two 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? 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. |
#28
|
|||
|
|||
Certificate Purpose
"Michael Ströder" wrote in :
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)? |
#29
|
|||
|
|||
Certificate Purpose
VanguardLH wrote:
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. |
#30
|
|||
|
|||
Certificate Purpose
On Fri, 13 Jun 2008 16:22:20 -0400, David H. Lipman wrote:
From: "Brian Komar (MVP)" | 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. |
Thread Tools | |
Display Modes | |
|
|