[Cryptography] Private Information Sharing Protocol [P.I.S.P.] Requesting input, thoughts, comments.

[CANNON]

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

Title: Private Information Sharing Protocol [P.I.S.P.]
 Draft Version 1.1
  Author: Cannon Ciota <cannon at cannon-ciota.info> Created: 2017-01-21

 Abstract
	Opt in method of using publicly accessible directories,
	particularly namecoin, to list updatable information which
	can only be viewed by authorized entities.

 Motivation
	Primarily intended as a usecase for (but not limited to)
	namecoin as a proposal for a standard allowing entries such
	as contact information i.e. phone numbers, addresses, etc. to
	be listed in a way that allows only authorized entities of the
	entry owner's choice to be able to interpret such information.
	Namecoin, a secure decentralized universal directory, is
	great for binding a multitude of information to a single human
	readable identity in such a way that is not only censorship
	resistant, resilient, and verifiable, but also immune from
	tampering. However, due to the public nature of blockchain,
	what namecoin currently lacks in is a standard way to list
	specific portions of an identity's datastore in a way which
	allows sharing of such information to authorized entities only,
	at the control and discretion of the identity owner.

  Specification
	Each namecoin identity would have listed a public key, or
	pointer to a public key of which the owner's namecoin client
	software has a corresponding private key. This public/private
	keypair would be used for this Private Information Sharing
	Protocol, or P.I.S.P for short.  The public key would be
	denoted in the standard namecoin JSON format using one of two
	forms, embedded or as a pointer. A pointer would be useful
	in scenarios in which a large key is used or if space within
	the namecoin identity's limited size for data is scarce.

Examples

Embedded: 
- ---------
 {
   "pisp-pub":"026D3CA82768BC8D8E512EC97DFFAA7CACD52FF913A66911CFF074172F3CB0934E"
}

Pointer: 
- --------
{
  "pisp-point":
   {
    "url":"http://cannon-ciota.bit/cannon-ciota_publickey.pisp",
    "fingerprint":"2BB515CD66E74E2845DC6494A5A22879"
   }
}

or optionally we can use a hashsum of the pointed file in case the
file contains more fields than just the public key, to allow for
future extensions to PISP proposed standard.

{
  "pisp-point":
   {
    "url":"http://cannon-ciota.bit/cannon-ciota_publickey.pisp",
    "sha256":"5580aaa1a28145a1ec6c4136af58bdafb23fc13dbdb820ef1da7753e9f744f7d"
   }
}

Contents of cannon-ciota_publickey.pisp:
- ----------------------------------------
 {
   "pisp-pub":"026D3CA82768BC8D8E512EC97DFFAA7CACD52FF913A66911CFF074172F3CB0934E"
}

	Whenever looking up someone’s PISP public key from their
	namecoin identity, the client would first search for the
	pisp-pub (PISP public key) field, and if not found will proceed
	to search for the pointer field denoted as pisp-point (PISP
	pointer). The PISP pointer field would have the location of the
	public key used for PISP along with the fingerprint, or hashsum
	of the pointed file. The contents of the file mentioned in the
	pointer field would have the public key in the same JSON format
	as would be if directly in the namecoin datastore. Reason why
	is to allow the enabling of any future extensions to the PISP
	proposed standard.  PISP would be opt in. To opt in one would
	simply include a field in their namecoin identity to advertise
	their PISP public key, using either pisp-pub or pisp-point.
	For purpose of demonstration we will assume Alice and Bob both
	have a PISP public key included in their namecoin ID. Bob
	wants his phone number listed in his namecoin identity so
	his contacts can reach him, even if his phone number changes
	frequently. However Bob only wants specific contacts to know
	his current personal phone number, and Bob may want a seperate
	group of contacts to know his business phone number. Bob may
	also have another phone number that is public. And so Bob's
	phone entry in his namecoin ID might look like the following

{
   "phone":
   {
    "pisp":"http://EXAMPLE.URL/bobs-phone.pisp"
   }
}

or for multiple phones

