Subject: [Endymail] FW: Group/Enterprise encrypted email

From: "Nordgren, Bryce L -FS" <[email-masked]>
Date: Mon, 1 Jun 2015 17:42:23 +0000

I was directed to this list because I posted the following to [kitten]. I looked at the archives here, and it seems that my proposed email key gatekeeper (run by the entity providing the email account) may solve the key distribution problem for transit, both for point to point ops as well as mailing lists.

No promises. It's not like I spend my life thinking about this stuff.

Bryce

From: Nordgren, Bryce L -FS
Sent: Friday, May 29, 2015 4:36 PM
To: [email-masked]
Subject: Group/Enterprise encrypted email

This is a "what if" message, centered around trying to make email encryption as painless as email signing. I want to be able to encrypt an email message once, no matter how many recipients there are. An enterprise should be able to decrypt employees' email to ensure there's no misbehavior. I want as little "extra" supporting infrastructure as possible. I also want to minimize the amount of inter-organizational coordination required.

What if sending an encrypted email required clients to contact an email key gatekeeper (EKG)? The EKG issues one-time-use encryption keys to authorized senders, and releases the decryption key once (only) to each recipient.

Detailed flow:

When encryption is desired, the sender's email client formats a key request to the EKG and signs it using the sender's email signing key. The key request includes the recipient's email addresses, but not their public keys, which are unknown. If the EKG is configured to recognize the sender, it replies with: 1] an encryption key, encrypted with the sender's public email signing key; and 2] a plaintext copy of the key request, signed by the EKG itself. The sender then decrypts the encryption key, encrypts the message and attachments, and attaches the signed key request. Poof. The message is sent. If the sender's client stores outgoing mail in a "sent mail" folder, the stored copy must be encrypted using some other means.

The EKG-signed key request includes: 1] a unique identifier for the encryption key; 2] contact info, so recipients can locate the EKG; and 3] of course, the list of recipients (part of the original key request).

The Sender's organization can decrypt the outbound email at a gateway by contacting the EKG and retrieving the decryption key (which could be the same as the encryption key if symmetric, or the other half of an asymmetric keypair if not.)

The recipient's organization (assuming different than sender's organization) cannot decrypt the inbound email at a gateway.

The recipient's email client detects the EKG's signed key request attached to the email. The EKG's signature is verified. The recipient's client uses the recipient's email signing cert to sign the EKG-signed key request, and sends to the EKG using the contact information provided.

The EKG verifies the recipients' signature. The EKG verifies that the recipient's certificate contains an email address that is included as a recipient in the original key request. The EKG verifies its own signature. The EKG encrypts the email's decryption key using the recipient's public email signing key, and signs the response. The recipient verifies the signature (ensuring same EKG signed key request and decryption key request) and decrypts the message/attachments.

If the message is to be stored, it must be re-encrypted in a locally recoverable fashion, likely with the recipient's credentials. If the recipient's organization is concerned about decrypting inbound email, the "locally recoverable fashion" should allow authorized individuals/services access. The original ciphertext should not be stored after decryption, and the decryption key must not be stored. Probably best not to get too psycho over this: the recipient can always cut and paste to some cleartext medium like word, or take a screenshot. Reasonable assurance that clients keep things encrypted when they're received encrypted is what we're after.

The EKG keeps track of which recipients have requested the decryption key. Recipients are allowed to request the key once and only once. When all recipients have requested the decryption key, that key must never be served out again. The EKG should not re-use encryption keys for subsequent messages.

Clearly, the EKG needs to be just as publicly available as the organization's mailserver. I do not believe there would need to be anything special in DNS (no "EKG" records, etc.) To summarize:  The EKG knows nothing about senders or recipients other than what the certificates tell it. Encryption keys for email messages are one-time-use, and shared among sender and all recipients. Recipients get decryption keys by having a certificate with a matching email address. No extra coordination is involved over and above the configuration necessary to verify email signatures.

