Zum Hauptinhalt springen

2.5. Creating the Signature Base (Erzeugung der Signaturbasis)

2.5. Creating the Signature Base (Erzeugung der Signaturbasis)​

Die Signaturbasis ist eine ASCII-Zeichenkette [ASCII] mit den kanonisierten HTTP-Nachrichtenkomponenten, die von der Signatur abgedeckt sind. Eingabe des Erzeugungsalgorithmus ist die geordnete Menge der abgedeckten Komponenten-Identifikatoren und ihrer zugehörigen Werte sowie die zusätzlichen Signaturparameter aus Abschnitt 2.3.

Komponenten-Identifikatoren werden mit den strikten Serialisierungsregeln aus [STRUCTURED-FIELDS], Abschnitt 4, serialisiert. Der Identifikator hat einen Komponentennamen als String-Item gemäß der ABNF-Regel sf-string und DARF definierte Parameter gemäß der ABNF-Regel parameters enthalten. Die Zeile der Signaturparameter (Abschnitt 2.3) folgt demselben Muster, aber der Komponenten-Identifier ist ein String-Item mit festem Wert ohne Parameter, und der Komponentenwert ist stets eine Inner List mit optionalen Parametern.

Die Serialisierung des Komponentennamens steht in doppelten Anführungszeichen; Parameter folgen semikolongetrennt, z. B. "cache-control", "@authority", "@signature-params" oder "example-dictionary";key="foo".

Die Ausgabe ist die geordnete Bytefolge der Signaturbasis mit folgender 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

Zur Erzeugung der Signaturbasis verkettet Signierender oder Verifizierender für jeden Komponenten-Identifier in den abgedeckten Komponenten (mit Parametern) gemäß folgendem Algorithmus. Alle beschriebenen Fehler MÜSSEN den Algorithmus sofort fehlschlagen lassen, ohne eine Signaturbasis auszugeben.

  1. Ausgabe als leere Zeichenkette initialisieren.

  2. Für jedes Nachrichtenkomponenten-Element in der Menge abgedeckter Komponenten (in Reihenfolge):

    2.1. Wurde der Komponenten-Identifier (inklusive Parameter) bereits zur Signaturbasis hinzugefügt, Fehler.

    2.2. Komponenten-Identifier gemäß ABNF-Regel component-identifier anhängen (Name in doppelten Anführungszeichen, Parameter außerhalb).

    2.3. Einen Doppelpunkt (:) anhängen.

    2.4. Ein Leerzeichen ( ) anhängen.

    2.5. Komponentenwert bestimmen:

    • Unbekannter Parameter → Fehler.

    • Gegensätzliche Parameter (z. B. bs und sf) → Fehler.

    • Parameter req und Zielnachricht ist Anfrage → Fehler.

    • Parameter req und Zielnachricht ist Antwort → Kontext ist die zugehörige Anfrage der Ziel-Antwort; sonst ist der Kontext die Zielnachricht.

    • Name beginnt mit @ → Wert gemäß Abschnitt 2.2 ableiten; unbekannter Name oder nicht ableitbar → Fehler.

    • Name beginnt nicht mit @ → HTTP-Feldwert gemäß Abschnitt 2.1 kanonisieren; Feld fehlt oder Wert im Kontext nicht verfügbar → Fehler.

    2.6. Kanonisierten Komponentenwert anhängen.

    2.7. Zeilenumbruch (\n) anhängen.

  3. Komponente der Signaturparameter (Abschnitt 2.3) gemäß signature-params-line anhängen:

    3.1. Identifier exakt "@signature-params" (mit Anführungszeichen).

    3.2. : anhängen.

    3.3. Leerzeichen anhängen.

    3.4. Kanonisierte Werte der Signaturparameter wie in Abschnitt 2.3 (Inner List mit Parametern).

  4. Enthält die Ausgabe Nicht-ASCII-Zeichen [ASCII], Fehler.

  5. Ausgabezeichenkette zurückgeben.

Kann ein abgedeckter Komponenten-Identifier nicht zu einem Komponentenwert in der Nachricht aufgelöst werden, MUSS die Implementierung einen Fehler erzeugen und keine Signaturbasis bilden. Dazu zählen unter anderem:

  • unbekannter Name abgeleiteter Komponente;

  • Feldname bezeichnet fehlendes oder fehlerhaft formatiertes Feld;

  • unbekannter oder auf den Identifier nicht anwendbarer Parameter;

  • sf-Parameter, obwohl kein Structured Field oder Typ unbekannt;

  • Dictionary-Mitglied-Identifier: Feld fehlt, kein Dictionary oder Wert fehlerhaft;

  • Dictionary-Mitglied oder benannter Query-Parameter: referenziertes Mitglied fehlt oder Wert fehlerhaft (z. B. "example-dict";key="c" bei Example-Dict: a=1, b=2).

Im folgenden nicht normativen Beispiel wird diese Anfrage signiert:

NOTE: '' Zeilenumbruch gemäß 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"}

Die abgedeckten Komponenten sind der Reihe nach die abgeleiteten Komponenten @method, @authority, @path sowie die Header-Felder Content-Digest, Content-Length und Content-Type. Die Signaturparameter umfassen den Erzeugungszeitstempel 1618884473 und den Schlüssel-Identifier test-key-rsa-pss. Es ist kein expliziter Parameter alg angegeben, da die Anwendung dem Verifizierenden den RSA-PSS-Algorithmus über den identifizierten Schlüssel zuordnet. Die Signaturbasis:

NOTE: '' Zeilenumbruch gemäß 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"

Abbildung 1: Nicht normatives Beispiel einer Signaturbasis

Die Beispiel-Signaturbasis enthält nicht den abschließenden Zeilenumbruch der Darstellung; dasselbe gilt für andere Beispiele in dieser Spezifikation.

Letztes Update am