RFC 9044 - Using the AES-GMAC Algorithm with the Cryptographic Message Syntax (CMS) 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc9044.html
タイトル : RFC 9044 - 暗号メッセージ構文（CMS）を使用したAES-GMACアルゴリズムを使用する
翻訳編集 : 自動生成

[要約] RFC 9044は、AES-GMACアルゴリズムをCryptographic Message Syntax (CMS)で使用する方法について説明しています。この文書の目的は、デジタル署名やメッセージ認証のために、AES-GMACをCMSフレームワーク内で効果的に利用するためのガイドラインを提供することです。主に、セキュアなメッセージング、データの完全性保証、および認証の文脈で利用されます。関連するRFCには、RFC 5652（CMSに関する基本的な仕様）、RFC 5084（AES-GCMとCMSの使用に関するもの）、およびRFC 5288（TLSでのAES-GCMの使用に関するもの）があります。これらの文書と合わせて、RFC 9044はセキュリティ強化されたデータ交換のための重要な基盤を提供します。

Internet Engineering Task Force (IETF)                        R. Housley
Request for Comments: 9044                                Vigil Security
Category: Standards Track                                      June 2021
ISSN: 2070-1721

Using the AES-GMAC Algorithm with the Cryptographic Message Syntax (CMS)

暗号メッセージ構文（CMS）を使用したAES-GMACアルゴリズムを使用する

Abstract

概要

This document specifies the conventions for using the AES-GMAC Message Authentication Code algorithm with the Cryptographic Message Syntax (CMS) as specified in RFC 5652.

このドキュメントは、RFC 5652で指定されている暗号メッセージ構文（CMS）を使用してAES-GMACメッセージ認証コードアルゴリズムを使用するための規則を指定します。

Status of This Memo

本文書の位置付け

This is an Internet Standards Track document.

これはインターネット規格のトラック文書です。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9044.

この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9044で入手できます。

著作権表示

著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。

Table of Contents

   1.  Introduction
   2.  Terminology
   3.  Message Authentication Code Algorithms
     3.1.  AES-GMAC
   4.  Implementation Considerations
   5.  ASN.1 Module
   6.  IANA Considerations
   7.  Security Considerations
   8.  References
     8.1.  Normative References
     8.2.  Informative References
   Acknowledgements
   Author's Address

1. Introduction

1. はじめに

This document specifies the conventions for using the AES-GMAC [AES] [GCM] Message Authentication Code (MAC) algorithm with the Cryptographic Message Syntax (CMS) [RFC5652].

このドキュメントは、暗号メッセージ構文（CMS）[RFC5652]を使用して、AES-GMAC [AES] [GCM]メッセージ認証コード（MAC）アルゴリズムを使用するための規則を指定します。

2. Terminology

2. 用語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。

3. Message Authentication Code Algorithms

3. メッセージ認証コードアルゴリズム

This section specifies the conventions employed by CMS [RFC5652] implementations that support the AES-GMAC [AES] [GCM] Message Authentication Code (MAC) algorithm.

このセクションでは、AES-GMAC [AES] [GCM]メッセージ認証コード（MAC）アルゴリズムをサポートするCMS [RFC5652]実装で採用されている規約を指定します。

MAC algorithm identifiers are located in the AuthenticatedData macAlgorithm field.

MACアルゴリズム識別子は、AuthenticatedData Macalgorithmフィールドにあります。

MAC values are located in the AuthenticatedData mac field.

MAC値はAuthenticatedData MACフィールドにあります。

3.1. AES-GMAC

The AES-GMAC [AES] [GCM] Message Authentication Code (MAC) algorithm uses one of the following algorithm identifiers in the AuthenticatedData macAlgorithm field; the choice depends on the size of the AES key, which is either 128 bits, 192 bits, or 256 bits:

AES-GMAC [AES] [GCM]メッセージ認証コード（MAC）アルゴリズムは、AuthenticedData Macalgorithmフィールドで次のアルゴリズム識別子のいずれかを使用します。選択はAESキーのサイズによって異なります。これは128ビット、192ビット、または256ビットです。

      aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840)
              organization(1) gov(101) csor(3) nistAlgorithm(4) 1 }

      id-aes128-GMAC OBJECT IDENTIFIER ::= { aes 9 }

      id-aes192-GMAC OBJECT IDENTIFIER ::= { aes 29 }

      id-aes256-GMAC OBJECT IDENTIFIER ::= { aes 49 }