What do you think? Is there an obvious reason this hasn't been done before?

Bryce

---

From: Trevor Freeman <[email-masked]>
Date: Mon, 01 Jun 2015 21:49:06 -0700

Hi Bryce,

What you propose is very similar to the Plasma work. The Plasma server
functions like a EKG as you describe. We generalized the model more so we
made authentication to the Plasma server via user tokens so it is possible
to support a broader set of authentication mechanisms and authentication
levels e.g. Facebook or Google+, as well as PIV cards.  Since we support
user tokes we can also do Attribute Based Access Control if the message
contents warrant e.g. if the message has ITAR material.  There were a number
of compares built a POC to show this works and interoperates. 

Here is the requirements document if you are interested.

Doing late key binging via an EKG does have a number of advantages over
early key binding. It is generally much more forgiving. It does not requires
everybody to have encryption keys at send time. It scales better if you have
a large number of recipients. It also does not require recipient key escrow
to prevent data loss if you lose your encryption key.  This main issue is
the security and scope of the EKG key or keys. 

Here is the draft if you want to read more.
https://datatracker.ietf.org/doc/draft-freeman-plasma-requirements/

Trevor

From: Endymail [mailto:[email-masked]] On Behalf Of Nordgren,
Bryce L -FS
Sent: Monday, June 01, 2015 10:42 AM
To: [email-masked]
Subject: [Endymail] FW: Group/Enterprise encrypted email

I was directed to this list because I posted the following to [kitten]. I
looked at the archives here, and it seems that my proposed email key
gatekeeper (run by the entity providing the email account) may solve the key
distribution problem for transit, both for point to point ops as well as
mailing lists.

Bryce

This is a "what if" message, centered around trying to make email encryption
as painless as email signing. I want to be able to encrypt an email message
once, no matter how many recipients there are. An enterprise should be able
to decrypt employees' email to ensure there's no misbehavior. I want as
little "extra" supporting infrastructure as possible. I also want to
minimize the amount of inter-organizational coordination required.

What if sending an encrypted email required clients to contact an email key
gatekeeper (EKG)? The EKG issues one-time-use encryption keys to authorized
senders, and releases the decryption key once (only) to each recipient. 

Detailed flow:

When encryption is desired, the sender's email client formats a key request
to the EKG and signs it using the sender's email signing key. The key
request includes the recipient's email addresses, but not their public keys,
which are unknown. If the EKG is configured to recognize the sender, it
replies with: 1] an encryption key, encrypted with the sender's public email
signing key; and 2] a plaintext copy of the key request, signed by the EKG
itself. The sender then decrypts the encryption key, encrypts the message
and attachments, and attaches the signed key request. Poof. The message is
sent. If the sender's client stores outgoing mail in a "sent mail" folder,
the stored copy must be encrypted using some other means.

The EKG-signed key request includes: 1] a unique identifier for the
encryption key; 2] contact info, so recipients can locate the EKG; and 3] of
course, the list of recipients (part of the original key request). 

The Sender's organization can decrypt the outbound email at a gateway by
contacting the EKG and retrieving the decryption key (which could be the
same as the encryption key if symmetric, or the other half of an asymmetric
keypair if not.)

The recipient's organization (assuming different than sender's organization)
cannot decrypt the inbound email at a gateway. 

The recipient's email client detects the EKG's signed key request attached
to the email. The EKG's signature is verified. The recipient's client uses
the recipient's email signing cert to sign the EKG-signed key request, and
sends to the EKG using the contact information provided. 

The EKG verifies the recipients' signature. The EKG verifies that the
recipient's certificate contains an email address that is included as a
recipient in the original key request. The EKG verifies its own signature.
The EKG encrypts the email's decryption key using the recipient's public
email signing key, and signs the response. The recipient verifies the
signature (ensuring same EKG signed key request and decryption key request)
and decrypts the message/attachments.

