Corporate public key?

[Mark H. Wood]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 9 Jul 2003, Adrian 'Dagurashibanipal' von Bidder wrote:
> A really interesting thread!
Yes!

[snip]
> As Neil said: many people will sign the corporate key. This will probably look
> ugly on the keyservers, but it doesn't really matter. And I guess the
> 'official' copy as distributed by the company would only include a few
> signatures (CAs, a few key employees perhaps)

I think the bank is going to need its own keyserver anyway.  People need
quick reliable access to those revocation signatures, you know.

And this leads to a problem I see with using GnuPG, which is a general
problem but more acute when using the product for business:  key updates.
I know I can refetch a key whenever I feel the need, but I don't recall
seeing any way to automagically check for revocations.  I would probably
refresh a key manually whenever I'm about to communicate something
critical, but in financial transactions that means "every time".

SSL has the same problem, but it also has a developing solution:  OCSP.
Does GnuPG have something like that and I just missed it?

[snip]
> My biggest beef with gpg (and pk crypto in general): what does the signature
> mean? Signature on an cusomers key means 'this persona has been identified by
> the company'. Signature on an employees key means 'identified *and also* this
> person is an employee'. Signatures between role keys are more like 'this key
> belongs to the company and should be used for this and that purpose'.
> Solution? (1) use role keys. A master key of the company used only to certify
> other role keys. A key only used to sign employees keys. A key used to sign
> customers' keys. Document these roles. (2) use of policy URLs (this is what I
> do - every signature by my key has a policy URL explaining what the signature
> means). In theory, policy URLs alone could be enough, but in practice, many
> people don't see the policy URL when they see the signature.

As you say, policy takes care of this.  The bank's signatures mean what
the bank says they mean.  You get a copy of the then-current policy when
you sign up for the service, just as with any other financial service.
You can follow the policy URLs anytime you want to check for changes.

[snip]
> To conclude: the technical problems can easily be solved - but your nice
> solution won't gain acceptance by the majority of the customers. And I guess
> for .1% of the customers, ING won't deploy such a solution. Yes, I think this
> is sad and should be changed, too, and I wish you good luck.

It's the standard chicken/egg problem faced by any new service.  It's
waiting for someone who smells enough money to stick his neck out by
providing an attractively packaged solution and waiting for customers to
show up.  Once a few customers start telling their friends, "oh, I use
this free encryption gadget to do my banking securely by mail, it's much
safer than the phone," word will spread and the service will take off.
And if it ramps up to just 10% of the customer base, it's probably well
worth the startup cost.

And once two or three "Internet banks" see significant use, the
brick&mortar banks with an Internet presence will *have* to follow suit,
or they'll be bleeding accounts even faster than before.

Moving up a layer, once we get the financial services industry sorted out,
maybe I can convince the medical and pharmacy professions to adopt secure
electronic communication instead of playing telephone tag or passing
handscribbled notes.

- -- 
Mark H. Wood, Lead System Programmer   mwood@IUPUI.Edu
MS Windows *is* user-friendly, but only for certain values of "user".
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: pgpenvelope 2.10.2 - http://pgpenvelope.sourceforge.net/

iD8DBQE/DHsbs/NR4JuTKG8RAnAtAJ9+Zin5WQxWlFwyob+V/s5ND9GpcwCeOSmh
6ZBPXJuZ+KeV7Bm1aOwqtjU=
=7vDM
-----END PGP SIGNATURE-----