For all three of these algorithm identifier values, the AlgorithmIdentifier parameters field MUST be present, and the parameters MUST contain GMACParameters:

これら3つのアルゴリズム識別子値すべてについて、AlgorithmIdentifierパラメータフィールドが存在しなければならず、パラメータにGMACPARAMETERSを含める必要があります。

      GMACParameters ::= SEQUENCE {
         nonce        OCTET STRING, -- recommended size is 12 octets
         length       MACLength DEFAULT 12 }

      MACLength ::= INTEGER (12 | 13 | 14 | 15 | 16)

The GMACParameters nonce field is the GMAC initialization vector. The nonce may have any number of bits between 8 and (2^64)-1, but it MUST be a multiple of 8 bits. Within the scope of any content-authentication key, the nonce value MUST be unique. A nonce value of 12 octets can be processed more efficiently, so that length for the nonce value is RECOMMENDED.

GMACPARAMETERS NONCEフィールドはGMAC初期化ベクトルです。nonceは、8から（2 ^ 64）-1の間の任意の数のビットを持つことができますが、それは8ビットの倍数でなければなりません。コンテンツ認証キーの範囲内で、NONCE値は一意である必要があります。12オクテットのNonce値をより効率的に処理することができるので、Nonce値の長さが推奨されます。

The GMACParameters length field tells the size of the message authentication code. It MUST match the size in octets of the value in the AuthenticatedData mac field. A length of 12 octets is RECOMMENDED.

GmacParameters Lengthフィールドは、メッセージ認証コードのサイズを示しています。AuthenticatedData MACフィールドの値のオクテットのサイズと一致する必要があります。12オクテットの長さをお勧めします。

4. Implementation Considerations

4. 実装に関する考慮事項

An implementation of the Advanced Encryption Standard (AES) Galois/ Counter Mode (GCM) authenticated encryption algorithm is specified in [GCM]. An implementation of AES-GCM can be used to compute the GMAC message authentication code by providing the content-authentication key as the AES key, the nonce as the initialization vector, a zero-length plaintext content, and the content to be authenticated as the additional authenticated data (AAD). The result of the AES-GCM invocation is the AES-GMAC authentication code, which is called the "authentication tag" in some implementations. In AES-GCM, the encryption step is skipped when no input plaintext is provided; therefore, no ciphertext is produced.

Advanced Encryption Standard（AES）ガロア/カウンタモード（GCM）認証された暗号化アルゴリズムの実装が[GCM]で指定されています。AES-GCMの実装は、Content-Authenticationキー、初期化ベクトル、長さゼロの平文のコンテンツ、および認証されるコンテンツとして、Content-AuthenticationキーをAESキー、Nonceとして提供することによってGMACメッセージ認証コードを計算することができます。追加の認証データ（AAD）。AES-GCM呼び出しの結果はAES-GMAC認証コードです。これはいくつかの実装形態では「認証タグ」と呼ばれます。AES-GCMでは、入力平文が提供されていないときに暗号化ステップはスキップされます。したがって、暗号文は作成されません。

The DEFAULT and RECOMMENDED values in GMACParameters were selected to align with the parameters defined for AES-GCM in Section 3.2 of [RFC5084].

GMACPARAMETERSのデフォルトおよび推奨値は、[RFC5084]のセクション3.2でAES-GCMに定義されているパラメータと整列するように選択されました。

5. ASN.1 Module

5. ASN.1モジュール

The following ASN.1 module uses the definition for MAC-ALGORITHM from [RFC5912].

次のASN.1モジュールは[RFC5912]からMACアルゴリズムの定義を使用します。

   CryptographicMessageSyntaxGMACAlgorithms
       { iso(1) member-body(2) us(840) rsadsi(113549)
         pkcs(1) pkcs-9(9) smime(16) modules(0)
         id-mod-aes-gmac-alg-2020(72) }

   DEFINITIONS IMPLICIT TAGS ::=
   BEGIN

-- EXPORTS All