If the message is to be stored, it must be re-encrypted in a locally
recoverable fashion, likely with the recipient's credentials. If the
recipient's organization is concerned about decrypting inbound email, the
"locally recoverable fashion" should allow authorized individuals/services
access. The original ciphertext should not be stored after decryption, and
the decryption key must not be stored. Probably best not to get too psycho
over this: the recipient can always cut and paste to some cleartext medium
like word, or take a screenshot. Reasonable assurance that clients keep
things encrypted when they're received encrypted is what we're after.

The EKG keeps track of which recipients have requested the decryption key.
Recipients are allowed to request the key once and only once. When all
recipients have requested the decryption key, that key must never be served
out again. The EKG should not re-use encryption keys for subsequent
messages.

Clearly, the EKG needs to be just as publicly available as the
organization's mailserver. I do not believe there would need to be anything
special in DNS (no "EKG" records, etc.) To summarize:  The EKG knows nothing
about senders or recipients other than what the certificates tell it.
Encryption keys for email messages are one-time-use, and shared among sender
and all recipients. Recipients get decryption keys by having a certificate
with a matching email address. No extra coordination is involved over and
above the configuration necessary to verify email signatures. 

Bryce

---

From: "Nordgren, Bryce L -FS" <[email-masked]>
Date: Tue, 2 Jun 2015 18:52:51 +0000

Hi Trevor, thanks for the link.

I like the multiple ways to authenticate to plasma servers, and of course your "late key binding". Sounds so much more professional than my version! In my quick read, I was not able to locate how I would specify who gets access to the keys for my message, or whether that was bound to the message payload. Does the message contain an untamperable list of authorized recipients?

I have some concerns about the DRM, basically that I'd like to see it factored out into a separate doc. To me, the point of encrypted messaging is to deliver content to a specified party while preventing others from snooping. If I have concerns about what that party might do with the content upon receipt, I shouldn't be sending it to them in the first place. You just can't fix stupid.

But let's say we try to fix stupid. And we specify a perfect message DRM ecosystem. Screenshots will likely still work. Cell phones with cameras can always still be pointed at the screen. Are you really comfortable stating that any situation has a "high", "significant", or even "some" confidence that policy is enforced when just about anyone can defeat the system with a keypress? Will users, after they defeat it themselves? Will security officers?

Attachments. The perfect DRM-compliant email client will have to decrypt the attachment payload and hand it off to the application which recognizes it. At this point it has been exported from the DRM system and you again must trust the other party will use it appropriately. Either that, or assimilate every possible application which can process every possible attachment into your DRM system. Such a system would be like "Ultraviolet for Everything".

The solution to both of these drawbacks is "think before you send", which is what you should do if you're dealing with sensitive data anyway. Simplifies the spec immensely, by providing a clear, well defined, easily understood user responsibility. Even an "Ultraviolet for Everything" approach does not relieve the user of this responsibility. IMHO, the design of a comprehensive DRM system for all content is a much different animal than just making sure the content is delivered reliably and protected from snooping. I recommend starting with just secure transport and tackling DRM later.

Finally, a secure, self-contained DRM system excludes open source software by definition. If anyone can comment out the "enforcement code" then recompile, all confidence is low. This is why open source blue ray players on Linux rely on cracking old codes: no one will give them "good" codes. On the other hand, secure delivery of "no strings attached" encrypted messages is something that open source can do very well. Respecting this boundary line is an excellent reason to split the spec into transport and DRM.

Just some thoughts.
Bryce

From: Trevor Freeman [mailto:[email-masked]]
Sent: Monday, June 01, 2015 10:49 PM
To: Nordgren, Bryce L -FS; [email-masked]
Subject: RE: [Endymail] FW: Group/Enterprise encrypted email

