Corporate use of gnupg

[Texaskilt]

Apologies if this has already been asked.  Honestly, I did my homework and looked in the archives!

I am wanting to setup up users to use GnuPG for encrypting email, mainly for internal e-mail.

Unfortunately, the "powers-that-be" want everyone that encrypts an email to also encrypt it to the "corporate secret key".  Their reasoning is that if a person leaves, they want to have access to the old emails in case there is a "business critical" email in there.

Is there a way to "force" users to encrypt to a corporate key, in addition to the receipient's key?

Thanks,

TK

[David Shaw]

On Wed, Feb 06, 2008 at 11:35:14AM -0800, Texaskilt wrote:

>
> Apologies if this has already been asked.  Honestly, I did my homework and
> looked in the archives!
>
> I am wanting to setup up users to use GnuPG for encrypting email, mainly for
> internal e-mail.
>
> Unfortunately, the "powers-that-be" want everyone that encrypts an email to
> also encrypt it to the "corporate secret key".  Their reasoning is that if a
> person leaves, they want to have access to the old emails in case there is a
> "business critical" email in there.

This is essentially the rationale behind the "ADK" (additional
decryption key) feature of PGP.

> Is there a way to "force" users to encrypt to a corporate key, in addition
> to the receipient's key?

It depends on how strong the term "force" is.  Even in PGP, the ADK
system can be circumvented if the person tries hard enough.

If you trust your employees to not hack you, then you can just stick a
"encrypt-to (the keyid)" in everyone's gpg.conf file and give everyone
a copy of the corporate public key.

Note that this isn't safe because of the crypto math.  It's "safe"
because you can fire people that don't do it ;)

David

_______________________________________________
Gnupg-users mailing list
Gnupg-users@...
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[gnupg]

And what do they want to do with the recieved emails? The only possibility I
see is to put everyone's private keys and passowrds into a safe - then you
can decrypt sent and received mail later.

> Apologies if this has already been asked.  Honestly, I did my homework and
> looked in the archives!
>
> I am wanting to setup up users to use GnuPG for encrypting email, mainly
> for internal e-mail.
>
> Unfortunately, the "powers-that-be" want everyone that encrypts an email to
> also encrypt it to the "corporate secret key".  Their reasoning is that if
> a person leaves, they want to have access to the old emails in case there
> is a "business critical" email in there.
>
> Is there a way to "force" users to encrypt to a corporate key, in addition
> to the receipient's key?
>
> Thanks,
>
> TK

_______________________________________________
Gnupg-users mailing list
Gnupg-users@...
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[Robert J. Hansen-3]

Quoting gnupg@...:
> And what do they want to do with the recieved emails? The only possibility I
> see is to put everyone's private keys and passowrds into a safe - then you
> can decrypt sent and received mail later.

Same problem exists with PGP's ADK feature, which should really be  
named an ARR, for Additional Recipient Request.  While ADK usage can  
be enforced within the ADK-using group (mostly: there are some  
caveats), emails from outside the group going in to the group are  
under no such restrictions.


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.


_______________________________________________
Gnupg-users mailing list
Gnupg-users@...
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[Max Allan]

You're cracking the wrong nut. We've concluded : You can't enforce everyone to ensure their email is decryptable.
So the solution is to make sure they don't get encrypted email.

Use GPG at a gateway level and deny any internal mail that can't be decrypted. This is the way PGPU can work. All internal users'
keys are stored on the PGPU server, users don't need to know their passwords or anything about their keys. The server decrypts or
encrypts as required. All traffic on your local network is in the clear.

We used to have a TFS server doing something similar using GPG. (you need to buy TFS, I don't know if there is a free solution out
there)

Of course if your encryption policy is designed to prevent colleagues reading each others email, then this doesn't work. But if
people can access each others mailboxes, you've got a different problem (with file permissions)!

