On 02/18/2018 05:55 PM, Ben McGinnes wrote:
> So you took a system built from the outset on a security model founded
> entirely on public key exchanges between distributed and federated
> (both self-determining and self-governing) nodes ... and then spent a
> considerable amount of time and effort
On 01/05/2018 12:54 PM, Kristian Fiskerstrand wrote:
> On 01/05/2018 05:29 PM, Lou Wynn wrote:
>> The auditing key is certified by the root key and stays with the latter
>> in my design. Only the administrator can make policy to turn on/off
>> auditing, the client plugi
On 01/04/2018 02:28 PM, Ben McGinnes wrote:
> It seems to me, though, that the idea was to provide a means for the
> company to repudiate an employee's key even if the employee was no
> longer available.
This is just one of the benefits enabled by my goals which I stated at
the beginning, and it i
On 01/05/2018 01:10 AM, Kristian Fiskerstrand wrote:
> There are easily scenarios where a customer forgets to add the "auditing
> key", making the data unavailable to the organization, in particular in
> context of loss of employee.
>
The auditing key is certified by the root key and stays with the
On 01/05/2018 12:18 AM, Kristian Fiskerstrand wrote:
> Businesses have reasonable need to access their data, so they need to
> have access to his private keys, which contradicts "which
> is meant to prevent others from using his private keys", although
> reading it again I presume you're limiting t
On 01/04/2018 04:15 PM, Kristian Fiskerstrand wrote:
> On 01/05/2018 01:12 AM, Lou Wynn wrote:
>> I guess that you've missed somewhere I said in my previous posts that
>> the end user chooses his own password to protect his key password, which
>> is meant to prevent oth
On 01/04/2018 04:31 PM, Lou Wynn wrote:
> I think that I simplified my original description too much. The two
> levels of protection works like this.
> 1. The employee chooses his own password, which is used to encrypt his
> private key.
>
> 2. Then the encrypted key is encryp
On 01/04/2018 02:28 PM, Ben McGinnes wrote:
> On Wed, Jan 03, 2018 at 05:34:30PM -0800, Lou Wynn wrote:
>> The management of users' private key is a little more complicated. I
>> use two levels of protection. One level is at the organization. An
>> organization actually
On 01/04/2018 04:06 PM, Kristian Fiskerstrand wrote:
> But in the end it doesn't matter, as the organization anyways has access
> to the private key material of the employee. So a third party "auditing
> key" is irrespective of any access goals.
>
I guess that you've missed somewhere I said in my p
On 01/04/2018 02:57 PM, Kristian Fiskerstrand wrote:
> On 01/04/2018 11:24 PM, Lou Wynn wrote:
> but you add the requirement that all end users sending email to you
> require to validate the auditing key as well (auditing is likely wrong
> word, archiving is more likely relevant). for
On 01/04/2018 02:59 PM, Kristian Fiskerstrand wrote:
> On 01/04/2018 11:14 PM, Lou Wynn wrote:
>> Compared to using two CAs, my design introduces two properties to a
>> certificate. One is the certificate type, which is "p" for a partner and
>> "e" for
On 01/04/2018 02:08 PM, Kristian Fiskerstrand wrote:
> no, there isn't necessarily a client plugin, the gateway decrypts the
> message before it hits the internal email server, so end-user sees
> un-encrypted message, this is protecting transport, but security of
> on-site is ensures through differ
On 01/04/2018 02:04 PM, Kristian Fiskerstrand wrote:
>> I don't think it necessary to use business unit level certifying keys in
>> my design. It introduces management overhead which shadows its benefits.
>> If you understand the concept of trust realm/trust group and its
>> verification methods I
On 01/04/2018 01:04 PM, Ben McGinnes wrote:
> On Thu, Jan 04, 2018 at 12:40:59AM +, MFPA wrote:
>> For example, my ISP [0] says "All staff keys are signed using the
>> company signing key. This is very much like a traditional company
>> seal. Only the director has access to this key and it is o
On 01/04/2018 01:31 PM, Kristian Fiskerstrand wrote:
> On 01/04/2018 10:21 PM, Lou Wynn wrote:
>> After a client plugin logs in successfully, the server sends the user's
>> encrypted email key to the client.
> Aren't you better off with a gateway solution like PGP Unive
On 01/04/2018 12:25 AM, Andrew Gallagher wrote:
>> On 4 Jan 2018, at 04:42, Lou Wynn wrote:
>>
>> It has a client key and uses it to log into the server, which is
>> similar to SSH key authentication, to retrieve the private key after
>> authentication.
> Thi
On 01/03/2018 04:40 PM, MFPA wrote:
>> It is already the case that an organisation does not need to depend on
>> third-party CAs to certify its staff's OpenPGP keys.
>>
It's true for OpenPGP because OpenPGP is a distributed system, there is
no single CA, or it doesn't have the concept of CA at all
On 01/03/2018 06:37 PM, MFPA wrote:
> Hi
>
>
> On Thursday 4 January 2018 at 1:46:55 AM, in
> , Lou Wynn wrote:-
>
> If the user's OpenPGP software accesses that database each time it
> needs to use the private key, the database is providing the same
> function as t
On 01/03/2018 05:34 PM, Lou Wynn wrote:
>> Are you talking about something like a shared keyring? Or just managing
>> trust relationships by issuing key certifications and
>> revocations?
> The short answer is for both. End users do not need to manage their
When I said for
Hi MFPA,
On 01/03/2018 04:40 PM, MFPA wrote:
> Hi
>
>> a. An organization does not depend on third-party certificate
>> authorities.
> It is already the case that an organisation does not need to depend on
> third-party CAs to certify its staff's OpenPGP keys.
>
> For example, my ISP [0] says "All
01/03/2018 01:04 PM, Lou Wynn wrote:
> Yes, "trusted" keys do not mean much without contexts. There are few
> contexts to see what trustworthiness means.
>
> 1. From certificate verification point of view, a trusted key means that
> the certificate is verified to be in the s
On 01/03/2018 11:21 AM, Daniel Kahn Gillmor wrote:
> Hi Lou--
>
> On Tue 2018-01-02 23:02:08 -0800, Lou Wynn wrote:
>> b. Its employees and business partners do not manually manage their own
>> keys and trust relationship, and the administrator centrally manages al
I saw some interests in this mailing list about PGP's certification and
web-of-trust. I've been working on a system for enterprise customers
that dramatically changes how PGP key signing and verification work and
would like to discuss it here to see if someone is interested in it.
1. Goals of the
On 06/29/2017 02:31 PM, Robert J. Hansen wrote:
>> SHA1 got broken some months ago, but I see no useful move to get rid
>> of using it for even new stuff.
> (a) Not for OpenPGP's uses. For our uses it's still safe, although we
> recommend moving to other, better, hashes as soon as possible.
>
> (b
According to my understanding of crypto theory, your only way is to
generate keys and compare their fingerprints and with the value you
want. I would be surprised that you can find one in your lifetime. Or
it'd be a breakthrough in cryptography if you managed to do it somehow.
Thanks,
Lou
On 06/1
I also want to know if someone is actually using trust levels in
practice. You're the first one whom I came across, so I obviously can't
answer your question.
Thanks,
Lou
On 01/16/2017 08:52 AM, John Lane wrote:
> I'm trying to experiment with trust signatures but I can't work out how
> the 'doma
Hi,
I created a master key and two subkeys with one subkey being signing and
the other encryption. I then exported the two subkeys only.
However, when I used pgpdump to inspect packet types, both subkeys are
been marked as "RSA Encrypt or Sign (pub 1)." When I used another
program whose backend i
On 01/03/2017 06:05 AM, Daniel Kahn Gillmor wrote:
> You should stick with a single public certificate per user (containing
> the two keys that you describe) so that your users' correspondents don't
> have to juggle multiple keys per person they communicate with.
>
> --dkg
I overlooked this p
The author's stand is hilarious to me. He is
"My day-to-day work is in the field of information security and
especially incident handling, analysis and response. "
That's is to say, he's a security expert. But he compares himself with
Johnny by quoting "Why Johnny Can’t Encrypt”
Actually, there
On 01/02/2017 11:26 AM, Christopher Beck wrote:
>
> Hi Lynn,
>
>
> well, it is possible. There is an option for exporting only subkeys:
>
> gpg --output secret-subkeys --export-secret-subkeys SUBKEYID!
>
> It is important to use the exclamation mark at the end of the subkey-id!
>
> Instead of this
Hi,
I'm developing a key management solution for an organization. For an
employee, I'd like to generate two keys: one for signing and the other
for encryption. In my proposed solution, the encryption key should be
backed up in an organizational central server for auditing purpose, and
the signing
On 12/15/2016 04:18 PM, Andrew Gallagher wrote:
>> On 15 Dec 2016, at 19:24, Lou Wynn wrote:
>>
>> If the host machine is compromised, what's the purpose of doing encryption
>> on the SmartCard? Attackers don't need to know the key to get your plaint
>>
Let me analyze your steps to see what you'd like to achieve in each of them.
0. Alice and Bob knows each other's email addresses: alice@A and bob@B.
1. Bob sends Alice his public key at Alice email address alice@A.
2. Alice relies to Bob with her public key.
3. Alice calls B's support and asks
complete TCB, which must include
certain trusted host environment.
On 12/15/2016 11:24 AM, Lou Wynn wrote:
>
> If the host machine is compromised, what's the purpose of doing
> encryption on the SmartCard? Attackers don't need to know the key to
> get your plaint ext, beca
he keys, while
> with the USB drive approach, you just need to attack the host machine.
>
>
> On Thu, Dec 15, 2016, at 08:34 AM, Lou Wynn wrote:
>>
>> I've come cross a simple and secure approach at this post:
>>
>> http://zacharyvoase.com/2009/08/20/o
I've come cross a simple and secure approach at this post:
http://zacharyvoase.com/2009/08/20/openpgp/
In the MAKING BACKUPS section, this method simply places your gnupg
directory in an encrypted usb drive and make a symlink to it like this:
ln -s /Volumes/EncDrive/gnupg ~/.gnupg
That's all. A
I just happened to read this page today, and it's still open in my browser.
https://www.gnupg.org/documentation/manuals/gnupg/GPG-Configuration.html#GPG-Configuration
~/.gnupg/pubring.kbx
The public keyring using a different format. This file is sharred with
gpgsm. You should backup this file.
37 matches
Mail list logo