Hi Bryce,
What you propose is very similar to the Plasma work. The Plasma server functions like a EKG as you describe. We generalized the model more so we made authentication to the Plasma server via user tokens so it is possible to support a broader set of authentication mechanisms and authentication levels e.g. Facebook or Google+, as well as PIV cards.  Since we support user tokes we can also do Attribute Based Access Control if the message contents warrant e.g. if the message has ITAR material.  There were a number of compares built a POC to show this works and interoperates.
Here is the requirements document if you are interested.
Doing late key binging via an EKG does have a number of advantages over early key binding. It is generally much more forgiving. It does not requires everybody to have encryption keys at send time. It scales better if you have a large number of recipients. It also does not require recipient key escrow to prevent data loss if you lose your encryption key.  This main issue is the security and scope of the EKG key or keys.
Here is the draft if you want to read more. https://datatracker.ietf.org/doc/draft-freeman-plasma-requirements/

Trevor

From: Endymail [mailto:[email-masked]] On Behalf Of Nordgren, Bryce L -FS
Sent: Monday, June 01, 2015 10:42 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Endymail] FW: Group/Enterprise encrypted email

Bryce

From: Nordgren, Bryce L -FS
Sent: Friday, May 29, 2015 4:36 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Group/Enterprise encrypted email

Detailed flow:

Bryce

---

From: Trevor Freeman <[email-masked]>
Date: Wed, 03 Jun 2015 11:00:52 -0700

Hi Bryce,

The technical specs are in a separate draft. We modified S/MIME but there is
nothing to stop this being applied to PGP.

https://datatracker.ietf.org/doc/draft-schaad-plasma-cms/

The Plasma token which is generated by the EKG s bound to the message by a
detached signature. The token has an encrypted payload which can contain
policy dependent metadata such as a recipient list. Not all polices require
a receipt list. 

Plasma does not attempt DRM in that it places no technical obligations on
the receipt when we release the decryption key. SMIME or PGP encryption is
Identity Based Access Control since the sender is authorizing the receipt
based on the identity binding to the key. We were putting email based
content on par with content which was published via the web.  So if you
wanted to send content covered by a policy, you would get the same
protection and policy enforcement as if you published via the web. This is
not about fixing stupid, its more not requiring clairvoyance about every
recipient. 

Another aspect is Plasma allows for device attributes so before we release
the decryption key we can requires information about the state of the
environment. That way if the recipient is infected, we can block decryption
which is another plus for late binding. Again his is option so for low
assurance polices you probably not care. 

Plasma can also handle multiple polices on a single message so if there were
mixed content, we can selectively release keys i.e. it allows for auto
redaction. 

Trevor

From: Endymail [mailto:[email-masked]] On Behalf Of Nordgren,
Bryce L -FS
Sent: Tuesday, June 02, 2015 11:53 AM
To: Trevor Freeman; [email-masked]
Subject: Re: [Endymail] FW: Group/Enterprise encrypted email

I like the multiple ways to authenticate to plasma servers, and of course
your "late key binding". Sounds so much more professional than my version!
In my quick read, I was not able to locate how I would specify who gets
access to the keys for my message, or whether that was bound to the message
payload. Does the message contain an untamperable list of authorized
recipients?

I have some concerns about the DRM, basically that I'd like to see it
factored out into a separate doc. To me, the point of encrypted messaging is
to deliver content to a specified party while preventing others from
snooping. If I have concerns about what that party might do with the content
upon receipt, I shouldn't be sending it to them in the first place. You just
can't fix stupid.

But let's say we try to fix stupid. And we specify a perfect message DRM
ecosystem. Screenshots will likely still work. Cell phones with cameras can
always still be pointed at the screen. Are you really comfortable stating
that any situation has a "high", "significant", or even "some" confidence
that policy is enforced when just about anyone can defeat the system with a
keypress? Will users, after they defeat it themselves? Will security
officers?

Attachments. The perfect DRM-compliant email client will have to decrypt the
attachment payload and hand it off to the application which recognizes it.
At this point it has been exported from the DRM system and you again must
trust the other party will use it appropriately. Either that, or assimilate
every possible application which can process every possible attachment into
your DRM system. Such a system would be like "Ultraviolet for Everything".

