web-dev-qa-db-ja.com

DERのオプションのNULLのエンコード

PKCS1 にはDigestInfoがあります：

  DigestInfo ::= SEQUENCE {
      digestAlgorithm AlgorithmIdentifier,
      digest OCTET STRING
  }

AlgorithmIdentifierは RFC528 で定義されています：

   AlgorithmIdentifier  ::=  SEQUENCE  {
        algorithm               OBJECT IDENTIFIER,
        parameters              ANY DEFINED BY algorithm OPTIONAL  }

PKCS1は、さまざまなハッシュアルゴリズム用にDigestInfoのDERエンコーディングを提供します 43ページ ：

   1. For the six hash functions mentioned in Appendix B.1, the DER
      encoding T of the DigestInfo value is equal to the following:

      MD2:     (0x)30 20 30 0c 06 08 2a 86 48 86 f7 0d 02 02 05 00 04
                   10 || H.
      MD5:     (0x)30 20 30 0c 06 08 2a 86 48 86 f7 0d 02 05 05 00 04
                   10 || H.
      SHA-1:   (0x)30 21 30 09 06 05 2b 0e 03 02 1a 05 00 04 14 || H.
      SHA-256: (0x)30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00
                   04 20 || H.
      SHA-384: (0x)30 41 30 0d 06 09 60 86 48 01 65 03 04 02 02 05 00
                   04 30 || H.
      SHA-512: (0x)30 51 30 0d 06 09 60 86 48 01 65 03 04 02 03 05 00
                      04 40 || H.

これらのDERエンコーディング（sha512）のいずれかでdo asn1parseを作成すると、次のようになります。

    0:d=0  hl=2 l=  81 cons: SEQUENCE
    2:d=1  hl=2 l=  13 cons:  SEQUENCE
    4:d=2  hl=2 l=   9 prim:   OBJECT            :sha512
   15:d=2  hl=2 l=   0 prim:   NULL
   17:d=1  hl=2 l=  64 prim:  OCTET STRING

アルゴリズムはOBJECTで示され、パラメーターはNULLで示されます。私の質問は...

パラメータがオプションの場合、なぜNULLが存在するのですか？ PKCS1で提供される文字列が、たとえばこれ（NULLなし）ではなく、上記のDERエンコーディングに対応するのはなぜですか？：

    0:d=0  hl=2 l=  79 cons: SEQUENCE
    2:d=1  hl=2 l=  11 cons:  SEQUENCE
    4:d=2  hl=2 l=   9 prim:   OBJECT            :sha512
   15:d=1  hl=2 l=  64 prim:  OCTET STRING
asn1pkcs1
3
neubert

引用された2つのRFCの情報は、NULLアフターアルゴリズムに関しては少し矛盾しているようです。

構造の全体的な定義では、parameters属性はオプションであると主張していますが、rsaEncryptionアルゴリズムに関する付録では、具体的には次のようになっています。

-- When rsaEncryption is used in an AlgorithmIdentifier the
-- parameters MUST be present and MUST be NULL.

そして同様に特定のハッシュアルゴリズム：

-- When the following OIDs are used in an AlgorithmIdentifier the
-- parameters MUST be present and MUST be NULL.
--
md2WithRSAEncryption       OBJECT IDENTIFIER ::= { pkcs-1 2 }
md5WithRSAEncryption       OBJECT IDENTIFIER ::= { pkcs-1 4 }
sha1WithRSAEncryption      OBJECT IDENTIFIER ::= { pkcs-1 5 }
sha256WithRSAEncryption    OBJECT IDENTIFIER ::= { pkcs-1 11 }
sha384WithRSAEncryption    OBJECT IDENTIFIER ::= { pkcs-1 12 }
sha512WithRSAEncryption    OBJECT IDENTIFIER ::= { pkcs-1 13 }

フィールドをオプションとして定義することは少しばかげているように見えますが、後でその存在と値を要求します。フィールドが省略される可能性のある他のアルゴリズムがあるかもしれませんが、これらのアルゴリズムは特にそれを必要としますか？

標準は、EMSA-PKCS1-v1_5セクションで混乱しているように見えます。このセクションでは、いくつかのアルゴリズムを使用したオプションのパラメーターについて説明しています。

-- When id-md2 and id-md5 are used in an AlgorithmIdentifier the
-- parameters MUST be present and MUST be NULL.

-- When id-sha1, id-sha256, id-sha384 and id-sha512 are used in an
-- AlgorithmIdentifier the parameters (which are optional) SHOULD
-- be omitted. However, an implementation MUST also accept
-- AlgorithmIdentifier values where the parameters are NULL.

ただし、このテキストの直後の例にはnullが含まれています。

sha1    HashAlgorithm ::= {
    algorithm   id-sha1,
    parameters  SHA1Parameters : NULL  -- included for compatibility
                                       -- with existing implementations
}

ドキュメントで調べたすべてのASN.1の例には、必須のオプションのnullが含まれているようです。 openssl（作成）とMozilla PKIX（検証： https://hg.mozilla.org/mozilla-central/rev/08032b8280c6 ）の両方の動作に基づいて、nulls-after-algorithmは必要とされる存在は元の構造定義に基づいて論じられることができ、nullは価値を追加しないように見えますが、ドキュメントの一般的に受け入れられている解釈。

更新：OpenSSLメーリングリストの投稿に遭遇しました https://mta.openssl.org/pipermail/openssl-dev/2015-January/000441.html この同じ問題を実際に説明している、そして解釈ロジックは、次のように（いくつかの履歴とともに）要約されているようです。

... declaring that in this particular case (optional parameters of
AlgorithmIdentifier) NULL is equivalent to (the same as) absent. In fact,
RFC 5754 (page 4) states that the correct encoding is omitting the empty
list altogether, but some uses defined their encoding as NULL, and it’s OK. 
It reveals some history of this duality:

The two alternatives arise from the loss of the OPTIONAL associated with the
algorithm identifier parameters when the 1988 syntax for
AlgorithmIdentifier was translated into the 1997 syntax.  Later, the
OPTIONAL was recovered via a defect report, but by then many people
thought that algorithm parameters were mandatory.  Because of this
history, some implementations encode parameters as a NULL element
while others omit them entirely.
2
metaclassing