- すべてのエクスポート

   IMPORTS
     AlgorithmIdentifier{}, MAC-ALGORITHM
     FROM AlgorithmInformation-2009 -- from [RFC5912]
         { iso(1) identified-organization(3) dod(6) internet(1)
           security(5) mechanisms(5) pkix(7) id-mod(0)
           id-mod-algorithmInformation-02(58)} ;

-- Object Identifiers

- オブジェクト識別子

   aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840)
          organization(1) gov(101) csor(3) nistAlgorithm(4) 1 }

   id-aes128-GMAC OBJECT IDENTIFIER ::= { aes 9 }

   id-aes192-GMAC OBJECT IDENTIFIER ::= { aes 29 }

   id-aes256-GMAC OBJECT IDENTIFIER ::= { aes 49 }

-- GMAC Parameters

- GMACパラメータ

   GMACParameters ::= SEQUENCE {
      nonce        OCTET STRING, -- recommended size is 12 octets
      length       MACLength DEFAULT 12 }

   MACLength ::= INTEGER (12 | 13 | 14 | 15 | 16)

-- Algorithm Identifiers

- アルゴリズム識別子

   maca-aes128-GMAC MAC-ALGORITHM ::= {
      IDENTIFIER id-aes128-GMAC
      PARAMS TYPE GMACParameters ARE required
      IS-KEYED-MAC TRUE }

   maca-aes192-GMAC MAC-ALGORITHM ::= {
      IDENTIFIER id-aes192-GMAC
      PARAMS TYPE GMACParameters ARE required
      IS-KEYED-MAC TRUE }

   maca-aes256-GMAC MAC-ALGORITHM ::= {
      IDENTIFIER id-aes256-GMAC
      PARAMS TYPE GMACParameters ARE required
      IS-KEYED-MAC TRUE }

   END -- of CryptographicMessageSyntaxGMACAlgorithms

6. IANA Considerations

6. IANAの考慮事項

IANA has registered the object identifier shown in Table 1 in the "SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)" registry.

IANAは、「S / MIMEモジュール識別子（1.2.840.113549.1.9.16.0）」レジストリの「SMIセキュリティ」の表1に示すオブジェクト識別子を登録しました。

            +=========+==========================+============+
            | Decimal | Description              | References |
            +=========+==========================+============+
            | 72      | id-mod-aes-gmac-alg-2020 | RFC 9044   |
            +---------+--------------------------+------------+

Table 1

表1

7. Security Considerations

7. セキュリティに関する考慮事項

The CMS provides a method for authenticating data. This document identifies the conventions for using the AES-GMAC algorithm with the CMS.

CMSはデータを認証するための方法を提供します。この文書は、CMSを使用してAES-GMACアルゴリズムを使用するための規則を識別します。

The key management technique employed to distribute message-authentication keys must itself provide authentication; otherwise, the content is delivered with integrity from an unknown source.

メッセージ認証キーを配布するために採用されている鍵管理技術自体は認証を提供する必要があります。それ以外の場合、コンテンツは未知のソースからの整合性を使用して配信されます。

When more than two parties share the same message-authentication key, data origin authentication is not provided. Any party that knows the message-authentication key can compute a valid MAC; therefore, the content could originate from any one of the parties.

2人以上のパーティーが同じメッセージ認証キーを共有する場合、データの原点認証は提供されていません。メッセージ認証キーを知っているパーティは、有効なMacを計算できます。したがって、コンテンツはいずれかの当事者に由来する可能性があります。

Within the scope of any content-authentication key, the AES-GMAC nonce value MUST be unique. Use of a nonce value more than once allows an attacker to generate valid AES-GMAC authentication codes for arbitrary messages, resulting in the loss of authentication as described in Appendix A of [GCM].

Content-Authenticationキーの範囲内で、AES-GMACのNonce値は一意である必要があります。攻撃者が任意のメッセージに対して有効なAES-GMAC認証コードを生成することを攻撃者が攻撃者が任意のメッセージを生成することを可能にし、[GCM]の付録Aで説明されているように認証が失われることができる。

Within the scope of any content-authentication key, the authentication tag length (MACLength) MUST be fixed.

任意のコンテンツ認証キーの範囲内で、認証タグの長さ（MACLENGTH）は固定されている必要があります。