{
   "phone":
   {
    "public":"+99 1234567890", 
    "business":
      {
		"pisp":"http://EXAMPLE.URL/bobs-business-phone.pisp"
      },
    "personal":
      {
		"pisp":"http://EXAMPLE.URL/bobs-phone.pisp"
      }
   }
}

	The .pisp file would have the relevant information but
	encrypted to the pisp public key of each of the contacts Bob
	authorizes to have access to such information. To prevent Bob's
	connections from being revealed each encrypted data snippet
	(one per contact) would not list public keys, only encrypted
	data. And so any contact would have to attempt to decrypt
	each snippet within the .pisp file until it finds a snippet
	it is able to decrypt. As a result outsiders cannot determine
	whom Bob's connections are, only the number of authorized
	connections. One mitigation to advertising number of authorized
	contacts would be to pad the .pisp file with decoy snippets. As
	a precaution against bruteforcing data to matching cypher text
	each snippet would also include a random salt unique for each
	snippet before encrypting.  And so if Bob wanted his number
	visible to Alice, he would include his current phone number
	(with a random salt) encrypted to Alice's listed PISP key and
	include the encrypted snippet into his .pisp file referenced
	in his namecoin identity. Alice's addressbook app on her phone
	would automatically lookup Bob's number from his namecoin ID,
	after seeing it as not publicly viewable but protected by
	PISP it would then use Alice's private PISP key to attempt to
	decrypt each snippet in Bob's .pisp file until successfully
	decrypting a snippet which then reveals Bob's number to Alice.
	If Bob's PISP protected phone number is not visible to Alice,
	after finding no decipherable snippet the app can tell Alice
	"not authorized to view this information". Alice then can
	hit a button on her app such as "request contact info for
	Bob's phone" which would send a request to Bob through a
	communications channel (such as publically listed email
	address or bitmessage address in Bob's namecoin ID) which
	would request Bob to include Alice as an authorized contact
	for that specified piece of information (in this case, Bob's
	personal number). The request would be signed by Alice's
	PISP key before being encrypted to Bob's PISP key to protect
	from spoofing and to maintain confidentiality of both the
	contents and identity of requester, to anyone who is not Bob.
	Upon receiving such request, Bob can choose to either allow
	Alice access or ignore such request. Because denying access
	is passive rather than active unlike granting access, this
	provides plausible deniability for Bob. If Bob chooses to
	not allow Alice as an authorized contact to view his number,
	he simply does nothing which provides plausible deniability
	of Bob's decision as Alice would not know if Bob explicitly
	chose to not to acknowledge request, or if Bob simply just
	forgot, or did not read the request.

//EOF
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYiHEeAAoJEAYDai9lH2mwo4wQAI9gvQdGqypsBWXa8F7tdjvY
iKBzcD1Xhhlva2Tl8FPGeJ9XrF+8xair1bu/wYjNq0L6Pnj5x2OO5zmkpXlTpuwk
aIzgqOeDKJIEPGNPu1eLQcsNuYNlwF0I8eTh1uC02a51wCmCyK2K0gnCzjJR6B3n
8hu0yBnnPqrYxN5/mP0efYrYHIrYQ+qrditvat4xHFRQPgoNuQHbah43yabDmBSD
9eqAO9Tzm09APx7mfgDSTNswE+DaF2J+CguNKiPuUhmznuAGGaAHj7Rjx/pjR6uc
oxyw8EkLWCTQvTGqpnNz2NyDRMFwjjj6lfqJ7dk4OAPfcIDnCcqaGp6iKA7K7M4d
VLgl6KIYkZheKRBqBNKPKcbmEeQvaqW5k38bgDERMF918LnPwSzVRbko3RVdAU8i
mNLfyIH5GOxFGVEWVK4x0Z7S9Mzr+PnGak8QPQ9HdzcvInq9BgwyIv4Mb4+RQoVb
FU0L0amvAo4FfK5K12FECilR9TK9hb1azUhk2BBEgzrkcY1kr6J8a0bpvWUP4ODC
uVB0FCvieiQU8PWYolU4BobOBR7KpTeQJZCv33RXGWZahpFfcxDWfEj0F97k8Qvl
T9X5Fn2w7B6gERrzmxbVj+aErlhL9UAvlhORGW968zfK2GDtkAPxhTOZN9q2I7Pq
FpAUdjmGzztdZm3goAKG
=K+r6
-----END PGP SIGNATURE-----

-- 
Cannon
PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832 
Email: cannon at cannon-ciota.info

NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.