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 |
#31
|
|||
|
|||
Certificate Purpose
On Mon, 16 Jun 2008 16:42:41 -0400, David H. Lipman wrote:
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. 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 |
Ads |
#32
|
|||
|
|||
Certificate Purpose
Paul Adare writes:
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. 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). |
#33
|
|||
|
|||
Certificate Purpose
Anne & Lynn Wheeler writes: 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. 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. |
#34
|
|||
|
|||
Certificate Purpose
From: "Paul Adare"
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. -- Dave http://www.claymania.com/removal-trojan-adware.html Multi-AV - http://www.pctipp.ch/downloads/dl/35905.asp |
#35
|
|||
|
|||
Certificate Purpose
From: "Paul Adare"
| 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. | http://www.infosec.gov.hk/english/it...blic_main.html "Digital signature is the means to ensure integrity, authenticity, and non-repudiation. A digital signature is derived by applying a mathematical function to compute the message digest of an electronic message or document, and then encrypting the result of the computation with the use of the signer's private key. Recipient can verify the digital signature with the use of the sender's public key." http://www.pcmag.com/encyclopedia_te...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 -- Dave http://www.claymania.com/removal-trojan-adware.html Multi-AV - http://www.pctipp.ch/downloads/dl/35905.asp |
#36
|
|||
|
|||
Certificate Purpose
"David H. Lipman" writes:
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). |
#37
|
|||
|
|||
Certificate Purpose
On Wed, 18 Jun 2008 16:18:26 -0400, David H. Lipman wrote:
From: "Paul Adare" 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. |
#38
|
|||
|
|||
Certificate Purpose
On Wed, 18 Jun 2008 16:29:01 -0400, David H. Lipman wrote:
"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! |
#39
|
|||
|
|||
Certificate Purpose
From: "Paul Adare"
| | 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. -- Dave http://www.claymania.com/removal-trojan-adware.html Multi-AV - http://www.pctipp.ch/downloads/dl/35905.asp |
#40
|
|||
|
|||
Certificate Purpose
My summary is Non-Repudiation as you have discussed is just an attribute in
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" wrote in message ... From: "Paul Adare" | | 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. -- Dave http://www.claymania.com/removal-trojan-adware.html Multi-AV - http://www.pctipp.ch/downloads/dl/35905.asp |
#41
|
|||
|
|||
Certificate Purpose
MS Well, naturally language is somewhat ambigous. Since you're hopefully
MS the only one holding the accompanying private key it's true that *you* MS are proving your identity to the recipient. My concern is this: should the recipient trust the proof of identity that comes on the medium (certificate) that does not say it's good for the purpose of proving the identity? Two examples: 1. a reporter is interviewing a government official. The official is believed to issue only truthful official statements. But now he says something "off the record". Should reporter assume that this is true, or not? I guess not. He _might_, but he does not guarantee that he just _did_. 2. I buy a CD that says it has high fidelity sound recording of performance X. I know that this studio has good equipment, so I trust their word that this is indeed high fidelity. I also know that the studio has good photographers who can make very good pictures. The CD also has the picture of the performer, but there's no statement that it's accurate. Should I trust that the picture is accurate as well? I guess not. They _might_, but they don't guarantee that they just _did_. Same he 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 |
#42
|
|||
|
|||
Certificate Purpose
"Vadim Rapp" writes:
My concern is this: should the recipient trust the proof of identity that comes on the medium (certificate) that does not say it's good for the purpose of proving the identity? 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. |
#43
|
|||
|
|||
Certificate Purpose
Hi David:
"David H. Lipman" wrote in message http://www.infosec.gov.hk/english/it...blic_main.html "Digital signature is the means to ensure integrity, authenticity, and non-repudiation. A digital signature is derived by applying a mathematical function to compute the message digest of an electronic message or document, and then encrypting the result of the computation with the use of the signer's private key. Recipient can verify the digital signature with the use of the sender's public key." Digital signature is required, but is not sufficient, to facilitate non-repudiation. -- Svyatoslav Pidgorny, MS MVP - Security, MCSE -= F1 is the key =- * http://sl.mvps.org * http://msmvps.com/blogs/sp * |
Thread Tools | |
Display Modes | |
|
|