If it's too many people with root/administrator account that can read everyone's mail causing fear, then move the mail server to a
new, more secure box and only one person has the password (probably you should have sudo or similar setup so you can do admin
tasks).

Max

> -----Original Message-----
> From: gnupg-users-bounces@...
> [mailto:gnupg-users-bounces@...] On Behalf Of Robert J. Hansen
> Sent: 14 February 2008 05:24
> To: gnupg-users@...
> Subject: Re: Corporate use of gnupg
>
> Quoting gnupg@...:
> > And what do they want to do with the recieved emails? The only
> > possibility I see is to put everyone's private keys and
> passowrds into
> > a safe - then you can decrypt sent and received mail later.
>
> Same problem exists with PGP's ADK feature, which should
> really be named an ARR, for Additional Recipient Request.
> While ADK usage can be enforced within the ADK-using group
> (mostly: there are some caveats), emails from outside the
> group going in to the group are under no such restrictions.
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users@...
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>

_______________________________________________
Gnupg-users mailing list
Gnupg-users@...
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[Texaskilt]

I guess what we are wanting is for every mail user to have their own public/private key.  This way they can encrypt their own email on the corporate system.

In addition, every email would also be encrypted using the "corporate key" that would be in the hands of a select few (supposedly).

For example, the sales force can send encrypted mail to each other, but when a salesperson leaves the company, the Email Admin can retreive and decrypt the email so that the salesperson's replacement can pick up their accounts without too much disruption.

Looks like this is ADK.  Is there any way to do this on gpg?

Thanks,

TK

David Shaw wrote:

On Wed, Feb 06, 2008 at 11:35:14AM -0800, Texaskilt wrote:
>
> Apologies if this has already been asked.  Honestly, I did my homework and
> looked in the archives!
>
> I am wanting to setup up users to use GnuPG for encrypting email, mainly for
> internal e-mail.
>
> Unfortunately, the "powers-that-be" want everyone that encrypts an email to
> also encrypt it to the "corporate secret key".  Their reasoning is that if a
> person leaves, they want to have access to the old emails in case there is a
> "business critical" email in there.

This is essentially the rationale behind the "ADK" (additional
decryption key) feature of PGP.

> Is there a way to "force" users to encrypt to a corporate key, in addition
> to the receipient's key?

It depends on how strong the term "force" is.  Even in PGP, the ADK
system can be circumvented if the person tries hard enough.

If you trust your employees to not hack you, then you can just stick a
"encrypt-to (the keyid)" in everyone's gpg.conf file and give everyone
a copy of the corporate public key.

Note that this isn't safe because of the crypto math.  It's "safe"
because you can fire people that don't do it ;)

David

_______________________________________________
Gnupg-users mailing list
[e-mail]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[Nicholas Cole]

On Sat, Feb 16, 2008 at 3:00 AM, Texaskilt <texaskilt@...> wrote:
>
>  Looks like this is ADK.  Is there any way to do this on gpg?

GPG does not implement ADK.  I think that, historically, it seemed too
much like the kind of key escrow systems that governments have from
time to time talked about wanting, although clearly there is a
difference.

I know that ADK can be circumvented by a determined attacker, but it
strikes me as a useful feature, and I have never quite understood the
opposition to it.  It would have made encryption more palatable in
corporate settings, which surely would have been a good thing!

But I'm not an expert, and I'm probably missing a point somewhere...

_______________________________________________
Gnupg-users mailing list
Gnupg-users@...
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[David Picón Álvarez-2]

> I know that ADK can be circumvented by a determined attacker, but it
> strikes me as a useful feature, and I have never quite understood the
> opposition to it.  It would have made encryption more palatable in
> corporate settings, which surely would have been a good thing!

IMO there are two possibilities: 1) your users are forgetful but honest, 2)
your users are dishonest.

For case 1, an equivalent of ADK can be obtained with a line on GPG's
configuration file.

For case 2, you are screwed, and ADK is only going to give you a false sense
of security.

