Alexander Afanasyev | e280023 | 2013-11-27 02:24:14 +0000 | [diff] [blame] | 1 | .. _Signature: |
Alexander Afanasyev | eee8c25 | 2013-11-21 23:22:41 +0000 | [diff] [blame] | 2 | |
| 3 | Signature |
| 4 | --------- |
| 5 | |
Alexander Afanasyev | e280023 | 2013-11-27 02:24:14 +0000 | [diff] [blame] | 6 | NDN Signature is defined as two consecutive TLV blocks: ``SignatureInfo`` and ``SignatureValue``. |
| 7 | The following general considerations about SignatureInfo and SignatureValue blocks that apply for all signature types: |
Alexander Afanasyev | eee8c25 | 2013-11-21 23:22:41 +0000 | [diff] [blame] | 8 | |
Alexander Afanasyev | e280023 | 2013-11-27 02:24:14 +0000 | [diff] [blame] | 9 | 1. ``SignatureInfo`` is **included** in signature calculation and fully describes the signature, signature algorithm, and any other relevant information to obtain parent certificate(s), such as :ref:`KeyLocator` |
Alexander Afanasyev | eee8c25 | 2013-11-21 23:22:41 +0000 | [diff] [blame] | 10 | |
Alexander Afanasyev | e280023 | 2013-11-27 02:24:14 +0000 | [diff] [blame] | 11 | 2. ``SignatureValue`` is **excluded** from signature calculation and represent actual bits of the signature and any other supporting signature material. |
Alexander Afanasyev | eee8c25 | 2013-11-21 23:22:41 +0000 | [diff] [blame] | 12 | |
Alexander Afanasyev | e280023 | 2013-11-27 02:24:14 +0000 | [diff] [blame] | 13 | :: |
Alexander Afanasyev | eee8c25 | 2013-11-21 23:22:41 +0000 | [diff] [blame] | 14 | |
Alexander Afanasyev | e280023 | 2013-11-27 02:24:14 +0000 | [diff] [blame] | 15 | Signature ::= SignatureInfo |
| 16 | SignatureBits |
Alexander Afanasyev | eee8c25 | 2013-11-21 23:22:41 +0000 | [diff] [blame] | 17 | |
Alexander Afanasyev | e280023 | 2013-11-27 02:24:14 +0000 | [diff] [blame] | 18 | SignatureInfo ::= SIGNATURE-INFO-TYPE TLV-LENGTH |
| 19 | SignatureType |
| 20 | ... (SignatureType-specific TLVs) |
Alexander Afanasyev | eee8c25 | 2013-11-21 23:22:41 +0000 | [diff] [blame] | 21 | |
Alexander Afanasyev | 23c2e41 | 2014-02-12 19:53:48 +0000 | [diff] [blame] | 22 | SignatureValue ::= SIGNATURE-VALUE-TYPE TLV-LENGTH |
Jeff Thompson | d4225d4 | 2014-06-09 12:32:21 -0700 | [diff] [blame] | 23 | ... (SignatureType-specific TLVs and |
Alexander Afanasyev | e280023 | 2013-11-27 02:24:14 +0000 | [diff] [blame] | 24 | BYTE+ |
Alexander Afanasyev | eee8c25 | 2013-11-21 23:22:41 +0000 | [diff] [blame] | 25 | |
Alexander Afanasyev | e280023 | 2013-11-27 02:24:14 +0000 | [diff] [blame] | 26 | SignatureType |
| 27 | ~~~~~~~~~~~~~ |
Alexander Afanasyev | eee8c25 | 2013-11-21 23:22:41 +0000 | [diff] [blame] | 28 | |
Alexander Afanasyev | e280023 | 2013-11-27 02:24:14 +0000 | [diff] [blame] | 29 | :: |
Alexander Afanasyev | eee8c25 | 2013-11-21 23:22:41 +0000 | [diff] [blame] | 30 | |
Alexander Afanasyev | e280023 | 2013-11-27 02:24:14 +0000 | [diff] [blame] | 31 | SignatureType ::= SIGNATURE-TYPE-TYPE TLV-LENGTH |
| 32 | nonNegativeInteger |
Jeff Thompson | d4225d4 | 2014-06-09 12:32:21 -0700 | [diff] [blame] | 33 | |
Alexander Afanasyev | eee8c25 | 2013-11-21 23:22:41 +0000 | [diff] [blame] | 34 | |
Alexander Afanasyev | e280023 | 2013-11-27 02:24:14 +0000 | [diff] [blame] | 35 | This specification defines the following SignatureType values: |
Alexander Afanasyev | eee8c25 | 2013-11-21 23:22:41 +0000 | [diff] [blame] | 36 | |
Jeff Thompson | d4225d4 | 2014-06-09 12:32:21 -0700 | [diff] [blame] | 37 | +---------+----------------------------------------+-------------------------------------------------+ |
| 38 | | Value | Reference | Description | |
| 39 | +=========+========================================+=================================================+ |
| 40 | | 0 | :ref:`DigestSha256` | Integrity protection using SHA-256 digest | |
| 41 | +---------+----------------------------------------+-------------------------------------------------+ |
| 42 | | 1 | :ref:`SignatureSha256WithRsa` | Integrity and provenance protection using | |
| 43 | | | | RSA signature over a SHA-256 digest | |
| 44 | +---------+----------------------------------------+-------------------------------------------------+ |
| 45 | | 3 | :ref:`SignatureSha256WithEcdsa` | Integrity and provenance protection using | |
| 46 | | | | an ECDSA signature over a SHA-256 digest | |
| 47 | +---------+----------------------------------------+-------------------------------------------------+ |
| 48 | | 2,4-200 | | reserved for future assignments | |
| 49 | +---------+----------------------------------------+-------------------------------------------------+ |
| 50 | | >200 | | unassigned | |
| 51 | +---------+----------------------------------------+-------------------------------------------------+ |
Alexander Afanasyev | eee8c25 | 2013-11-21 23:22:41 +0000 | [diff] [blame] | 52 | |
Alexander Afanasyev | e280023 | 2013-11-27 02:24:14 +0000 | [diff] [blame] | 53 | .. +-------+----------------------------------------+-------------------------------------------------+ |
| 54 | .. | 2 | :ref:`SignatureSha256WithRsaAndMerkle` | Integrity and provenance protection using | |
| 55 | .. | | | RSA signature over SHA-256-Merkle-Hash digest. | |
| 56 | .. | | | | |
| 57 | .. | | | This signature type defines an aggregated | |
| 58 | .. | | | signing algorithm that reduces cost of signing | |
| 59 | .. | | | of a large segmented content (e.g., video file).| |
Alexander Afanasyev | eee8c25 | 2013-11-21 23:22:41 +0000 | [diff] [blame] | 60 | |
Alexander Afanasyev | e280023 | 2013-11-27 02:24:14 +0000 | [diff] [blame] | 61 | .. _DigestSha256: |
Alexander Afanasyev | eee8c25 | 2013-11-21 23:22:41 +0000 | [diff] [blame] | 62 | |
Alexander Afanasyev | e280023 | 2013-11-27 02:24:14 +0000 | [diff] [blame] | 63 | DigestSha256 |
| 64 | ^^^^^^^^^^^^ |
Alexander Afanasyev | eee8c25 | 2013-11-21 23:22:41 +0000 | [diff] [blame] | 65 | |
Alexander Afanasyev | e280023 | 2013-11-27 02:24:14 +0000 | [diff] [blame] | 66 | ``DigestSha256`` provides no provenance of a Data packet or any kind of guarantee that packet is from the original source. |
| 67 | This signature type is indended only for debug purposes and limited circumstances when it is necessary to protect only against unexpected modification during the transmition. |
| 68 | |
| 69 | ``DigestSha256`` is defined as a SHA256 hash of the :ref:`Name`, :ref:`MetaInfo`, :ref:`Content`, and :ref:`SignatureInfo <Signature>` TLVs: |
| 70 | |
| 71 | :: |
| 72 | |
| 73 | SignatureInfo ::= SIGNATURE-INFO-TYPE TLV-LENGTH(=3) |
| 74 | SIGNATURE-TYPE-TYPE TLV-LENGTH(=1) 0 |
| 75 | |
Alexander Afanasyev | 23c2e41 | 2014-02-12 19:53:48 +0000 | [diff] [blame] | 76 | SignatureValue ::= SIGNATURE-VALUE-TYPE TLV-LENGTH(=32) |
| 77 | BYTE+(=SHA256{Name, MetaInfo, Content, SignatureInfo}) |
Alexander Afanasyev | e280023 | 2013-11-27 02:24:14 +0000 | [diff] [blame] | 78 | |
| 79 | |
| 80 | .. _SignatureSha256WithRsa: |
| 81 | |
| 82 | SignatureSha256WithRsa |
| 83 | ^^^^^^^^^^^^^^^^^^^^^^ |
| 84 | |
| 85 | ``SignatureSha256WithRsa`` is the basic signature algorithm that MUST be supported by any NDN-compliant software. |
| 86 | As suggested by the name, it defines an RSA public key signature that is calculated over SHA256 hash of the :ref:`Name`, :ref:`MetaInfo`, :ref:`Content`, and :ref:`SignatureInfo <Signature>` TLVs. |
| 87 | |
| 88 | |
| 89 | :: |
| 90 | |
| 91 | SignatureInfo ::= SIGNATURE-INFO-TYPE TLV-LENGTH |
| 92 | SIGNATURE-TYPE-TYPE TLV-LENGTH(=1) 1 |
| 93 | KeyLocator |
| 94 | |
Alexander Afanasyev | 23c2e41 | 2014-02-12 19:53:48 +0000 | [diff] [blame] | 95 | SignatureValue ::= SIGNATURE-VALUE-TYPE TLV-LENGTH |
| 96 | BYTE+(=RSA over SHA256{Name, MetaInfo, Content, SignatureInfo}) |
Alexander Afanasyev | e280023 | 2013-11-27 02:24:14 +0000 | [diff] [blame] | 97 | |
Alexander Afanasyev | 16962fc | 2014-02-12 19:53:47 +0000 | [diff] [blame] | 98 | .. note:: |
| 99 | |
| 100 | SignatureValue size varies (typically 128 or 256 bytes) depending on the private key length used during the signing process. |
Alexander Afanasyev | e280023 | 2013-11-27 02:24:14 +0000 | [diff] [blame] | 101 | |
| 102 | This type of signature ensures strict provenance of a Data packet, provided that the signature verifies and signature issuer is authorized to sign the Data packet. |
Jeff Thompson | d4225d4 | 2014-06-09 12:32:21 -0700 | [diff] [blame] | 103 | The signature issuer is identified using :ref:`KeyLocator` block in :ref:`SignatureInfo <Signature>` block of ``SignatureSha256WithRsa``. |
Alexander Afanasyev | e280023 | 2013-11-27 02:24:14 +0000 | [diff] [blame] | 104 | See :ref:`KeyLocator section <KeyLocator>` for more detail. |
| 105 | |
| 106 | .. note:: |
| 107 | |
| 108 | It is application's responsibility to define rules (trust model) of when a specific issuer (KeyLocator) is authorized to sign a specific Data packet. |
| 109 | While trust model is outside the scope of the current specification, generally, trust model needs to specify authorization rules between KeyName and Data packet Name, as well as clearly define trust anchor(s). |
Jeff Thompson | d4225d4 | 2014-06-09 12:32:21 -0700 | [diff] [blame] | 110 | For example, an application can elect to use hierarchical trust model :cite:`testbed-key-management` to ensure Data integrity and provenance. |
Alexander Afanasyev | e280023 | 2013-11-27 02:24:14 +0000 | [diff] [blame] | 111 | |
| 112 | .. bibliography:: ndnspec-refs.bib |
| 113 | |
Jeff Thompson | d4225d4 | 2014-06-09 12:32:21 -0700 | [diff] [blame] | 114 | .. _SignatureSha256WithEcdsa: |
| 115 | |
| 116 | SignatureSha256WithEcdsa |
| 117 | ^^^^^^^^^^^^^^^^^^^^^^^^ |
| 118 | |
| 119 | ``SignatureSha256WithEcdsa`` defines an ECDSA public key signature that is calculated over the SHA256 hash of the :ref:`Name`, :ref:`MetaInfo`, :ref:`Content`, and :ref:`SignatureInfo <Signature>` TLVs. |
| 120 | The signature algorithm is defined in `[RFC5753], Section 2.1 <http://tools.ietf.org/html/rfc5753#section-2.1>`_. |
| 121 | |
| 122 | :: |
| 123 | |
| 124 | SignatureInfo ::= SIGNATURE-INFO-TYPE TLV-LENGTH |
| 125 | SIGNATURE-TYPE-TYPE TLV-LENGTH(=1) 3 |
| 126 | KeyLocator |
| 127 | |
| 128 | SignatureValue ::= SIGNATURE-VALUE-TYPE TLV-LENGTH |
| 129 | BYTE+(=ECDSA over SHA256{Name, MetaInfo, Content, SignatureInfo}) |
| 130 | |
| 131 | .. note:: |
| 132 | |
| 133 | The SignatureValue size depends on the private key length used during the signing process (about 63 bytes for a 224 bit key). |
| 134 | |
| 135 | This type of signature ensures strict provenance of a Data packet, provided that the signature verifies and the signature issuer is authorized to sign the Data packet. |
| 136 | The signature issuer is identified using the :ref:`KeyLocator` block in the :ref:`SignatureInfo <Signature>` block of the ``SignatureSha256WithEcdsa``. |
| 137 | A KeyLocatorDigest is defined over the DER encoding of the SubjectPublicKeyInfo for an EC key as defined by `RFC 5480 <http://www.ietf.org/rfc/rfc5480.txt>`_. |
| 138 | See the :ref:`KeyLocator section <KeyLocator>` for more detail. |
| 139 | |
| 140 | The value of ``SignatureValue`` of ``SignatureSha256WithEcdsa`` is a DER encoded DSA signature as defined in `Section 2.2.3 in RFC 3279 <http://tools.ietf.org/html/rfc3279#section-2.2.3>`_. |
| 141 | |
| 142 | :: |
| 143 | |
| 144 | Ecdsa-Sig-Value ::= SEQUENCE { |
| 145 | r INTEGER, |
| 146 | s INTEGER } |
| 147 | |
Alexander Afanasyev | e280023 | 2013-11-27 02:24:14 +0000 | [diff] [blame] | 148 | .. .. _SignatureSha256WithRsaAndMerkle: |
| 149 | |
| 150 | .. SignatureSha256WithRsaAndMerkle |
| 151 | .. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 152 | |
| 153 | .. :: |
| 154 | |
| 155 | .. SignatureInfo ::= SIGNATURE-INFO-TYPE TLV-LENGTH |
| 156 | .. SIGNATURE-TYPE-TYPE TLV-LENGTH(=1) 2 |
| 157 | .. KeyLocator |
| 158 | |
Alexander Afanasyev | 23c2e41 | 2014-02-12 19:53:48 +0000 | [diff] [blame] | 159 | .. SignatureValue ::= SIGNATURE-VALUE-TYPE TLV-LENGTH |
| 160 | .. BYTE+(=RSA over SHA256{Name, MetaInfo, Content, SignatureInfo}) |
Alexander Afanasyev | e280023 | 2013-11-27 02:24:14 +0000 | [diff] [blame] | 161 | .. Witness |
| 162 | |
| 163 | .. Witness ::= WITNESS-TYPE TLV-LENGTH BYTE+ |
| 164 | |
| 165 | .. _KeyLocator: |
| 166 | |
| 167 | KeyLocator |
| 168 | ~~~~~~~~~~ |
| 169 | |
| 170 | A ``KeyLocator`` specifies a name that points to another Data packet containing certificate or public key, or can be used by the specific trust model in another way to verify the the content. |
| 171 | |
| 172 | :: |
| 173 | |
Alexander Afanasyev | fffabfb | 2013-12-11 21:29:05 +0000 | [diff] [blame] | 174 | KeyLocator ::= KEY-LOCATOR-TYPE TLV-LENGTH KeyLocatorValue |
Alexander Afanasyev | e280023 | 2013-11-27 02:24:14 +0000 | [diff] [blame] | 175 | |
Alexander Afanasyev | fffabfb | 2013-12-11 21:29:05 +0000 | [diff] [blame] | 176 | KeyLocatorValue ::= Name | |
| 177 | KeyLocatorDigest | |
| 178 | ... |
| 179 | |
| 180 | KeyLocatorDigest ::= KEY-LOCATOR-DIGEST-TYPE TLV-LENGTH BYTE+ |
Alexander Afanasyev | e280023 | 2013-11-27 02:24:14 +0000 | [diff] [blame] | 181 | |
| 182 | .. note:: |
| 183 | |
| 184 | KeyLocator has meaning only for specific trust model and the current specification does not imply or suggest use of any specific trust model. |
Alexander Afanasyev | fffabfb | 2013-12-11 21:29:05 +0000 | [diff] [blame] | 185 | Generally, KeyLocator should point to another Data packet which is interpreted by the trust model, but trust model can allow alternative forms of the KeyLocator. |
Alexander Afanasyev | e280023 | 2013-11-27 02:24:14 +0000 | [diff] [blame] | 186 | |
| 187 | For example, one can define a trust model that does not interpret KeyLocator at all (KeyLocator MUST be present, but TLV-LENGTH could be 0) and uses naming conventions to infer proper public key or public key certificate for the name of the Data packet itself. |
Alexander Afanasyev | fffabfb | 2013-12-11 21:29:05 +0000 | [diff] [blame] | 188 | Another possibility for the trust model is to define digest-based KeyLocatorValue (``KeyLocatorDigest``), where RSA public key will be identified using SHA256 digest, assuming that the trust model has some other means to obtain the public key. |