Passa al contenuto principale

2.5. Creating the Signature Base (Creazione della base della firma)

2.5. Creating the Signature Base (Creazione della base della firma)​

La base della firma è una stringa ASCII [ASCII] contenente le componenti del messaggio HTTP canonicalizzate coperte dalla firma. L'input dell'algoritmo di creazione è l'insieme ordinato degli identificatori delle componenti coperte e i valori associati, insieme ai parametri della firma aggiuntivi (Sezione 2.3).

Gli identificatori di componente sono serializzati con le regole strict di [STRUCTURED-FIELDS], Sezione 4. L'identificatore ha un nome di componente, Item String serializzato con la regola ABNF sf-string. L'identificatore PUÒ includere parametri serializzati con la regola ABNF parameters. La riga dei parametri della firma (Sezione 2.3) segue lo stesso schema, ma l'identificatore è un Item String con valore fisso senza parametri, e il valore della componente è sempre una Inner List con parametri opzionali.

Ciò implica che la serializzazione del nome della componente è tra virgolette doppie, con parametri dopo come elenco separato da punto e virgola, ad esempio "cache-control", "@authority", "@signature-params", o "example-dictionary";key="foo".

L'output è l'insieme ordinato di byte che forma la base della firma, conforme al seguente ABNF:

signature-base = *( signature-base-line LF ) signature-params-line
signature-base-line = component-identifier ":" SP ( derived-component-value / *field-content )
; no obs-fold nor obs-text
component-identifier = component-name parameters
component-name = sf-string
derived-component-value = *( VCHAR / SP )
signature-params-line = DQUOTE "@signature-params" DQUOTE ":" SP inner-list

Per creare la base, il firmatario o verificatore concatena voci per ogni identificatore nell'insieme delle componenti coperte (con i loro parametri) usando l'algoritmo seguente. Tutti gli errori descritti DEVONO far fallire immediatamente l'algoritmo, senza output di base.

  1. Sia l'output una stringa vuota.

  2. Per ogni elemento dell'insieme delle componenti coperte (in ordine):

2.1. Se l'identificatore (con parametri) è già stato aggiunto, produrre errore.

2.2. Appendere l'identificatore serializzato secondo la regola component-identifier (nome tra virgolette, parametri fuori).

2.3. Appendere ':'.

2.4. Appendere uno spazio.

2.5. Determinare il valore della componente.

  • Se l'identificatore ha un parametro non compreso, errore.

  • Se i parametri sono incompatibili tra loro (es. bs e sf), errore.

  • Se c'è req e il messaggio di destinazione è una richiesta, errore.

  • Se c'è req e il messaggio è una risposta, il contesto per il valore è la richiesta correlata alla risposta. Altrimenti il contesto è il messaggio di destinazione.

  • Se il nome inizia con @, derivare il valore secondo la Sezione 2.2. Se il nome derivato è sconosciuto o il valore non è derivabile, errore.

  • Se il nome non inizia con @, canonicalizzare il field value come Sezione 2.1. Se il campo manca o il valore non è ottenibile nel contesto, errore.

2.6. Appendere il valore canonicalizzato.

2.7. Appendere newline (\n).

  1. Appendere la componente dei parametri della firma (Sezione 2.3) secondo signature-params-line:

3.1. Identificatore esatto "@signature-params" (con virgolette).

3.2. ':'.

3.3. Spazio.

3.4. Valori canonicalizzati come Inner List con parametri (Sezione 2.3).

  1. Errore se l'output contiene caratteri non ASCII [ASCII].

  2. Restituire la stringa.

Se le componenti coperte referenziano un identificatore che non può essere risolto, l'implementazione DEVE produrre errore e non creare la base. Situazioni includono: nome derivato sconosciuto; campo assente o malformato; parametro sconosciuto o non applicabile; sf su campo non Structured Field o tipo sconosciuto; membro Dictionary assente o campo non Dictionary; membro o parametro di query nominato assente o malformato.

Esempio non normativo: messaggio firmato (richiesta):

NOTA: '\' per RFC 8792

POST /foo?param=Value&Pet=dog HTTP/1.1
Host: example.com
Date: Tue, 20 Apr 2021 02:07:55 GMT
Content-Type: application/json
Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T\
 aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
Content-Length: 18

{"hello": "world"}

Componenti coperte: @method, @authority, @path, poi Content-Digest, Content-Length, Content-Type. Parametri: created 1618884473, keyid test-key-rsa-pss. Nessun alg esplicito perché l'applicazione usa RSA-PSS dalla chiave identificata.

NOTA: '\' per RFC 8792

"@method": POST "@authority": example.com "@path": /foo "content-digest": sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX\ +TaPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==: "content-length": 18 "content-type": application/json "@signature-params": ("@method" "@authority" "@path" \ "content-digest" "content-length" "content-type")\ ;created=1618884473;keyid="test-key-rsa-pss"

Figura 1: Esempio non normativo di base della firma

L'esempio sopra non include il newline finale, come altre basi mostrate in questa specifica.

Ultimo aggiornamento il