Thus ADK is either pointless or unnecessary.

--David.


_______________________________________________
Gnupg-users mailing list
Gnupg-users@...
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[Robert J. Hansen-3]

Nicholas Cole wrote:
> I know that ADK can be circumvented by a determined attacker, but it
> strikes me as a useful feature, and I have never quite understood the
> opposition to it.

PGP Corporation has a patent on ADKs.  That's the number one reason why
the other OpenPGP implementations do not support it.



_______________________________________________
Gnupg-users mailing list
Gnupg-users@...
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[David Shaw]

On Fri, Feb 15, 2008 at 07:00:12PM -0800, Texaskilt wrote:

>
> I guess what we are wanting is for every mail user to have their own
> public/private key.  This way they can encrypt their own email on the
> corporate system.
>
> In addition, every email would also be encrypted using the "corporate key"
> that would be in the hands of a select few (supposedly).
>
> For example, the sales force can send encrypted mail to each other, but when
> a salesperson leaves the company, the Email Admin can retreive and decrypt
> the email so that the salesperson's replacement can pick up their accounts
> without too much disruption.
>
> Looks like this is ADK.  Is there any way to do this on gpg?

Yes.  Put "encrypt-to (the-adk-key)" in everyone's gpg.conf.

Of course, they could turn around and take it right out again.  Unless
you have pretty tight control over the environment, ADKs or
encrypt-tos are not foolproof (and that applies to both PGP and GPG).

As I said before, note that this isn't safe because of the crypto
math.  It's "safe" because you can fire people who don't do it.

David

_______________________________________________
Gnupg-users mailing list
Gnupg-users@...
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[Hardeep Singh, Noida]

Hi All

Isnt it pretty easy to have a script on the server (try to) decrypt each
email. If the email decrypts, fine else not allow the email to go
through. That will force people to retain the option in conf file if
they want their message to reach.

Regards
Hardeep Singh
http://www.SeeingWithC.org/
 

-----Original Message-----
From: gnupg-users-bounces@...
[mailto:gnupg-users-bounces@...] On Behalf Of David Shaw
Sent: Tuesday, February 19, 2008 7:04 PM
To: gnupg-users@...
Subject: Re: Corporate use of gnupg

On Fri, Feb 15, 2008 at 07:00:12PM -0800, Texaskilt wrote:
>
> I guess what we are wanting is for every mail user to have their own
> public/private key.  This way they can encrypt their own email on the
> corporate system.
>
> In addition, every email would also be encrypted using the "corporate
key"
> that would be in the hands of a select few (supposedly).
>
> For example, the sales force can send encrypted mail to each other,
> but when a salesperson leaves the company, the Email Admin can
> retreive and decrypt the email so that the salesperson's replacement
> can pick up their accounts without too much disruption.
>
> Looks like this is ADK.  Is there any way to do this on gpg?

Yes.  Put "encrypt-to (the-adk-key)" in everyone's gpg.conf.

Of course, they could turn around and take it right out again.  Unless
you have pretty tight control over the environment, ADKs or encrypt-tos
are not foolproof (and that applies to both PGP and GPG).

As I said before, note that this isn't safe because of the crypto math.
It's "safe" because you can fire people who don't do it.

David

_______________________________________________
Gnupg-users mailing list
Gnupg-users@...
http://lists.gnupg.org/mailman/listinfo/gnupg-users

DISCLAIMER:
-----------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of
this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have
received this email in error please delete it and notify the sender immediately. Before opening any mail and
attachments please check them for viruses and defect.

-----------------------------------------------------------------------------------------------------------------------

_______________________________________________
Gnupg-users mailing list
Gnupg-users@...
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[Sven Radde-3]

