ngerakines / atproto-rs Goto Github PK

Be able to parse and verify lexicons.

From my notes.

Three cryptographic systems have been proposed for use in atproto:

• p256 elliptic curve: aka “NIST P-256”, aka secp256r1 (note the r), aka prime256v1
  • supported in WebCrypto
• k256 elliptic curve: aka “NIST K-256”, aka secp256k1 (note the k)
  • used in Bitcoin, other cryptocurrencies
  • not in WebCrypto (?)
• Ed25519 elliptic curve
  • broad adoption
  • not currently in WebCrypto
  • not used or supported in atproto currently

Because of the subtle different when written out fully, when we refer to p256 and/or k256 we should either use the short names, or disambiguate in a comment.

for did:plc

Both p256 or k256 can be specified in did:plc operations and used to sign the genesis block (creating the did:plc itself). Signing and recovery keys can be any combination of the two.

The did:key encoding is used in both did:plc operations and in DID docs. This encoding includes metadata about the type of key, so they can be parsed and used unambiguously. The encoding process is:

• encode public key “point” as bytes. for p256 keys specifically, “encode” or “compress” (lossless) for shorter representation (same or roughly same final size as k2561 in this representation)
• prepend the appropriate per-key-type multicode indicator bytes in front of the key bytes:
  • p256: [0x80, 0x24]
  • k256: [0xE7, 0x01]
• encode the combined bytes as base58btc, yielding a string
• add did:key: as a prefix

For more about the p256 ”compression” see:

02, 03 or 04? So What Are Compressed and Uncompressed Public Keys?

For inclusion in DID Documents, the keys also need to be encoded in “multibase” format, under verificationMethod, field publicKeyMultibase. The encoding for that is:

• base58btc encoding of the key bytes. Do not compress p256 bytes in this context.
• add the character z as a prefix

The sibling JSON keys contain the context of which key type is being indicated:

• p256: EcdsaSecp256r1VerificationKey2019
• k256: EcdsaSecp256k1VerificationKey2019

for repo signing

The signing key indicated in the DID doc is used for signing and verification of repo root nodes.

As discussed above, in the current system the CommitNode DAG-CBOR object contains a CID (as a “Link”, meaning binary encoding) and signature (as bytes).

The signing key is used to sign the CID in binary representation. Not to be confused with the CID as a string then encoded in UTF-8. The signature is then stored as bytes.

The CommitNode itself then has a CID which may be referenced, for example as the root block in CAR file exports, or in XRPC sync APIs.

Note that the CommitNode, including the signature bytes inside it, has no metadata about which key was used for the signature, or what cryptography was used. This is discussed in the repo metadata node section.

Parse payloads and then apply lexicons against them to see if they validate.