Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Make all Multicodec / Multibase references non-normative. #42

Merged
merged 3 commits into from
Oct 12, 2023
Merged

Make all Multicodec / Multibase references non-normative. #42

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
4deff71
Make all Multicodec / Multibase references non-normative.
msporny Sep 27, 2023
b6aa1a8
Fix grammar in Multiformats references.
msporny Sep 28, 2023
668357b
Remove all non-normative references to IETF Multibase I-Ds.
msporny Oct 6, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
135 changes: 82 additions & 53 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -298,20 +298,33 @@ <h4>Multikey</h4>

<p>
The `publicKeyMultibase` property represents a Multibase-encoded Multikey
expression of a P-256 or P-384 public key. The encoding of a P-256 public key is
the two-byte prefix `0x8024` (the varint expression of `0x1200`) followed
by the 33-byte compressed public key data.
The 35-byte value is then encoded using base58-btc (`z`) as the prefix. The
encoding of a P-384 public key is the two-byte prefix `0x8124` (the varint
expression of `0x1201`) followed by the 49-byte compressed public key data.
The 51-byte value is then encoded using base58-btc (`z`) as the prefix. Any
other encodings MUST NOT be allowed.
expression of a P-256 or P-384 public key.
</p>

<p>
The Multikey encoding of a P-256
public key MUST start with the two-byte prefix `0x8024` (the varint expression
of `0x1200`) followed by the 33-byte compressed public key data. The resulting
35-byte value MUST then be encoded using the base-58-btc alphabet, according to
the <a data-cite="VC-DATA-INTEGRITY#multibase-0">Multibase</a> section in the
[[VC-DATA-INTEGRITY]] specification, and then prepended with the base-58-btc
Multibase header (`z`).
</p>

<p>
The encoding of a P-384 public key MUST start with the
two-byte prefix `0x8124` (the varint expression of `0x1201`) followed by the
49-byte compressed public key data. The resulting 51-byte value is then encoded
using the base-58-btc alphabet, according to the
<a data-cite="VC-DATA-INTEGRITY#multibase-0">Multibase</a> section in the
[[VC-DATA-INTEGRITY]] specification, and then prepended with the base-58-btc
Multibase header (`z`). Any other encodings MUST NOT be allowed.
</p>

<p class="advisement">
Developers are advised to not accidentally publish a representation of a private
key. Implementations of this specification will raise errors in the event of a
[[?MULTICODEC]] value other than `0x1200` or `0x1201` being used in a
Multicodec value other than `0x1200` or `0x1201` being used in a
`publicKeyMultibase` value.
</p>

Expand Down Expand Up @@ -372,17 +385,25 @@ <h4>Multikey</h4>
</pre>

<p>
The `secretKeyMultibase` property represents a Multibase-encoded Multikey
expression of a P-256 or P-384 secret key (also sometimes referred to
as a private key). The encoding of a P-256 secret key is
the two-byte prefix `0x8626` (the varint expression of `0x1306`) followed
by the 32-byte secret key data.
The 34-byte value is then base58-btc encoded and `z` is added as the prefix.

The encoding of a P-384 secret key is the two-byte prefix `0x8726` (the varint
expression of `0x1307`) followed by the 48-byte secret key data.
The 50-byte value is then base58-btc encoded and `z` is added as the prefix. Any
other encodings MUST NOT be allowed.
The `secretKeyMultibase` property represents a Multibase-encoded Multikey
expression of a P-256 or P-384 secret key (also sometimes referred to as a
private key).
</p>
<p>
The encoding of a P-256 secret key MUST start with the two-byte prefix `0x8626`
(the varint expression of `0x1306`) followed by the 32-byte secret key data. The
34-byte value MUST then be encoded using the base-58-btc alphabet, according to
the <a data-cite="VC-DATA-INTEGRITY#multibase-0">Multibase</a> section in the
[[VC-DATA-INTEGRITY]] specification, and then prepended with the base-58-btc
Multibase header (`z`). Any other encodings MUST NOT be allowed.
</p>
<p>
The encoding of a P-384 secret key is the two-byte prefix `0x8726` (the varint
expression of `0x1307`) followed by the 48-byte secret key data. The 50-byte
value MUST then be encoded using the base-58-btc alphabet, according to the
<a data-cite="VC-DATA-INTEGRITY#multibase-0">Multibase</a> section in the
[[VC-DATA-INTEGRITY]] specification, and then prepended with the base-58-btc
Multibase header (`z`). Any other encodings MUST NOT be allowed.
</p>