David Shaw schrieb:
>> Looks like this is ADK.  Is there any way to do this on gpg?
>>    
> Yes.  Put "encrypt-to (the-adk-key)" in everyone's gpg.conf.
I thought that ADKs would work whenever encrypting to a key with that
feature enabled (i.e. also for incoming emails)? I.e. it is per-key and
not a per-user setting?
Of course, for outgoing mail you'd still need the additional encrypt-to
(unless you regularly encrypt to your own key which would have the ADK).

Furthermore, PGP has this fascinating key-splitting options that allow
you to distribute shares of a secret key to a group and define how many
shares would be necessary to conduct secret-key operations. There, you
would actually have "the math" ensuring that the boss can read the email.
This would allow advances schemes like: "Either the original owner alone
or the boss in cooperation with the company's notary public can decrypt
mail."
Or, leaving ADK-related use-cases aside, "3 of 5 board members are
required to approve an order by digitally signing it."

It seems that GnuPG has no capability to ensure decrypt-ability for
incoming encrypted data, apart from outright key-escrow.

It has been a while since I was last using the commercial PGPs, and I
could remember falsely.
So, feel free to correct me if I'm wrong (in particular, I have no idea
whether these features are still present in recent (freeware) versions).

cu, Sven

_______________________________________________
Gnupg-users mailing list
Gnupg-users@...
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[Nicholas Cole]

Just to address the original point of the thread, though, could you
not use sub-keys to achieve the most of the effect you want?

Have everyone share an encryption/decryption subkey, but have their
own separate signing keys.  The disadvantage would be that anyone in
the group (ie not just an administrator or the like) could decrypt
anyone else's email - but in many settings that might be acceptable or
even advantageous.

Best,

N

_______________________________________________
Gnupg-users mailing list
Gnupg-users@...
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[Nicholas Cole]

On Tue, Feb 19, 2008 at 1:23 PM, David Picón Álvarez
<david@...> wrote:

> > I know that ADK can be circumvented by a determined attacker, but it
>  > strikes me as a useful feature, and I have never quite understood the
>  > opposition to it.  It would have made encryption more palatable in
>  > corporate settings, which surely would have been a good thing!
>
>  IMO there are two possibilities: 1) your users are forgetful but honest, 2)
>  your users are dishonest.
>
>  For case 1, an equivalent of ADK can be obtained with a line on GPG's
>  configuration file.
>
>  For case 2, you are screwed, and ADK is only going to give you a false sense
>  of security.
>
>  Thus ADK is either pointless or unnecessary.

This just simply isn't true.

Putting a line in a config file may be fine for internal mail, but
does nothing to help you to be able to decrypt mail sent from outside
your organisation.  It also locks everyone into using gpg - I thought
the whole point of gpg / opengpg was to be inter-operative.

Secondly, there might be any number of reasons why a user might not be
able to give you access to a key.  He might be incompetent, he might
be unexpectedly ill or worse.  And so on, and so forth.

But my real point is this: gpg in most areas says "This is a tool.
Your threat models will vary, and we give you a tool which you can
deploy".  But in the area of ADK, even when for years people have said
on this list and elsewhere, "ADK would help with the
threat/organizational model we have", GPG refuses to help.  "alter
your config file" solves (at best) half of the problem.

There may be very good technical reasons why ADKs are a bad idea, but
I've never seen them explained.  There was, I know, an attack on PGP
which relied upon them a while ago, but IIRC that bug was easily
fixed.

Best wishes,

N

_______________________________________________
Gnupg-users mailing list
Gnupg-users@...
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[Werner Koch]

On Tue, 19 Feb 2008 14:25, rjh@... said:

> PGP Corporation has a patent on ADKs.  That's the number one reason
> why the other OpenPGP implementations do not support it.

Frankly, I did not knew about this patent until now.

I consider the ADK the wrong solution to a problem which can't be solved
by a tool.

