Public Peer File

The Makeup of the Public Peer File

A Public Peer File contains information required to locate, connect and establish a secure channel between peers and contains Identities within the same file. The Public Peer File is made up of three sections, appropriately named Section “A”, Section “B” and Section “C”. Section “A” can be safely transmitted to any third party allowing any third party to know the Peer Contact’s “contact ID” as well as its pubic key to prove ownership (only the owner would have the related private key). Section “B” allows for another peer to find the peer and initiate contact. Section “B” can be withheld from any other peer if the peer does not wish itself to be found by that peer. Section “C” is used to include proven identities of the contact. This section can be given or withheld depending how anonymous the peer wishes to be. The entire file is only given to third parties (i.e. Section A+B+C) allowed to communicate directly to the peer containing where the peer wants to be contacted and wants to expose its identities. At minimal, Section “A” is required to establish a secure channel between peers and Section “B” is required to allow a peer to be found by another peer and Section “C” is required to prove public identities of the peer.

A Public Peer File should contain the extension of “.peer”

Section “A” (packaged and signed by identity’s private key)

  • Cipher suite to use for all hash computations and encryptions related to contents of the peer file (note: this does not apply to signed XML segments which have their own method to describe algorithms and key selection)
  • Public peer file creation date
  • Public peer file expiry date
  • Salt signed by salt service’s key
  • Extension authorized-peer data
  • Peer’s public key (in signature)
  • Peer Contact’s full URI (to know how to locate the peer universally) that do not reveal any identities. Peer’s contact ID is calculated as follows: hash value of section “A”, i.e. tolower(base16encode(hash(“contact:” + <public-peer-section-A>))). When the input <public-peer-file-section-A is used in the hash, the same canonical algorithm method as the signature in section “A”. The input into the algorithm is the entire section “A” bundle including the certificate signing the section bundle.
  • Find secret (must be known by peer attempting to initiate a finder connection to another peer). This is a simple random string and is not encoded into base-64.
  • Extension authorized-peer data
  • Peer Contact’s full URI (to know how to locate the peer universally).
  • Any/all asserted public identities
  • Extension authorized-peer data

Section “B” (packaged and signed by identity’s private key)

  • Peer Contact’s full URI (to know how to locate the peer universally) that do not reveal any identities. Peer’s contact ID is calculated as follows: hash value of section “A”, i.e. tolower(base16encode(hash(“contact:” + <public-peer-section-A>))). When the input <public-peer-file-section-A is used in the hash, the same canonical algorithm method as the signature in section “A”. The input into the algorithm is the entire section “A” bundle including the certificate signing the section bundle.
  • Find secret (must be known by peer attempting to initiate a finder connection to another peer). This is a simple random string and is not encoded into base-64.
  • Extension authorized-peer data

Section “C” (packaged and signed by identity’s private key)

  • Peer Contact’s full URI (to know how to locate the peer universally).
  • Any/all asserted public identities
  • Extension authorized-peer data

The public key is used as a way to send the peer privately encrypted data from another source. As long as the other source has the correct public key it is possible to establish direct secure communication by exchanging keys using public/private keys as the encryptions method.

The salt is used in Section “A” to establish randomness into the files that is not forgeable or controllable by the creator of the file this ensuring that hashes are dispersed based on randomness being present.

Asserted identities are used to prove the owner of the peer file is whom they claim to be.

Extension data is arbitrary for future extension of the peer file.

The peer’s contact ID is used to prove that Section “B” and Section “C” correlates properly to section “A” and isn’t two or three distinct files being glued together as a forgery.

Security Considerations

The Section “A” bundle must contain salt that has been signed by the salt service whose certificate is still within the window of validity. Further the Section “A” bundle must be signed by a self-signed certificate whose certificate is included in the signature of the bundle. This ensures the integrity of the Section “A” bundle and ensures anyone who has Section “A” knows the public key for the peer.

Section “B” includes a finder secret that other peers will use to find the peer to which the peer file belongs.

Asserted Identities contained within section “C” can be verified whenever verification is needed. Verification is dependent on the identity assertion type.

The integrity of Section “B” and Section “C” should be verified by ensuring that the public key contained in Section “A” signed these sections. The URIs in these sections are not verified as it’s up to the client generating the URIs to generate resources that are accurate to the network and up to other peers to ensure they are contacting identities they should be contacting.

Only elements contained within the signed sections are ever considered as part of the file. All other elements are erroneous and should be discarded or ignored and when present. In Section “A”, erroneous elements outside the protection of a signature should never be used as part of the calculation of the contact ID.

Example Public Peer File

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113

