blob: 9a0d7135f959fa39517e86db1ed45c046d900a4d [file] [log] [blame]
Zhiyi Zhang0c04fd82018-09-04 16:29:47 -04001Signature
2=========
3
Alexander Afanasyeve2800232013-11-27 02:24:14 +00004.. _Signature:
Alexander Afanasyeveee8c252013-11-21 23:22:41 +00005
Zhiyi Zhang0c04fd82018-09-04 16:29:47 -04006Data Signature
7--------------
Alexander Afanasyeveee8c252013-11-21 23:22:41 +00008
Zhiyi Zhang0c04fd82018-09-04 16:29:47 -04009NDN Data Signature is defined as two consecutive TLV blocks: ``SignatureInfo`` and ``SignatureValue``.
Alexander Afanasyeve2800232013-11-27 02:24:14 +000010The following general considerations about SignatureInfo and SignatureValue blocks that apply for all signature types:
Alexander Afanasyeveee8c252013-11-21 23:22:41 +000011
Zhiyi Zhang47e51372019-02-25 13:47:01 -0800121. ``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 Afanasyeveee8c252013-11-21 23:22:41 +000013
Alexander Afanasyeve2800232013-11-27 02:24:14 +0000142. ``SignatureValue`` is **excluded** from signature calculation and represent actual bits of the signature and any other supporting signature material.
Alexander Afanasyeveee8c252013-11-21 23:22:41 +000015
Alexander Afanasyev7455e9b2014-06-25 09:41:08 -070016The reason for separating the signature into two separate TLV blocks is to allow efficient signing of a contiguous memory block (e.g., for Data packet this block starts from Name TLV and ends with SignatureInfo TLV).
17
Alexander Afanasyeve2800232013-11-27 02:24:14 +000018::
Alexander Afanasyeveee8c252013-11-21 23:22:41 +000019
Alexander Afanasyeve2800232013-11-27 02:24:14 +000020 Signature ::= SignatureInfo
Alexander Afanasyev9e0791a2015-06-12 19:00:31 -070021 SignatureValue
Alexander Afanasyeveee8c252013-11-21 23:22:41 +000022
Alexander Afanasyeve2800232013-11-27 02:24:14 +000023 SignatureInfo ::= SIGNATURE-INFO-TYPE TLV-LENGTH
24 SignatureType
Alexander Afanasyev4b896112014-06-23 21:47:15 -070025 KeyLocator?
Alexander Afanasyeveee8c252013-11-21 23:22:41 +000026
Alexander Afanasyev23c2e412014-02-12 19:53:48 +000027 SignatureValue ::= SIGNATURE-VALUE-TYPE TLV-LENGTH
Zhiyi Zhang47e51372019-02-25 13:47:01 -080028 BYTE+
29
Zhiyi Zhang0c04fd82018-09-04 16:29:47 -040030.. _InterestSignature:
31
32Interest Signature
33------------------
34
35NDN Interest Signature is defined as two consecutive TLV blocks: ``InterestSignatureInfo`` and ``InterestSignatureValue``.
36
37To ensure uniqueness of the signed Interest name and to mitigate potential replay attacks, the ``InterestSignatureInfo`` element can include a ``SignatureNonce`` element, ``SignatureTime`` element, and/or ``SignatureSeqNum`` element.
38
39The cryptographic signature in the ``InterestSignatureValue`` element covers all the ``NameComponent`` elements inside ``Name`` up to but not including ``ParametersSha256DigestComponent`` component, and the complete TLVs starting from ``ApplicationParameters`` up until but not including ``InterestSignatureValue``.
40
41
42::
43
44 InterestSignatureInfo ::= INTEREST-SIGNATURE-INFO-TYPE TLV-LENGTH
45 SignatureType
46 KeyLocator?
47 SignatureNonce?
48 SignatureTime?
49 SignatureSeqNum?
50
51 InterestSignatureValue ::= INTEREST-SIGNATURE-VALUE-TYPE TLV-LENGTH
52 BYTE+
53
54Signature Elements
55------------------
Alexander Afanasyeveee8c252013-11-21 23:22:41 +000056
Alexander Afanasyeve2800232013-11-27 02:24:14 +000057SignatureType
58~~~~~~~~~~~~~
Alexander Afanasyeveee8c252013-11-21 23:22:41 +000059
Alexander Afanasyeve2800232013-11-27 02:24:14 +000060::
Alexander Afanasyeveee8c252013-11-21 23:22:41 +000061
Alexander Afanasyeve2800232013-11-27 02:24:14 +000062 SignatureType ::= SIGNATURE-TYPE-TYPE TLV-LENGTH
63 nonNegativeInteger
Jeff Thompsond4225d42014-06-09 12:32:21 -070064
Alexander Afanasyeveee8c252013-11-21 23:22:41 +000065
Alexander Afanasyeve2800232013-11-27 02:24:14 +000066This specification defines the following SignatureType values:
Alexander Afanasyeveee8c252013-11-21 23:22:41 +000067
Jeff Thompsond4225d42014-06-09 12:32:21 -070068+---------+----------------------------------------+-------------------------------------------------+
69| Value | Reference | Description |
70+=========+========================================+=================================================+
71| 0 | :ref:`DigestSha256` | Integrity protection using SHA-256 digest |
72+---------+----------------------------------------+-------------------------------------------------+
73| 1 | :ref:`SignatureSha256WithRsa` | Integrity and provenance protection using |
74| | | RSA signature over a SHA-256 digest |
75+---------+----------------------------------------+-------------------------------------------------+
76| 3 | :ref:`SignatureSha256WithEcdsa` | Integrity and provenance protection using |
77| | | an ECDSA signature over a SHA-256 digest |
78+---------+----------------------------------------+-------------------------------------------------+
Jeff Thompson29840e82015-04-06 15:21:21 -070079| 4 | :ref:`SignatureHmacWithSha256` | Integrity and provenance protection using |
80| | | SHA256 hash-based message authentication codes |
81+---------+----------------------------------------+-------------------------------------------------+
82| 2,5-200 | | reserved for future assignments |
Jeff Thompsond4225d42014-06-09 12:32:21 -070083+---------+----------------------------------------+-------------------------------------------------+
84| >200 | | unassigned |
85+---------+----------------------------------------+-------------------------------------------------+
Alexander Afanasyeveee8c252013-11-21 23:22:41 +000086
Alexander Afanasyev4b896112014-06-23 21:47:15 -070087.. _KeyLocator:
88
89KeyLocator
90~~~~~~~~~~
91
Alexander Afanasyev7455e9b2014-06-25 09:41:08 -070092A ``KeyLocator`` specifies either ``Name`` that points to another Data packet containing certificate or public key or ``KeyDigest`` to identify the public key within a specific trust model (the trust model definition is outside the scope of the current specification).
Alexander Afanasyev4b896112014-06-23 21:47:15 -070093Note that although ``KeyLocator`` is defined as an optional field in ``SignatureInfo`` block, some signature types may require presence of it and some require ``KeyLocator`` absence.
94
95::
96
97 KeyLocator ::= KEY-LOCATOR-TYPE TLV-LENGTH (Name | KeyDigest)
98
99 KeyDigest ::= KEY-DIGEST-TYPE TLV-LENGTH BYTE+
100
101See :ref:`Name specification <Name>` for the definition of Name field.
102
103The specific definition of the usage of ``Name`` and ``KeyDigest`` options in ``KeyLocator`` field is outside the scope of this specification.
104Generally, ``Name`` names the Data packet with the corresponding certificate.
105However, it is up to the specific trust model to define whether this name is a full name of the Data packet or a prefix that can match multiple Data packets.
106For example, the hierarchical trust model :cite:`testbed-key-management` uses the latter approach, requiring clients to fetch the latest version of the Data packet pointed by the KeyLocator (the latest version of the public key certificate) in order to ensure that the public key was not yet revoked.
107
Zhiyi Zhang47e51372019-02-25 13:47:01 -0800108.. _SignatureInfoNonce:
109
110SignatureNonce
111~~~~~~~~~~~~~~
112
113::
114
115 SignatureNonce ::= SIGNATURE-NONCE-TYPE TLV-LENGTH(=4)
116 BYTE{4}
117
118
119The ``SignatureNonce`` element adds additional assurances that a signature will be unique.
120
Zhiyi Zhang0c04fd82018-09-04 16:29:47 -0400121.. _SignatureTime:
Zhiyi Zhang47e51372019-02-25 13:47:01 -0800122
Zhiyi Zhang0c04fd82018-09-04 16:29:47 -0400123SignatureTime
124~~~~~~~~~~~~~
Zhiyi Zhang47e51372019-02-25 13:47:01 -0800125
126::
127
Zhiyi Zhang0c04fd82018-09-04 16:29:47 -0400128 SignatureTime ::= SIGNATURE-TIME-TYPE TLV-LENGTH
Zhiyi Zhang47e51372019-02-25 13:47:01 -0800129 nonNegativeInteger
130
131
Zhiyi Zhang0c04fd82018-09-04 16:29:47 -0400132The value of the ``SignatureTime`` element is the signature's timestamp (in terms of milliseconds since 1970-01-01 00:00:00 UTC) encoded as nonNegativeInteger.
133The ``SignatureTime`` element may be used to protect against replay attacks.
134
135.. _SignatureSeqNum:
136
137SignatureSeqNum
138~~~~~~~~~~~~~~~
139
140::
141
142 SignatureSeqNum ::= SIGNATURE-SEQ-NUM-TYPE TLV-LENGTH
143 nonNegativeInteger
144
145
146The ``SignatureSeqNum`` element adds additional assurances that a signature will be unique.
147The ``SignatureSeqNum`` may be used to protect against replay attacks.
148
Zhiyi Zhang47e51372019-02-25 13:47:01 -0800149
150Different Types of Signature
151~~~~~~~~~~~~~~~~~~~~~~~~~~~~
152
Zhiyi Zhang0c04fd82018-09-04 16:29:47 -0400153Each signature type has different requirements on the format of its ``SignatureInfo`` or ``InterestSignatureInfo`` element.
154In the following sections, these requirements are specified along 2 dimensions:
Zhiyi Zhang47e51372019-02-25 13:47:01 -0800155
156* The TLV-VALUE of ``SignatureType``
157* ``KeyLocator`` is required/forbidden
Zhiyi Zhang47e51372019-02-25 13:47:01 -0800158
Alexander Afanasyeve2800232013-11-27 02:24:14 +0000159.. _DigestSha256:
Alexander Afanasyeveee8c252013-11-21 23:22:41 +0000160
Alexander Afanasyeve2800232013-11-27 02:24:14 +0000161DigestSha256
162^^^^^^^^^^^^
Alexander Afanasyeveee8c252013-11-21 23:22:41 +0000163
Alexander Afanasyeve2800232013-11-27 02:24:14 +0000164``DigestSha256`` provides no provenance of a Data packet or any kind of guarantee that packet is from the original source.
Alexander Afanasyev4b896112014-06-23 21:47:15 -0700165This signature type is intended only for debug purposes and limited circumstances when it is necessary to protect only against unexpected modification during the transmission.
Alexander Afanasyeve2800232013-11-27 02:24:14 +0000166
167``DigestSha256`` is defined as a SHA256 hash of the :ref:`Name`, :ref:`MetaInfo`, :ref:`Content`, and :ref:`SignatureInfo <Signature>` TLVs:
168
Zhiyi Zhang47e51372019-02-25 13:47:01 -0800169* The TLV-VALUE of ``SignatureType`` is 0
170* ``KeyLocator`` is forbidden; if present, it must be ignored
Alexander Afanasyeve2800232013-11-27 02:24:14 +0000171
Zhiyi Zhang47e51372019-02-25 13:47:01 -0800172::
Alexander Afanasyeve2800232013-11-27 02:24:14 +0000173
Alexander Afanasyev23c2e412014-02-12 19:53:48 +0000174 SignatureValue ::= SIGNATURE-VALUE-TYPE TLV-LENGTH(=32)
175 BYTE+(=SHA256{Name, MetaInfo, Content, SignatureInfo})
Alexander Afanasyeve2800232013-11-27 02:24:14 +0000176
Zhiyi Zhang0c04fd82018-09-04 16:29:47 -0400177 InterestSignatureValue ::= INTEREST-SIGNATURE-VALUE-TYPE TLV-LENGTH(=32)
178 BYTE+(=SHA256{Name(without T, L, and ParametersSha256DigestComponent),
179 ApplicationParameters,
180 InterestSignatureInfo})
181
Alexander Afanasyeve2800232013-11-27 02:24:14 +0000182.. _SignatureSha256WithRsa:
183
184SignatureSha256WithRsa
185^^^^^^^^^^^^^^^^^^^^^^
186
187``SignatureSha256WithRsa`` is the basic signature algorithm that MUST be supported by any NDN-compliant software.
188As 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.
189
Zhiyi Zhang47e51372019-02-25 13:47:01 -0800190* The TLV-VALUE of ``SignatureType`` is 1
191* ``KeyLocator`` is required
Alexander Afanasyeve2800232013-11-27 02:24:14 +0000192
193::
194
Alexander Afanasyev23c2e412014-02-12 19:53:48 +0000195 SignatureValue ::= SIGNATURE-VALUE-TYPE TLV-LENGTH
196 BYTE+(=RSA over SHA256{Name, MetaInfo, Content, SignatureInfo})
Alexander Afanasyeve2800232013-11-27 02:24:14 +0000197
Zhiyi Zhang0c04fd82018-09-04 16:29:47 -0400198 InterestSignatureValue ::= INTEREST-SIGNATURE-VALUE-TYPE TLV-LENGTH(=32)
199 BYTE+(=RSA over SHA256{Name(without T, L, and ParametersSha256DigestComponent),
200 ApplicationParameters,
201 InterestSignatureInfo})
202
Alexander Afanasyev16962fc2014-02-12 19:53:47 +0000203.. note::
204
205 SignatureValue size varies (typically 128 or 256 bytes) depending on the private key length used during the signing process.
Alexander Afanasyeve2800232013-11-27 02:24:14 +0000206
207This 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 Thompsond4225d42014-06-09 12:32:21 -0700208The signature issuer is identified using :ref:`KeyLocator` block in :ref:`SignatureInfo <Signature>` block of ``SignatureSha256WithRsa``.
Alexander Afanasyev4b896112014-06-23 21:47:15 -0700209KeyDigest option in ``KeyLocator`` is defined as SHA256 digest over the DER encoding of the SubjectPublicKeyInfo for an RSA key as defined by `RFC 3279 <http://www.rfc-editor.org/rfc/rfc3279.txt>`_."
Alexander Afanasyeve2800232013-11-27 02:24:14 +0000210See :ref:`KeyLocator section <KeyLocator>` for more detail.
211
212.. note::
213
214 It is application's responsibility to define rules (trust model) of when a specific issuer (KeyLocator) is authorized to sign a specific Data packet.
215 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 Thompsond4225d42014-06-09 12:32:21 -0700216 For example, an application can elect to use hierarchical trust model :cite:`testbed-key-management` to ensure Data integrity and provenance.
Alexander Afanasyeve2800232013-11-27 02:24:14 +0000217
Jeff Thompsond4225d42014-06-09 12:32:21 -0700218.. _SignatureSha256WithEcdsa:
219
220SignatureSha256WithEcdsa
221^^^^^^^^^^^^^^^^^^^^^^^^
222
223``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.
224The signature algorithm is defined in `[RFC5753], Section 2.1 <http://tools.ietf.org/html/rfc5753#section-2.1>`_.
225
Zhiyi Zhang47e51372019-02-25 13:47:01 -0800226* The TLV-VALUE of ``SignatureType`` is 3
227* ``KeyLocator`` is required
Jeff Thompsond4225d42014-06-09 12:32:21 -0700228
Zhiyi Zhang47e51372019-02-25 13:47:01 -0800229::
Jeff Thompsond4225d42014-06-09 12:32:21 -0700230
231 SignatureValue ::= SIGNATURE-VALUE-TYPE TLV-LENGTH
232 BYTE+(=ECDSA over SHA256{Name, MetaInfo, Content, SignatureInfo})
233
Zhiyi Zhang0c04fd82018-09-04 16:29:47 -0400234 InterestSignatureValue ::= INTEREST-SIGNATURE-VALUE-TYPE TLV-LENGTH(=32)
235 BYTE+(=ECDSA over SHA256{Name(without T, L, and ParametersSha256DigestComponent),
236 ApplicationParameters,
237 InterestSignatureInfo})
238
Jeff Thompsond4225d42014-06-09 12:32:21 -0700239.. note::
240
241 The SignatureValue size depends on the private key length used during the signing process (about 63 bytes for a 224 bit key).
242
243This 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.
244The signature issuer is identified using the :ref:`KeyLocator` block in the :ref:`SignatureInfo <Signature>` block of the ``SignatureSha256WithEcdsa``.
Alexander Afanasyev4b896112014-06-23 21:47:15 -0700245KeyDigest option in ``KeyLocator`` is defined as SHA256 digest over the DER encoding of the SubjectPublicKeyInfo for an EC key as defined by `RFC 5480 <http://www.ietf.org/rfc/rfc5480.txt>`_.
Jeff Thompsond4225d42014-06-09 12:32:21 -0700246See the :ref:`KeyLocator section <KeyLocator>` for more detail.
247
248The 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>`_.
249
250::
251
252 Ecdsa-Sig-Value ::= SEQUENCE {
253 r INTEGER,
254 s INTEGER }
255
Jeff Thompson29840e82015-04-06 15:21:21 -0700256.. _SignatureHmacWithSha256:
257
258SignatureHmacWithSha256
259^^^^^^^^^^^^^^^^^^^^^^^
260
261``SignatureHmacWithSha256`` defines a hash-based message authentication code (HMAC) that is calculated over the :ref:`Name`, :ref:`MetaInfo`, :ref:`Content`, and :ref:`SignatureInfo <Signature>` TLVs, using SHA256 as the hash function, salted with a shared secret key.
262The signature algorithm is defined in `Section 2 in RFC 2104 <http://tools.ietf.org/html/rfc2104#section-2>`__.
263
Zhiyi Zhang47e51372019-02-25 13:47:01 -0800264* The TLV-VALUE of ``SignatureType`` is 4
265* ``KeyLocator`` is required
Jeff Thompson29840e82015-04-06 15:21:21 -0700266
Zhiyi Zhang47e51372019-02-25 13:47:01 -0800267::
Jeff Thompson29840e82015-04-06 15:21:21 -0700268
269 SignatureValue ::= SIGNATURE-VALUE-TYPE TLV-LENGTH(=32)
270 BYTE+(=HMAC{Name, MetaInfo, Content, SignatureInfo})
271
Zhiyi Zhang0c04fd82018-09-04 16:29:47 -0400272 InterestSignatureValue ::= INTEREST-SIGNATURE-VALUE-TYPE TLV-LENGTH(=32)
273 BYTE+(=HMAC{Name(without T, L, and ParametersSha256DigestComponent),
274 ApplicationParameters,
275 InterestSignatureInfo})
276
Jeff Thompson29840e82015-04-06 15:21:21 -0700277.. note::
278
279 The shared secret key is not included in the signature and must not be included anywhere in the data packet, as it would invalidate security properties of HMAC.
280
281.. note::
282
283 As stated in `Section 3 of RFC 2104 <http://tools.ietf.org/html/rfc2104#section-3>`__, shared keys shorter than the SHA256 output byte length (32 bytes) are strongly discouraged.
284
285Provided that the signature verifies, this type of signature ensures provenance that the Data packet was signed by one of the parties who holds the shared key.
286The shared key used to generate HMAC signature can be identified by the :ref:`KeyLocator` block in :ref:`SignatureInfo <Signature>`, e.g., by using the ``Name`` according to application's naming conventions.
287It is the application's responsibility to establish association between the shared key and the identities of the parties who hold the shared key.
288
Zhiyi Zhang47e51372019-02-25 13:47:01 -0800289.. bibliography:: ndnspec-refs.bib