The assumed threat model is that an encrypted mail is received by an
employee and then other employees are not able to read this mail.  In
particular if the original recipient is on vacation or not anymore with
the company.  Or well, he willfully keeps that (company) mail private.
The latter case is actually identical to snail mail: How do you assure
that all mail to a company really receives the company and not just one
person?  The internal post office opens the envelope, stamps it,
sometimes makes a copy and then distributes it to the actual recipient.
Problem solved.  Also solves the problem of keeping archives of all
business mail (which is a legal requirment in Germany).

You can and need do do the same with email: Either use a central gateway
or create pool keys for the employees.  It is merely an organisational
matter that an employee does not use his private key for business tasks.
And if he does anyway, it is the same as with snail mail: The address on
the envelope is marked "private" and not to be opened by the company.

We won't add ARR (aka ADK) to GnuPG.  It would be more useful to add a
re-encode feature to add another public or symmetric key for decryption.
A mail framework may the use this to enforce a mail policy.


Salam-Shalom,

   Werner


--
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.


_______________________________________________
Gnupg-users mailing list
Gnupg-users@...
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[Alan Olsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512


>From:  Nicholas Cole
>Sent: Tuesday, February 19, 2008 6:54 AM
>To: gnupg-users@...
>Subject: Re: Corporate use of gnupg

>On Tue, Feb 19, 2008 at 1:23 PM, David Picón Álvarez <david@...> wrote:
>> > I know that ADK can be circumvented by a determined attacker, but it
>>  > strikes me as a useful feature, and I have never quite understood
>> the  > opposition to it.  It would have made encryption more palatable
>> in  > corporate settings, which surely would have been a good thing!
>>
>>  IMO there are two possibilities: 1) your users are forgetful but
>> honest, 2)  your users are dishonest.
>>
>>  For case 1, an equivalent of ADK can be obtained with a line on GPG's  
>> configuration file.
>>
>>  For case 2, you are screwed, and ADK is only going to give you a
>> false sense  of security.
>>
>>  Thus ADK is either pointless or unnecessary.

>This just simply isn't true.

>Putting a line in a config file may be fine for internal mail, but does nothing to help you to be able to decrypt mail sent from outside your organisation.  >It also locks everyone into using gpg - I thought the whole point of gpg / opengpg was to be inter-operative.

>Secondly, there might be any number of reasons why a user might not be able to give you access to a key.  He might be incompetent, he might be unexpectedly >ill or worse.  And so on, and so forth.

>But my real point is this: gpg in most areas says "This is a tool. Your threat models will vary, and we give you a tool which you can deploy".  But in the >area of ADK, even when for years people have said on this list and elsewhere, "ADK would help with the threat/organizational model we have", GPG refuses to >help.  "alter your config file" solves (at best) half of the problem.

>There may be very good technical reasons why ADKs are a bad idea, but I've never seen them explained.  There was, I know, an attack on PGP which relied
>upon them a while ago, but IIRC that bug was easily fixed.

Someone else brought up the issue of the technique being patented.  (Seems like a pretty obvious idea, but so are most software patents.)

In a corporate setting, you really just want key escrow.  Have a "official" company signing key.  When new employees come on board, they are issued a PGP/GPG key that is signed and the secret key data is copied to non-volitile media and stored in a safe.  It is only available under restricted circumstances (to prevent managers from exploiting the keys for their own gain).  It also gives some authenticity to the key by having some sort of web of trust internally.  Something like this takes manpower and time to manage, but so does manageing employee keycards and other authorization data.

Not that I have ever seen a company that does this.  Even companies that make heavy use of encryption do not seem to have anyone at a mamagement level that understands how it needs to be managed.
 

-----BEGIN PGP SIGNATURE-----
Version: 9.5.3 (Build 5003)

