Citiverse è uno spazio aperto a tutte le comunità. Se vuoi aprire un gruppo locale o una sezione per la tua organizzazione, puoi contattare gli amministratori: pagina dei contatti.
Dismissing HTTP Signature on presence of Object Integrity Proof
-
I have a question for implementors pursuing object integrity proofs.
I am implementing the ability to serve these proofs in NodeBB with the assistance of an LLM. It is adhering to @silverpill@mitra.social's FEP-8b32: Object Integrity Proofs.
As part of its work, it implemented a quirk I thought was curious. If the proof was present in an embedded object, the activity's HTTP signature was ignored/not-checked.
I challenged the model and it pointed to this line from the FEP...
> If both HTTP signature and integrity proof are used, the integrity proof MUST be given precedence over HTTP signature. The HTTP signature MAY be dismissed.
... and cited potential interop if someone were to send an activity with integrity proof but explicitly no HTTP signature. That is, if NodeBB were to implement a hard requirement for HTTP signatures, then that specific case would fail inbound checks.
My rationale is:
- The HTTP signature guarantees that the payload has not been modified in-transit, and
- The proof guarantees the authenticity of the payload, and
- This is doubly so for payloads belonging to separate origins
Am I incorrect? It would seem like we need to exercise both checks to ensure authenticity of the entire payload chain: activity and object.
Pinging other interested parties: @hongminhee@hollo.social @mike@macgirvin.com @pfefferle@mastodon.social @evan@cosocial.ca
-
Additional points:
- I know of no situation where an AP-compliant server POSTs another server without an HTTP Signature. Pretty sure any attempt to do so would just mean the activity is dropped.
So why does 8b32 allow for dropping the HTTP signature? My best guess is that the wording is vague and the intention is that an object integrity proof at top level means an HTTP signature can be discarded.
- Cross-origin activity-object combos are common. FEP 1b12 is built upon this, as are standard Mastodon Announce/boosts. To give up HTTP signature checks because an embedded object contains a proof means the wrapping activity is spoofable.
So I think the local LLM took that line very literally.
-
So why does 8b32 allow for dropping the HTTP signature? My best guess is that the wording is vague and the intention is that an object integrity proof at top level means an HTTP signature can be discarded.
You're right, the sentence was poorly written. It was meant to apply to top-level proofs only.
I'll update the FEP.
I know of no situation where an AP-compliant server POSTs another server without an HTTP Signature. Pretty sure any attempt to do so would just mean the activity is dropped.
Mitra would accept an activity with integrity proof if HTTP signature is not present.
-
@mario@hub.somaton.com @silverpill@mitra.social yeah, I get that if a top level proof is present, then the signature can be avoided.
I just meant in the absence of a proof and signature, it's just noise.
Ciao! Sembra che tu sia interessato a questa conversazione, ma non hai ancora un account.
Stanco di dover scorrere gli stessi post a ogni visita? Quando registri un account, tornerai sempre esattamente dove eri rimasto e potrai scegliere di essere avvisato delle nuove risposte (tramite email o notifica push). Potrai anche salvare segnalibri e votare i post per mostrare il tuo apprezzamento agli altri membri della comunità.
Con il tuo contributo, questo post potrebbe essere ancora migliore 💗
Registrati Accedi
Citiverse è un progetto che si basa su NodeBB ed è federato! | Categorie federate | Chat | 📱 Installa web app o APK | 🧡 Donazioni | Privacy Policy