If AES-GMAC is used as a building block in another algorithm (e.g., as a pseudorandom function), AES-GMAC MUST be used only one time by that algorithm. For instance, AES-GMAC MUST NOT be used as the pseudorandom function for PBKDF2.

AES-GMACが別のアルゴリズム（例えば、擬似乱数関数として）の構成要素として使用されている場合、AES-GMACはそのアルゴリズムによって1回だけ使用されなければなりません。たとえば、AES-GMACはPBKDF2の疑似乱数関数として使用してはいけません。

When initialization vector (IV) lengths other than 96 bits are used, the GHASH function is used to process the provided IV, which introduces a potential for IV collisions. However, IV collisions are not a concern with CMS AuthenticatedData because a fresh content-authentication key is usually generated for each message.

96ビット以外の初期化ベクトル（IV）長さが使用されるとき、ガッシュ機能は提供されたIVを処理するために使用され、これはIV衝突の可能性を導入する。ただし、新しいコンテンツ認証キーが通常各メッセージに対して生成されるため、IV衝突はCMS AuthenticatedDataの懸念ではありません。

The probability of a successful forgery is close to 2^(-t), where t is the number of bits in the authentication tag length (MACLength*8). This nearly ideal authentication protection is achieved for CMS AuthenticatedData when a fresh content-authentication key is generated for each message. However, the strength of GMAC degrades slightly as a function of the length of the message being authenticated [F2005] [MV2005]. Implementations SHOULD use 16-octet authentication tags for messages over 2^64 octets.

成功した偽造の可能性は2 ^（ - t）に近い。ここで、tは認証タグの長さのビット数（MacLength * 8）です。新たなコンテンツ認証キーが各メッセージに対して生成されたときに、CMS AuthenticatedDataに対してこのほぼ理想的な認証保護が達成されます。しかし、GMACの強度は、認証されているメッセージの長さの関数としてわずかに低下します[F2005] [MV2005]。実装は、2 ^ 64オクテットを超えるメッセージに16オクテット認証タグを使用する必要があります。

Implementations must randomly generate message-authentication keys. The use of inadequate pseudorandom number generators (PRNGs) to generate keys can result in little or no security. An attacker may find it much easier to reproduce the PRNG environment that produced the keys, searching the resulting small set of possibilities, rather than brute-force searching the whole key space. The generation of quality random numbers is difficult. [RFC4086] offers important guidance in this area.

実装は、メッセージ認証キーをランダムに生成する必要があります。キーを生成するための不適切な疑似乱数ジェネレータ（PRNG）を使用すると、セキュリティがほとんどまたはまったくありません。攻撃者は、キースペース全体を検索するのではなく、その結果、その結果の小さな可能性を検索するPRNG環境を再現する方がはるかに簡単になります。品質の乱数の生成は困難です。[RFC4086]この分野で重要なガイダンスを提供します。

Implementers should be aware that cryptographic algorithms become weaker with time. As new cryptanalysis techniques are developed and computing performance improves, the work factor to break a particular cryptographic algorithm will reduce. Therefore, cryptographic algorithm implementations should be modular, allowing new algorithms to be readily inserted. That is, implementers should be prepared to regularly update the set of algorithms in their implementations. More information is available in BCP 201 [RFC7696].

実装者は、暗号化アルゴリズムが時間とともに弱くなることに注意する必要があります。新しい暗号解析技術が開発されコンピューティング性能が向上するにつれて、特定の暗号化アルゴリズムを破るための作業係数は減少するであろう。したがって、暗号化アルゴリズムの実装はモジュール式であるべきであり、新しいアルゴリズムを容易に挿入することができます。つまり、実装者は、実装内のアルゴリズムのセットを定期的に更新する準備をしてください。詳細についてはBCP 201 [RFC7696]で入手できます。

8. References

8. 参考文献

8.1. Normative References

8.1. 引用文献

[AES] National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", FIPS PUB 197, DOI 10.6028/NIST.FIPS.197, November 2001, <https://doi.org/10.6028/NIST.FIPS.197>.

[AES]国立標準技術研究所、「高度な暗号化規格（AES）」、FIPS PUB 197、DOI 10.6028 / NIST.FIPS.197、2001年11月、<https://doi.org/10.6028/nist.fips。197>。