wsBVAwUBR7sUEWqdmbpu7ejzAQo+CQf/apv9Vb0gI8fpaURwxyXJlxcJCNfOcnMU
WwBQxdL0p2v6H+H8OMf+seAMixmoNl9EzT3NMalmdISP6H9g0656Fte+IemawBOj
N0gPB/i2FqmbgW7XlEaULl8LTqwBKfZ9VCqas/HC+ur4q1BrcgHOmlp939R+9fdC
u+ByXAF+bdLAwKMoRj5+rCLZ8UV1YYPe8mKIVIlVp4O62iLRENpPtFDF8hYJMO3O
3YSZ/L/+Gq8wjfB690ufhMs2Lvb3QF+8rFx2jsopEPVAedjKjtKq/1h3KbXql6//
VrtGCkMM3wmxDkdRDmAwMhNMSyo5TPoeA1VITRQAoc2IR/MzxBrAmg==
=8YBw
-----END PGP SIGNATURE-----

_______________________________________________
Gnupg-users mailing list
Gnupg-users@...
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[David Shaw]

On Tue, Feb 19, 2008 at 02:54:07PM +0000, Nicholas Cole wrote:

> On Tue, Feb 19, 2008 at 1:23 PM, David Picón Álvarez
> <david@...> wrote:
> > > I know that ADK can be circumvented by a determined attacker, but it
> >  > strikes me as a useful feature, and I have never quite understood the
> >  > opposition to it.  It would have made encryption more palatable in
> >  > corporate settings, which surely would have been a good thing!
> >
> >  IMO there are two possibilities: 1) your users are forgetful but honest, 2)
> >  your users are dishonest.
> >
> >  For case 1, an equivalent of ADK can be obtained with a line on GPG's
> >  configuration file.
> >
> >  For case 2, you are screwed, and ADK is only going to give you a false sense
> >  of security.
> >
> >  Thus ADK is either pointless or unnecessary.
>
> This just simply isn't true.
>
> Putting a line in a config file may be fine for internal mail, but
> does nothing to help you to be able to decrypt mail sent from outside
> your organisation.  It also locks everyone into using gpg - I thought
> the whole point of gpg / opengpg was to be inter-operative.

Let's define some terms, so we're all talking about the same thing in
the same way.

An ADK, for "Additional Decryption Key", sometimes called ARR for
"Additional Recipient Request", is a packet that is added to a key.
It is hashed into the key self-signature, so the key itself is needed
to add it.  This implies acceptance (or at least knowledge) of the
existence of the packet by the key owner, and if nothing else, they
can simply look at the key to see the ADK is there.  (There was a bug
a few years back where PGP accepted ADKs that weren't part of the
self-signature, but that has been fixed).

The main point of an ADK is to allow companies to get the benefit of
encryption, but help avoid the big risk of an employee encrypting
something in such a way that the company can't get it back.  The
employee could encrypt it and then quit (either maliciously or
coincidentally), or encrypt it and lose their key, and so on.  It's a
real risk.

The ADK contains two pieces of data: First, a key fingerprint.  This
is the key that the key owner is asking you to also encrypt to.
Secondly, there is a bunch of flags that tell you how strongly the key
owner feels about this.  The key owner can say either "Please also
encrypt to this key" or "You MUST also encrypt to this key".  In use,
an ADK is just another recipient.  It's more or less equivalent to
automatically adding a "-r the-adk-key" to a GPG command line.

Finally, note that the ADK is *not* part of OpenPGP.  It is a
proprietary extension of the PGP product.  It is also patented, which
prevents those other than PGP from implementing it.  (The PGP folks
are actually very reasonable about interoperability issues, but as far
as I know, nobody has asked about this.)

Now, in a closed environment (say, internal email) where everyone is
using PGP, it's great.  Every message is also encrypted to the ADK
key, and the company has assurance they won't lose any critical data.
In a mixed (PGP + GPG) but still closed environment, it's still pretty
good: those people using PGP will follow the ADK, and those people
using something else won't.  In the case of disaster, some data will
potentially not be recoverable.  This can be handled via the
"encrypt-to the-adk-key" in gpg.conf method.

To be sure, an employee in this closed environment could hack up
something that doesn't respect the ADK.  That's not a problem with the
software.  That's a problem with the employee.