The solution to both of these drawbacks is "think before you send", which is
what you should do if you're dealing with sensitive data anyway. Simplifies
the spec immensely, by providing a clear, well defined, easily understood
user responsibility. Even an "Ultraviolet for Everything" approach does not
relieve the user of this responsibility. IMHO, the design of a comprehensive
DRM system for all content is a much different animal than just making sure
the content is delivered reliably and protected from snooping. I recommend
starting with just secure transport and tackling DRM later.

Finally, a secure, self-contained DRM system excludes open source software
by definition. If anyone can comment out the "enforcement code" then
recompile, all confidence is low. This is why open source blue ray players
on Linux rely on cracking old codes: no one will give them "good" codes. On
the other hand, secure delivery of "no strings attached" encrypted messages
is something that open source can do very well. Respecting this boundary
line is an excellent reason to split the spec into transport and DRM.

Just some thoughts.

Bryce

Hi Bryce,

Trevor

Bryce

Detailed flow:

Bryce

---

From: "Nordgren, Bryce L -FS" <[email-masked]>
Date: Wed, 3 Jun 2015 19:49:16 +0000

Please forgive my organizations' utter reliance on an email client that can't even quote correctly. Not to mention it keeps trying to make hyperlinks in a plain text message.

> The technical specs are in a separate draft. We modified S/MIME but there is nothing 
> to stop this being applied to PGP.

Thanks. I'll put it on my list. Is this the correct place to provide feedback or is there another IETF list?

>Plasma does not attempt DRM in that it places no technical obligations on the receipt 
>when we release the decryption key. 
> ...
> So if you wanted to send content covered by a policy, you would get the same protection 
> and policy enforcement as if you published via the web.

I'm having a hard time wrapping my head around the notion of enforcement comingling with "no obligations on receipt" of the key. Enforcement is an obligation.

> Not all polices require a receipt list.

Why would you send something to someone if you weren't going to allow them to decrypt it? If you need finer grained control than an email list affords, perhaps an email list is not an appropriate solution. All email-related policies should require a recipient list, and in addition the policy's list should be synchronized with the email's recipient list (albeit, the policy can refer to the same list of people by non email identifiers). It's probably going to be hard enough just making sure that everyone's identifier somehow tracks back to their email address, and you're not giving away access to someone you didn't send the message to.

Section 4.1 seems too centered on the end user's ISP. I have a few email accounts, none of which are from my ISP. (gmail, yahoo, work, etc.) Suggest changing to "mail provider" or equivalent.

>From section 4.4.1: 

  (5)  Frank clicks the "send email" button. The client signs the email
       using his smart card private key and includes the certificate
       with the appropriate public key for verification of the signature
       by recipients. The client then encrypts the message and obtains a
       token for the message from a server that will enable the
       recipients' servers to enforce the access control requirements
       for Frank, and sends the email to his email server.

Unless the client is encrypting with Frank's smart card private key, I think it needs to contact "a server that will enable the recipients' servers to enforce the access control requirements" to obtain the encryption key. 

Editorial note: I think it would be helpful to define how many servers there are, what they are called, and the role for each one then use that nomenclature consistently throughout the use cases. I know you outlined a "generic access control model", and include a vocabulary, but the list appears to be missing the thing that makes and releases keys, which is kind of a cornerstone of this architecture. I'm also somewhat unclear as to how many of the "xx xx Point" items are servers, and which are clients.

  (7)  Once Grace has shown she passes the policy requirements, the PDEP
       releases the message Content Encryption Key (CEK) to Grace using
       her level 3 encryption certificate.

Does the PDEP do all the key management? (e.g., does Frank contact the PDEP to get a new key for his message?)

  (9)  The CEK Grace received has a Time To Live (TTL)  value which
       defines when Grace must discard the CEK and reapply for a new
       CEK.  

I'd like to point out that an adversary would just keep the CEK. Or make a plaintext/alternate ciphertext copy of the content while the CEK is still valid. 