<p class="advisement">
Expand All @@ -399,8 +420,8 @@ <h4>Multikey</h4>
<h3>Proof Representations</h3>

<p>
This suite relies on detached digital signatures represented using [[MULTIBASE]]
and [[?MULTICODEC]].
This section details the proof representation formats that are defined by
this specification.
</p>

<section>
Expand Down Expand Up @@ -429,12 +450,15 @@ <h4>DataIntegrityProof</h4>
`controller`.
</p>
<p>
The value of the `proofValue` property of the proof MUST be an ECDSA signature produced
according to [[FIPS-186-5]] and SHOULD use the <em>deterministic</em> ECDSA
signature variant, produced according to [[FIPS-186-5]] using the curves and
hashes as specified in section <a href="#algorithms"></a>, encoded according to
section 7 of [[RFC4754]] (sometimes referred to as the IEEE P1363 format), and
serialized according to [[MULTIBASE]] using the base58-btc base encoding.
The value of the `proofValue` property of the proof MUST be an ECDSA signature
produced according to [[FIPS-186-5]] and SHOULD use the <em>deterministic</em>
ECDSA signature variant, produced according to [[FIPS-186-5]] using the curves
and hashes as specified in section <a href="#algorithms"></a>, encoded according
to section 7 of [[RFC4754]] (sometimes referred to as the IEEE P1363 format),
and encoded using the base-58-btc header and
alphabet as described in the
<a href="https://www.w3.org/TR/vc-data-integrity/#multibase-0">
Multibase section</a> of [[VC-DATA-INTEGRITY]].
</p>

<pre class="example nohighlight"
Expand Down Expand Up @@ -1985,9 +2009,12 @@ <h4>serializeBaseProofValue</h4>
CBOR-encode `components` and append it to `proofValue`.
</li>
<li>
Initialize `baseProof` to a string with the multibase-base64url-no-pad-encoding
of `proofValue`. That is, return a string starting with "u" and ending with the
base64url-no-pad-encoded value of `proofValue`.
Initialize `baseProof` to a string with the Multibase
base64url-no-pad-encoding of `proofValue` as described in the
<a href="https://www.w3.org/TR/vc-data-integrity/#multibase-0">
Multibase section</a> of [[VC-DATA-INTEGRITY]]. That is, return a string
starting with "`u`" and ending with the base64url-no-pad-encoded value of
`proofValue`.
</li>
<li>
Return `baseProof` as <em>base proof</em>.
Expand Down Expand Up @@ -2256,8 +2283,10 @@ <h4>serializeDerivedProofValue</h4>
</li>
<li>
Return the <em>derived proof</em> as a string with the
multibase-base64url-no-pad-encoding of `proofValue`. That is, return a string
starting with "u" and ending with the base64url-no-pad-encoded value of
base64url-no-pad-encoding of `proofValue` as described in the
<a href="https://www.w3.org/TR/vc-data-integrity/#multibase-0">
Multibase section</a> of [[VC-DATA-INTEGRITY]]. That is, return a string
starting with "`u`" and ending with the base64url-no-pad-encoded value of
`proofValue`.
</li>
</ol>
Expand Down Expand Up @@ -2945,8 +2974,8 @@ <h3>Representation: ecdsa-rdfc-2019, with curve P-256</h3>
<p>
The signer needs to generate a private/public key pair with the private key used
for signing and the public key made available for verification. The
[[MULTIBASE]]/[[?MULTICODEC]] representation for the public key, <code>p256-pub</code>,
and the representation for the private key, <code>p256-priv</code>, are shown below.
representation of the public key,
and the representation of the private key, are shown below.
</p>
<pre class="example nohighlight" title="Private and Public keys for Signature"
data-include="TestVectors/p256KeyPair.json"
Expand Down Expand Up @@ -2984,7 +3013,7 @@ <h3>Representation: ecdsa-rdfc-2019, with curve P-256</h3>

