signature: Defining KeyLocator as an optional field in generic SignatureInfo
Change-Id: I2e2850bdf5b1795c07aea208fe8c80c8b6df509f
diff --git a/signature.rst b/signature.rst
index c430c87..ad9defc 100644
--- a/signature.rst
+++ b/signature.rst
@@ -17,6 +17,7 @@
SignatureInfo ::= SIGNATURE-INFO-TYPE TLV-LENGTH
SignatureType
+ KeyLocator?
... (SignatureType-specific TLVs)
SignatureValue ::= SIGNATURE-VALUE-TYPE TLV-LENGTH
@@ -58,13 +59,35 @@
.. | | | signing algorithm that reduces cost of signing |
.. | | | of a large segmented content (e.g., video file).|
+
+.. _KeyLocator:
+
+KeyLocator
+~~~~~~~~~~
+
+A ``KeyLocator`` specifies either a 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).
+Note 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.
+
+::
+
+ KeyLocator ::= KEY-LOCATOR-TYPE TLV-LENGTH (Name | KeyDigest)
+
+ KeyDigest ::= KEY-DIGEST-TYPE TLV-LENGTH BYTE+
+
+See :ref:`Name specification <Name>` for the definition of Name field.
+
+The specific definition of the usage of ``Name`` and ``KeyDigest`` options in ``KeyLocator`` field is outside the scope of this specification.
+Generally, ``Name`` names the Data packet with the corresponding certificate.
+However, 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.
+For 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.
+
.. _DigestSha256:
DigestSha256
^^^^^^^^^^^^
``DigestSha256`` provides no provenance of a Data packet or any kind of guarantee that packet is from the original source.
-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.
+This signature type is intended only for debug purposes and limited circumstances when it is necessary to protect only against unexpected modification during the transmission.
``DigestSha256`` is defined as a SHA256 hash of the :ref:`Name`, :ref:`MetaInfo`, :ref:`Content`, and :ref:`SignatureInfo <Signature>` TLVs:
@@ -76,6 +99,8 @@
SignatureValue ::= SIGNATURE-VALUE-TYPE TLV-LENGTH(=32)
BYTE+(=SHA256{Name, MetaInfo, Content, SignatureInfo})
+Note that ``SignatureInfo`` does not require ``KeyLocator`` field, since there digest calculation and verification does not require any additional information.
+If ``KeyLocator`` is present in ``SignatureInfo``, it must be ignored.
.. _SignatureSha256WithRsa:
@@ -101,6 +126,7 @@
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.
The signature issuer is identified using :ref:`KeyLocator` block in :ref:`SignatureInfo <Signature>` block of ``SignatureSha256WithRsa``.
+KeyDigest 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>`_."
See :ref:`KeyLocator section <KeyLocator>` for more detail.
.. note::
@@ -109,8 +135,6 @@
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).
For example, an application can elect to use hierarchical trust model :cite:`testbed-key-management` to ensure Data integrity and provenance.
- .. bibliography:: ndnspec-refs.bib
-
.. _SignatureSha256WithEcdsa:
SignatureSha256WithEcdsa
@@ -134,7 +158,7 @@
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.
The signature issuer is identified using the :ref:`KeyLocator` block in the :ref:`SignatureInfo <Signature>` block of the ``SignatureSha256WithEcdsa``.
-A ``KeyDigest`` 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>`_.
+KeyDigest 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>`_.
See the :ref:`KeyLocator section <KeyLocator>` for more detail.
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>`_.
@@ -162,27 +186,4 @@
.. Witness ::= WITNESS-TYPE TLV-LENGTH BYTE+
-.. _KeyLocator:
-
-KeyLocator
-~~~~~~~~~~
-
-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.
-
-::
-
- KeyLocator ::= KEY-LOCATOR-TYPE TLV-LENGTH KeyLocatorValue
-
- KeyLocatorValue ::= Name |
- KeyDigest |
- ...
-
- KeyDigest ::= KEY-DIGEST-TYPE TLV-LENGTH BYTE+
-
-.. note::
-
- KeyLocator has meaning only for specific trust model and the current specification does not imply or suggest use of any specific trust model.
- 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.
-
- 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.
- Another possibility for the trust model is to define digest-based KeyLocatorValue (``KeyDigest``), where the key bits (e.g., RSA or ECDA public key bits or AES secret key bits) will be identified using a SHA256 digest, assuming that the trust model has some other means to obtain the public key.
+.. bibliography:: ndnspec-refs.bib