問題タブ [canonicalization]

私の問題は、このページのステップ 6、7、および 8 にあります: http://docs.aws.amazon.com/general/latest/gr/sigv4-create-canonical-request.html

手順 6 と 7 は簡単に実行できます。説明のために、無料のジェネレーターを使用できます: http://hash.online-convert.com/sha256-generator

Action=ListUsers&Version=2010-05-08b6359072c78d70ebee1e81adcbab4f01bf2c23245fa365ef83fe8f1f955085e2それが言うように、に変換します。しかし、同じアルゴリズムを使用するように指示されているステップ 8 では、

にはまったく変換さ3511de7e95d28ecd39e9513b642aee07e54f4941150d8df8bf94b328ef7e55e2れません。むしろ、私は得る8b483975a604a39ca8882bc11bc0101df17c9ecc64a96206e504babc614fcb37。例は私には非常に不明確です。間違った解釈をしている可能性が高いですが、どうですか？

次のようなコードがあります。

私が書いたとき：

それは返す

いいえ

大文字と小文字を区別する値を取得する方法はありますか?

コースデータベースで試験のために学習していますが、機能の依存関係に問題があります。

だから私は機能的な依存関係を得ました：

A->BE, AE->BD, F->CD, CD->BEF, CF->B

分解と左縮小の後、次のようになります。

A->B, A->E, A->D, F->B, F->C, F->D, CD->B, CD->E, CD->F

したがって、推移性を確認した後、解決策として得られます。

A-> BDE, F->CD, CD->BEF

しかし、それが正しいかどうかはわかりません。ここで、このチュートリアルと同じ手順を実行しました。

http://www.youtube.com/watch?v=lKYz5e7INTg

助けてくれてありがとう！

少しの WS-Security (XML 署名) を使用して単純な CXF クライアントとサーバーを作成しています。ここまでは順調ですね。

私が変更したいのは、正規化アルゴリズムEXCLUSIVE(C14N_EXCL_OMIT_COMMENTS aka " http://www.w3.org/2001/10/xml-exc-c14n# ") です。

Zend Framework 1.12、PHP 5.3.1 を使用。Zend_Mail に複数のメール受信者を指定し、Smtp トランスポートを使用すると、"To:" ヘッダーにはコンマで区切られた受信者のリストが含まれます。例えば

To: a@example.com,b@example.com

これは、 RFC 2822によると正しい構文のようです。DKIM 署名 ( https://github.com/louisameline/php-mail-signatureを使用) を追加しました。これは正常に機能し、gmail やその他の検証者が単一の To: 受信者で受け入れた署名を渡します。ただし、受信者が複数の場合、署名は失敗します。

署名付きメールを に送信check-auth@verifier.port25.comすると、さまざまなチェックの結果の中で、計算されたヘッダーと本文の正規化されたバージョンを含む電子メールが Return-path に返されます。To: ヘッダーを正規化するときに、各コンマの後にスペースが追加されていることがわかります (ヘッダーと本文の両方に緩和された正規化を指定しています)。実際、署名生成をハックして、To: ヘッダーを正規化するときにそのスペースを追加しました。これで問題が解決しました。port25.com ベリファイア、gmail などは署名を渡すようになりました。

しかし、 RFC 6376のセクション 3.4 をかなり注意深く読んだことや、上記で参照した github からダウンロードした署名クラスのコードなど、DKIM の緩和された正規化について私が見た説明では、何も追加されていない場所に空白を追加するものは何もありません。オリジナルに存在します。指定された正規化はすべて、既存の空白の変更に関するものです。

したがって、ポート 25 ベリファイアによって行われている正規化は、RFC 6376 と矛盾しているように思えます。ただし、gmail、autorespond+dkim-relaxed@dk.elandsys.com、およびhttp://www.appmaildevなどの他の DKIM ベリファイアは例外です。 com/en/dkim/はすべて最終結果に同意します (port25 のように実行した正規化は表示されませんが、カンマの後のスペースで正規化しないと、署名が拒否されます)。

ここに誰かがこれについて何か洞察を持っていますか? この分野での実践は、2011 年付けの RFC と一貫して異なるように見えるため、RFC を更新するべきではありませんか? もちろん、WSP を単一のスペースに置き換える前に、To: ヘッダー値のすべてのカンマをカンマ スペースに正規化する必要があるかどうか、および他のヘッダーが影響を受けるかどうかという問題もあります。

最終決議の概要

Evan の答えは OP に関して正確でした。私の MTA は、バリデーターの正規化ではなく、スペースを追加していました。実際に受信した To: ヘッダーを十分に注意深く見ていませんでした。

しかし、それを知っていても、正しい署名を生成するという問題を完全に簡単に解決できるわけではありません。「根本的な」問題は、Zend_Mail がヘッダー内のアドレスリストの値を生成する際に、カンマを区切り文字として使用して後続のスペースを使用しないことです。これは完全に有効な構文ですが、MTA がそれぞれの後にスペースを導入することも完全に有効です。また、RFC 6376 で指定され、広く実装されている緩和された正規化は、このような MTA の書き換えに対応していません。Zend_Mail のコードを変更してカンマ スペースを区切り記号として使用するのは簡単なことですが、それはかなり長くて複雑なメソッドの途中で行われるため、オーバーライドするためにコピー アンド ペーストを大量に行う必要があり、間違っていると感じられます。それで、私がやったことは、ヘッダーに署名する前にヘッダーにスペースを入れるプレフィルターを書くことでした。

この質問と同様に、SEPA コンテナ ファイルのドキュメント ハッシュ値を計算しようとしています。これは、私のコードが現在生成しているコンテナーです。

銀行提供のフォーマット チェック ツールによると、私のファイルはハッシュを除いてほとんど正しいです。PHP の SHA256 の実装にはおそらく問題がないので、ドキュメントを正規化するときに何か間違ったことをしていると思います。

問題のコードはかなり単純です。

$elementノードを含む DOMElement<Document>です。この関数は、コンテナ ファイルの作成中に呼び出されます。したがって、xmlns:xsiパラメータはノードに適用されません。ただし、手動で追加しても問題は改善されないようです。

生成されたハッシュは間違っています - 058098433DAC5D66ED34933CFFD98BF65CAD5C97CC45F9B0619B1FF96C3930E7 です。フォーマット チェッカーによる期待値は 942AB2F57DBAF6302EDC526472098DF38C540EB75E1913DAB0DF416D168C3253 です。ここで問題となるのは、私がここで何を間違っているのかということです。むしろ、銀行を喜ばせるために、XML をどのように操作しなければならないのかということです。

(残念ながら、正規化された XML はきれいな$textコード ブロックにはなりません。)

http://www.w3.org/TR/xml-exc-c14n/に従って XML を正規化する必要がある場合、次の XML の部分は等しくなりますか? （注、.文字は' 'スペースを表します）

と

つまり、Exclusive Canonicalization は空白を無視しますか? (またはインデントサイズを無視)

または、インデントは同じままにする必要がありますか? そして、最初のものはどうですか？<b>（秒の例から）の正規化されたバージョンは

また

また