[GCM] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC", NIST Special Publication 800-38D, DOI 10.6028/NIST.SP.800-38D, November 2007, <https://doi.org/10.6028/NIST.SP.800-38D>.

[GCM] DWICHIN、M。、「ブロック暗号化モードのための推奨事項：ガロア/カウンタモード（GCM）およびGMAC」、NIST特別出版物800-38D、DOI 10.6028 / NIST.SP.800-38D、2007年11月、<https://doi.org/10.6028/nist.sp.800-38D>。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。

[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <https://www.rfc-editor.org/info/rfc5652>.

[RFC5652] Housley、R.、 "Cryptographic Message Syntax（CMS）"、STD 70、RFC 5652、DOI 10.17487 / RFC5652、2009年9月、<https：//www.rfc-editor.org/info/rfc5652>。

[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, DOI 10.17487/RFC5912, June 2010, <https://www.rfc-editor.org/info/rfc5912>.

[RFC5912] HOFFMAN、P.およびJ.Schaad、「X.509（PKIX）を使用した公開鍵インフラストラクチャのための新しいASN.1モジュール、RFC 5912、DOI 10.17487 / RFC5912、2010年6月、<https：// www。rfc-editor.org/info/rfc5912>

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。

8.2. Informative References

8.2. 参考引用

[F2005] Ferguson, N., "Authentication weaknesses in GCM", May 2005, <https://csrc.nist.gov/csrc/media/projects/block-cipher-techniques/documents/bcm/comments/cwc-gcm/ ferguson2.pdf>.

[F2005] Ferguson、N.、2005年5月、<https：//csrc.nist.gov/csrc/media/projects/block-cephers-techniques/documents/bcm/comments/cwc-gcm/ ferguson2.pdf>。

[MV2005] McGrew, D. and J. Viega, "GCM Update", May 2005, <https://csrc.nist.gov/CSRC/media/Projects/Block-Cipher-Techniques/documents/BCM/Comments/CWC-GCM/gcm-update.pdf>.

[MV2005] McGrew、D.およびJ.Viega、2005年5月、<https：//csrc.nist.gov/csrc/media/projects/block-cepher-techniques/documents/bcm/comments/cwc-gcm / gcm-update.pdf>。

[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/info/rfc4086>.

[RFC4086]イーストレイク3RD、D.、Schiller、J.、S. Crocker、「セキュリティのためのランダム性要件」、BCP 106、RFC 4086、DOI 10.17487 / RFC4086、2005年6月、<https：//www.rfc-編集者.org / info / rfc4086>。

[RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)", RFC 5084, DOI 10.17487/RFC5084, November 2007, <https://www.rfc-editor.org/info/rfc5084>.

[RFC5084]、「暗号メッセージ構文（CMS）でAES-CCMおよびAES-GCM認証暗号化を使用する」、RFC 5084、DOI 10.17487 / RFC5084、2007年11月、<https：//www.rfc-editor.org / info / rfc5084>。

[RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms", BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, <https://www.rfc-editor.org/info/rfc7696>.

[RFC7696]ハウスリー、R.、「暗号化アルゴリズムの敏捷性のためのガイドラインと必須の実施のアルゴリズムの選択」、BCP 201、RFC 7696、DOI 10.17487 / RFC7696、2015年11月、<https://www.rfc-editor.org/ info / rfc7696>。

Acknowledgements

謝辞

Many thanks to Hans Aschauer, Hendrik Brockhaus, Quynh Dang, Roman Danyliw, Tim Hollebeek, Ben Kaduk, Mike Ounsworth, and Magnus Westerlund for their careful review and thoughtful improvements.

Hans Aschauer、Hendrik Brockhaus、Quynh Dang、Roman Danyliw、Tim Hollebeek、Ben Kaduk、Mike Ounsworth、およびMagnus Westerlundのおかげで、慎重なレビューと思いやりのある改善に感謝します。

Author's Address

著者の住所

Russ Housley Vigil Security, LLC 516 Dranesville Road Herndon, VA 20170 United States of America

Russ Housley Vigil Security、LLC 516 Dranesville Road Herndon、VA 20170アメリカ合衆国

   Email: housley@vigilsec.com