| View previous topic :: View next topic |
| Author |
Message |
Nico Kadel-Garcia
Guest
|
 Posted: Sun Nov 16, 2008 3:16 am Post subject: Re: GPG |
 |
|
Anne & Lynn Wheeler wrote:
| Quote: | Doug Laidlaw <doug@dougshost.invalid> writes:
I have never believed in "Don't ask questions; just follow the crowd."
Accepting "the crowd" has given me a disk bloated with drivers that I will
never use, and locales that I will never use, with no better justification
than the famous "Because they are there!"
I am still wondering if I need GPG at all. About the only scenario I can
see where it is worth the trouble is emailing credit card details. If such
an email is signed with GPG, is it protected during transit? It is in no
way protected upon arrival.
"asymmetric cryptography" is technology where there are a pair of keys
... what one key encodes, the other key decodes. this is in contrast to
symmetric key technology where the same key is used to both encode &
decode.
"public key" is a business process is where one of the key pair is
designated "public" and is freely published. the other key is kept
private & confidential and never divulged.
|
I have *NEVER* heard this called a business process. Who calls it that? |
|
| |
|
 Back to top |
Anne & Lynn Wheeler
Guest
|
| Posted: Sun Nov 16, 2008 3:37 am Post subject: Re: GPG |
|
|
Nico Kadel-Garcia <nkadel@gmail.com> writes:
| Quote: | I have *NEVER* heard this called a business process. Who calls it that?
|
re:
http://www.garlic.com/~lynn/2008q.html#0 GPG
I do all the time ... for a little topic drift ... recent post
http://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network
containing copy of old email from may81 ... part of thread discussing
proposal for PGP-like email operation on the internal network
http://www.garlic.com/~lynn/2006w.html#email810515
the internal network was larger than the arpanet/internet from just
about the beginning until possibly late 85 or early 86 ... misc. past
posts mentioning internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet
another part of the discussion in this post
http://www.garlic.com/~lynn/2007d.html#49 certificate distribution
with this slightly earlier email
http://www.garlic.com/~lynn/2007d.html#email810506
--
40+yrs virtualization experience (since Jan68), online at home since Mar70 |
|
| |
|
| Back to top |
Nico Kadel-Garcia
Guest
|
| Posted: Sun Nov 16, 2008 6:03 am Post subject: Re: GPG |
|
|
Anne & Lynn Wheeler wrote:
| Quote: | Nico Kadel-Garcia <nkadel@gmail.com> writes:
I have *NEVER* heard this called a business process. Who calls it that?
re:
http://www.garlic.com/~lynn/2008q.html#0 GPG
I do all the time ... for a little topic drift ... recent post
http://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network
containing copy of old email from may81 ... part of thread discussing
proposal for PGP-like email operation on the internal network
http://www.garlic.com/~lynn/2006w.html#email810515
the internal network was larger than the arpanet/internet from just
about the beginning until possibly late 85 or early 86 ... misc. past
posts mentioning internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet
another part of the discussion in this post
http://www.garlic.com/~lynn/2007d.html#49 certificate distribution
with this slightly earlier email
http://www.garlic.com/~lynn/2007d.html#email810506
|
I don't see them describing the PGP/GPG public/private key technology as a
business practice. Really, I see a lot of mentions about using them *in*
business practices, but I've never seen the technology itself referred to as
one. Or am I missing something in your references? Seriously, you're the only
one I've seen do so, and even your own references above to your own
conversations don't seem to do this.
I'm not trying to be cranky, just really surprised at this description. |
|
| |
|
| Back to top |
Anne & Lynn Wheeler
Guest
|
| Posted: Sun Nov 16, 2008 6:14 am Post subject: Re: GPG |
|
|
Nico Kadel-Garcia <nkadel@gmail.com> writes:
| Quote: | I don't see them describing the PGP/GPG public/private key technology as a
business practice. Really, I see a lot of mentions about using them *in*
business practices, but I've never seen the technology itself referred to as
one. Or am I missing something in your references? Seriously, you're the only
one I've seen do so, and even your own references above to your own
conversations don't seem to do this.
|
re:
http://www.garlic.com/~lynn/2008q.html#0 GPG
http://www.garlic.com/~lynn/2008q.html#1 GPG
a few business process references ....
http://www.garlic.com/~lynn/98.html#41 AADS, X9.59, & privacy
http://www.garlic.com/~lynn/aepay2.htm#aadsx959 Account Authority Digital Signatures ... in support of x9.59
http://www.garlic.com/~lynn/aadsm3.htm#cstech cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#kiss1 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm3.htm#kiss3 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm8.htm#softpki19 DNSSEC (RE: Software for PKI)
http://www.garlic.com/~lynn/aadsmore.htm#client4 Client-side revocation checking capability
http://www.garlic.com/~lynn/aepay10.htm#65 eBay Customers Targetted by Credit Card Scam
http://www.garlic.com/~lynn/aepay11.htm#68 Confusing Authentication and Identiification?
http://www.garlic.com/~lynn/aadsm12.htm#53 TTPs & AADS Was: First Data Unit Says It's Untangling Authentication
http://www.garlic.com/~lynn/aadsm13.htm#12 Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS)
http://www.garlic.com/~lynn/aadsm13.htm#16 A challenge
http://www.garlic.com/~lynn/aadsm14.htm#35 The real problem that https has conspicuously failed to fix
http://www.garlic.com/~lynn/aadsm19.htm#2 Do You Need a Digital ID?
http://www.garlic.com/~lynn/aadsm19.htm#9 PKI News
http://www.garlic.com/~lynn/aadsm19.htm#17 What happened with the session fixation bug?
http://www.garlic.com/~lynn/aadsm2.htm#pkikrb PKI/KRB
http://www.garlic.com/~lynn/aadsm20.htm#0 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#13 ID "theft" -- so what?
http://www.garlic.com/~lynn/aadsm21.htm#28 X.509 / PKI, PGP, and IBE Secure Email Technologies
http://www.garlic.com/~lynn/aadsm22.htm#5 long-term GPG signing key
http://www.garlic.com/~lynn/2000.html#39 "Trusted" CA - Oxymoron?
http://www.garlic.com/~lynn/2001c.html#45 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001g.html#14 Public key newbie question
http://www.garlic.com/~lynn/2002i.html#67 Does Diffie-Hellman schema belong to Public Key schema family?
http://www.garlic.com/~lynn/2002m.html#16 A new e-commerce security proposal
http://www.garlic.com/~lynn/2003b.html#30 Public key encryption
http://www.garlic.com/~lynn/2003b.html#64 Storing digital IDs on token for use with Outlook
http://www.garlic.com/~lynn/2003f.html#35 Public Encryption Key
http://www.garlic.com/~lynn/2003h.html#55 PKINIT
http://www.garlic.com/~lynn/2003j.html#53 public key confusion
http://www.garlic.com/~lynn/2004f.html#8 racf
http://www.garlic.com/~lynn/2004h.html#47 very basic quextions: public key encryption
http://www.garlic.com/~lynn/2004p.html#60 Single User: Password or Certificate
http://www.garlic.com/~lynn/2005e.html#22 PKI: the end
http://www.garlic.com/~lynn/2005e.html#26 PKI: the end
http://www.garlic.com/~lynn/2005e.html#45 TLS-certificates and interoperability-issues sendmail/Exchange/postfix
http://www.garlic.com/~lynn/2005f.html#20 Some questions on smart cards (Software licensing using smart cards)
http://www.garlic.com/~lynn/2005g.html#0 What is a Certificate?
http://www.garlic.com/~lynn/2005i.html#36 Improving Authentication on the Internet
http://www.garlic.com/~lynn/2005j.html#0 private key encryption - doubts
http://www.garlic.com/~lynn/2005l.html#7 Signing and bundling data using certificates
http://www.garlic.com/~lynn/2005l.html#25 PKI Crypto and VSAM RLS
http://www.garlic.com/~lynn/2005l.html#29 Importing CA certificate to smartcard
http://www.garlic.com/~lynn/2005l.html#35 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005m.html#1 Creating certs for others (without their private keys)
http://www.garlic.com/~lynn/2005m.html#15 Course 2821; how this will help for CISSP exam ?
http://www.garlic.com/~lynn/2005m.html#18 S/MIME Certificates from External CA
http://www.garlic.com/~lynn/2005m.html#27 how do i encrypt outgoing email
http://www.garlic.com/~lynn/2005m.html#37 public key authentication
http://www.garlic.com/~lynn/2005m.html#45 Digital ID
http://www.garlic.com/~lynn/2005n.html#33 X509 digital certificate for offline solution
http://www.garlic.com/~lynn/2005n.html#39 Uploading to Asimov
http://www.garlic.com/~lynn/2005o.html#6 X509 digital certificate for offline solution
http://www.garlic.com/~lynn/2005o.html#9 Need a HOW TO create a client certificate for partner access
http://www.garlic.com/~lynn/2005o.html#17 Smart Cards?
http://www.garlic.com/~lynn/2005o.html#42 Catch22. If you cannot legally be forced to sign a document etc - Tax Declaration etc etc etc
http://www.garlic.com/~lynn/2005p.html#32 PKI Certificate question
http://www.garlic.com/~lynn/2005p.html#33 Digital Singatures question
http://www.garlic.com/~lynn/2005q.html#13 IPSEC with non-domain Server
http://www.garlic.com/~lynn/2005q.html#23 Logon with Digital Siganture (PKI/OCES - or what else they're called)
http://www.garlic.com/~lynn/2005r.html#54 NEW USA FFIES Guidance
http://www.garlic.com/~lynn/2005s.html#42 feasibility of certificate based login (PKI) w/o real smart card
http://www.garlic.com/~lynn/2005t.html#32 RSA SecurID product
http://www.garlic.com/~lynn/2005t.html#52 PGP Lame question
http://www.garlic.com/~lynn/2005v.html#5 famous literature
http://www.garlic.com/~lynn/2006d.html#33 When *not* to sign an e-mail message?
http://www.garlic.com/~lynn/2006d.html#41 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006f.html#29 X.509 and ssh
http://www.garlic.com/~lynn/2006t.html#40 Encryption and authentication
http://www.garlic.com/~lynn/2007k.html#79 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007l.html#0 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2008i.html#80 Certificate Purpose
http://www.garlic.com/~lynn/2008i.html#90 Certificate Purpose
http://www.garlic.com/~lynn/2008k.html#38 Calling Out
http://www.garlic.com/~lynn/2008p.html#58 Do soft certificates provide two factor authentication?
http://www.garlic.com/~lynn/2008p.html#79 PIN entry on digital signatures + extra token
--
40+yrs virtualization experience (since Jan68), online at home since Mar70 |
|
| |
|
| Back to top |
Nico Kadel-Garcia
Guest
|
| Posted: Sun Nov 16, 2008 3:18 pm Post subject: Re: GPG |
|
|
Anne & Lynn Wheeler wrote:
| Quote: | Nico Kadel-Garcia <nkadel@gmail.com> writes:
I don't see them describing the PGP/GPG public/private key technology as a
business practice. Really, I see a lot of mentions about using them *in*
business practices, but I've never seen the technology itself referred to as
one. Or am I missing something in your references? Seriously, you're the only
one I've seen do so, and even your own references above to your own
conversations don't seem to do this.
re:
http://www.garlic.com/~lynn/2008q.html#0 GPG
http://www.garlic.com/~lynn/2008q.html#1 GPG
a few business process references ....
http://www.garlic.com/~lynn/98.html#41 AADS, X9.59, & privacy
|
And you're doing the *same thing*. For example, in your first reference, you
yourself say:
| Quote: | to incorporate (public key digital signature) strong authentication into
existing business infrastructure. |
And you make similar, reasonable sorts of statements in all the others.
(That's a lot of references! Your time to do that is appreciated.) That's
fine, key handling and authentication are certainly parts of business
processes. But that does not make public key encryption, *in and of itself*, a
business process such as you said in your earlier post quoted below.
| Quote: | "public key" is a business process is where one of the key pair is
designated "public" and is freely published. the other key is kept |
private & confidential and never divulged.
It's like the difference between a car jack, and the bill for having your car
fixed. The technology is not, itself, a business process. This has just become
even more important to keep in mind, too, because the recent Bilski decision
just made business method patents invalid! (Check it out over on groklaw.net,
it's wonderful fun to follow.)
And key handling is, in many cases, a personal practice due to its use for
personal correspondence. In fact, there are good reasons to use it for all
correspondence as a default, but various factors have prevented it from
becoming widespread in mail clients. |
|
| |
|
| Back to top |
Anne & Lynn Wheeler
Guest
|
| Posted: Sun Nov 16, 2008 8:51 pm Post subject: Re: GPG |
|
|
Nico Kadel-Garcia <nkadel@gmail.com> writes:
| Quote: | And key handling is, in many cases, a personal practice due to its use
for personal correspondence. In fact, there are good reasons to use it
for all correspondence as a default, but various factors have
prevented it from becoming widespread in mail clients.
|
http://www.garlic.com/~lynn/2008q.html#0 GPG
http://www.garlic.com/~lynn/2008q.html#1 GPG
http://www.garlic.com/~lynn/2008q.html#2 GPG
key handling of a private key kept "confidential and never divulged" is
more than "personal practice" ... if other parties are to "rely" on the
convention ... it has to be an accepted business process. if it is
personal preference on how the key pairs are treated/managed ... then it
is still asymmetric cryptography technology. it is when others come to
depend on ("relying parties") how the key pairs are treated/managed,
that it becomes a turst issue and business processes.
if no other entities are affected by how an individual deals with their
private key ... then it is "personal pracice" ... if others are to
depend on how an individual deals with their private key ... then it
becomes a business process.
some number of countries have even passed laws regarding the business
process of "digital signatures" ... which includes a bunch
of related stuff percolating down thru the whole public/private key
business process infrastructure.
we were called in to help word-smith the cal. state electronic signature
legislation (and later federal) ... and as a result had to go thru a
bunch of the handling from the standpoint of relied on business
processes ... numerous past posts mentioning electronic signature
(business process) http://www.garlic.com/~lynn/subpubkey.html#signature
similarly, i've mentioned that we were called to consulte with a small
client/server startup that had invented this technology called SSL and
wanted to use it for payment transactions on their server. as part of
that we had to do a lot of work related to apply a technology to
business processes that world could trust. for people to "trust" both
"digital signatures" and "SSL" there is a trust chain starts with the
business process (more than "personal practice") of keeping the private
key (of a public/private key pair) confidential and never divulged. If
it is purely "personal practice" ... then the abilitiy of whether or not
others can place any trust in the whole infrastructure unravels.
for other drift, misc. past posts mentioning issues with trusting the
digital certificates and certification authorities related to SSL
(public/private key infrastructures)
http://www.garlic.com/~lynn/subpubkey.html#sslcert
and even catch22/gotcha related to SSL domain name digital certificates
http://www.garlic.com/~lynn/subpubkey.html#catch22
have looked at a whole lot of issues for market inhibitors to
public/private key. part of it is the cost/convenience vis-a-vis
incremental security/privacy. since a large part of lack of security
involves compromised PC ... just having a software-based public/private
key operation doesn't provide a whole lot (witness that a majority of
spam in the world originates from compromised PCs ... that have been
organized in botnets).
a decade ago there were efforts to introduce hardware tokens (supporting
public/private key business processes) into the personal computer
environment as part of countermeasure to compromised PCs. some of that
was with respect to the EU FINREAD standard ... misc. past posts
http://www.garlic.com/~lynn/subintegrity.html#finread
however, there were some poor choses made as part of some of those
introductions ... which culminated in the efforts being aborted and the
rapidly spreading opinion that hardware tokens were not practical in the
personal computing environment. some recent posts discussing various of
the issues (as part of discussions of recent Kansas City Fed paper):
http://www.garlic.com/~lynn/2008p.html#7 Dealing with the neew MA ID protection law
http://www.garlic.com/~lynn/2008p.html#10 Strings story
http://www.garlic.com/~lynn/2008p.html#11 Can Smart Cards Reduce Payments Fraud and Identity Theft?
http://www.garlic.com/~lynn/2008p.html#13 "Telecommunications" from '85
http://www.garlic.com/~lynn/2008p.html#14 Can Smart Cards Reduce Payments Fraud and Identity Theft?
http://www.garlic.com/~lynn/2008p.html#15 Can Smart Cards Reduce Payments Fraud and Identity Theft?
http://www.garlic.com/~lynn/2008p.html#17 Open Source, Unbundling, and Future System
http://www.garlic.com/~lynn/2008p.html#18 Can Smart Cards Reduce Payments Fraud and Identity Theft?
http://www.garlic.com/~lynn/2008p.html#19 Can Smart Cards Reduce Payments Fraud and Identity Theft?
http://www.garlic.com/~lynn/2008p.html#20 Donald Knuth stops paying for errata
http://www.garlic.com/~lynn/2008p.html#21 Would you say high tech authentication gizmo's are a waste of time/money/effort?
http://www.garlic.com/~lynn/2008p.html#22 Can Smart Cards Reduce Payments Fraud and Identity Theft?
http://www.garlic.com/~lynn/2008p.html#23 Your views on the increase in phishing crimes such as the recent problem French president Sarkozy faces
http://www.garlic.com/~lynn/2008p.html#27 Father Of Financial Dataprocessing
http://www.garlic.com/~lynn/2008p.html#28 Can Smart Cards Reduce Payments Fraud and Identity Theft?
http://www.garlic.com/~lynn/2008p.html#31 FC5 Special Workshop CFP: Emerging trends in Online Banking and Electronic Payments
http://www.garlic.com/~lynn/2008p.html#32 Can Smart Cards Reduce Payments Fraud and Identity Theft?
http://www.garlic.com/~lynn/2008p.html#34 How can I tell if a keylogger got added to my PC while I was in Beijing?
http://www.garlic.com/~lynn/2008p.html#38 How do group members think the US payments business will evolve over the next 3 years?
http://www.garlic.com/~lynn/2008p.html#44 Can Smart Cards Reduce Payments Fraud and Identity Theft?
http://www.garlic.com/~lynn/2008p.html#48 How much knowledge should a software architect have regarding software security?
http://www.garlic.com/~lynn/2008p.html#49 Can Smart Cards Reduce Payments Fruad and Identity Theft?
http://www.garlic.com/~lynn/2008p.html#54 Barbless
http://www.garlic.com/~lynn/2008p.html#55 Can Smart Cards Reduce Payments Fraud and Identity Theft?
http://www.garlic.com/~lynn/2008p.html#58 Do soft certificates provide two factor authentication?
http://www.garlic.com/~lynn/2008p.html#59 Can Smart Cards Reduce Payments Fraud and Identity Theft?
http://www.garlic.com/~lynn/2008p.html#65 Barbless
http://www.garlic.com/~lynn/2008p.html#67 Web Security hasn't moved since 1995
http://www.garlic.com/~lynn/2008p.html#69 ATM PIN through phone or Internet. Is it secure? Is it allowed by PCI-DSS?, Visa, MC, etc.?
http://www.garlic.com/~lynn/2008p.html#72 Alternative credit card network
http://www.garlic.com/~lynn/2008p.html#74 2008 Data Breaches: 30 Million and Counting
http://www.garlic.com/~lynn/2008p.html#75 Alternative credit card network
http://www.garlic.com/~lynn/2008p.html#76 Multi-Factor Authentication - Moving Beyond Passwords for Security of Online Transactions
http://www.garlic.com/~lynn/2008p.html#79 PIN entry on digital signatures + extra token
http://www.garlic.com/~lynn/2008p.html#83 Residual Risk Methodology for Single Factor Authentication
--
40+yrs virtualization experience (since Jan68), online at home since Mar70 |
|
| |
|
| Back to top |
Nico Kadel-Garcia
Guest
|
| Posted: Sun Nov 16, 2008 10:22 pm Post subject: Re: GPG |
|
|
Anne & Lynn Wheeler wrote:
| Quote: | Nico Kadel-Garcia <nkadel@gmail.com> writes:
And key handling is, in many cases, a personal practice due to its use
for personal correspondence. In fact, there are good reasons to use it
for all correspondence as a default, but various factors have
prevented it from becoming widespread in mail clients.
http://www.garlic.com/~lynn/2008q.html#0 GPG
http://www.garlic.com/~lynn/2008q.html#1 GPG
http://www.garlic.com/~lynn/2008q.html#2 GPG
key handling of a private key kept "confidential and never divulged" is
more than "personal practice" ... if other parties are to "rely" on the
convention ... it has to be an accepted business process. if it is
personal preference on how the key pairs are treated/managed ... then it
is still asymmetric cryptography technology. it is when others come to
depend on ("relying parties") how the key pairs are treated/managed,
that it becomes a turst issue and business processes.
|
Public key encryption is not key handling. Key handling *is* a good business
practice, but that's an important distinction from the technology itself.
That's a policy matter that public key encryption, itself, does not address.
*THAT* part is a business practice, yes.
| Quote: | if no other entities are affected by how an individual deals with their
private key ... then it is "personal pracice" ... if others are to
depend on how an individual deals with their private key ... then it
becomes a business process.
|
But it's still public key encryption. Please don't call the technology,
itself, a business practice. That can confuse people who read it: you remain
the *only one* I've ever seen who calls public key encryption, itself, a
business practice, and your own citations of your own writing seem to agree
with my point that key handling is an important practice, but do not refer to
the technology itself as a business practice. I've no idea why you did so:
please stop.
I do sympathize with your business experiences: I've been working with SSH and
PGP and SSL for.... well, since you had to download PGP from outside the US to
work with, and I tried to offer RSA money to be able to use their patented
work inside PGP for my company and keep our noses clean. And I remember the
Skipjack fun and games, and writing about them, and I'm doing some lobbying
and a lot of explaining about Palladium (Microsoft's "let's keep all your
important private keys for you, moo-ha-ha" project, renamed "Trusted
Computing). If you want to see bad, bad, bad key-handling, look at what that
technology proposes. |
|
| |
|
| Back to top |
Anne & Lynn Wheeler
Guest
|
| Posted: Sun Nov 16, 2008 11:36 pm Post subject: Re: GPG |
|
|
Nico Kadel-Garcia <nkadel@gmail.com> writes:
| Quote: | But it's still public key encryption. Please don't call the
technology, itself, a business practice. That can confuse people who
read it: you remain the *only one* I've ever seen who calls public key
encryption, itself, a business practice, and your own citations of
your own writing seem to agree with my point that key handling is an
important practice, but do not refer to the technology itself as a
business practice. I've no idea why you did so: please stop.
|
as per the original post
http://www.garlic.com/~lynn/2008q.html#0 GPG
the technology is asymmetric cryptography with a pair of keys ... what
one key encode, the other key decodes.
the business process is publishing one key of the key-pair ... and
keeping the other key of the key-pair confidential and never divulging
it. by definition ... the attributes "public key" and "private key"
refer to the business processes of key handling ... aka the very
attributes "public" and "private" refer to the key handling business
process ... not to the asymmetric cryptography technology.
if you use the term "public" ... by defintion, you are not referring to
the cryptography technology ... you are referring to the business
process key handling.
the technology is asymmetric cryptography technology that deals with
encryption/decryption.
using the terms "public" and/or "private" ... moves passed talking about
the asymmetric cryptography technology ... and are referring to key
handling business processes.
by definition the terms "public" and/or "private" refers to the business
process of handling the keys .... and has moved passed the basic
asymmetric cryptography technology.
asymmetric cryptography refers to the technologies of cryptography,
encryption, etc.
public key, private key, etc ... refers to the key handling business
processes.
as in the reference to cognitive dissonance and/or semantic confusion
with regard to the term "digital signature" .. recent post:
http://www.garlic.com/~lynn/2008p.html#79 PIN entry on digital signature + extra token
.... there may be similar cognitive dissonance and/or semantic confusion
with the term "public key cryptography".
"public key" refers to the key handling business processes.
asymmetric cryptography refers to the cryptography technology.
another similar cognitive dissonance and/or semantic confusion occurs
when CA is used for "certificate authority" ... when in fact, CA refers
to "certification authority" ... and a "certification authority" issues
certificates which are representation of some certification business
process.
I've gotten (similar) jabs for continuing to be about the only person
that continues to insist on the semantic correct "certification
authority" ... as opposed to the more popular "certificate authority".
The popular use tends to obscure the fact that certificates are
representations of some certification business process ... possibly
allowing certificates to actually be meaningless and fail to represent
anything.
also:
http://www.garlic.com/~lynn/2008q.html#1 GPG
http://www.garlic.com/~lynn/2008q.html#2 GPG
http://www.garlic.com/~lynn/2008q.html#3 GPG
--
40+yrs virtualization experience (since Jan68), online at home since Mar70 |
|
| |
|
| Back to top |
Anne & Lynn Wheeler
Guest
|
| Posted: Mon Nov 17, 2008 12:04 am Post subject: Re: GPG |
|
|
Nico Kadel-Garcia <nkadel@gmail.com> writes:
| Quote: | But it's still public key encryption. Please don't call the
technology, itself, a business practice. That can confuse people who
read it: you remain the *only one* I've ever seen who calls public key
encryption, itself, a business practice, and your own citations of
your own writing seem to agree with my point that key handling is an
important practice, but do not refer to the technology itself as a
business practice. I've no idea why you did so: please stop.
|
as per the original post:
http://www.garlic.com/~lynn/2008q.html#0 GPG
from above:
"asymmetric cryptography" is technology where there are a pair of keys
.... what one key encodes, the other key decodes. this is in contrast to
symmetric key technology where the same key is used to both encode &
decode.
"public key" is a business process where one of the key pair is
designated "public" and is freely published. the other key is kept
private & confidential and never divulged.
.... snip ...
I referred to "asymmetric cryptography" as technology ... and i referred
to "public key" as (key handling) business processes.
I didn't use the term "public key encryption" (except when quoting some
other use) ... as means of clearly differentiating the "asymmetric
cryptography" technology and the "public key" (key handling) business
processes.
Part of this is trying to avoid the cognitive dissonance &/or semantic
confusion ... i clearly differentiated "asymmetric cryptography"
technology and "public key" (key handling) business processes.
also:
http://www.garlic.com/~lynn/2008q.html#1 GPG
http://www.garlic.com/~lynn/2008q.html#2 GPG
http://www.garlic.com/~lynn/2008q.html#3 GPG
http://www.garlic.com/~lynn/2008q.html#4 GPG
--
40+yrs virtualization experience (since Jan68), online at home since Mar70 |
|
| |
|
| Back to top |
Anne & Lynn Wheeler
Guest
|
| Posted: Mon Nov 17, 2008 12:26 am Post subject: Re: GPG |
|
|
Nico Kadel-Garcia <nkadel@gmail.com> writes:
| Quote: | But it's still public key encryption. Please don't call the
technology, itself, a business practice. That can confuse people who
read it: you remain the *only one* I've ever seen who calls public key
encryption, itself, a business practice, and your own citations of
your own writing seem to agree with my point that key handling is an
important practice, but do not refer to the technology itself as a
business practice. I've no idea why you did so: please stop.
|
re:
http://www.garlic.com/~lynn/2008q.html#0 GPG
http://www.garlic.com/~lynn/2008q.html#1 GPG
http://www.garlic.com/~lynn/2008q.html#2 GPG
http://www.garlic.com/~lynn/2008q.html#3 GPG
http://www.garlic.com/~lynn/2008q.html#4 GPG
http://www.garlic.com/~lynn/2008q.html#5 GPG
I would assume, for somebody using the term "public key encryption"
.... which i try to avoid (to minimize the semantic confusion), ... they
would *semantically* be referring to both "asymmetric key encryption"
technology as well as "public(/private) key" handling business processes
.... since the use of the word "encryption" implies the technology and
the word "public" imples the key handling business processes.
--
40+yrs virtualization experience (since Jan68), online at home since Mar70 |
|
| |
|
| Back to top |
Anne & Lynn Wheeler
Guest
|
| Posted: Mon Nov 17, 2008 1:26 am Post subject: Re: GPG |
|
|
Nico Kadel-Garcia <nkadel@gmail.com> writes:
| Quote: | But it's still public key encryption. Please don't call the
technology, itself, a business practice. That can confuse people who
read it: you remain the *only one* I've ever seen who calls public key
encryption, itself, a business practice, and your own citations of
your own writing seem to agree with my point that key handling is an
important practice, but do not refer to the technology itself as a
business practice. I've no idea why you did so: please stop.
|
oh, and as mentioned in the original post
http://www.garlic.com/~lynn/2008q.html#0 GPG
the use of the term "asymmetric" was somewhat chosen to differentiate
from "symmetric key encryption".
there are times when "symmetric key encryption" is referred to as
"secret key encryption" ... referring to both the key handling business
process (keeping the key secret) as well as the symmetric key encryption
technology ... somewhat analogous when "public key encryption" is used
to refer to both the key handling business process and the asymmetric
key encryption.
in the case of the public key handling business process ... "public"
refers to the business process handling of one of the key-pair being
made public. the other key (of the key-pair) is kept secret ... but is
called "private" key ... to both differentiate it from the key handling
in symmetric key encryption ... and to have a semantic connotation that
is more the opposite of "public".
in symmetric key encryption ... for "communication", the "secret" key
becomes a "shared-secret" ... since both ends of the communication have
to share the same "secret" key.
in most asymmetric key encryption implementations involving
"communication" ... like SSL ... a "shared-secret" symmetric key is
normally used (for efficiency purposes) .... but it is generated at
random. it becomes a random/temporary session key ... that is used to
encode the communication ... and then that session/secret key is encoded
with the recipient's "public key" (and the both the encoded
communication and the encoded secret key are transmitted together).
the recipient then decodes the secret key (using their private key) and
then uses the temporary/session (shared-secret) key to decode the actual
message.
the business process characteristic of not having to "share" a private
key ... is also an enabler for the "digital signature" business process.
the connotation of the "public key" handling business process ... there
is the implication of being shared ... while the connotation of the
"private key" business processes carries the implication of never being
shared ... which further differentiates it from a "shared-secret"
business process key handling that is found in various uses of symmetric
key encryption (futher differentiating symmetric key encryption and
asymmetric key encryption technologies).
"shared-secret" handling of symmetric key encryption carries some of the
same dependencies involved with "shared-secret" "something you know"
authentication. the "never shared" implication of the "private key"
handling business process has also been leveraged for improved
authentication as part of "digital signature" authentication business
process.
other past posts mentiong shared-secret
http://www.garlic.com/~lynn/subintegrity.html#secrets
past posts mentioning 3-factor authentication paradigm
http://www.garlic.com/~lynn/subintegrity.html#3factor
re:
http://www.garlic.com/~lynn/2008q.html#1 GPG
http://www.garlic.com/~lynn/2008q.html#2 GPG
http://www.garlic.com/~lynn/2008q.html#3 GPG
http://www.garlic.com/~lynn/2008q.html#4 GPG
http://www.garlic.com/~lynn/2008q.html#5 GPG
http://www.garlic.com/~lynn/2008q.html#6 GPG
--
40+yrs virtualization experience (since Jan68), online at home since Mar70 |
|
| |
|
| Back to top |
Tim Greer
Guest
|
| Posted: Mon Nov 17, 2008 1:44 am Post subject: Re: GPG |
|
|
Anne & Lynn Wheeler wrote:
| Quote: | a few business process references ....
|
....
I don't understand, the poster asked who refers to it this way, besides
you. You then went on to post 100 or so links to your own site where
you yourself referred to it as such?
PS: I really don't care about the discussion of what it's referred to as
(I don't care to get involved in that), but I just thought that was a
strange response?
--
Tim Greer, CEO/Founder/CTO, BurlyHost.com, Inc.
Shared Hosting, Reseller Hosting, Dedicated & Semi-Dedicated servers
and Custom Hosting. 24/7 support, 30 day guarantee, secure servers.
Industry's most experienced staff! -- Web Hosting With Muscle! |
|
| |
|
| Back to top |
Anne & Lynn Wheeler
Guest
|
| Posted: Mon Nov 17, 2008 3:41 am Post subject: Re: GPG |
|
|
Tim Greer <tim@burlyhost.com> writes:
| Quote: | I don't understand, the poster asked who refers to it this way, besides
you. You then went on to post 100 or so links to your own site where
you yourself referred to it as such?
|
semantic confusion ... one post asked the question "who calls it that"
.... and i answered "I do all the time" ... reference exchange archived
here:
http://www.garlic.com/~lynn/2008q.html#1 GPG
the response to the above stated "even you own references" ... so I
replied with some of my references that did ... reference exchange
archived here:
http://www.garlic.com/~lynn/2008q.html#2 GPG
potentially you are confusing the context of two different posts?
--
40+yrs virtualization experience (since Jan68), online at home since Mar70 |
|
| |
|
| Back to top |
Tim Greer
Guest
|
| Posted: Mon Nov 17, 2008 3:56 am Post subject: Re: GPG |
|
|
Anne & Lynn Wheeler wrote:
| Quote: | Tim Greer <tim@burlyhost.com> writes:
I don't understand, the poster asked who refers to it this way,
besides
you. You then went on to post 100 or so links to your own site where
you yourself referred to it as such?
semantic confusion ... one post asked the question "who calls it that"
... and i answered "I do all the time" ... reference exchange archived
here:
http://www.garlic.com/~lynn/2008q.html#1 GPG
the response to the above stated "even you own references" ... so I
replied with some of my references that did ... reference exchange
archived here:
http://www.garlic.com/~lynn/2008q.html#2 GPG
potentially you are confusing the context of two different posts?
|
This is what I read the poster say:
"I don't see them describing the PGP/GPG public/private key technology
as a business practice. Really, I see a lot of mentions about using
them *in* business practices, but I've never seen the technology itself
referred to as one. Or am I missing something in your references?
Seriously, you're the only one I've seen do so, and even your own
references above to your own conversations don't seem to do this."
So, perhaps the wording was confusing? I really don't mind anyway, just
thought it was odd.
--
Tim Greer, CEO/Founder/CTO, BurlyHost.com, Inc.
Shared Hosting, Reseller Hosting, Dedicated & Semi-Dedicated servers
and Custom Hosting. 24/7 support, 30 day guarantee, secure servers.
Industry's most experienced staff! -- Web Hosting With Muscle! |
|
| |
|
| Back to top |
Anne & Lynn Wheeler
Guest
|
| Posted: Mon Nov 17, 2008 5:10 am Post subject: Re: GPG |
|
|
Tim Greer <tim@burlyhost.com> writes:
| Quote: | This is what I read the poster say:
"I don't see them describing the PGP/GPG public/private key technology
as a business practice. Really, I see a lot of mentions about using
them *in* business practices, but I've never seen the technology itself
referred to as one. Or am I missing something in your references?
Seriously, you're the only one I've seen do so, and even your own
references above to your own conversations don't seem to do this."
So, perhaps the wording was confusing? I really don't mind anyway, just
thought it was odd.
|
re:
http://www.garlic.com/~lynn/2008q.html#8 GPG
this is a different "semantic confusion" issue ... from a post that made
an assertion that i had used the term "public key encryption" in my
original post ... which clearly isn't correct.
as referenced in these posts:
http://www.garlic.com/~lynn/2008q.html#4 GPG
http://www.garlic.com/~lynn/2008q.html#5 GPG
http://www.garlic.com/~lynn/2008q.html#6 GPG
http://www.garlic.com/~lynn/2008q.html#7 GPG
there was assertion that in my original post (also archived here)
http://www.garlic.com/~lynn/2008q.html#0 GPG
that I made reference to "public key encryption" as a business process.
but as repeatedly quoted (and can be clearly seen in the original post)
and in the above references ... i clearly differentiated between
"asymmetric cryptography" as a technology and "public key" as a business
process (involving the key handling business process).
in the original post, i never used the term "public key encryption"
.... although in later explanations ... i contend that "public key
encryption" would tend to imply combined reference to both the
(asymmetric) encryption technology and the (public) key handling
business process.
the analogy is the use of "symmetric key encryption" (referenced in the
original post) as being technology (and the use of "asymmetric" to
differentiate from "symmetric").
if the term "secret key encryption" were to be used, it would tend to
combine references to both the "symmetric key encryption" technology and
the "secret key" key handling business process.
--
40+yrs virtualization experience (since Jan68), online at home since Mar70 |
|
| |
|
| Back to top |
|
