blob: c91c47d26230ebc632f8eadb25d9361c27e73e13 [file] [log] [blame]
Alexander Afanasyeve2800232013-11-27 02:24:14 +00001.. _Signature:
Alexander Afanasyeveee8c252013-11-21 23:22:41 +00002
3Signature
4---------
5
Alexander Afanasyeve2800232013-11-27 02:24:14 +00006NDN Signature is defined as two consecutive TLV blocks: ``SignatureInfo`` and ``SignatureValue``.
7The following general considerations about SignatureInfo and SignatureValue blocks that apply for all signature types:
Alexander Afanasyeveee8c252013-11-21 23:22:41 +00008
Alexander Afanasyeve2800232013-11-27 02:24:14 +000091. ``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 +000010
Alexander Afanasyeve2800232013-11-27 02:24:14 +0000112. ``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 +000012
Alexander Afanasyeve2800232013-11-27 02:24:14 +000013::
Alexander Afanasyeveee8c252013-11-21 23:22:41 +000014
Alexander Afanasyeve2800232013-11-27 02:24:14 +000015 Signature ::= SignatureInfo
16 SignatureBits
Alexander Afanasyeveee8c252013-11-21 23:22:41 +000017
Alexander Afanasyeve2800232013-11-27 02:24:14 +000018 SignatureInfo ::= SIGNATURE-INFO-TYPE TLV-LENGTH
19 SignatureType
20 ... (SignatureType-specific TLVs)
Alexander Afanasyeveee8c252013-11-21 23:22:41 +000021
Alexander Afanasyeve2800232013-11-27 02:24:14 +000022 SignatureValue ::= SIGNATURE-BITS-TYPE TLV-LENGTH
23 ... (SignatureType-specific TLVs and
24 BYTE+
Alexander Afanasyeveee8c252013-11-21 23:22:41 +000025
Alexander Afanasyeve2800232013-11-27 02:24:14 +000026SignatureType
27~~~~~~~~~~~~~
Alexander Afanasyeveee8c252013-11-21 23:22:41 +000028
Alexander Afanasyeve2800232013-11-27 02:24:14 +000029::
Alexander Afanasyeveee8c252013-11-21 23:22:41 +000030
Alexander Afanasyeve2800232013-11-27 02:24:14 +000031 SignatureType ::= SIGNATURE-TYPE-TYPE TLV-LENGTH
32 nonNegativeInteger
Alexander Afanasyeveee8c252013-11-21 23:22:41 +000033
Alexander Afanasyeveee8c252013-11-21 23:22:41 +000034
Alexander Afanasyeve2800232013-11-27 02:24:14 +000035This specification defines the following SignatureType values:
Alexander Afanasyeveee8c252013-11-21 23:22:41 +000036
Alexander Afanasyeve2800232013-11-27 02:24:14 +000037+-------+----------------------------------------+-------------------------------------------------+
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| 2-200 | | reserved for future assignments |
46+-------+----------------------------------------+-------------------------------------------------+
47| >200 | | unassigned |
48+-------+----------------------------------------+-------------------------------------------------+
Alexander Afanasyeveee8c252013-11-21 23:22:41 +000049
Alexander Afanasyeve2800232013-11-27 02:24:14 +000050.. +-------+----------------------------------------+-------------------------------------------------+
51.. | 2 | :ref:`SignatureSha256WithRsaAndMerkle` | Integrity and provenance protection using |
52.. | | | RSA signature over SHA-256-Merkle-Hash digest. |
53.. | | | |
54.. | | | This signature type defines an aggregated |
55.. | | | signing algorithm that reduces cost of signing |
56.. | | | of a large segmented content (e.g., video file).|
Alexander Afanasyeveee8c252013-11-21 23:22:41 +000057
Alexander Afanasyeve2800232013-11-27 02:24:14 +000058.. _DigestSha256:
Alexander Afanasyeveee8c252013-11-21 23:22:41 +000059
Alexander Afanasyeve2800232013-11-27 02:24:14 +000060DigestSha256
61^^^^^^^^^^^^
Alexander Afanasyeveee8c252013-11-21 23:22:41 +000062
Alexander Afanasyeve2800232013-11-27 02:24:14 +000063``DigestSha256`` provides no provenance of a Data packet or any kind of guarantee that packet is from the original source.
64This signature type is indended only for debug purposes and limited circumstances when it is necessary to protect only against unexpected modification during the transmition.
65
66``DigestSha256`` is defined as a SHA256 hash of the :ref:`Name`, :ref:`MetaInfo`, :ref:`Content`, and :ref:`SignatureInfo <Signature>` TLVs:
67
68::
69
70 SignatureInfo ::= SIGNATURE-INFO-TYPE TLV-LENGTH(=3)
71 SIGNATURE-TYPE-TYPE TLV-LENGTH(=1) 0
72
73 SignatureValue ::= BYTE{32}(=SHA256{Name, MetaInfo, Content, SignatureInfo})
74
75
76.. _SignatureSha256WithRsa:
77
78SignatureSha256WithRsa
79^^^^^^^^^^^^^^^^^^^^^^
80
81``SignatureSha256WithRsa`` is the basic signature algorithm that MUST be supported by any NDN-compliant software.
82As 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.
83
84
85::
86
87 SignatureInfo ::= SIGNATURE-INFO-TYPE TLV-LENGTH
88 SIGNATURE-TYPE-TYPE TLV-LENGTH(=1) 1
89 KeyLocator
90
91 SignatureValue ::= BYTE{32}(=RSA over SHA256{Name, MetaInfo, Content, SignatureInfo})
92
93
94This 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.
95The signature issuer is idenfified using :ref:`KeyLocator` block in :ref:`SignatureInfo <Signature>` block of ``SignatureSha256WithRsa``.
96See :ref:`KeyLocator section <KeyLocator>` for more detail.
97
98.. note::
99
100 It is application's responsibility to define rules (trust model) of when a specific issuer (KeyLocator) is authorized to sign a specific Data packet.
101 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).
102 For example, an application can elect to use hierarchical trust model :cite:`testbed-key-management` to ensure Data integrity and provenance.
103
104 .. bibliography:: ndnspec-refs.bib
105
106.. .. _SignatureSha256WithRsaAndMerkle:
107
108.. SignatureSha256WithRsaAndMerkle
109.. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
110
111.. ::
112
113.. SignatureInfo ::= SIGNATURE-INFO-TYPE TLV-LENGTH
114.. SIGNATURE-TYPE-TYPE TLV-LENGTH(=1) 2
115.. KeyLocator
116
117.. SignatureValue ::= BYTE{32}(=RSA over SHA256{Name, MetaInfo, Content, SignatureInfo})
118.. Witness
119
120.. Witness ::= WITNESS-TYPE TLV-LENGTH BYTE+
121
122.. _KeyLocator:
123
124KeyLocator
125~~~~~~~~~~
126
127A ``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.
128
129::
130
131 KeyLocator ::= KEY-LOCATOR-TYPE TLV-LENGTH Name
132
133
134.. note::
135
136 KeyLocator has meaning only for specific trust model and the current specification does not imply or suggest use of any specific trust model.
137 Generally, KeyLocator should point to another Data packet which is interpreted by the trust model, but trust model can allow alternative interpretations of the KeyLocator.
138
139 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.
140 Another possibility for the trust model is to define a naming convention for the KeyLocator, where Name ``/keyid/<sha256>`` identifies RSA public key using SHA256 digest, assuming that the trust model has some other means to obtain the public key.
141
Alexander Afanasyeveee8c252013-11-21 23:22:41 +0000142
143Changes from CCNx
144~~~~~~~~~~~~~~~~~
145
146- ``Signature`` is moved to the end of Data packet.
147
Alexander Afanasyeve2800232013-11-27 02:24:14 +0000148- ``KeyLocator`` is moved to be a part of the ``SignatureInfo`` block, if it is applicable for the specific signature type.
149 The rationale for the move is to make Signature (sequence of ``SignatureInfo`` and ``SignatureValue`` TLVs) self-contained and self-sufficient.
Alexander Afanasyeveee8c252013-11-21 23:22:41 +0000150
Alexander Afanasyeve2800232013-11-27 02:24:14 +0000151- ``KeyLocator`` is expressed as a trust model-interpreted name, removing nested blocks and alternative packet-format specified representations (``KeyName``, ``Key``, and ``Certificate``)
152
153- Signature type (or signing method information) is expressed as an assigned integer value (with no assumed default), rather than OID.
Alexander Afanasyeveee8c252013-11-21 23:22:41 +0000154
155- Added support for cheaper signatures
156
Alexander Afanasyeve2800232013-11-27 02:24:14 +0000157- The current specification does not define Merkle Hash Tree Aggregated Signatures, but it is expected that such (or similar) signatures will be defined in future version of this specification.