[要約] RFC 7486は、HTTP Origin-Bound Authentication（HOBA）プロトコルに関する仕様であり、ユーザーの認証をオリジンに結び付けることを目的としています。HOBAは、セキュアな認証手段を提供し、クライアントとサーバー間の通信を保護します。
Internet Engineering Task Force (IETF) S. Farrell
Request for Comments: 7486 Trinity College Dublin
Category: Experimental P. Hoffman
ISSN: 2070-1721 VPN Consortium
M. Thomas
Phresheez
March 2015
HTTP Origin-Bound Authentication (HOBA)
HTTP Origin-Bound Authentication（HOBA）
Abstract
概要
HTTP Origin-Bound Authentication (HOBA) is a digital-signature-based design for an HTTP authentication method. The design can also be used in JavaScript-based authentication embedded in HTML. HOBA is an alternative to HTTP authentication schemes that require passwords and therefore avoids all problems related to passwords, such as leakage of server-side password databases.
HTTP Origin-Bound Authentication（HOBA）は、HTTP認証方式のデジタル署名ベースの設計です。このデザインは、HTMLに埋め込まれたJavaScriptベースの認証でも使用できます。 HOBAは、パスワードを必要とするHTTP認証スキームの代替手段であり、サーバー側のパスワードデータベースの漏洩など、パスワードに関連するすべての問題を回避します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7486.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7486で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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トラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Interfacing to Applications (Cookies) . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Step-by-Step Overview of HOBA-http . . . . . . . . . . . 6
2. The HOBA Authentication Scheme . . . . . . . . . . . . . . . 6
3. Introduction to the HOBA-http Mechanism . . . . . . . . . . . 9
4. Introduction to the HOBA-js Mechanism . . . . . . . . . . . . 10
5. HOBA's Authentication Process . . . . . . . . . . . . . . . . 11
5.1. CPK Preparation Phase . . . . . . . . . . . . . . . . . . 11
5.2. Signing Phase . . . . . . . . . . . . . . . . . . . . . . 11
5.3. Authentication Phase . . . . . . . . . . . . . . . . . . 11
6. Other Parts of the HOBA Process . . . . . . . . . . . . . . . 12
6.1. Registration . . . . . . . . . . . . . . . . . . . . . . 13
6.1.1. Hobareg Definition . . . . . . . . . . . . . . . . . 14
6.2. Associating Additional Keys to an Existing Account . . . 16
6.2.1. Moving Private Keys . . . . . . . . . . . . . . . . . 16
6.2.2. Human-Memorable One-Time Password (Don't Do This One) 16
6.2.3. Out-of-Band URL . . . . . . . . . . . . . . . . . . . 17
6.3. Logging Out . . . . . . . . . . . . . . . . . . . . . . . 17
6.4. Getting a Fresh Challenge . . . . . . . . . . . . . . . . 17
7. Mandatory-to-Implement Algorithms . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8.1. Privacy Considerations . . . . . . . . . . . . . . . . . 18
8.2. localStorage Security for JavaScript . . . . . . . . . . 19
8.3. Multiple Accounts on One User Agent . . . . . . . . . . . 20
8.4. Injective Mapping for HOBA-TBS . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9.1. HOBA Authentication Scheme . . . . . . . . . . . . . . . 21
9.2. .well-known URI . . . . . . . . . . . . . . . . . . . . . 21
9.3. Algorithm Names . . . . . . . . . . . . . . . . . . . . . 21
9.4. Key Identifier Types . . . . . . . . . . . . . . . . . . 22
9.5. Device Identifier Types . . . . . . . . . . . . . . . . . 22
9.6. Hobareg HTTP Header Field . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. Problems with Passwords . . . . . . . . . . . . . . 26
Appendix B. Example . . . . . . . . . . . . . . . . . . . . . . 27
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
HTTP Origin-Bound Authentication (HOBA) is an authentication design that can be used as an HTTP authentication scheme [RFC7235] and for JavaScript-based authentication embedded in HTML. The main goal of HOBA is to offer an easy-to-implement authentication scheme that is not based on passwords but that can easily replace HTTP or HTML forms-based password authentication. Deployment of HOBA can reduce or eliminate password entries in databases, with potentially significant security benefits.
HTTP Origin-Bound Authentication（HOBA）は、HTTP認証スキーム[RFC7235]として、およびHTMLに埋め込まれたJavaScriptベースの認証に使用できる認証設計です。 HOBAの主な目的は、パスワードに基づくのではなく、HTTPまたはHTMLフォームベースのパスワード認証を簡単に置き換えることができる、実装が容易な認証スキームを提供することです。 HOBAを導入すると、データベース内のパスワードエントリを削減または排除できるため、セキュリティが大幅に向上する可能性があります。
HOBA is an HTTP authentication mechanism that complies with the framework for such schemes [RFC7235]. As a JavaScript design, HOBA demonstrates a way for clients and servers to interact using the same credentials that are used by the HTTP authentication scheme.
HOBAは、そのようなスキームのフレームワーク[RFC7235]に準拠するHTTP認証メカニズムです。 JavaScriptの設計として、HOBAはクライアントとサーバーがHTTP認証スキームで使用されるのと同じ資格情報を使用して対話する方法を示します。
Current username/password authentication methods such as HTTP Basic, HTTP Digest, and web forms have been in use for many years but are susceptible to theft of server-side password databases. Instead of passwords, HOBA uses digital signatures in a challenge-response scheme as its authentication mechanism. HOBA also adds useful features such as credential management and session logout. In HOBA, the client creates a new public-private key pair for each host ("web origin" [RFC6454]) to which it authenticates. These keys are used in HOBA for HTTP clients to authenticate themselves to servers in the HTTP protocol or in a JavaScript authentication program.
HTTP Basic、HTTP Digest、Webフォームなどの現在のユーザー名/パスワード認証方法は長年使用されてきましたが、サーバー側のパスワードデータベースの盗難の影響を受けやすくなっています。パスワードの代わりに、HOBAは認証メカニズムとしてチャレンジ/レスポンス方式でデジタル署名を使用します。 HOBAには、資格情報管理やセッションログアウトなどの便利な機能も追加されています。 HOBAでは、クライアントは認証する各ホスト（ "web origin" [RFC6454]）ごとに新しい公開鍵と秘密鍵のペアを作成します。これらのキーは、HTTPクライアントがHTTPプロトコルまたはJavaScript認証プログラムでサーバーに対して自身を認証するために、HOBAで使用されます。
HOBA session management is identical to username/password session management, with a server-side session management tool or script inserting a session cookie [RFC6265] into the output to the browser. Use of Transport Layer Security (TLS) for the HTTP session is still necessary to prevent session cookie hijacking.
HOBAセッション管理はユーザー名/パスワードセッション管理と同じであり、サーバー側のセッション管理ツールまたはスクリプトがブラウザーへの出力にセッションCookie [RFC6265]を挿入します。セッションCookieのハイジャックを防ぐために、HTTPセッションにトランスポート層セキュリティ（TLS）を使用する必要があります。
HOBA keys are "bare keys", so there is no need for the semantic overhead of X.509 public key certificates, particularly with respect to naming and trust anchors. The Client Public Key (CPK) structures in HOBA do not have any publicly visible identifier for the user who possesses the corresponding private key, nor the web origin with which the client is using the CPK.
HOBAキーは「ベアキー」であるため、特に名前付けアンカーとトラストアンカーに関して、X.509公開キー証明書のセマンティックオーバーヘッドは必要ありません。 HOBAのクライアント公開鍵（CPK）構造には、対応する秘密鍵を所有するユーザーの公開識別子も、クライアントがCPKを使用しているWebオリジンもありません。
HOBA also defines some services that are needed for modern HTTP authentication:
HOBAでは、最新のHTTP認証に必要ないくつかのサービスも定義しています。
o Servers can bind a CPK with an identifier, such as an account name. Servers using HOBA define their own policies for binding CPKs with accounts during account registration.
o サーバーは、CPKをアカウント名などの識別子にバインドできます。 HOBAを使用するサーバーは、アカウント登録時にCPKをアカウントにバインドするための独自のポリシーを定義します。
o Users are likely to use more than one device or User Agent (UA) for the same HTTP-based service, so HOBA gives a way to associate more than one CPK to the same account without having to register for each separately.
o ユーザーは同じHTTPベースのサービスに複数のデバイスまたはユーザーエージェント（UA）を使用する可能性が高いため、HOBAは、複数のCPKを同じアカウントに関連付ける方法を提供します。それぞれを個別に登録する必要はありません。
o Logout features can be useful for UAs, so HOBA defines a way to close a current HTTP "session".
o ログアウト機能はUAに役立つため、HOBAは現在のHTTP「セッション」を閉じる方法を定義します。
o Digital signatures can be expensive to compute, so HOBA defines a way for HTTP servers to indicate how long a given challenge value is valid, and a way for UAs to fetch a fresh challenge at any time.
o デジタル署名は計算にコストがかかる可能性があるため、HOBAは、HTTPサーバーが特定のチャレンジ値の有効期間を示す方法と、UAがいつでも新しいチャレンジをフェッチする方法を定義します。
Users are also likely to lose a private key, or the client's memory of which key pair is associated with which origin, such as when a user loses the computer or mobile device in which state is stored. HOBA does not define a mechanism for deleting the association between an existing CPK and an account. Such a mechanism can be implemented at the application layer.
ユーザーは、秘密キー、またはユーザーが状態が保存されているコンピューターまたはモバイルデバイスを紛失した場合など、どのキーペアがどのオリジンに関連付けられているかを示すクライアントのメモリも失う可能性があります。 HOBAは、既存のCPKとアカウント間の関連付けを削除するメカニズムを定義していません。このようなメカニズムは、アプリケーション層で実装できます。
The HOBA scheme is far from new; for example, the basic idea is pretty much identical to the first two messages from "Mechanism R" on page 6 of [MI93], which predates HOBA by 20 years.
HOBAスキームは決して新しいものではありません。たとえば、基本的な考え方は、HOBAより20年前の[MI93]の6ページの「Mechanism R」からの最初の2つのメッセージとほとんど同じです。
HOBA can be used as a drop-in replacement for password-based user authentication schemes used in common web applications. The simplest way is to (re)direct the UA to a HOBA "Login" URL and for the response to a successful HTTP request containing a HOBA signature to set a session cookie [RFC6265]. Further interactions with the web application will then be secured via the session cookie, as is commonly done today.
HOBAは、一般的なWebアプリケーションで使用されるパスワードベースのユーザー認証スキームのドロップイン代替として使用できます。最も簡単な方法は、UAをHOBAの「ログイン」URLに（再）リダイレクトし、HOBA署名を含む成功したHTTPリクエストへの応答でセッションCookieを設定することです[RFC6265]。 Webアプリケーションとのさらなる対話は、今日一般的に行われているように、セッションCookieを介して保護されます。
While cookies are bearer tokens, and thus weaker than HOBA signatures, they are currently ubiquitously used. If non-bearer token session continuation schemes are developed in the future in the IETF or elsewhere, then those can interface to HOBA as easily as with any password-based authentication scheme.
Cookieはベアラートークンであるため、HOBA署名よりも脆弱ですが、現在、ユビキタスで使用されています。非ベアラートークンセッション継続スキームがIETFまたはその他の場所で将来開発される場合、それらは、パスワードベースの認証スキームと同じように簡単にHOBAに接続できます。
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 RFC 2119 [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの "は、RFC 2119 [RFC2119]で説明されているように解釈されます。
This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234].
この仕様では、[RFC5234]の拡張バッカスナウアフォーム（ABNF）表記を使用しています。
Account: The term "account" is (loosely) used to refer to whatever data structure(s) the server maintains that are associated with an identity. That will contain at least one CPK and a web origin; it will also optionally include an HTTP "realm" as defined in the HTTP authentication specification [RFC7235]. It might also involve many other non-standard pieces of data that the server accumulates as part of account creation processes. An account may have many CPKs that are considered equivalent in terms of being usable for authentication, but the meaning of "equivalent" is really up to the server and is not defined here.
アカウント：「アカウント」という用語は、（大まかに）IDに関連付けられている、サーバーが維持するデータ構造を指すために使用されます。これには、少なくとも1つのCPKとWebオリジンが含まれます。また、オプションで、HTTP認証仕様[RFC7235]で定義されているHTTP「レルム」も含まれます。また、サーバーがアカウント作成プロセスの一部として蓄積する他の多くの非標準的なデータが含まれる場合もあります。アカウントには、認証に使用できるという点で同等と見なされる多くのCPKがある場合がありますが、「同等」の意味は実際にはサーバー次第であり、ここでは定義しません。
Client public key (CPK): A CPK is the public key and associated cryptographic parameters needed for a server to validate a signature.
クライアント公開鍵（CPK）：CPKは、サーバーが署名を検証するために必要な公開鍵および関連する暗号化パラメーターです。
HOBA-http: We use this term when describing something that is specific to HOBA as an HTTP authentication mechanism.
HOBA-http：HTTP認証メカニズムとしてのHOBAに固有の何かを説明する場合、この用語を使用します。
HOBA-js: We use this term when describing something that is unrelated to HOBA-http but is relevant for HOBA as a design pattern that can be implemented in a browser in JavaScript.
HOBA-js：この用語は、HOBA-httpとは無関係ですが、JavaScriptのブラウザーに実装できる設計パターンとしてHOBAに関連するものを表すときに使用します。
User agent (UA): typically, but not always, a web browser.
ユーザーエージェント（UA）：常にではありませんが、通常はWebブラウザー。
User: a person who is running a UA. In this document, "user" does not mean "user name" or "account name".
ユーザー：UAを実行している人。このドキュメントでは、「ユーザー」は「ユーザー名」または「アカウント名」を意味しません。
Web client: the content and JavaScript code that run within the context of a single UA instance (such as a tab in a web browser).
Webクライアント：単一のUAインスタンス（Webブラウザーのタブなど）のコンテキスト内で実行されるコンテンツとJavaScriptコード。
Step-by-step, a typical HOBA-http registration and authentication flow might look like this:
段階的な、典型的なHOBA-http登録および認証フローは次のようになります。
1. The client connects to the server and makes a request, and the server's response includes a WWW-Authenticate header field that contains the "HOBA" auth-scheme, along with associated parameters (see Section 3).
1. クライアントはサーバーに接続して要求を出し、サーバーの応答には "HOBA" auth-schemeとそれに関連するパラメーターを含むWWW-Authenticateヘッダーフィールドが含まれます（セクション3を参照）。
2. If the client was not already registered with the web origin and realm it is trying to access, the "joining" process is invoked (see Section 6.1). This creates a key pair and makes the CPK known to the server so that the server can carry out the account creation processes required.
2. クライアントがまだアクセスしようとしているWebオリジンとレルムに登録されていない場合、「参加」プロセスが呼び出されます（6.1節を参照）。これにより、キーペアが作成され、CPKがサーバーに認識されるため、サーバーは必要なアカウント作成プロセスを実行できます。
3. The client uses the challenge from the HOBA auth-scheme parameters, along with other information it knows about the web origin and realm, to create and sign a HOBA to-be-signed (HOBA-TBS) string (see Section 2).
3. クライアントは、HOBA auth-schemeパラメーターからのチャレンジと、Webの起点とレルムについて知っている他の情報を使用して、署名するHOBA（HOBA-TBS）文字列を作成して署名します（セクション2を参照）。
4. The client creates a HOBA client-result (HOBA-RES), using the signed HOBA-TBS for the "sig" value (see Section 2).
4. クライアントは、「sig」値に署名付きのHOBA-TBSを使用して、HOBAクライアント結果（HOBA-RES）を作成します（セクション2を参照）。
5. The client includes the Authorization header field in its next request, using the "HOBA" auth-scheme and putting the HOBA client-result in an auth-param named "result" (see Section 3).
5. クライアントは、次のリクエストにAuthorizationヘッダーフィールドを含め、「HOBA」auth-schemeを使用して、HOBA client-resultを「result」という名前のauth-paramに入れます（セクション3を参照）。
6. The server authenticates the HOBA client-result (see Section 5.1).
6. サーバーはHOBAクライアントの結果を認証します（セクション5.1を参照）。
7. Typically, the server's response includes a session cookie that allows the client to indicate its authentication state in future requests (see Section 1.1).
7. 通常、サーバーの応答には、クライアントが将来のリクエストで認証状態を示すことができるようにするセッションCookieが含まれます（セクション1.1を参照）。
A UA that implements HOBA maintains a list of web origins and realms. The UA also maintains one or more client credentials for each web origin/realm combination for which it has created a CPK.
HOBAを実装するUAは、Webのオリジンとレルムのリストを維持します。 UAは、CPKを作成したWebの起点とレルムの組み合わせごとに、1つ以上のクライアント資格情報も保持します。
On receipt of a challenge (and optional realm) from a server, the client marshals a HOBA-TBS blob that includes a client generated nonce, the web origin, the realm, an identifier for the CPK, and the challenge string, and signs that blob with the private key corresponding to the CPK for that web origin. The formatting chosen for this TBS blob is chosen so as to make server-side signature verification as simple as possible for a wide range of current server tooling.
サーバーからチャレンジ（およびオプションのレルム）を受信すると、クライアントは、クライアントが生成したナンス、Webオリジン、レルム、CPKの識別子、およびチャレンジ文字列を含むHOBA-TBS BLOBをマーシャリングし、それに署名します。そのWebオリジンのCPKに対応する秘密キーを持つblob。このTBS blobに選択されたフォーマットは、現在のさまざまなサーバーツールでサーバー側の署名検証をできるだけ簡単にするように選択されています。
Figure 1 specifies the ABNF for the signature input. The term "unreserved" means that the field does not have a specific format defined and allows the characters specified in Section 2.3 of [RFC3986].
図1は、署名入力のABNFを示しています。 「未予約」という用語は、フィールドに特定の形式が定義されておらず、[RFC3986]のセクション2.3で指定された文字を許可することを意味します。
HOBA-TBS = len ":" nonce
len ":" alg
len ":" origin
len ":" [ realm ]
len ":" kid
len ":" challenge
len = 1*DIGIT
nonce = 1*base64urlchars
alg = 1*2DIGIT
origin = scheme "://" authority ":" port
; scheme, etc., are from RFC 3986
realm = unreserved
; realm is to be treated as in Section 2.2 of RFC 7235
kid = 1*base64urlchars
challenge = 1*base64urlchars
; Characters for Base64URL encoding from Table 2 of RFC 4648
; all of which are US-ASCII (see RFC 20)
base64urlchars = %x30-39 ; Digits
/ %x41-5A ; Uppercase letters
/ %x61-7A ; Lowercase letters
/ "-" / "_" / "=" ; Special characters
Figure 1: To-Be-Signed Data for HOBA
図1：HOBAの署名対象データ
The fields above contain the following:
上記のフィールドには以下が含まれます。
o len: Each field is preceded by the number of octets of the following field, expressed as a decimal number in ASCII [RFC20]. Lengths are separated from field values by a colon character. So if a nonce with the value "ABCD" were used, then that would be preceeded by "4:" (see the example in Appendix B for details).
o len：各フィールドの前には、ASCII [RFC20]で10進数として表される次のフィールドのオクテット数が続きます。長さはフィールド値からコロン文字で区切られます。したがって、値「ABCD」のノンスが使用された場合、その前に「4：」が付きます（詳細については、付録Bの例を参照してください）。
o nonce: a random value chosen by the UA and MUST be base64url encoded before being included in the HOBA-TBS value. (base64url encoding is defined in [RFC4648]; guidelines for randomness are given in [RFC4086].) UAs MUST be able to use at least 32 bits of randomness in generating a nonce. UAs SHOULD be able to use 64 or more bits of randomness for nonces.
o nonce：UAによって選択されたランダムな値であり、HOBA-TBS値に含まれる前にbase64urlエンコードされる必要があります。 （base64urlエンコーディングは[RFC4648]で定義されています。ランダム性のガイドラインは[RFC4086]で提供されています。）UAはナンスの生成に少なくとも32ビットのランダム性を使用できなければなりません（MUST）。 UAはノンスに64ビット以上のランダム性を使用できる必要があります（SHOULD）。
o alg: specifies the signature algorithm being used. See Section 7 for details of algorithm support requirements. The IANA-registered algorithm values (see Section 9.3) are encoded as one-or two-digit ASCII numbers. For example, RSA-SHA256 (number 0) is encoded as the ASCII character "0" (0x30), while a future algorithm registered as number 17 would be encoded as the ASCII characters "17" (0x3137).
o alg：使用されている署名アルゴリズムを指定します。アルゴリズムサポート要件の詳細については、セクション7を参照してください。 IANAに登録されたアルゴリズム値（9.3項を参照）は、1桁または2桁のASCII番号としてエンコードされます。たとえば、RSA-SHA256（数値0）はASCII文字 "0"（0x30）としてエンコードされますが、数値17として登録された将来のアルゴリズムはASCII文字 "17"（0x3137）としてエンコードされます。
o origin: the web origin expressed as the concatenation of the scheme, authority, and port from [RFC3986]. These are not base64 encoded, as they will be most readily available to the server in plain text. For example, if accessing the URL "https://www.example.com:8080/foo", then the bytes input to the signature process will be "https://www.example.com:8080". There is no default for the port number, and the port number MUST be present.
o origin：[RFC3986]からのスキーム、権限、およびポートの連結として表されるWebの起源。これらはプレーンテキストでサーバーが最も簡単に利用できるため、base64エンコードされていません。たとえば、URL「https://www.example.com:8080/foo」にアクセスする場合、署名プロセスに入力されるバイトは「https://www.example.com:8080」になります。ポート番号のデフォルトはなく、ポート番号が存在しなければなりません。
o realm: a string with the syntactic restrictions defined in [RFC7235]. If no realm is specified for this authentication, then this is absent but is preceeded by a length of zero ("0:"). Recall that both sides know when this needs to be there, independent of the encoding via a zero length.
o レルム：[RFC7235]で定義された構文制限を持つ文字列。この認証にレルムが指定されていない場合、これは存在しませんが、長さゼロ（ "0："）が前に付きます。長さがゼロのエンコーディングとは関係なく、これがいつ必要かを両側が知っていることを思い出してください。
o kid: a key identifier. This MUST be a base64url-encoded value that is presented to the server in the HOBA client result (see below).
o kid：キー識別子。これは、HOBAクライアントの結果でサーバーに提示されるbase64urlエンコード値である必要があります（以下を参照）。
o challenge: MUST be a base64url-encoded challenge value that the server chose to send to the client. The challenge MUST be chosen so that it is infeasible to guess and SHOULD be indistinguishable from (the base64url encoding of) a random string that is at least 128 bits long.
o challenge：サーバーがクライアントに送信することを選択したbase64urlでエンコードされたチャレンジ値である必要があります。チャレンジは、推測することが不可能であり、少なくとも128ビット長のランダム文字列（のbase64urlエンコーディング）と区別できないように選択する必要があります。
The HOBA-TBS string is the input to the client's signing process but is not itself sent over the network since some fields are already inherent in the HTTP exchange. The challenge, however, is sent over the network so as to reduce the amount of state that needs to be maintained by servers. (One form of stateless challenge might be a ciphertext that the server decrypts and checks, but that is an implementation detail.) The value that is sent over the network by the UA is the HOBA "client result", which we now define.
HOBA-TBS文字列はクライアントの署名プロセスへの入力ですが、一部のフィールドはすでにHTTP交換に組み込まれているため、それ自体はネットワークを介して送信されません。ただし、サーバーが維持する必要のある状態の量を減らすために、チャレンジはネットワークを介して送信されます。 （ステートレスチャレンジの1つの形式は、サーバーが復号化してチェックする暗号文である可能性がありますが、これは実装の詳細です。）UAによってネットワーク経由で送信される値は、HOBAの「クライアント結果」であり、これを定義します。
The HOBA "client result" is a dot-separated string that includes the signature and is sent in the HTTP Authorization header field value using the value syntax defined in Figure 2. The "sig" value is the base64url-encoded version of the binary output of the signing process. The kid, challenge, and nonce are as defined above and are also base64url encoded.
HOBAの「クライアント結果」は、署名を含むドット区切りの文字列であり、図2で定義されている値の構文を使用してHTTP Authorizationヘッダーフィールド値で送信されます。「sig」値は、バイナリ出力のbase64urlエンコードバージョンです署名プロセスの。 kid、challenge、およびnonceは上記で定義したとおりであり、base64urlでエンコードされています。
HOBA-RES = kid "." challenge "." nonce "." sig sig = 1*base64urlchars
HOBA-RES = kid "。" 「。」に挑戦ナンス "。" sig sig = 1 * base64urlchars
Figure 2: HOBA Client Result Value
図2：HOBAクライアントの結果値
If a malformed message of any kind is received by a server, the server MUST fail authentication. If a malformed message of any kind is received by a client, the client MUST abandon that authentication attempt. (The client is, of course, free to start another authentication attempt if it desires.)
不正な形式のメッセージをサーバーが受信した場合、サーバーは認証に失敗する必要があります。不正な形式のメッセージがクライアントによって受信された場合、クライアントはその認証の試行を中止しなければなりません（MUST）。 （もちろん、クライアントは必要に応じて別の認証試行を自由に開始できます。）
An HTTP server that supports HOBA authentication includes the "HOBA" auth-scheme value in a WWW-Authenticate header field when it wants the client to authenticate with HOBA. Note that the HOBA auth-scheme might not be the only one that the server includes in a WWW-Authenticate header.
HOBA認証をサポートするHTTPサーバーは、クライアントにHOBAでの認証を要求するときに、WWW-Authenticateヘッダーフィールドに "HOBA" auth-scheme値を含めます。サーバーがWWW-Authenticateヘッダーに含めるのはHOBA auth-schemeだけではない場合があることに注意してください。
The HOBA scheme has two REQUIRED attributes (challenge and max-age) and one OPTIONAL attribute (realm):
HOBAスキームには、2つの必須属性（challengeおよびmax-age）と1つのOPTIONAL属性（レルム）があります。
o The "challenge" attribute MUST be included. The challenge is the string made up of the base64url-encoded octets that the server wants the client to sign in its response. The challenge MUST be unique for every 401 HTTP response in order to prevent replay attacks from passive observers.
o 「チャレンジ」属性を含める必要があります。チャレンジは、base64urlでエンコードされたオクテットで構成される文字列であり、サーバーはクライアントに応答へのサインインを要求します。パッシブオブザーバーからのリプレイ攻撃を防ぐために、チャレンジは401 HTTP応答ごとに一意である必要があります。
o A "max-age" attribute MUST be included. It specifies the number of seconds from the time the HTTP response is emitted for which responses to this challenge can be accepted; for example, "max-age: 10" would indicate ten seconds. If max-age is set to zero, then that means that only one signature will be accepted for this challenge.
o 「max-age」属性を含める必要があります。これは、このチャレンジへの応答を受け入れることができるHTTP応答が発行されてからの秒数を指定します。たとえば、「max-age：10」は10秒を示します。 max-ageがゼロに設定されている場合、このチャレンジでは1つの署名のみが受け入れられます。
o A "realm" attribute MAY be included to indicate the scope of protection in the manner described in HTTP/1.1, Authentication [RFC7235]. The "realm" attribute MUST NOT appear more than once.
o HTTP / 1.1、認証[RFC7235]で説明されている方法で保護の範囲を示すために、「レルム」属性が含まれる場合があります。 「レルム」属性は2回以上指定してはなりません。
When the "client response" is created, the UA encodes the HOBA client-result and returns that in the Authorization header. The client-result is a string matching the HOBA-RES production in Figure 2 as an auth-param with the name "result".
「クライアント応答」が作成されると、UAはHOBAクライアント結果をエンコードし、Authorizationヘッダーで返します。 client-resultは、「result」という名前のauth-paramとして図2のHOBA-RESプロダクションに一致する文字列です。
The server MUST check the cryptographic correctness of the signature based on a public key it knows for the kid in the signatures, and if the server cannot do that, or if the signature fails cryptographic checks, then validation has failed. The server can use any additional mechanisms to validate the signature. If the validation fails, or if the server chooses to reject the signature for any reason whatsoever, the server fails the request with a 401 Unauthorized HTTP response.
サーバーは、署名の子供について知っている公開鍵に基づいて、署名の暗号の正しさをチェックする必要があります。サーバーがそれを行えない場合、または署名が暗号チェックに失敗した場合、検証は失敗しました。サーバーは、追加のメカニズムを使用して署名を検証できます。検証が失敗した場合、またはサーバーが何らかの理由で署名を拒否することを選択した場合、サーバーは401 Unauthorized HTTP応答で要求を失敗させます。
The server MUST check that the same web origin is used in all of the server's TLS server certificates, the URL being accessed, and the HOBA signature. If any of those checks fail, the server treats the signature as being cryptographically incorrect.
サーバーは、サーバーのすべてのTLSサーバー証明書、アクセスされるURL、およびHOBA署名で同じWebオリジンが使用されていることを確認する必要があります。これらのチェックのいずれかが失敗した場合、サーバーは署名を暗号的に正しくないものとして扱います。
Note that a HOBA signature is good for however long a non-zero max-age parameter allows. This means that replay is possible within the time window specified by the "max-age" value chosen by the server. Servers can attempt to detect any such replay (via caching if they so choose) and MAY react to such replays by responding with a second (or subsequent) 401 HTTP response containing a new challenge.
HOBAシグネチャは、ゼロ以外のmax-ageパラメーターが許可する限り有効です。これは、サーバーによって選択された「max-age」値によって指定された時間枠内で再生が可能であることを意味します。サーバーは、そのようなリプレイの検出を試み（選択した場合はキャッシングを介して）、新しいチャレンジを含む2番目（または後続）の401 HTTP応答で応答することにより、そのようなリプレイに反応してもよい（MAY）。
To optimize their use of challenges, UAs MAY prefetch a challenge value, for example, after (max-age)/2 seconds have elapsed, using the ".well-known/hoba/getchal" scheme described later in this document. This also allows for precalculation of HOBA signatures, if that is required in order to produce a responsive user interface.
チャレンジの使用を最適化するために、UAは、このドキュメントで後述する「.well-known / hoba / getchal」スキームを使用して、たとえば（max-age）/ 2秒が経過した後、チャレンジ値をプリフェッチできます（MAY）。これにより、応答性の高いユーザーインターフェイスを作成するために必要な場合は、HOBA署名の事前計算も可能になります。
Web sites using JavaScript can also perform origin-bound authentication without needing to involve the HTTP layer and by inference not needing HOBA-http support in browsers. HOBA-js is not an on-the-wire protocol like HOBA-http is; instead, it is a design pattern that can be realized completely in JavaScript served in normal HTML pages.
JavaScriptを使用するWebサイトは、HTTPレイヤーを使用する必要がなく、ブラウザーでHOBA-httpサポートを必要としない推論によって、オリジンバインド認証を実行することもできます。 HOBA-jsは、HOBA-httpのようなネットワーク上のプロトコルではありません。代わりに、通常のHTMLページで提供されるJavaScriptで完全に実現できる設計パターンです。
One thing that is highly desirable for HOBA-js is WebCrypto (see <http://www.w3.org/TR/WebCryptoAPI>), which is (at the time of writing) starting to see deployment. In lieu of WebCrypto, JavaScript crypto libraries can be employed with the known deficiencies of their pseudo-random number generators and the general immaturity of those libraries.
HOBA-jsにとって非常に望ましいことの1つは、WebCrypto（<http://www.w3.org/TR/WebCryptoAPI>を参照）です。これは、（執筆時点で）展開を開始し始めています。 WebCryptoの代わりに、JavaScript暗号ライブラリーを、疑似乱数ジェネレーターの既知の欠陥とそれらのライブラリーの一般的な未熟さとともに使用できます。
Without Webcrypto, one element is required for HOBA-js; localStorage (see <http://www.w3.org/TR/webstorage/>) from HTML5 can be used for persistent key storage. For example, an implementation would store a dictionary account identifier as well as public key and private key tuples in the origin's localStorage for subsequent authentication requests. How this information is actually stored in localStorage is an implementation detail. This type of key storage relies on the security properties of the same-origin policy that localStorage enforces. See the security considerations for discussion about attacks on localStorage. Note that IndexedDB (see <http://www.w3.org/TR/IndexedDB/>) is an alternative to localStorage that can also be used here and that is used by WebCrypto.
Webcryptoがない場合、HOBA-jsには1つの要素が必要です。 HTML5のlocalStorage（<http://www.w3.org/TR/webstorage/>を参照）は、永続的なキーストレージに使用できます。たとえば、実装では、以降の認証リクエストのために、オリジンのlocalStorageに辞書アカウント識別子と公開鍵および秘密鍵のタプルを格納します。この情報が実際にlocalStorageに格納される方法は、実装の詳細です。このタイプのキーストレージは、localStorageが適用する同一生成元ポリシーのセキュリティプロパティに依存しています。 localStorageに対する攻撃については、セキュリティに関する考慮事項を参照してください。 IndexedDB（<http://www.w3.org/TR/IndexedDB/>を参照）はlocalStorageの代替であり、ここでも使用でき、WebCryptoで使用されることに注意してください。
Because of JavaScript's same-origin policy, scripts from subdomains do not have access to the same localStorage that scripts in their parent domains do. For larger or more complex sites, this could be an issue that requires enrollment into subdomains, which could be difficult for users. One way to get around this is to use session cookies because they can be used across subdomains. That is, with HOBA-js, the user might log in using a single well-known domain, and then session cookies are used whilst the user navigates around the site.
JavaScriptの同じ生成元のポリシーにより、サブドメインのスクリプトは、親ドメインのスクリプトが行うのと同じlocalStorageにアクセスできません。大規模または複雑なサイトの場合、これはサブドメインへの登録を必要とする問題である可能性があり、ユーザーにとって難しい場合があります。これを回避する1つの方法は、サブドメイン間で使用できるため、セッションCookieを使用することです。つまり、HOBA-jsを使用すると、ユーザーは単一の既知のドメインを使用してログインし、ユーザーがサイト内を移動するときにセッションCookieが使用されます。
This section describes how clients and servers use HOBA for authentication. The interaction between an HTTP client and HTTP server using HOBA happens in three phases: the CPK preparation phase, the signing phase, and the authentication phase. This section also covers the actions that give HOBA features similar to today's password-based schemes.
このセクションでは、クライアントとサーバーが認証にHOBAを使用する方法について説明します。 HOBAを使用したHTTPクライアントとHTTPサーバー間の対話は、CPK準備フェーズ、署名フェーズ、および認証フェーズの3つのフェーズで行われます。このセクションでは、今日のパスワードベースのスキームと同様のHOBA機能を提供するアクションについても説明します。
In the CPK preparation phase, the client determines if it already has a CPK for the web origin with which it needs to authenticate. If the client has a CPK, the client will use it; if the client does not have a CPK, it generates one in anticipation of the server asking for one.
CPK準備フェーズでは、クライアントは、認証が必要なWebオリジンのCPKがすでにあるかどうかを判断します。クライアントにCPKがある場合、クライアントはそれを使用します。クライアントにCPKがない場合は、サーバーが1つ要求することを見越して1つ生成します。
In the signing phase, the client connects to the server, the server asks for HOBA-based authentication, and the client authenticates by signing a blob of information as described in the previous sections.
署名フェーズでは、クライアントはサーバーに接続し、サーバーはHOBAベースの認証を要求し、クライアントは前のセクションで説明したように情報のblobに署名することによって認証します。
The authentication phase is completely dependent on the policies and practices of the server. That is, this phase involves no standardized protocol in HOBA-http; in HOBA-js, there is no suggested interaction template.
認証フェーズは、サーバーのポリシーとプラクティスに完全に依存しています。つまり、このフェーズにはHOBA-httpの標準プロトコルは含まれません。 HOBA-jsでは、推奨される相互作用テンプレートはありません。
In the authentication phase, the server uses the key identifier (kid) to determine the CPK from the signing phase and decides if it recognizes the CPK. If the server recognizes the CPK, the server may finish the client authentication process.
認証フェーズでは、サーバーはキー識別子（kid）を使用して署名フェーズからCPKを決定し、CPKを認識するかどうかを決定します。サーバーがCPKを認識すると、サーバーはクライアント認証プロセスを終了する場合があります。
If this stage of the process involves additional information for authentication, such as asking the user which account she wants to use (in the case where a UA is used for multiple accounts on a site), the server can prompt the user for account identifying information, or the user could choose based on HTML offered by the server before the 401 response is triggered. None of this is standardized: it all follows the server's security policy and session flow. At the end of this, the server probably assigns or updates a session cookie for the client.
プロセスのこの段階で認証に追加情報が必要な場合（たとえば、サイトの複数のアカウントにUAが使用されている場合）、ユーザーにアカウントの識別情報を要求することができます。 、またはユーザーは、401応答がトリガーされる前にサーバーによって提供されるHTMLに基づいて選択できます。これはいずれも標準化されていません。すべてサーバーのセキュリティポリシーとセッションフローに従います。この最後に、サーバーはおそらくクライアントにセッションCookieを割り当てるか更新します。
During the authentication phase, if the server cannot determine the correct CPK, it could use HTML and JavaScript to ask the user if they are really a new user or want to associate this new CPK with another CPK. The server can then use some out-of-band method (such as a confirmation email round trip, SMS, or a UA that is already enrolled) to verify that the "new" user is the same as the already-enrolled one. Thus, logging in on a new UA is identical to logging in with an existing account.
認証フェーズ中に、サーバーが正しいCPKを判別できない場合、サーバーはHTMLおよびJavaScriptを使用して、ユーザーに本当に新しいユーザーであるか、またはこの新しいCPKを別のCPKに関連付けるかを尋ねます。次に、サーバーは帯域外の方法（確認メールの往復、SMS、または既に登録されているUAなど）を使用して、「新しい」ユーザーがすでに登録されているユーザーと同じであることを確認できます。したがって、新しいUAでのログインは、既存のアカウントでのログインと同じです。
If the server does not recognize the CPK, the server might send the client through either a join or login-new-UA (see below) process. This process is completely up to the server and probably entails using HTML and JavaScript to ask the user some questions in order to assess whether or not the server wants to give the client an account. Completion of the joining process might require confirmation by email, SMS, CAPTCHA, and so on.
サーバーがCPKを認識しない場合、サーバーはjoinまたはlogin-new-UA（下記を参照）プロセスのいずれかを介してクライアントを送信する可能性があります。このプロセスは完全にサーバー次第であり、おそらくサーバーがクライアントにアカウントを与えたいかどうかを評価するために、HTMLとJavaScriptを使用してユーザーにいくつかの質問をする必要があります。参加プロセスを完了するには、電子メール、SMS、CAPTCHAなどによる確認が必要になる場合があります。
Note that there is no necessity for the server to initiate a joining or login process upon completion of the signing phase. Indeed, the server may desire to challenge the UA even for unprotected resources and set a session cookie for later use in a join or login process as it becomes necessary. For example, a server might only want to offer an account to someone who had been to a few pages on the web site; in such a case, the server could use the CPK from an associated session cookie as a way of building reputation for the user until the server wants the user to join.
署名フェーズの完了時にサーバーが参加またはログインプロセスを開始する必要がないことに注意してください。実際、サーバーは、保護されていないリソースでもUAにチャレンジし、後で必要になったときに参加またはログインプロセスで使用するためにセッションCookieを設定することを望む場合があります。たとえば、サーバーは、Webサイトのいくつかのページにアクセスしたことがある人にのみアカウントを提供したい場合があります。このような場合、サーバーは、サーバーがユーザーの参加を希望するまで、ユーザーのレピュテーションを構築する方法として、関連付けられたセッションCookieのCPKを使用できます。
The authentication process is more than just the act of authentication. In password-based authentication and HOBA, there are other processes that are needed both before and after an authentication step. This section covers those processes. Where possible, it combines practices of HOBA-http and HOBA-js; where that is not possible, the differences are called out.
認証プロセスは、単なる認証行為ではありません。パスワードベースの認証とHOBAでは、認証ステップの前後に必要な他のプロセスがあります。このセクションでは、これらのプロセスについて説明します。可能な場合は、HOBA-httpとHOBA-jsのプラクティスを組み合わせます。それが不可能な場合は、相違点が示されます。
All HOBA interactions other than those defined in Section 5 MUST be performed in TLS-protected sessions [RFC5246]. If the current HTTP traffic is not running under TLS, a new session is started before any of the actions described here are performed.
セクション5で定義されたもの以外のすべてのHOBA対話は、TLSで保護されたセッションで実行する必要があります[RFC5246]。現在のHTTPトラフィックがTLSで実行されていない場合、ここで説明するアクションが実行される前に新しいセッションが開始されます。
HOBA-http uses a well-known URI [RFC5785] "hoba" as a base URI for performing many tasks: "https://www.example.com/.well-known/hoba". These URIs are based on the name of the host that the HTTP client is accessing.
HOBA-httpは、よく知られているURI [RFC5785]「hoba」を、多くのタスクを実行するためのベースURIとして使用します：「https://www.example.com/.well-known/hoba」。これらのURIは、HTTPクライアントがアクセスしているホストの名前に基づいています。
There are many use cases for these URLs to redirect to other URLs: a site that does registration through a federated site, a site that only does registration under HTTPS, and so on. Like any HTTP client, HOBA-http clients have to be able to handle redirection of these requests. However, as that would potentially cause security issues when a re-direct brings the client to a different web origin, servers implementing HOBA-http SHOULD NOT redirect to a different web origin from below ".well-known/hoba" URLs. The above is considered sufficient to allow experimentation with HOBA, but if at some point HOBA is placed on the Standards Track, then a full analysis of off-origin redirections would need to be documented.
これらのURLが他のURLにリダイレクトする多くの使用例があります。フェデレーションサイトを通じて登録を行うサイト、HTTPSでのみ登録を行うサイトなどです。他のHTTPクライアントと同様に、HOBA-httpクライアントはこれらの要求のリダイレクトを処理できる必要があります。ただし、リダイレクトによってクライアントが別のWebオリジンに移動したときにセキュリティの問題が発生する可能性があるため、HOBA-httpを実装するサーバーは、「。well-known / hoba」URLの下から別のWebオリジンにリダイレクトしないでください。上記はHOBAでの実験を可能にするのに十分であると考えられますが、ある時点でHOBAが標準化トラックに配置される場合、オフオリジンリダイレクトの完全な分析を文書化する必要があります。
Normally, a registration (also called "joining") is expected to happen after a UA receives a 401 response for a web origin and realm (for HOBA-http) or on demand (for HOBA-js) for which it has no associated CPK. The process of registration for a HOBA account on a server is relatively lightweight. The UA generates a new key pair and associates it with the web origin/realm in question.
通常、登録（ "参加"とも呼ばれます）は、UAがWebオリジンとレルム（HOBA-httpの場合）またはオンデマンド（HOBA-jsの場合）の401応答を受信した後に発生し、CPKが関連付けられていない場合に発生します。 。サーバー上のHOBAアカウントの登録プロセスは比較的軽量です。 UAは新しいキーペアを生成し、それを問題のWebオリジン/レルムに関連付けます。
Note that if the UA has a CPK associated with the web origin, but not for the realm concerned, then a new registration is REQUIRED. If the server did not wish for that outcome, then it ought to use the same or no realm.
UAにWebオリジンに関連付けられたCPKがあるが、関連するレルムには関連付けられていない場合は、新規登録が必要です。サーバーがその結果を望まない場合は、同じレルムを使用するか、レルムを使用しないでください。
The registration message for HOBA-http is sent as a POST message to the URL ".well-known/hoba/register" with an HTML form (x-www-form-encoded, see <http://www.w3.org/TR/2014/REC-html5-20141028/ forms.html#url-encoded-form-data>), described below. The registration message for HOBA-js can be in any format specified by the server, but it could be the same as the one described here for HOBA-http. It is up to the server to decide what kind of user interaction is required before the account is finally set up. When the server's chosen registration flow is completed successfully, the server MUST add a Hobareg HTTP header (see Section 6.1.1) to the HTTP response message that completes the registration flow.
HOBA-httpの登録メッセージは、POSTメッセージとしてHTMLフォーム（x-www-form-encoded、<http://www.w3.org /TR/2014/REC-html5-20141028/forms.html#url-encoded-form-data>）、以下で説明します。 HOBA-jsの登録メッセージは、サーバーで指定された任意の形式にすることができますが、HOBA-httpについてここで説明されているものと同じにすることができます。アカウントが最終的に設定される前に、どのような種類のユーザー操作が必要かを決定するのはサーバーです。サーバーの選択された登録フローが正常に完了すると、サーバーは、登録フローを完了するHTTP応答メッセージにHobareg HTTPヘッダー（セクション6.1.1を参照）を追加する必要があります。
The registration message sent to the server has one mandatory field (pub) and some optional fields that allow the UA to specify the type and value of key and device identifiers that the UA wishes to use.
サーバーに送信される登録メッセージには、1つの必須フィールド（pub）と、UAが使用するキーとデバイス識別子のタイプと値をUAで指定できるようにするいくつかのオプションフィールドがあります。
o pub: a mandatory field containing the Privacy Enhanced Mail (PEM) formatted public key of the client. See Appendix C of [RFC6376] for an example of how to generate this key format.
o pub：クライアントのプライバシー強化メール（PEM）形式の公開鍵を含む必須フィールド。この鍵形式を生成する方法の例については、[RFC6376]の付録Cを参照してください。
o kidtype: contains the type of key identifier. This is a numeric value intended to contain one of the values from Section 9.4. If this is not present, then the mandatory-to-implement hashed public key option MUST be used.
o kidtype：キー識別子のタイプを含みます。これは、9.4項のいずれかの値を含むことを目的とした数値です。これが存在しない場合は、実装が必須のハッシュ公開鍵オプションを使用する必要があります。
o kid: contains the key identifier as a base64url-encoded string that is of the type indicated in the kidtype. If the kid is a hash of a public key, then the correct (base64url-encoded) hash value MUST be provided and the server SHOULD check that and refuse the registration if an incorrect value was supplied.
o kid：kidtypeで示されたタイプのbase64urlエンコード文字列としてキー識別子を含みます。子供が公開鍵のハッシュである場合、正しい（base64urlでエンコードされた）ハッシュ値を指定する必要があり、サーバーはそれを確認して、不正な値が指定された場合は登録を拒否する必要があります。
o didtype: specifies a kind of device identifier intended to contain one of the values from Section 9.5. If absent, then the "string" form of device identifier defined in Section 9.5 MUST be used.
o didtype：セクション9.5の値の1つを含めることを目的とした一種のデバイス識別子を指定します。存在しない場合、セクション9.5で定義された「文字列」形式のデバイス識別子を使用する必要があります。
o did: a UTF-8 string that specifies the device identifier. This can be used to help a user be confident that authentication has worked, e.g., following authentication, some web content might say "You last logged in from device 'did' at time T."
o did：デバイス識別子を指定するUTF-8文字列。これは、認証が機能したことをユーザーが確信できるようにするために使用できます。たとえば、認証に続いて、一部のWebコンテンツに「最後にログインしたのは、時刻Tにデバイス 'did'でした」と表示される場合があります。
Note that replay of registration (and other HOBA) messages is quite possible. That, however, can be counteracted if challenge freshness is ensured. See Section 2 for details. Note also that with HOBA-http, the HOBA signature does not cover the POST message body. If that is required, then HOBA-JS may be a better fit for registration and other account management actions.
登録（およびその他のHOBA）メッセージの再生はかなり可能です。ただし、チャレンジの鮮度が確保されている場合は、これを打ち消すことができます。詳細については、セクション2を参照してください。 HOBA-httpでは、HOBA署名はPOSTメッセージ本文をカバーしないことにも注意してください。それが必要な場合は、HOBA-JSが登録やその他のアカウント管理アクションに適している可能性があります。
Since registration can often be a multi-step process, e.g., requiring a user to fill in contact details, the initial response to the HTTP POST message defined above may not be the end of the registration process even though the HTTP response has a 200 OK status. This creates an issue for the UA since, during the registration process (e.g., while dealing with interstitial pages), the UA doesn't yet know whether the CPK is good for that web origin or not.
登録は多くの場合、ユーザーが連絡先の詳細を入力する必要があるなどの複数ステップのプロセスになる可能性があるため、上記で定義されたHTTP POSTメッセージに対する最初の応答は、HTTP応答に200 OK状態。これは、登録プロセス中（インタースティシャルページの処理中など）に、UAがCPKがそのWebオリジンに適しているかどうかをまだ認識していないため、UAに問題を引き起こします。
For this reason, the server MUST add a header field to the response message when the registration has succeeded in order to indicate the new state. The header to be used is "Hobareg", and the value when registration has succeeded is to be "regok". When registration is in an intermediate state (e.g., on an HTTP response for an interstitial page), the server MAY add this header with a value of "reginwork". See Section 9.6 for the relevant IANA registration of this header field.
このため、サーバーは、新しい状態を示すために、登録が成功したときにヘッダーフィールドを応答メッセージに追加する必要があります。使用するヘッダは「Hobareg」で、登録成功時の値は「regok」となります。登録が中間状態（インタースティシャルページのHTTP応答など）の場合、サーバーはこのヘッダーに「reginwork」の値を追加できます（MAY）。このヘッダーフィールドの関連するIANA登録については、セクション9.6を参照してください。
For interstitial pages, the client MAY include a HOBA Authorization header. This is not considered a "MUST", as that might needlessly complicate client implementations, but is noted here in case a server implementer assumes that all registration messages contain a HOBA Authorization header.
インタースティシャルページの場合、クライアントはHOBA Authorizationヘッダーを含めることができます。クライアントの実装を不必要に複雑にする可能性があるため、これは「必須」とは見なされませんが、サーバーの実装者がすべての登録メッセージにHOBA Authorizationヘッダーが含まれていると想定している場合に備えて、ここで注記します。
Hobareg-val = "regok" / "reginwork"
Figure 3: Hobareg Header Field Definition
図3：Hobaregヘッダーフィールドの定義
Figure 3 provides an ABNF definition for the values allowed in the Hobareg header field. Note that these (and the header field name) are case insensitive. Section 8.3.1 of [RFC7231] calls for documenting the following details for this new header field:
図3は、Hobaregヘッダーフィールドで許可される値のABNF定義を示しています。これら（およびヘッダーフィールド名）は大文字と小文字を区別しないことに注意してください。 [RFC7231]のセクション8.3.1では、この新しいヘッダーフィールドに関する以下の詳細を文書化する必要があります。
o Only one single value is allowed in a Hobareg header field. Should more than one (a list) be encountered, or any other ABNF-invalid value, that SHOULD be interpreted as being the same as "reginwork".
o Hobaregヘッダーフィールドで許可される単一の値のみ。複数（リスト）に遭遇した場合、または他のABNF無効な値に遭遇した場合、「reginwork」と同じものとして解釈されるべきです（SHOULD）。
o The Hobareg header field can only be used in HTTP responses.
o Hobaregヘッダーフィールドは、HTTP応答でのみ使用できます。
o Since Hobareg is only meant for responses, it ought not appear in requests.
o Hobaregは応答のみを目的としているため、リクエストには表示されません。
o The HTTP response code does affect the interpretation of Hobareg. Registration is only considered to have succeeded if the regok value is seen in a 2xx response. 4xx and other errors mean that registration has failed regardless of the value of Hobareg seen. The request method has no influence on the interpretation of Hobareg.
o HTTP応答コードはHobaregの解釈に影響を与えます。登録は、regok値が2xx応答で見られる場合にのみ成功したと見なされます。 4xxおよびその他のエラーは、表示されたHobaregの値に関係なく、登録が失敗したことを意味します。 requestメソッドはHobaregの解釈に影響を与えません。
o Intermediaries never insert, delete, or modify a Hobareg header field.
o 仲介者がHobaregヘッダーフィールドを挿入、削除、または変更することはありません。
o As a response-only header field, it is not appropriate to list a Hobareg in a Vary response header field.
o 応答のみのヘッダーフィールドとして、Vary応答ヘッダーフィールドにHobaregをリストすることは適切ではありません。
o Hobareg is allowed in trailers.
o Hobaregはトレーラーで許可されています。
o As a response-only header field, Hobareg will not be preserved across re-directs.
o 応答のみのヘッダーフィールドとして、ホバレグはリダイレクト間で保持されません。
o Hobareg itself discloses little security- or privacy-sensitive information. If an attacker can somehow detect that a Hobareg header field is being added, then that attacker would know that the UA is in the process of registration, which could be significant. However, it is likely that the set of messages between the UA and server would expose this information in many cases, regardless of whether or not TLS is used. Using TLS is still, however, a good plan.
o Hobareg自体は、セキュリティやプライバシーに敏感な情報をほとんど開示していません。攻撃者がHobaregヘッダーフィールドが追加されていることを何らかの方法で検出できる場合、その攻撃者はUAが登録処理中であることを知る可能性があります。ただし、TLSが使用されているかどうかに関係なく、UAとサーバー間の一連のメッセージがこの情報を公開することがよくあります。ただし、TLSの使用は依然として適切な計画です。
From the user perspective, the UA having a CPK for a web origin will often appear to be the same as having a way to sign in to an account at that web site. Since users often have more than one UA, and since the CPKs are, in general, UA specific, that raises the question of how the user can sign in to that account from different UAs. And from the server perspective, that turns into the question of how to safely bind different CPKs to one account. In this section, we describe some ways in which this can be done, as well as one way in which this ought not be done.
ユーザーの観点から見ると、WebオリジンのCPKを持つUAは、そのWebサイトのアカウントにサインインする方法を持つのと同じように見えることがよくあります。ユーザーは複数のUAを持っていることが多く、CPKは一般にUA固有であるため、ユーザーがさまざまなUAからそのアカウントにどのようにサインインできるかという疑問が生じます。そして、サーバーの観点からは、異なるCPKを1つのアカウントに安全にバインドする方法の問題に変わります。このセクションでは、これを実行できるいくつかの方法と、これを実行してはならない1つの方法について説明します。
Note that the context here is usually that the user has succeeded in registering with one or more UAs (for the purposes of this section, we call this "the first UA" below) and can use HOBA with those, and the user is now adding another UA. The newest UA might or might not have a CPK for the site in question. Since it is in fact trivial, we assume that the site is able to put in place some appropriate, quicker, easier registration for a CPK for the newest UA. The issue then becomes one of binding the CPK from the newest UA with those of other UAs bound to the account.
ここでのコンテキストは通常、ユーザーが1つ以上のUAへの登録に成功し（このセクションでは、これを「最初のUA」と呼びます）、HOBAをそれらと一緒に使用できることに注意してください。別のUA。最新のUAには、問題のサイトのCPKがある場合とない場合があります。それは実際には取るに足らないことなので、サイトは最新のUAのCPKに対して適切で迅速かつ簡単な登録を行うことができると想定しています。次に、問題は、最新のUAからのCPKを、アカウントにバインドされている他のUAのCPKとバインドすることの1つになります。
It is common for a user to have multiple UAs and to want all those UAs to be able to authenticate to a single account. One method to allow a user who has an existing account to be able to authenticate on a second device is to securely transport the private and public keys and the origin information from the first device to the second. If this approach is taken, then there is no impact on the HOBA-http or HOBA-js, so this is a pure UA implementation issue and not discussed further.
ユーザーが複数のUAを持ち、それらすべてのUAが単一のアカウントに対して認証できるようにすることは一般的です。既存のアカウントを持つユーザーが2番目のデバイスで認証できるようにする1つの方法は、秘密キーと公開キー、および発信元情報を最初のデバイスから2番目のデバイスに安全に転送することです。このアプローチを採用した場合、HOBA-httpまたはHOBA-jsへの影響はないため、これは純粋なUA実装の問題であり、これ以上は説明しません。
It will be tempting for implementers to use a human-memorable One-Time Password (OTP) in order to "authenticate" binding CPKs to the same account. The workflow here would likely be something along the lines of some server administrative utility generating a human- memorable OTP such as "1234" and sending that to the user out of band for the user to enter at two web pages, each authenticated via the relevant CPK. While this seems obvious enough and could even be secure enough in some limited cases, we consider that this is too risky to use in the Internet, and so servers SHOULD NOT provide such a mechanism. The reason this is so dangerous is that it would be trivial for an automated client to guess such tokens and "steal" the binding intended for some other user. At any scale, there would always be some in-process bindings so that even with only a trickle of guesses (and hence not being detectable via message volume), an attacker would have a high probability of succeeding in registering a binding with the attacker's CPK.
同じアカウントへのCPKのバインドを「認証」するために、実装者が人間が記憶できるワンタイムパスワード（OTP）を使用するのは魅力的です。ここでのワークフローは、「1234」などの記憶に残るOTPを生成し、2つのWebページにユーザーが入力できるように帯域外でユーザーに送信するサーバー管理ユーティリティのラインに沿ったものである可能性があります。 CPK。これは十分に明白であり、一部の限られたケースでは十分に安全である可能性もありますが、これはインターネットで使用するには危険すぎるため、サーバーはそのようなメカニズムを提供しないでください。これが非常に危険である理由は、自動化されたクライアントがそのようなトークンを推測し、他のユーザー向けのバインディングを「盗む」ことは簡単なことです。どんなスケールでも、常にいくつかのインプロセスバインディングが存在するため、推測の細流が1つしかなくても（したがって、メッセージの量では検出できません）、攻撃者はバインディングを攻撃者のCPKに登録することに成功する可能性が高くなります。 。
This method of binding CPKs together is therefore NOT RECOMMENDED.
したがって、CPKを一緒にバインドするこの方法はお勧めしません。
One easy binding method is to simply provide a web page where, using the first UA, the user can generate a URL (containing some "unguessable" cryptographically generated value) that the user then later dereferences on the newest UA. The user could email that URL to herself, for example, or the web server accessed at the first UA could automatically do that.
簡単なバインディング方法の1つは、最初のUAを使用して、ユーザーがURLを生成できるWebページを提供することです（ユーザーは、「最新のUAで参照できない」暗号化された値を含みます）。たとえば、ユーザーはそのURLを自分宛てに電子メールで送信したり、最初のUAでアクセスしたWebサーバーが自動的に送信したりできます。
Such a URL SHOULD contain at least the equivalent of 128 bits of randomness.
そのようなURLには、少なくとも128ビットのランダム性と同等のものを含める必要があります（SHOULD）。
The user can tell the server it wishes to log out. With HOBA-http, this is done by sending a HOBA-authenticated POST message to the URL ".well-known/hoba/logout" on the site in question. The UA SHOULD also delete session cookies associated with the session so that the user's state is no longer "logged in."
ユーザーは、ログアウトするサーバーを指定できます。 HOBA-httpでは、これは、問題のサイトのURL ".well-known / hoba / logout"にHOBA認証のPOSTメッセージを送信することで行われます。 UAは、ユーザーの状態が「ログイン」されないように、セッションに関連付けられたセッションCookieも削除する必要があります（SHOULD）。
The server MUST NOT allow TLS session resumption for any logged out session.
サーバーは、ログアウトしたセッションのTLSセッションの再開を許可してはなりません（MUST NOT）。
The server SHOULD also revoke or delete any cookies associated with the session.
サーバーはまた、セッションに関連付けられたCookieを取り消しまたは削除する必要があります（SHOULD）。
The UA can get a "fresh" challenge from the server. In HOBA-http, it sends a POST message to ".well-known/hoba/getchal". If successful, the response MUST contain a fresh (base64url-encoded) HOBA challenge for this origin in the body of the response. Whitespace in the response MUST be ignored.
UAはサーバーから「新しい」チャレンジを取得できます。 HOBA-httpでは、POSTメッセージを「.well-known / hoba / getchal」に送信します。成功した場合、応答の本文には、このオリジンに対する新しい（base64urlでエンコードされた）HOBAチャレンジが含まれている必要があります。応答の空白は無視する必要があります。
RSA-SHA256 MUST be supported. HOBA implementations MUST use RSA-SHA256 if it is provided by the underlying cryptographic libraries. RSA-SHA1 MAY be used. RSA modulus lengths of at least 2048 bits SHOULD be used. RSA indicates the RSASSA-PKCS1-v1_5 algorithm defined in Section 8.2 of [RFC3447], and SHA-1 and SHA-256 are defined in [SHS]. Keys with moduli shorter than 2048 bits SHOULD only be used in cases where generating 2048-bit (or longer) keys is impractical, e.g., on very constrained or old devices.
RSA-SHA256をサポートする必要があります。 HOBA実装は、RSA-SHA256を使用する必要があります（基盤となる暗号化ライブラリによって提供される場合）。 RSA-SHA1を使用できます。少なくとも2048ビットのRSAモジュラス長を使用する必要があります。 RSAは、[RFC3447]のセクション8.2で定義されたRSASSA-PKCS1-v1_5アルゴリズムを示し、SHA-1およびSHA-256は[SHS]で定義されています。モジュラスが2048ビットより短いキーは、非常に制約されたデバイスや古いデバイスなど、2048ビット（またはそれ以上）のキーの生成が実用的でない場合にのみ使用してください。
Binding my CPK with someone else's account would be fun and profitable so SHOULD be appropriately hard. In particular, URLs or other values generated by the server as part of any CPK binding process MUST be hard to guess, for whatever level of difficulty is chosen by the server. The server SHOULD NOT allow a random guess to reveal whether or not an account exists.
私のCPKを他の誰かのアカウントにバインドすることは、楽しくて利益があるので、適切に難しいものであるべきです。特に、CPKバインディングプロセスの一部としてサーバーによって生成されたURLまたはその他の値は、サーバーがどのような難易度を選択しても、推測するのは困難です。サーバーは、アカウントが存在するかどうかをランダムな推測で明らかにすべきではありません（SHOULD NOT）。
If key binding was server selected, then a bad actor could bind different accounts belonging to the user from the network with possible bad consequences, especially if one of the private keys was compromised somehow.
キーバインディングがサーバーで選択されている場合、特に非公開キーの1つが何らかの形で危険にさらされている場合、悪意のあるアクターはネットワークからユーザーに属するさまざまなアカウントをバインドして、悪影響をもたらす可能性があります。
When the max-age parameter is not zero, then a HOBA signature has a property that is like a bearer token for the relevant number of seconds: it can be replayed for a server-selected duration. Similarly, for HOBA-js, signatures might be replayable depending on the specific implementation. The security considerations of [RFC6750] therefore apply in any case where the HOBA signature can be replayed. Server administrators can set the max-age to the minimum acceptable value in such cases, which would often be expected to be just a few seconds. There seems to be no reason to ever set the max-age more than a few minutes; the value ought also decrease over time as device capabilities improve. The administrator will most likely want to set the max-age to something that is not too short for the slowest signing device that is significant for that site.
max-ageパラメーターがゼロでない場合、HOBAシグニチャーには、該当する秒数の無記名トークンのようなプロパティーがあり、サーバーが選択した期間再生できます。同様に、HOBA-jsの場合、特定の実装によってはシグニチャが再生可能になる場合があります。したがって、[RFC6750]のセキュリティに関する考慮事項は、HOBA署名を再生できるすべての場合に適用されます。サーバー管理者は、そのような場合にmax-ageを最小許容値に設定できます。これは、ほんの数秒であると予想されることがよくあります。 max-ageを数分以上設定する理由はないようです。また、デバイスの機能が向上するにつれて、時間の経過とともに価値が低下するはずです。管理者は、そのサイトにとって重要な、最も遅い署名デバイスにとって短すぎない値にmax-ageを設定する可能性が高いでしょう。
HOBA does, to some extent, impact privacy and could be considered to represent a super-cookie to the server or to any entity on the path from UA to HTTP server that can see the HOBA signature. This is because we need to send a key identifier as part of the signature and that will not vary for a given key. For this reason, and others, it is strongly RECOMMENDED to only use HOBA over server-authenticated TLS and to migrate web sites using HOBA to only use "https" URLs.
HOBAはある程度プライバシーに影響を与え、サーバーまたはUAからHTTPサーバーへのパス上の、HOBA署名を見ることができるエンティティーへのスーパーCookieを表すと見なすことができます。これは、署名の一部としてキー識別子を送信する必要があるためであり、指定されたキーによって変化することはありません。このため、およびその他の理由から、サーバー認証されたTLSではなくHOBAのみを使用し、HOBAを使用して "https" URLのみを使用するようにWebサイトを移行することを強くお勧めします。
UAs SHOULD provide users a way to manage their CPKs. Ideally, there would be a way for a user to maintain their HOBA details for a site while at the same time deleting other site information such as cookies or non-HOBA HTML5 localStorage. However, as this is likely to be complex, and appropriate user interfaces counterintuitive, we expect that UAs that implement HOBA will likely treat HOBA information as just some more site data that would disappear should the user choose to "forget" that site.
UAはユーザーにCPKを管理する方法を提供する必要があります（SHOULD）。理想的には、ユーザーがサイトのHOBA詳細を維持すると同時に、Cookieや非HOBA HTML5 localStorageなどの他のサイト情報を削除する方法が存在します。ただし、これは複雑で適切なユーザーインターフェイスが直感に反する可能性が高いため、HOBAを実装するUAはHOBA情報を、ユーザーがそのサイトを「忘れた」場合に表示されなくなるいくつかのサイトデータとして扱うと考えられます。
Device identifiers are intended to specify classes of device in a way that can assist with registration and with presentation to the user of information about previous sessions, e.g., last login time. Device identifier types MUST NOT be privacy sensitive, with values that would allow tracking a user in unexpected ways. In particular, using a device identifier type that is analogous to the International Mobile Equipment Identifier (IMEI) would be a really bad idea and is the reason for the "MUST NOT" above. In that case, "mobile phone" could be an acceptable choice.
デバイス識別子は、前回のログイン時間など、以前のセッションに関する情報をユーザーに登録および提示できるように、デバイスのクラスを指定することを目的としています。デバイス識別子のタイプはプライバシーに配慮してはならず、予期しない方法でユーザーを追跡できる値を使用する必要があります。特に、International Mobile Equipment Identifier（IMEI）に類似したデバイス識別子タイプを使用することは非常に悪い考えであり、上記の「必須ではない」理由です。その場合、「携帯電話」は許容できる選択肢です。
If possible, implementations ought to encourage the use of device identifier values that are not personally identifying except for the user concerned; for example, "Alice's mobile" is likely to be chosen and is somewhat identifying, but "Alice's phone: UUID 1234-5567- 89abc-def0" would be a very bad choice.
可能な場合、実装は、関係するユーザーを除いて個人を識別しないデバイス識別子の値の使用を奨励する必要があります。たとえば、「アリスの携帯電話」が選択される可能性が高く、ある程度は識別できますが、「アリスの電話：UUID 1234-5567-89abc-def0」は非常に悪い選択です。
The use of localStorage (likely with a non-WebCrypto implementation of HOBA-js) will undoubtedly be a cause for concern. localStorage uses the same-origin model that says that the scheme, domain, and port define a localStorage instance. Beyond that, any code executing will have access to private keying material. Of particular concern are Cross-Site Scripting (XSS) attacks, which could conceivably take the keying material and use it to create UAs under the control of an attacker. XSS attacks are, in reality, devastating across the board since they can and do steal credit card information, passwords, perform illicit acts, etc. It's not evident that we are introducing unique threats from which cleartext passwords don't already suffer.
localStorageの使用（HOBA-jsの非WebCrypto実装での可能性が高い）は、疑いの余地なく問題の原因になります。 localStorageは、スキーム、ドメイン、ポートがlocalStorageインスタンスを定義するという同じ起源のモデルを使用します。それを超えて、実行するコードはすべて秘密鍵の資料にアクセスできます。特に懸念されるのはクロスサイトスクリプティング（XSS）攻撃であり、これはおそらくキー情報を取得し、それを使用して攻撃者の制御下でUAを作成する可能性があります。 XSS攻撃は、実際には、クレジットカード情報やパスワードを盗んだり、不正な行為をしたりすることができるため、全面的に破壊的です。クリアテキストのパスワードがまだ影響を受けていない独自の脅威を導入していることは明らかではありません。
Another source of concern is local access to the keys. That is, if an attacker has access to the UA itself, they could snoop on the key through a JavaScript console or find the file(s) that implement localStorage on the host computer. Again, it's not clear that we are worse in this regard because the same attacker could get at browser password files, etc., too. One possible mitigation is to encrypt the keystore with a password/PIN that the user supplies. This may sound counterintuitive, but the object here is to keep passwords off of servers to mitigate the multiplier effect of a large-scale compromise (e.g., [ThreatReport]) because of shared passwords across sites.
もう1つの懸念事項は、キーへのローカルアクセスです。つまり、攻撃者がUA自体にアクセスできる場合、JavaScriptコンソールを介してキーをスヌープするか、ホストコンピューターにlocalStorageを実装するファイルを見つけることができます。繰り返しになりますが、同じ攻撃者がブラウザのパスワードファイルなどにもアクセスできる可能性があるため、この点で私たちがさらに悪いことは明らかではありません。考えられる1つの緩和策は、ユーザーが提供するパスワード/ PINを使用してキーストアを暗号化することです。これは直観に反するように思えるかもしれませんが、ここでの目的は、サイト間でパスワードを共有するため、サーバーからパスワードを離して、大規模な侵害（[ThreatReport]など）の相乗効果を軽減することです。
It's worth noting that HOBA uses asymmetric keys and not passwords when evaluating threats. As various password database leaks have shown, the real threat of a password breach is not just to the site that was breached, it's also to all of the sites on which a user used the same password. That is, the collateral damage is severe because password reuse is common. Storing a password in localStorage would also have a similar multiplier effect for an attacker, though perhaps on a smaller scale than a server-side compromise: one successful crack gains the attacker potential access to hundreds if not thousands of sites the user visits. HOBA does not suffer from that attack multiplier since each asymmetric key pair is unique per site/UA/user.
脅威を評価する場合、HOBAはパスワードではなく非対称キーを使用することに注意してください。さまざまなパスワードデータベースリークが示しているように、パスワード侵害の本当の脅威は、侵害されたサイトだけでなく、ユーザーが同じパスワードを使用したすべてのサイトにもあります。つまり、パスワードの再利用が一般的であるため、副次的な被害は深刻です。 localStorageにパスワードを保存すると、攻撃者にとっても同様の乗数効果がありますが、サーバー側の侵害よりも規模は小さいかもしれません。1つのクラックが成功すると、攻撃者はユーザーがアクセスする数千のサイトではなくても数百のサイトにアクセスする可能性があります。各非対称キーペアはサイト/ UA /ユーザーごとに一意であるため、HOBAはその攻撃乗数の影響を受けません。
A shared UA with multiple accounts is possible if the account identifier is stored along with the asymmetric key pair binding them to one another. Multiple entries can be kept, one for each account, and selected by the current user. This, of course, is fraught with the possibility for abuse, since a server is potentially enrolling the device for a long period and the user may not want to have to be responsible for the credential for that long. To alleviate this problem, the user could request that the credential be erased from the browser. Similarly, during the enrollment phase, a user could request that the key pair only be kept for a certain amount of time or that it not be stored beyond the current browser session. However, all such features really ought to be part of the operating system or platform and not part of a HOBA implementation, so those are not discussed further.
複数のアカウントを持つ共有UAは、アカウント識別子がそれらを互いにバインドする非対称キーペアと共に保存されている場合に可能です。アカウントごとに1つずつ、複数のエントリを保持し、現在のユーザーが選択できます。もちろん、サーバーは長期間デバイスを登録している可能性があり、ユーザーはその資格情報に長期間責任を負う必要がない場合があるため、これは不正使用の可能性に満ちています。この問題を軽減するために、ユーザーは資格情報をブラウザーから消去するように要求できます。同様に、登録フェーズ中に、ユーザーはキーペアを特定の時間だけ保持すること、または現在のブラウザセッションを超えてキーペアを保存しないことを要求できます。ただし、そのような機能はすべて、オペレーティングシステムまたはプラットフォームの一部であり、HOBA実装の一部ではないため、これ以上は説明しません。
The repeated length fields in the HOBA-TBS structure are present in order to ensure that there is no possibility that the catenation of different input values can cause confusion that might lead to an attack, either against HOBA as specified here, or else an attack against some other protocol that reused this to-be-signed structure. Those fields ensure that the mapping from input fields to the HOBA-TBS string is an injective mapping.
HOBA-TBS構造の繰り返しの長さフィールドは、異なる入力値の連結が混乱を引き起こし、ここで指定されたHOBAに対する攻撃、またはそれに対する攻撃につながる可能性がないことを保証するために存在します。この署名対象の構造を再利用した他のプロトコル。これらのフィールドは、入力フィールドからHOBA-TBS文字列へのマッピングが単射マッピングであることを保証します。
IANA has made registrations and created new registries as described below.
IANAは、以下の説明に従って登録を行い、新しいレジストリを作成しました。
All new registries have been placed beneath a new "HTTP Origin-Bound Authentication (HOBA) Parameters" category.
すべての新しいレジストリは、新しい「HTTP Origin-Bound Authentication（HOBA）パラメータ」カテゴリの下に配置されています。
A new scheme has been registered in the HTTP Authentication Scheme Registry as follows:
新しいスキームは、次のようにHTTP認証スキームレジストリに登録されています。
Authentication Scheme Name: HOBA
認証スキーム名：HOBA
Reference: Section 3 of RFC 7486
参照：RFC 7486のセクション3
Notes (optional): The HOBA scheme can be used with either HTTP servers or proxies. When used in response to a 407 Proxy Authentication Required indication, the appropriate proxy authentication header fields are used instead, as with any other HTTP authentication scheme.
注（オプション）：HOBAスキームは、HTTPサーバーまたはプロキシのいずれかで使用できます。他のHTTP認証スキームと同様に、「407プロキシ認証が必要」の指示に応じて使用される場合は、代わりに適切なプロキシ認証ヘッダーフィールドが使用されます。
A new .well-known URI has been registered in the Well-Known URIs registry as described below.
以下に説明するように、新しい.well-known URIがWell-Known URIレジストリに登録されました。
URI Suffix: hoba
うり すっふぃｘ： ほば
Change Controller: IETF
コントローラの変更：IETF
Reference: Section 6 of RFC 7486
参照：RFC 7486のセクション6
Related Information: N/A
関連情報：なし
A new HOBA signature algorithms registry has been created as follows, with Specification Required as the registration procedure. New HOBA signature algorithms SHOULD be in use with other IETF Standards Track protocols before being added to this registry.
新しいHOBA署名アルゴリズムレジストリが次のように作成されました。登録手順は「仕様が必要です」です。新しいHOBA署名アルゴリズムは、このレジストリに追加する前に、他のIETF標準トラックプロトコルで使用する必要があります（SHOULD）。
Number Meaning Reference
----------- ------------------------------ ------------
0 RSA-SHA256 RFC 7486
1 RSA-SHA1 RFC 7486
RSA is defined in Section 8.2 of [RFC3447], and SHA-1 and SHA-256 are
defined in [SHS].
For this registry, the number column should contain a small positive integer. Following the ABNF in Figure 1, the maximum value for this is decimal 99.
このレジストリの場合、数値列には小さな正の整数を含める必要があります。図1のABNFに従って、これの最大値は10進数の99です。
A new HOBA Key Identifier Types registry has been created as follows, with Specification Required as the registration procedure.
新しいHOBA鍵識別子タイプレジストリが次のように作成され、登録手順として指定が必要です。
Number Meaning Reference
----------- ------------------------------ ------------
0 a hashed public key [RFC6698]
1 a URI [RFC3986]
2 an unformatted string, at the RFC 7486
user's/UA's whim
For the number 0, hashed public keys are as done in DNS-Based Authentication of Named Entities (DANE) [RFC6698].
数値0の場合、ハッシュされた公開鍵は、名前付きエンティティのDNSベースの認証（DANE）[RFC6698]と同じです。
For this registry, the number column should contain a small positive integer.
このレジストリの場合、数値列には小さな正の整数を含める必要があります。
A new HOBA Device Identifier Types registry has been created as follows, with Specification Required as the registration procedure.
新しいHOBAデバイス識別子タイプレジストリが次のように作成され、登録手順として指定が必要です。
The designated expert for this registry is to carefully pay attention to the notes on this field in Section 8.1, in particular, the "MUST NOT" stated therein.
このレジストリに指定されたエキスパートは、セクション8.1のこのフィールドに関する注記、特にそこに記載されている「MUST NOT」に注意を払うことです。
Number Meaning Reference
----------- ------------------------------ -----------
0 an unformatted string, at the RFC 7486
user's/UA's whim
For this registry, the number column should contain a small positive integer.
このレジストリの場合、数値列には小さな正の整数を含める必要があります。
A new identifier has been registered in the Permanent Message Header Field Names registry as described below.
以下で説明するように、新しい識別子が恒久メッセージヘッダーフィールド名レジストリに登録されました。
Header Field Name: Hobareg
ヘッダーフィールド名：Hobareg
Protocol: http (RFC 7230)
プロトコル：http（RFC 7230）
Status: experimental
ステータス：実験的
Author/Change controller: IETF
作成者/変更コントローラ：IETF
Reference: Section 6.1.1 of RFC 7486
参照：RFC 7486のセクション6.1.1
Related information: N/A
関連情報：なし
[RFC20] Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, October 1969, <http://www.rfc-editor.org/info/rfc20>.
[RFC20] Cerf、V。、「ネットワーク交換用のASCII形式」、STD 80、RFC 20、1969年10月、<http://www.rfc-editor.org/info/rfc20>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003, <http://www.rfc-editor.org/info/rfc3447>.
[RFC3447] Jonsson、J。およびB. Kaliski、「Public-Key Cryptography Standards（PKCS）＃1：RSA Cryptography Specifications Version 2.1」、RFC 3447、2003年2月、<http://www.rfc-editor.org/ info / rfc3447>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月、<http：//www.rfc- editor.org/info/rfc3986>。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006, <http://www.rfc-editor.org/info/rfc4648>.
[RFC4648] Josefsson、S。、「The Base16、Base32、およびBase64データエンコーディング」、RFC 4648、2006年10月、<http://www.rfc-editor.org/info/rfc4648>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月、<http://www.rfc-editor.org/info/rfc5234>。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月、<http://www.rfc-editor.org/info/rfc5246>。
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, April 2010, <http://www.rfc-editor.org/info/rfc5785>.
[RFC5785]ノッティンガム、M。およびE.ハマーラハブ、「Defining Well-Known Uniform Resource Identifiers（URIs）」、RFC 5785、2010年4月、<http://www.rfc-editor.org/info/rfc5785> 。
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, December 2011, <http://www.rfc-editor.org/info/rfc6454>.
[RFC6454] Barth、A。、「The Web Origin Concept」、RFC 6454、2011年12月、<http://www.rfc-editor.org/info/rfc6454>。
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, August 2012, <http://www.rfc-editor.org/info/rfc6698>.
[RFC6698] Hoffman、P。およびJ. Schlyter、「DNSベースの名前付きエンティティ（DANE）トランスポート層セキュリティ（TLS）プロトコルの認証：TLSA」、RFC 6698、2012年8月、<http：//www.rfc- editor.org/info/rfc6698>。
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, October 2012, <http://www.rfc-editor.org/info/rfc6750>.
[RFC6750]ジョーンズ、M。およびD.ハート、「OAuth 2.0 Authorization Framework：Bearer Token Usage」、RFC 6750、2012年10月、<http://www.rfc-editor.org/info/rfc6750>。
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014, <http://www.rfc-editor.org/info/rfc7231>.
[RFC7231]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Semantics and Content」、RFC 7231、2014年6月、<http://www.rfc-editor.org/info/rfc7231>。
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014, <http://www.rfc-editor.org/info/rfc7235>.
[RFC7235]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Authentication」、RFC 7235、2014年6月、<http://www.rfc-editor.org/info/rfc7235>。
[SHS] NIST, "Secure Hash Standard (SHS)", FIPS PUB 180-4, March 2012.
[SHS] NIST、「Secure Hash Standard（SHS）」、FIPS PUB 180-4、2012年3月。
[Bonneau] Bonneau, J., "The Science of Guessing: Analyzing an Anonymized Corpus of 70 Million Passwords", IEEE Symposium on Security and Privacy 538-552, 2012.
[Bonneau] Bonneau、J。、「The Science of Guessing：Analyzing an Anonymized Corpus of 70 Million Passwords」、IEEE Symposium on Security and Privacy 538-552、2012。
[MI93] Mitchell, C. and A. Thomas, "Standardising authentication protocols based on public key techniques", Journal of Computer Security Volume 2, 23-36, 1993.
[MI93] Mitchell、C。およびA. Thomas、「公開鍵技術に基づく認証プロトコルの標準化」、Journal of Computer Security Volume 2、23-36、1993。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005, <http://www.rfc-editor.org/info/rfc4086>.
[RFC4086] Eastlake 3rd、D.、Schiller、J.、and S. Crocker、 "Randomness Requirements for Security"、BCP 106、RFC 4086、June 2005、<http://www.rfc-editor.org/info/ rfc4086>。
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, April 2011, <http://www.rfc-editor.org/info/rfc6265>.
[RFC6265] Barth、A。、「HTTP State Management Mechanism」、RFC 6265、2011年4月、<http://www.rfc-editor.org/info/rfc6265>。
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, September 2011, <http://www.rfc-editor.org/info/rfc6376>.
[RFC6376] Crocker、D.、Ed。、Hansen、T.、Ed。、and M. Kucherawy、Ed。、 "DomainKeys Identified Mail（DKIM）Signatures"、STD 76、RFC 6376、September 2011、<http：/ /www.rfc-editor.org/info/rfc6376>。
[ThreatReport] Sophos, "Security Threat Report 2013", January 2013, <http://www.sophos.com/en-us/medialibrary/pdfs/other/ sophossecuritythreatreport2013.pdf>.
[ThreatReport]ソフォス、「セキュリティ脅威レポート2013」、2013年1月、<http://www.sophos.com/en-us/medialibrary/pdfs/other/ sophossecuritythreatreport2013.pdf>。
By far, the most common mechanism for web authentication is passwords that can be remembered by the user, called "human-memorable passwords". There is plenty of good research on how users typically use human-memorable passwords (e.g., see [Bonneau]), but some of the highlights are that users typically try hard to reuse passwords on as many web sites as possible, and that web sites often use either email addresses or users' names as the identifiers that go with these passwords.
はるかに、Web認証の最も一般的なメカニズムは、「人間が記憶できるパスワード」と呼ばれる、ユーザーが記憶できるパスワードです。ユーザーが通常人間が記憶できるパスワードをどのように使用するかについては多くの良い調査があります（たとえば、[Bonneau]を参照）。ハイライトのいくつかは、ユーザーが通常、できるだけ多くのWebサイトでパスワードを再利用しようと努力していること、およびそのWebサイトです。多くの場合、これらのパスワードに使用する識別子として、電子メールアドレスまたはユーザー名を使用します。
If an attacker gets access to the database of memorizable passwords, that attacker can impersonate any of the users. Even if the breach is discovered, the attacker can still impersonate users until every password is changed. Even if all the passwords are changed or at least made unusable, the attacker now possesses a list of likely username/password pairs that might exist on other sites.
攻撃者が覚えやすいパスワードのデータベースにアクセスした場合、その攻撃者は任意のユーザーになりすますことができます。違反が発見されても、攻撃者はすべてのパスワードが変更されるまでユーザーになりすますことができます。すべてのパスワードが変更された場合、または少なくとも使用不可になった場合でも、攻撃者は他のサイトに存在する可能性のあるユーザー名とパスワードのペアのリストを所有しています。
Using memorizable passwords on unencrypted channels also poses risks to the users. If a web site uses either the HTTP Basic authentication method, or an HTML form that does no cryptographic protection of the password in transit, a passive attacker can see the password and immediately impersonate the user. If a hash-based authentication scheme such as HTTP Digest authentication is used, a passive attacker still has a high chance of being able to determine the password using a dictionary of known passwords.
暗号化されていないチャネルで覚えやすいパスワードを使用することも、ユーザーにリスクをもたらします。 WebサイトがHTTP基本認証方式、または転送中のパスワードを暗号で保護しないHTMLフォームのいずれかを使用している場合、受動的な攻撃者がパスワードを確認し、すぐにユーザーになりすますことができます。 HTTPダイジェスト認証などのハッシュベースの認証スキームが使用されている場合でも、パッシブ攻撃者は既知のパスワードの辞書を使用してパスワードを特定できる可能性が高くなります。
Note that passwords that are not human-memorable are still subject to database attack, though they are of course unlikely to be reused across many systems. Similarly, database attacks of some form or other will work against any password-based authentication scheme, regardless of the cryptographic protocol used. So for example, zero-knowledge or Password-Authenticated Key Exchange (PAKE) schemes, though making use of elegant cryptographic protocols, remain as vulnerable to what is clearly the most common exploit seen when it comes to passwords. HOBA is, however, not vulnerable to database theft.
人間が記憶できないパスワードは、依然としてデータベース攻撃の対象となることに注意してください。ただし、パスワードが多くのシステムで再利用される可能性はありません。同様に、何らかの形式のデータベース攻撃は、使用されている暗号化プロトコルに関係なく、パスワードベースの認証スキームに対して機能します。したがって、たとえば、ゼロナレッジまたはパスワード認証キー交換（PAKE）スキームは、エレガントな暗号化プロトコルを利用していますが、パスワードに関して見られる最も一般的なエクスプロイトに対して明らかに脆弱です。ただし、HOBAはデータベースの盗難に対して脆弱ではありません。
The following values show an example of HOBA-http authentication to the origin "https://example.com:443". Carriage returns have been added and need to be removed to validate the example.
次の値は、オリジン "https://example.com:443"に対するHOBA-http認証の例を示しています。キャリッジリターンが追加されたため、例を検証するには削除する必要があります。
Public Key:
公開鍵：
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAviE8fMrGIPZN9up94M28
6o38B99fsz5cUqYHXXJlnHIi6gGKjqLgn3P7n4snUSQswLExrkhSr0TPhRDuPH_t
fXLKLBbh17ofB7t7shnPKxmyZ69hCLbe7pB1HvaBzTxPC2KOqskDiDBOQ6-JLHQ8
egXB14W-641RQt0CsC5nXzo92kPCdV4NZ45MW0ws3twCIUDCH0nibIG9SorrBbCl
DPHQZS5Dk5pgS7P5hrAr634Zn4bzXhUnm7cON2x4rv83oqB3lRqjF4T9exEMyZBS
L26m5KbK860uSOKywI0xp4ymnHMc6Led5qfEMnJC9PEI90tIMcgdHrmdHC_vpldG
DQIDAQAB
-----END PUBLIC KEY-----
Origin: https://example.com:443
Key Identifier: vesscamS2Kze4FFOg3e2UyCJPhuQ6_3_gzN-k_L6t3w
キー識別子：vesscamS2Kze4FFOg3e2UyCJPhuQ6_3_gzN-k_L6t3w
Challenge: pUE77w0LylHypHKhBqAiQHuGC751GiOVv4/7pSlo9jc=
Signature algorithm: RSA-SHA256 ("0")
署名アルゴリズム：RSA-SHA256（ "0"）
Nonce: Pm3yUW-sW5Q
ナンス：Pm3yUW-sW5Q
Signature:
署名：
VD-0LGVBVEVjfq4xEd35FjnOrIqzJ2OQMx5w8E52dgVvxFD6R0ryEsHcD31ykh0i 4YIzIHXirx7bE4x9yP-9fMBCEwnHJsYwYQhfRpmScwAz-Ih1Hn4yORTb-U66miUz q04ZgTHm4jAj45afU20wYpGXY2r3W-FRKc6J6Glv_zI_ROghERalxgXG-QVGZrKP tG0V593Yf9IPnFSpLyW6fnxscCMWUA9T-4NjMdypI-Ze4HsC9J06tRTOunQdofr9 6ZJ2i9LE6uKSUDLCD2oeEeSEvUR--4OGtrgjzYysHZkdVSxAi7OoQBK34EUWg9kI S13qQA43m4IMExkbApqrSg
CEO 0LGVBVEVjfq4xEd35FjnOrIqzJ2OQMx5w8E52dgVvxFD6R0ryEsHcD31ykh0i 4YIzIHXirx7bE4x9yP-9fMBCEwnHJsYwYQhfRpmScwAz-Ih1Hn4yORTb-U66miUz q04ZgTHm4jAj45afU20wYpGXY2r3W-FRKc6J6Glv_zI_ROghERalxgXG-QVGZrKP tG0V593Yf9IPnFSpLyW6fnxscCMWUA9T-4NjMdypI-Ze4HsC9J06tRTOunQdofr9 6ZJ2i9LE6uKSUDLCD2oeEeSEvUR - 4OGtrgjzYysHZkdVSxAi7OoQBK34EUWg9kI S13qQA43m4IMExkbApqrSg
Authorization Header:
承認ヘッダー：
Authorization: HOBA result="vesscamS2Kze4FFOg3e2UyCJPhuQ6_3_gzN-k_L6t3w.pUE77w0LylHypHKhBqAiQHuGC751GiOVv4/7pSlo9jc=.Pm3yUW-sW5Q .VD-0LGVBVEVjfq4xEd35FjnOrIqzJ2OQMx5w8E52dgVvxFD6R0ryEsHcD31ykh0 i4YIzIHXirx7bE4x9yP-9fMBCEwnHJsYwYQhfRpmScwAz-Ih1Hn4yORTb-U66miU zq04ZgTHm4jAj45afU20wYpGXY2r3W-FRKc6J6Glv_zI_ROghERalxgXG-QVGZrK PtG0V593Yf9IPnFSpLyW6fnxscCMWUA9T-4NjMdypI-Ze4HsC9J06tRTOunQdofr 96ZJ2i9LE6uKSUDLCD2oeEeSEvUR--4OGtrgjzYysHZkdVSxAi7OoQBK34EUWg9k IS13qQA43m4IMExkbApqrSg"
認可：HOBA結果= "vesscamS2Kze4FFOg3e2UyCJPhuQ6_3_gzN-k_L6t3w.pUE77w0LylHypHKhBqAiQHuGC751GiOVv4 / 7pSlo9jc = .Pm3yUW-sW5Q .VD-0LGVBVEVjfq4xEd35FjnOrIqzJ2OQMx5w8E52dgVvxFD6R0ryEsHcD31ykh0 i4YIzIHXirx7bE4x9yP-9fMBCEwnHJsYwYQhfRpmScwAz-Ih1Hn4yORTb-U66miU zq04ZgTHm4jAj45afU20wYpGXY2r3W-FRKc6J6Glv_zI_ROghERalxgXG-QVGZrK PtG0V593Yf9IPnFSpLyW6fnxscCMWUA9T-4NjMdypI-Ze4HsC9J06tRTOunQdofr 96ZJ2i9LE6uKSUDLCD2oeEeSEvUR - 4OGtrgjzYysHZkdVSxAi7OoQBK34EUWg9k IS13qQA43m4IMExkbApqrSg"
Acknowledgements
謝辞
Thanks to the following for good comments received during the preparation of this specification: Richard Barnes, David Black, Alissa Cooper, Donald Eastlake, Amos Jeffries, Benjamin Kaduk, Watson Ladd, Barry Leiba, Matt Lepinski, Ilari Liusvaara, James Manger, Alexey Melnikov, Kathleen Moriarty, Yoav Nir, Mark Nottingham, Julian Reschke, Pete Resnick, Michael Richardson, Yaron Sheffer, and Michael Sweet. All errors and stupidities are of course the editors' fault.
この仕様の準備中に受け取った良いコメントに対する感謝：リチャードバーンズ、デビッドブラック、アリッサクーパー、ドナルドイーストレイク、アモスジェフリーズ、ベンジャミンカドゥック、ワトソンラッド、バリーレイバ、マットレピンスキー、イラリリウスヴァーラ、ジェームズマンガー、アレクセイメルニコフ、キャスリーン・モリアーティ、ヨーブ・ニール、マーク・ノッティンガム、ジュリアン・レシュケ、ピート・レズニック、マイケル・リチャードソン、ヤロン・シェファー、マイケル・スウィート。もちろん、すべてのエラーと愚かさは編集者の責任です。
Authors' Addresses
著者のアドレス
Stephen Farrell Trinity College Dublin Dublin 2 Ireland
スティーブンファレルトリニティカレッジダブリンダブリン2アイルランド
Phone: +353-1-896-2354
EMail: stephen.farrell@cs.tcd.ie
Paul Hoffman VPN Consortium
ポールホフマンVPNコンソーシアム
EMail: paul.hoffman@vpnc.org
Michael Thomas Phresheez
ミントトーマスフレッシュ
EMail: mike@phresheez.com