Even with well behaved actors, in the case of attachments, it is likely that the attachment will have to be decrypted, saved on disk in plaintext, and opened with an external application. They have a "forever" copy even when the CEK expires. Why would they even notice that a CEK expired?

It is probably worth stressing in security considerations that the only rational assumption is: "once decrypted, always accessible". While the example is designed  to show that confidentiality policies change over time, the solution proposed by this system only allows for an expansion of the pool of actors in possession of your sensitive data, never a reduction. Ever. 

> Another aspect is Plasma allows for device attributes so before we 
> release the decryption key we can requires information about the 
> state of the environment. That way if the recipient is infected, we 
> can block decryption which is another plus for late binding. Again 
> his is option so for low assurance polices you probably not care. 

For high assurance policies, I would assume infected/malicious clients to be lying. Particularly if they were not administered by me, and probably even then. Should you ever expect any response other than "I'm healthy and you can trust me!"? Am I missing something? 

Thanks,
Bryce

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 3 Jun 2015 16:07:59 -0400

On Wed, Jun 3, 2015 at 3:49 PM, Nordgren, Bryce L -FS <[email-masked]>
wrote:

>
> I'm having a hard time wrapping my head around the notion of enforcement
> comingling with "no obligations on receipt" of the key. Enforcement is an
> obligation.

Trevor sais 'no Technical obligations'. I think what he means here is that
people who use this technology are probably going to use clients that make
a best effort to not leak confidential bits but not require the use of
trustworthy hardware that can provide technical enforcement. In other
words, I can use a completely open source client modified in any way I like
without having to get the executable signed by someone the rights owner
trusts.

In a corporate context, this makes perfect sense. If I am downloading
company confidential material to my laptop, I want to be able to read it on
the laptop but I don't want to accidentally send a copy to someone else by
doing an unfortunate 'reply all'.

---

From: "Nordgren, Bryce L -FS" <[email-masked]>
Date: Wed, 3 Jun 2015 20:45:27 +0000

> In a corporate context, this makes perfect sense. If I am downloading company confidential 
> material to my laptop, I want to be able to read it on the laptop but I don't want to accidentally 
> send a copy to someone else by doing an unfortunate 'reply all'.

So another thing to note in security considerations is that this is a scheme intended to protect well behaved actors who have good habits and an honest software ecosystem from causing damage due to specific single honest mistakes. It is not intended to protect against adversaries, well behaved actors who have sloppy habits, well behaved actors who make more than one mistake on the same message (reply all + attachment with no tag/inappropriate tag), or well behaved actors who make a single mistake from which multiple correlated incorrect actions are derived (misclassify content -> incorrect content tag/incorrect mailing list). 

In light of these things, I think any language about "ensuring that policy is followed" or the like should just be expunged. If the target is to encourage well-meaning partners to do the accepted thing, that's how it should be presented.

Bryce

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 3 Jun 2015 17:09:51 -0400

On Wed, Jun 3, 2015 at 4:45 PM, Nordgren, Bryce L -FS <[email-masked]>
wrote:

> company confidential
> So another thing to note in security considerations is that this is a
> scheme intended to protect well behaved actors who have good habits and an
> honest software ecosystem from causing damage due to specific single honest
> mistakes. It is not intended to protect against adversaries, well behaved
> actors who have sloppy habits, well behaved actors who make more than one
> mistake on the same message (reply all + attachment with no
> tag/inappropriate tag), or well behaved actors who make a single mistake
> from which multiple correlated incorrect actions are derived (misclassify
> content -> incorrect content tag/incorrect mailing list).
>
> In light of these things, I think any language about "ensuring that policy
> is followed" or the like should just be expunged. If the target is to
> encourage well-meaning partners to do the accepted thing, that's how it
> should be presented.

As I said to a former director of the NSA recently, the fact that Snowden
and Manning had effectively unrestricted access to such a large amount of
data is an indictment of both the institution and the approach to
controlling information.