<peer version="1">
<sectionBundle xmlns="http://www.hookflash.com/openpeer/1.0/message">
 <section id="A">
  <cipher>sha256/aes256</cipher>
  <created>54593943</created>
  <expires>65439343</expires>
  <saltBundle xmlns="http://www.hookflash.com/openpeer/1.0/message">
   <salt id="cf9c4688b014e13d8bdd2655912ffd3253f53768">Z3nfnDenen29291mfde…21n</salt>
   <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
    <SignedInfo>
     <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1" /> 
     <Reference URI="#cf9c4688b014e13d8bdd2655912ffd3253f53768">
      <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>jeirjLrta6skoV5/A8Q38Gj4j323=</DigestValue> 
     </Reference>
    </SignedInfo>
    <SignatureValue>DEfGM~C0/Ez=</SignatureValue>
    <KeyInfo><KeyName>DN=example.org, SN=salt, ID=db144bb314f8e018303bba7d52e</KeyName></KeyInfo>
   </Signature>
  </saltBundle>
 </section>
 <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
  <SignedInfo>
   <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1" /> 
   <Reference URI="#A">
    <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
    <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue> 
   </Reference>
  </SignedInfo>
  <SignatureValue>G4Fwe0E/YT=</SignatureValue>
  <KeyInfo>
   <X509Data>
    <X509Certificate>MIID5jCCA0+gA...lVN</X509Certificate>
   </X509Data>
  </KeyInfo>
 </Signature>
</sectionBundle>
<sectionBundle xmlns="http://www.hookflash.com/openpeer/1.0/message">
 <section id="B">
  <contact>peer://example.com/ab43bd44390dabc329192a392bef1</contact>
  <findSecret>YjAwOWE2YmU4OWNlOTdkY2QxNzY1NDA5MGYy</findSecret>
 </section>
 <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
  <SignedInfo>
   <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1" /> 
   <Reference URI="#B">
    <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
    <DigestValue>UrXLDLBIta6skoV5/A8Q38GEw44=</DigestValue> 
   </Reference>
  </SignedInfo>
  <SignatureValue>MC0E~LE=</SignatureValue>
 </Signature>
</sectionBundle>
<sectionBundle xmlns="http://www.hookflash.com/openpeer/1.0/message">
 <section id="C">
  <contact>peer://example.com/ab43bd44390dabc329192a392bef1</contact>
  <identities>
   <identityBundle xmlns="http://www.hookflash.com/openpeer/1.0/message">
    <identity id="b5dfaf2d00ca5ef3ed1a2aa7ec23c2db">
     <contact>peer://example.com/ab43bd44390dabc329192a392bef1</contact>
     <uri>identity://facebook.com/id48483</uri>
     <created>54593943</created>
     <expires>65439343</expires>
    </identity>
    <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
     <SignedInfo>
      <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1" /> 
      <Reference URI="#b5dfaf2d00ca5ef3ed1a2aa7ec23c2db">
       <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
       <DigestValue>IUe324koV5/A8Q38Gj45i4jddX=</DigestValue> 
      </Reference>
     </SignedInfo>
     <SignatureValue>MDAwMDAwMGJ5dGVzLiBQbGVhc2UsIGQ=</SignatureValue>
     <KeyInfo><KeyName>DN=hookflash.org, SN=identity, ID=b7ef37...4a0d58628d3</KeyName></KeyInfo>
    </Signature>
   </identityBundle>
   <identityBundle xmlns="http://www.hookflash.com/openpeer/1.0/message">
    <identity id="0a9b2290343734118469e36d88276ffa6277d196">
     <contact>peer://example.com/ab43bd44390dabc329192a392bef1</contact>
     <uri>identity://twitter.com/booyah</uri>
     <created>54593943</created>
     <expires>65439343</expires>
</identity>
    <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
     <SignedInfo>
      <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1" /> 
      <Reference URI="#b5dfaf2d00ca5ef3ed1a2aa7ec23c2db">
       <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
       <DigestValue>IUe324koV5/A8Q38Gj45i4jddX=</DigestValue> 
      </Reference>
     </SignedInfo>
     <SignatureValue>MDAwMDAwMGJ5dGVzLiBQbGVhc2UsIGQ=</SignatureValue>
     <KeyInfo><KeyName>DN=twitter.com, SN=identity, ID=cb231aa9a9...eaf43f</KeyName></KeyInfo>
    </Signature>
   </identityBundle>
  </identities>
 </section>
 <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
  <SignedInfo>
   <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1" /> 
   <Reference URI="#B">
    <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
    <DigestValue>UrXLDLBIta6skoV5/A8Q38GEw44=</DigestValue> 
   </Reference>
  </SignedInfo>
  <SignatureValue>MC0E~LE=</SignatureValue>
 </Signature>
</sectionBundle>
</peer>