<p>
Finally, we concatenate the hash of the proof options followed by the hash of the credential without proof, use the private key with the combined hash to
compute the ECDSA signature, and then base58-btc encode the signature.
compute the ECDSA signature, and then base-58-btc encode the signature.
</p>

<pre class="example nohighlight" title="Combine hashes of Proof Options and Credential (hex)"
Expand All @@ -2993,13 +3022,13 @@ <h3>Representation: ecdsa-rdfc-2019, with curve P-256</h3>
<pre class="example nohighlight" title="Signature of Combined Hashes (hex)"
data-include="TestVectors/ecdsa-rdfc-2019-p256/sigHexECDSAP256.txt" data-include-format="text"></pre>

<pre class="example nohighlight" title="Signature of Combined Hashes base58-btc"
<pre class="example nohighlight" title="Signature of Combined Hashes base-58-btc"
data-include="TestVectors/ecdsa-rdfc-2019-p256/sigBTC58ECDSAP256.txt" data-include-format="text"></pre>

<p>Assemble the signed credential with the following two steps:</p>
<ol>
<li>
Add the <code>proofValue</code> field with the previously computed base58-btc
Add the <code>proofValue</code> field with the previously computed base-58-btc
value to the proof options document.
</li>
<li>
Expand All @@ -3016,8 +3045,8 @@ <h3>Representation: ecdsa-rdfc-2019, with curve P-384</h3>
<p>
The signer needs to generate a private/public key pair with the private key used
for signing and the public key made available for verification. The
[[MULTIBASE]]/[[?MULTICODEC]] representation for the public key, <code>p384-pub</code>,
and the representation for the private key, <code>p384-priv</code>, are shown below.
representation of the public key,
and the representation of the private key, are shown below.
</p>
<pre class="example nohighlight" title="Private and Public keys for Signature"
data-include="TestVectors/p384KeyPair.json"
Expand Down Expand Up @@ -3055,7 +3084,7 @@ <h3>Representation: ecdsa-rdfc-2019, with curve P-384</h3>

<p>
Finally, we concatenate the hash of the proof options followed by the hash of the credential without proof, use the private key with the combined hash to
compute the ECDSA signature, and then base58-btc encode the signature.
compute the ECDSA signature, and then base-58-btc encode the signature.
</p>

<pre class="example nohighlight" title="Combine hashes of Proof Options and Credential (hex)"
Expand All @@ -3064,13 +3093,13 @@ <h3>Representation: ecdsa-rdfc-2019, with curve P-384</h3>
<pre class="example nohighlight" title="Signature of Combined Hashes (hex)"
data-include="TestVectors/ecdsa-rdfc-2019-p384/sigHexECDSAP384.txt" data-include-format="text"></pre>

<pre class="example nohighlight" title="Signature of Combined Hashes base58-btc"
<pre class="example nohighlight" title="Signature of Combined Hashes base-58-btc"
data-include="TestVectors/ecdsa-rdfc-2019-p384/sigBTC58ECDSAP384.txt" data-include-format="text"></pre>

