Meta tags:
description= Public key cryptography and supported signature schemes over HTTP and JSON-LD.;
Headings (most frequently used words):
signatures, http, requests, creating, ld, verifying, security, signed, linked, data, sponsored, by, message, rfc9421, signing, post, and, the, digest, header,
Text of the page (most frequently used words):
the (101), signature (49), and (38), http (35), #signatures (34), mastodon (33), actor (28), key (26), https (24), example (24), request (22), for (18), headers (16), with (15), date (15), keyid (14), host (13), admin (13), that (12), your (12), header (12), target (12), this (11), com (11), type (10), users (10), username (10), signed (10), digest (10), main (9), public (8), following (8), json (8), org (8), using (8), profile (8), rfc9421 (7), content (7), when (6), not (6), uri (6), must (6), from (6), hash (6), 2019 (6), will (6), specification (6), message (6), y2fiyw (6), ixngrizdk4za (6), requests (6), www (6), activitystreams (6), get (6), object (5), base64 (5), creator (5), created (5), server (5), instance (5), are (5), within (5), data (5), support (5), security (5), like (5), string (5), application (5), dec (5), gmt (5), owner (4), has (4), value (4), publickey (4), signaturevalue (4), only (4), make (4), create (4), rsa (4), sha256 (4), creating (4), all (4), use (4), used (4), linked (4), context (4), app (4), components (4), method (4), enabled (4), inbox (4), post (4), signing (4), account (4), api (4), oauth (4), back (3), should (3), document (3), publickeypem (3), verify (3), sure (3), rsasignature2017 (3), uses (3), algorithm (3), verifying (3), attached (3), then (3), resulting (3), activities (3), relay (3), can (3), any (3), running (3), validating (3), was (3), draft (3), but (3), activitypub (3), implementing (3), more (3), supported (3), sha (3), 256 (3), parameters (3), input (3), default (3), note (3), you (3), accept (3), generate (3), search (3), preferences (3), apps (3), reports (3), accounts (3), setting (3), new (3), source (2), blog (2), points (2), same (2), does (2), reference (2), property (2), against (2), leaving (2), fetch (2), exists (2), keypair (2), into (2), sent (2), have (2), activity (2), servers (2), status (2), because (2), since (2), information (2), they (2), stage (2), define (2), been (2), which (2), spec (2), lib (2), list (2), libraries (2), about (2), rsassa (2), pkcs1 (2), v1_5 (2), present (2), derived (2), parameter (2), single (2), compatible (2), includes (2), called (2), sig1 (2), standard (2), above (2), separate (2), added (2), incoming (2), feature (2), flag (2), hello (2), consider (2), include (2), also (2), private (2), provided (2), hashed (2), looks (2), outbox (2), well (2), being (2), see (2), messages (2), sign (2), notificationpolicy (2), filter (2), report (2), quote (2), domainblock (2), notifications (2), trends (2), collections (2), domain_blocks (2), tokens (2), environment (2), posts (2), machine (2), installing (2), features (2), configuring (2), imprint, view, join, sponsored, last, updated, january, 2026, improve, page, some, point, establishing, directional, claim, fragment, material, associated, owning, extracted, processed, follows, decode, strip, s69f3mfddd99dgjmvjdjjs81e12jn121gkm1, 08t03, 901z, creates, signs, strict, encodes, output, derive, merged, accepting, optionally, subscribing, manually, refetch, origin, prevents, having, potentially, infinite, attempt, load, sequence, send, delete, known, peers, payload, available, receiving, process, locally, cached, longer, hosting, old, self, destruct, attaching, cryptographic, documents, widely, situations, current, implementation, outdated, due, change, between, drafting, finalization, expects, while, later, drafts, instead, via, namespace, furthermore, whole, superseded, largely, incompatible, earlier, reason, advised, implement, verifiable, credential, integrity, w3id, rsasignature2018, linked_data_signature, interactive, playground, sandbox, details, learn, please, refer, still, rfc9530, requirements, actual, timestamp, different, need, these, url, 1748341414, biggest, difference, described, two, required, removes, enables, http_message_signatures, implemented, overhauled, released, renamed, version, history, check, made, past, hours, compare, decoded, decrypted, resolve, construct, split, its, verifies, e37e179c75071a291f90a5fd4f848da87b491f1282f7bb8509ef2115b81ee0f4, controllers, concerns, signature_verification, hck0gzb1bm4r0eenyrj9clybuyxs, lemt5iwrymix0a, making, calculate, body, encoding, included, functionally, equivalent, saying, requesting, proving, their, final, don, care, won, specifying, constructed, values, defined, joined, newlines, typically, want, assumes, none, would, joinmastodon, 2018, how, friends, begin, nmiibijanbgkqhkig9w0baqefaaocaq8amiibcgkcaqeavxc4vkecu2, ceuso1wtn, nfoim94ne1jbmyxtz9wm2ytdjq1oizkif06i2foqdzy, s9uccre9bkajv1dnko, nvm31qjwlhvpskynvxewjvbo5ienue8gnd0xvhiuxf87o61poqjeoepvsqfela5ym, novljwgsa, jpj7ozyguzhcxtas2w5ad5tnbqupco0lhitypytjnmzcc4y2nbjv8hz, n2s2g8qkv8fyime23gy1xrpjg, crf, g4pqfxujjlj7mihd9oqtlgxbu7o1ciftn3x, nbfidpythwu5b4cujnsb3m3awjjvmx, mhq9sugksiyxv0ina77ctns0m2pyih1pfr, ntwidaqab, end, correspond, whose, equal, concatenated, together, encoded, keys, three, parts, broken, down, historically, proposed, way, cryptographically, requires, order, validate, received, authored, generating, secure, mode, require, cryptography, schemes, over, webpushsubscription, translation, token, termsofservice, tag, suggestion, statussource, statusedit, shallowtag, shallowquote, scheduledstatus, rule, role, relationshipseveranceevent, relationship, reaction, quoteapproval, privacypolicy, previewcardauthor, previewcard, poll, notificationrequest, notificationfallback, notification, mediaattachment, marker, identityproof, filterstatus, filterresult, filterkeyword, featuredtag, featureapproval, familiarfollowers, extendeddescription, error, customemoji, conversation, collectionwithaccounts, collectionitem, collection, asyncrefresh, appeal, annualreport, announcement, measure, ipblock, emaildomainblock, domainallow, dimension, cohort, canonicalemailblock, accountwarning, entities, streaming, markers, lists, conversations, timelines, scheduled_statuses, polls, media, statuses, proofs, oembed, push, directory, custom_emojis, announcements, health, grouped, async_refreshes, emails, annual, retention, measures, ip_blocks, email_domain_blocks, domain_allows, dimensions, canonical_email_blocks, tags, suggestions, mutes, followed_tags, follow_requests, filters, featured_tags, favourites, endorsements, bookmarks, blocks, methods, rate, limits, scopes, guidelines, best, practices, datetime, formats, rest, bearcaps, microformats, webfinger, compliance, design, themes, css, styling, state, management, frontend, guide, issues, responsible, disclosure, routes, code, structure, dev, technical, overview, contributing, implementations, logging, obtaining, client, access, playing, getting, started, developing, roles, webhooks, database, index, corruption, troubleshooting, errors, moderation, actions, scaling, migrating, backing, upgrading, release, cli, captcha, onion, services, storage, optional, full, text, preparing, own, official, ios, android, moving, externally, settings, set, promoting, yourself, others, dealing, unwanted, quoting, other, network, posting, what, documentation,
Text of the page (random words):
security mastodon documentation what is mastodon using mastodon signing up for an account setting up your profile posting to your profile using the network features quoting other posts dealing with unwanted content promoting yourself and others set your preferences more settings using mastodon externally moving or leaving accounts official ios and android apps running your own server running mastodon preparing your machine installing from source configuring your environment configuring full text search installing optional features object storage onion services captcha single sign on setting up your new instance using the admin cli upgrading to a new release backing up your server migrating to a new machine scaling up your server moderation actions troubleshooting errors database index corruption webhooks roles developing mastodon apps getting started with the api playing with public data obtaining client app access logging in with an account libraries and implementations implementing quote posts implementing collections contributing to mastodon technical overview setting up a dev environment code structure routes security issues and responsible disclosure frontend guide components state management css and styling creating themes design tokens reference spec compliance activitypub webfinger security microformats oauth bearcaps rest api datetime formats guidelines and best practices oauth tokens oauth scopes rate limits api methods accounts blocks bookmarks domain_blocks endorsements favourites featured_tags filters follow_requests followed_tags mutes preferences reports suggestions tags admin accounts canonical_email_blocks dimensions domain_allows domain_blocks email_domain_blocks ip_blocks measures reports retention trends annual reports apps emails oauth async_refreshes collections grouped notifications health instance announcements custom_emojis directory trends notifications push oembed profile proofs search statuses media polls scheduled_statuses timelines conversations lists markers streaming api entities account accountwarning admin account admin canonicalemailblock admin cohort admin dimension admin domainallow admin domainblock admin emaildomainblock admin ip admin ipblock admin measure admin report announcement annualreport appeal application asyncrefresh collection collectionitem collectionwithaccounts context conversation customemoji domainblock error extendeddescription familiarfollowers featureapproval featuredtag filter filterkeyword filterresult filterstatus identityproof instance list marker mediaattachment notification notificationfallback notificationpolicy notificationrequest poll preferences previewcard previewcardauthor privacypolicy profile quote quoteapproval reaction relationship relationshipseveranceevent report role rule scheduledstatus search shallowquote shallowtag status statusedit statussource suggestion tag termsofservice token translation v1 filter v1 instance v1 notificationpolicy webpushsubscription security public key cryptography and supported signature schemes over http and json ld signed http requests http signatures http message signatures rfc9421 linked data signatures creating ld signatures verifying ld signatures signed http requests app lib request rb http signature headers are a way to cryptographically sign http messages mastodon requires the use of http signatures in order to validate that any activity received was authored by the actor generating it when secure mode is enabled all get requests require http signatures as well http signatures historically mastodon uses a proposed draft standard called http signatures this is a specification for signing http messages by using a signature header with your http request for any http request incoming to mastodon the signature header should be attached signature keyid https my example com actor main key headers request target host date signature y2fiyw ixngrizdk4za the three parts of the signature header can be broken down like so signature keyid https my example com actor main key headers request target host date signature y2fiyw ixngrizdk4za the keyid should correspond to the actor and the key being used to generate the signature whose value is equal to all parameters in headers concatenated together and signed by the key then base64 encoded see activitypub public key for more information on actor keys an example key looks like this publickey id https my example com actor main key owner https my example com actor publickeypem begin public key nmiibijanbgkqhkig9w0baqefaaocaq8amiibcgkcaqeavxc4vkecu2 ceuso1wtn nfoim94ne1jbmyxtz9wm2ytdjq1oizkif06i2foqdzy 4q s9uccre9bkajv1dnko nvm31qjwlhvpskynvxewjvbo5ienue8gnd0xvhiuxf87o61poqjeoepvsqfela5ym novljwgsa jpj7ozyguzhcxtas2w5ad5tnbqupco0lhitypytjnmzcc4y2nbjv8hz n2s2g8qkv8fyime23gy1xrpjg crf g4pqfxujjlj7mihd9oqtlgxbu7o1ciftn3x nbfidpythwu5b4cujnsb3m3awjjvmx mhq9sugksiyxv0ina77ctns0m2pyih1pfr ntwidaqab n end public key n see also https blog joinmastodon org 2018 07 how to make friends and verify requests creating http signatures to create an http signature you will have to define which headers are being hashed and signed for example consider the following get request get users username outbox http 1 1 host mastodon example date 18 dec 2019 10 08 46 gmt accept application ld json profile https www w3 org ns activitystreams the signature string is constructed using the values of the http headers defined in headers joined by newlines typically you will want to include the request target as well as the host and the date mastodon assumes date header if none are provided for the above get request to generate a signature with headers request target host date we would generate the following string request target get users username outbox host mastodon example date 18 dec 2019 10 08 46 gmt note that we don t care about the accept header because we won t be specifying it in headers the signature string is then hashed with rsa sha256 rsassa pkcs1 v1_5 with sha 256 and signed with the actor s private key the resulting value is attached as signature within the signature header the final request looks like this get users username inbox http 1 1 host mastodon example date 18 dec 2019 10 08 46 gmt accept application ld json profile https www w3 org ns activitystreams signature keyid https my example com actor main key headers request target host date signature y2fiyw ixngrizdk4za this request is functionally equivalent to saying that https my example com actor is requesting https mastodon example users username inbox and is proving that they sent this request by signing request target host and date with their private key linked at keyid resulting in the provided signature signing post requests and the digest header when making a post request to mastodon you must calculate the rsa sha256 digest hash of your request s body and include this hash in base64 encoding within the digest header the digest header must also be included within the headers parameter of the signature header for example post users username inbox http 1 1 host mastodon example date 18 dec 2019 10 08 46 gmt digest sha 256 hck0gzb1bm4r0eenyrj9clybuyxs lemt5iwrymix0a signature keyid https my example com actor main key headers request target host date digest signature y2fiyw ixngrizdk4za content type application ld json profile https www w3 org ns activitystreams context https www w3 org ns activitystreams actor https my example com actor type create object type note content hello to https mastodon example users username verifying http signatures app controllers concerns signature_verification rb consider the following request post users username inbox http 1 1 host mastodon example date 18 dec 2019 10 08 46 gmt digest e37e179c75071a291f90a5fd4f848da87b491f1282f7bb8509ef2115b81ee0f4 signature keyid https my example com actor main key headers request target host date digest signature y2fiyw ixngrizdk4za content type application ld json profile https www w3 org ns activitystreams context https www w3 org ns activitystreams actor https my example com actor type create object type note content hello to https mastodon example users username mastodon verifies the signature using the following algorithm split signature into its separate parameters construct the signature string from the value of headers fetch the keyid 1 and resolve to an actor s publickey rsa sha256 hash the signature string and compare to the base64 decoded signature as decrypted by publickey publickeypem use the date header to check that the signed request was made within the past 12 hours http message signatures rfc9421 version history 4 4 0 added support for validating signatures but not enabled by default 4 5 0 enabled support for validating signatures by default since mastodon implemented http signatures this draft specification has been overhauled released as rfc9421 and renamed to http message signatures mastodon 4 4 0 added support for incoming http requests to be signed with rfc9421 compatible signatures but required the http_message_signatures feature flag to be enabled mastodon 4 5 0 removes the feature flag and enables this support by default the biggest difference to the http signatures standard described above is that http message signatures use two separate http headers signature and signature input signature input sig1 method target uri content digest created 1748341414 keyid https my example com actor main key signature sig1 y2fiyw ixngrizdk4za signature input includes parameters like the keyid and a created timestamp and the different components that need to be signed these can be http headers and so called derived components like the http method method or url target uri used for the request signature only includes the actual signature s mastodon has the following requirements for rfc9421 compatible signatures only a single signature is supported the created parameter must be present the method and target uri derived components must be signed a content digest header rfc9530 must be present and signed the only supported algorithm is still rsassa pkcs1 v1_5 using sha 256 to learn more about http message signatures please refer to rfc9421 for all the details http message signatures sandbox for an interactive playground and a list of libraries implementing rfc9421 linked data signatures app lib activitypub linked_data_signature rb mastodon s current implementation of ld signatures is outdated due to a change in the json ld context between the drafting stage and finalization stage of the specification mastodon expects a type of rsasignature2017 while later drafts instead define rsasignature2018 via the namespace https w3id org security v2 furthermore the ld signatures specification as a whole has been superseded by the verifiable credential data integrity 1 0 specification which is largely incompatible with the earlier ld signature spec for this reason it is not advised to implement support for ld signatures linked data signatures 1 0 was a draft specification for attaching cryptographic signatures to json ld documents ld signatures are not used widely within mastodon but they are used in the following situations when running a self destruct sequence to send delete activities to all known peers the payload will use ld signatures because http signatures will not be available receiving servers will process the signature by validating it against the locally cached actor key since the http server will no longer be hosting old actor information when accepting activities from a relay public activities can optionally be sent to a relay with ld signatures and any server subscribing to a relay does not have to manually refetch the activity from the origin this prevents having potentially infinite servers attempt to load the status from your instance creating ld signatures to create a signature mastodon uses the keypair attached to an actor at https mastodon example users username main key it then creates an rsa sha256 hash of the document signs it with the keypair and base64 strict encodes the resulting output to derive a signaturevalue the following hash is merged into the json ld document signature type rsasignature2017 creator https mastodon example users username main key created 2019 12 08t03 48 33 901z signaturevalue s69f3mfddd99dgjmvjdjjs81e12jn121gkm1 verifying ld signatures to verify a signature mastodon uses the following algorithm make sure that a signature exists and is a hash make sure that signature type is rsasignature2017 fetch the signature creator uri make sure the creator exists strip type id and signaturevalue from the signature leaving only signature creator and signature created base64 decode the signaturevalue and verify it against the public key in signature creator the keyid does not reference the publickeypem property the key material it is a uri for the publickey object associated with the actor that public key object has an owner property that must be the uri of the owning actor the extracted keyid value is processed as follows when the keyid is an actor and fragment actor key the owner points back to the same document actor when the keyid is a key key the owner points back to some actor and that actor should point back to the same key establishing a bi directional claim ︎ last updated january 16 2026 improve this page sponsored by join mastodon blog view source cc by sa 4 0 imprint
|
