A Windows XP help forum. PCbanter

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.

Go Back   Home » PCbanter forum » Microsoft Windows XP » Security and Administration with Windows XP
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

Certificate Purpose



 
 
Thread Tools Display Modes
  #31  
Old June 18th 08, 08:27 PM posted to microsoft.public.security,microsoft.public.windowsxp.security_admin
Paul Adare[_2_]
external usenet poster
 
Posts: 24
Default 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  
Old June 18th 08, 08:52 PM posted to microsoft.public.security,microsoft.public.windowsxp.security_admin
Anne & Lynn Wheeler
external usenet poster
 
Posts: 6
Default 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  
Old June 18th 08, 09:13 PM posted to microsoft.public.security,microsoft.public.windowsxp.security_admin
Anne & Lynn Wheeler
external usenet poster
 
Posts: 6
Default 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  
Old June 18th 08, 09:18 PM posted to microsoft.public.security,microsoft.public.windowsxp.security_admin
David H. Lipman
external usenet poster
 
Posts: 4,185
Default 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  
Old June 18th 08, 09:29 PM posted to microsoft.public.security,microsoft.public.windowsxp.security_admin
David H. Lipman
external usenet poster
 
Posts: 4,185
Default 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  
Old June 18th 08, 10:10 PM posted to microsoft.public.security,microsoft.public.windowsxp.security_admin
Anne & Lynn Wheeler
external usenet poster
 
Posts: 6
Default 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  
Old June 18th 08, 11:41 PM posted to microsoft.public.security,microsoft.public.windowsxp.security_admin
Paul Adare[_2_]
external usenet poster
 
Posts: 24
Default 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  
Old June 18th 08, 11:44 PM posted to microsoft.public.security,microsoft.public.windowsxp.security_admin
Paul Adare[_2_]
external usenet poster
 
Posts: 24
Default 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  
Old June 19th 08, 12:13 AM posted to microsoft.public.security,microsoft.public.windowsxp.security_admin
David H. Lipman
external usenet poster
 
Posts: 4,185
Default 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  
Old June 19th 08, 12:35 AM posted to microsoft.public.security,microsoft.public.windowsxp.security_admin
Brian Komar \(MVP\)
external usenet poster
 
Posts: 5
Default 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  
Old June 19th 08, 03:52 PM posted to microsoft.public.security,microsoft.public.windowsxp.security_admin
Vadim Rapp[_2_]
external usenet poster
 
Posts: 4
Default 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  
Old June 19th 08, 08:04 PM posted to microsoft.public.security,microsoft.public.windowsxp.security_admin
Anne & Lynn Wheeler
external usenet poster
 
Posts: 6
Default 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  
Old June 20th 08, 09:23 AM posted to microsoft.public.security,microsoft.public.windowsxp.security_admin
S. Pidgorny
external usenet poster
 
Posts: 5
Default 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

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off






All times are GMT +1. The time now is 10:57 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 PCbanter.
The comments are property of their posters.