<p>Assemble the signed credential with the following two steps:</p>
<ol>
<li>
Add the <code>proofValue</code> field with the previously computed base58-btc
Add the <code>proofValue</code> field with the previously computed base-58-btc
value to the proof options document.
</li>
<li>
Expand All @@ -3087,8 +3116,8 @@ <h3>Representation: ecdsa-jcs-2019 with curve P-256</h3>
<p>
The signer needs to generate a private/public key pair with the private key used
for signing and the public key made available for verification. The
[[MULTIBASE]]/[[?MULTICODEC]] representation for the public key, <code>p256-pub</code>,
and the representation for the private key, <code>p256-priv</code>, are shown below.
representation of the public key,
and the representation of the private key, are shown below.
</p>
<pre class="example nohighlight" title="Private and Public keys for Signature"
data-include="TestVectors/p256KeyPair.json"
Expand Down Expand Up @@ -3126,7 +3155,7 @@ <h3>Representation: ecdsa-jcs-2019 with curve P-256</h3>

<p>
Finally, we concatenate the hash of the proof options followed by the hash of the credential without proof, use the private key with the combined hash to
compute the ECDSA signature, and then base58-btc encode the signature.
compute the ECDSA signature, and then base-58-btc encode the signature.
</p>

<pre class="example nohighlight" title="Combine hashes of Proof Options and Credential (hex)"
Expand All @@ -3135,13 +3164,13 @@ <h3>Representation: ecdsa-jcs-2019 with curve P-256</h3>
<pre class="example nohighlight" title="Signature of Combined Hashes (hex)"
data-include="TestVectors/ecdsa-jcs-2019-p256/sigHexJCSECDSAP256.txt" data-include-format="text"></pre>

<pre class="example nohighlight" title="Signature of Combined Hashes base58-btc"
<pre class="example nohighlight" title="Signature of Combined Hashes base-58-btc"
data-include="TestVectors/ecdsa-jcs-2019-p256/sigBTC58JCSECDSAP256.txt" data-include-format="text"></pre>

<p>Assemble the signed credential with the following two steps:</p>
<ol>
<li>
Add the <code>proofValue</code> field with the previously computed base58-btc
Add the <code>proofValue</code> field with the previously computed base-58-btc
value to the proof options document.
</li>
<li>
Expand All @@ -3158,8 +3187,8 @@ <h3>Representation: ecdsa-jcs-2019 with curve P-384</h3>
<p>
The signer needs to generate a private/public key pair with the private key used
for signing and the public key made available for verification. The
[[MULTIBASE]]/[[?MULTICODEC]] representation for the public key, <code>p384-pub</code>,
and the representation for the private key, <code>p384-priv</code>, are shown below.
representation of the public key,
and the representation of the private key, are shown below.
</p>
<pre class="example nohighlight" title="Private and Public keys for Signature"
data-include="TestVectors/p384KeyPair.json"
Expand Down Expand Up @@ -3197,7 +3226,7 @@ <h3>Representation: ecdsa-jcs-2019 with curve P-384</h3>

<p>
Finally, we concatenate the hash of the proof options followed by the hash of the credential without proof, use the private key with the combined hash to
compute the ECDSA signature, and then base58-btc encode the signature.
compute the ECDSA signature, and then base-58-btc encode the signature.
</p>

<pre class="example nohighlight" title="Combine hashes of Proof Options and Credential (hex)"
Expand All @@ -3206,13 +3235,13 @@ <h3>Representation: ecdsa-jcs-2019 with curve P-384</h3>
<pre class="example nohighlight" title="Signature of Combined Hashes (hex)"
data-include="TestVectors/ecdsa-jcs-2019-p384/sigHexJCSECDSAP384.txt" data-include-format="text"></pre>

<pre class="example nohighlight" title="Signature of Combined Hashes base58-btc"
<pre class="example nohighlight" title="Signature of Combined Hashes base-58-btc"
data-include="TestVectors/ecdsa-jcs-2019-p384/sigBTC58JCSECDSAP384.txt" data-include-format="text"></pre>

<p>Assemble the signed credential with the following two steps:</p>
<ol>
<li>
Add the <code>proofValue</code> field with the previously computed base58-btc
Add the <code>proofValue</code> field with the previously computed base-58-btc
value to the proof options document.
</li>
<li>
Expand Down