signature: Rename KeyLocatorDigest into KeyDigest
Change-Id: Ide8cace988e95269ec057786fc80db8036984c7f
diff --git a/changelog.rst b/changelog.rst
index f402bbe..fac1e35 100644
--- a/changelog.rst
+++ b/changelog.rst
@@ -7,6 +7,7 @@
- **Signature**
+ New ``SignatureSha256WithEcdsa`` signature type for Elliptic Curve Digital Signature Algorithm (ECDSA)
+ + ``KeyLocatorDigest`` renamed to ``KeyDigest``. The specification now explicitly allows KeyDigest to be a SHA256 of any type of the key.
Since CCNx 0.7.2
----------------
diff --git a/signature.rst b/signature.rst
index e55ff85..c430c87 100644
--- a/signature.rst
+++ b/signature.rst
@@ -134,7 +134,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 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>`_.
+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>`_.
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>`_.
@@ -174,10 +174,10 @@
KeyLocator ::= KEY-LOCATOR-TYPE TLV-LENGTH KeyLocatorValue
KeyLocatorValue ::= Name |
- KeyLocatorDigest |
+ KeyDigest |
...
- KeyLocatorDigest ::= KEY-LOCATOR-DIGEST-TYPE TLV-LENGTH BYTE+
+ KeyDigest ::= KEY-DIGEST-TYPE TLV-LENGTH BYTE+
.. note::
@@ -185,4 +185,4 @@
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 (``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.
+ 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.
diff --git a/types.rst b/types.rst
index 53fca7f..082b947 100644
--- a/types.rst
+++ b/types.rst
@@ -69,7 +69,7 @@
+---------------------------------------------+-------------------+----------------+
| KeyLocator | 28 | 0x1c |
+---------------------------------------------+-------------------+----------------+
-| KeyLocatorDigest | 29 | 0x1d |
+| KeyDigest | 29 | 0x1d |
+---------------------------------------------+-------------------+----------------+
.. _type reservations:
@@ -97,5 +97,3 @@
.. _NDNLP header: http://redmine.named-data.net/projects/nfd/wiki/NDNLP-TLV
.. _LocalControlHeader: http://redmine.named-data.net/projects/nfd/wiki/LocalControlHeader
-
-