The classification level of a document is a measure of the ego of the
author/classifier, not how important it is to keep it secret. If keeping
documents secret causes operational difficulties, people will not attach
the security labels necessary to control them properly.

Trying to absolutely control the flow of information has a lousy track
record. And not just in the US but FOIA means that the US examples are
rather more obvious. Trying to lock everything down resulted in security
systems so complicated, even an MIT professor was unable to figure them out
when he was made CIA director.

The lesson we have learned is that imperfect security systems that are
acceptable to end users are much more effective than theoretically perfect
schemes that users bypass. It is possible that the US federal govt. will
learn the same lesson someday. If they ever do, they know where to look.

---

From: "Nordgren, Bryce L -FS" <[email-masked]>
Date: Wed, 3 Jun 2015 22:20:14 +0000

>Trying to absolutely control the flow of information has a lousy track record. 
>And not just in the US but FOIA means that the US examples are rather more 
>obvious. Trying to lock everything down resulted in security systems so complicated, 
>even an MIT professor was unable to figure them out when he was made CIA director. 

>The lesson we have learned is that imperfect security systems that are acceptable 
>to end users are much more effective than theoretically perfect schemes that users 
>bypass. It is possible that the US federal govt. will learn the same lesson someday. 
> If they ever do, they know where to look.

I think we are in agreement that top down micromanagement of information flow is bad. My comments are intended to align the language in the doc with the actual security provided, not cause anyone to fix perceived security holes. :) It does very much read like the intent is to set up a DRM such that conforming systems provide certain guarantees. It shouldn't.

I'm not certain I've been persuaded that the DRM-esque aspects are worthwhile. Sticking with normal, un-augmented email semantics simplifies this proposal to the point that implementers may be able to make the encryption process completely transparent to users, or at least boil it down to a checkbox. Much of the value associated with generalizing the available policies beyond "encrypt this message and disseminate keys to the email recipients" seems to be predicated on prose making guarantees of policy enforcement across organizational boundaries. A very much clearer and more precise value statement is warranted.

Perhaps this is answered in that other spec, but I don't yet see how the mail client knows what parameters are expected by the policy. Does it need to understand and implement a UI for some sort of policy schema language?

Best,
Bryce

---

From: Trevor Freeman <[email-masked]>
Date: Thu, 04 Jun 2015 11:54:05 -0700

Hi Bryce,
I am not quite sure why you keep asserting Plasma is attempting DRM when it's not. All its doing is providing the same access controls for email content as the same content is published via the web - and why should an organization expect anything less. It help the sender make sure that recipients are entitled to receive the information and that the sender has complied with the information protection policy for the information in the email. Unlike DRM, Plasma does not raise expectations that the recipient does the right thing with the information. Plasma did show it is possible to provide additional controls to ensure it is appropriate only disseminate the decryption keys when policy has been satisfied. We do not set expectations beyond that because the only strong control is the act of releasing the decryption key. In the Plasma PoC we showed it was possible to drive Plasma via a simple combo box selection as a one stop shop which hid the specifics of each policy. One of the vendors who participated in the project also did a user trial to test Plasma against the check box options of today and we got back positive results that user preferred Plasma to the encrypt message check box.

Trevor

-----Original Message-----
From: Endymail [mailto:[email-masked]] On Behalf Of Nordgren, Bryce L -FS
Sent: Wednesday, June 03, 2015 3:20 PM
To: Phillip Hallam-Baker
Cc: Trevor Freeman; [email-masked]
Subject: Re: [Endymail] FW: Group/Enterprise encrypted email

>And not just in the US but FOIA means that the US examples are rather 
>more obvious. Trying to lock everything down resulted in security 
>systems so complicated, even an MIT professor was unable to figure them out when he was made CIA director.

>acceptable to end users are much more effective than theoretically 
>perfect schemes that users bypass. It is possible that the US federal govt. will learn the same lesson someday.

Best,
Bryce
_______________________________________________
Endymail mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/endymail