Description:A user creates a new document and enters two different usernames (belonging to other users) in the “PublicEncryptionKeys” field. While document saving, it is encrypted. Thereafter, the following inscription appears in the status string: “Encrypted document with 3 public key(s).”
If the user creates a new document and enters two different usernames (his own username and the other one belonging to a different user) in the “PublicEncryptionKeys” field, the document is saved and encrypted. The inscription mentioned above appears in the status string.
If the user creates a new document and enters only his username in the “PublicEncryptionKeys” field, the document is saved and encrypted. In this case the following inscription is displayed in the status string: “Encrypted document with 2 public key(s).”
Question:
Why is the document encrypted with more keys than specified in the PublicEncriptionKeys field? Who is the owner of that additional public key?
I assume that the authors name is automatically added to a reader/author field when the document is created? The first 2 cases indicates this. Why would he need to enter his own name in the field if no one else is supposed to read it?
Anyway, now his name appears in 2 separate reader/authors fields, therefore Notes probably encrypts the document twice with the same public key.
I can’t give you a definitive answer, as there are a number of different ways to encrypt documents and configuration settings can cause the behavior to vary, but the default behavior is to also encrypt the document for the author, even if a key belonging to the author has been explicitly specified.
Thank-you very much. But in my case, I’m need the accurate answer with link to any official documentation. The documentation that I can’t find until now, that is needed for provide documentary evidence but not hypothetical. Who is the owner of that additional public key?
I can’t tell you how your specific case works, since I don’t know your configuration settings, how the document was created, how the names were added, and how the document was saved. I can tell you that the only time that an additional key management key is used beyond those that were specified by the relevant fields in the document, by the caller of the API, or so on, involves adding an extra seal with the user’s own public key. This is done all of the time with encrypted email to ensure that the sender will be able to decrypt, read, and re-send bounces, but in other cases the API program, agent, etc, could choose to over-ride that default behavior.
Dave – I think that Sergey’s point about the lack of formal documentation (as far as we know, anyhow) of the default ways in which this works, and how it might be controlled by applications, is a point well-taken.
Check the User Preferences, specifically the “Encrypt saved copy of mail that you send” setting. Try the same test cases you describe with the setting on, and with it off. Does it make a difference?
The activities did implement in different data base, not in user mail file.I didn’t have a difference with the “Encrypt saved copy of mail that you send” setting on and with it off.