The more difficult case is a completely open environment (say, email
for a company that also wants to encrypt their external email).  In
this case, those people using PGP will use the ADK, and others won't.
It's not possible to require every external person to do what you want
(they don't work for the company and have no reason to follow the
ADK).  In these cases, there isn't much that can be done aside from
key escrow, or running some sort of mail gateway system that can be
the keeper of the secret keys, or possibly even bounce messages back
that don't have an ADK (eg "You won't use the ADK, so I'm not talking
to you").

> But my real point is this: gpg in most areas says "This is a tool.
> Your threat models will vary, and we give you a tool which you can
> deploy".  But in the area of ADK, even when for years people have said
> on this list and elsewhere, "ADK would help with the
> threat/organizational model we have", GPG refuses to help.  "alter
> your config file" solves (at best) half of the problem.

Even if the patent issue was resolved, it doesn't really solve much to
have GPG follow the ADK.  GPG is distributed as source - easy enough
for someone to simply comment out the ADK code if they didn't want it
to take effect.

David

_______________________________________________
Gnupg-users mailing list
Gnupg-users@...
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[Robert J. Hansen-3]

Werner Koch wrote:
> Frankly, I did not knew about this patent until now.

US Patent 6314190, for those who want to check it out.

> I consider the ADK the wrong solution to a problem which can't be solved
> by a tool.

Mostly agreed.

> We won't add ARR (aka ADK) to GnuPG.  It would be more useful to add a
> re-encode feature to add another public or symmetric key for decryption.

The patent language on #6314190 is sufficiently broad that it would
arguably cover this, too, depending on how it's implemented.


_______________________________________________
Gnupg-users mailing list
Gnupg-users@...
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[vedaal]

>> We won't add ARR (aka ADK) to GnuPG.  It would be more useful to
>add a
>> re-encode feature to add another public or symmetric key for
>decryption.
>
>The patent language on #6314190 is sufficiently broad that it
>would
>arguably cover this, too, depending on how it's implemented.


a simple corporate solution,
is for the company to generate a gnupg keypair for each employee,
have the employee change the passphrase as desired,
and have the employees generate their own separate signing keys
(not subkeys)

then the company can simply inform all employees that any and all
encrypted mail sent or received by the company must have a
recipient key id that is on the company's 'accepted' list of
employee encryption keys, or the corporate mail filter will discard
it

this way, the employees are responsible for their own signatures,
which cannot be forged by the company, and are aware that the
company can read all company related e-mail,
and no patents are even remotely infringed upon

employees who really want to deceive the company, can send
encrypted files another way, (cdrw truecrypt containers by snail
mail, using gnupg  on private home computers etc.), and there is no
simple solution to stop it.


vedaal

any ads or links below this message are added by hushmail without
my endorsement or awareness of the nature of the link

--
The Perfect Baby Gift. Click Here
http://tagline.hushmail.com/fc/Ioyw6h4eUCjMPYjHbFDlJl4GLFkdg5rzznRGZDWJt71njDIDf5WCr9/


_______________________________________________
Gnupg-users mailing list
Gnupg-users@...
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[Robert J. Hansen-3]

vedaal@... wrote:
> a simple corporate solution,

Again, check the patent and then check with a patent lawyer.  The patent
language is suitably broad that this sort of thing might be construed by
a court to fall under the patent.

Technical fixes to provide ADK-like functionality are well and good, but
if you aren't looking at the patent and creating this new technology
with an eye towards avoiding the patent, you're playing the legal
version of Russian roulette.

If you want ADK-like functionality, you have two real choices:

        (a) buy a commercial PGP product,
        (b) spend $200/hr on a patent attorney to make sure your
            solution doesn't infringe.

Of course, all this is null and void if you live in a jurisdiction where
software cannot be patented.



_______________________________________________
Gnupg-users mailing list
Gnupg-users@...
http://lists.gnupg.org/mailman/listinfo/gnupg-users