-
Notifications
You must be signed in to change notification settings - Fork 2
/
Copy pathdraft-ietf-jose-use-cases-03.xml
1921 lines (1728 loc) · 121 KB
/
draft-ietf-jose-use-cases-03.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="UTF-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-ietf-jose-use-cases-03"
ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="JOSE Use Cases">Use Cases and Requirements for JSON Object
Signing and Encryption (JOSE)</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<author fullname="Richard Barnes" initials="R.L." surname="Barnes">
<organization>BBN Technologies</organization>
<address>
<postal>
<street>1300 N 17th St</street>
<city>Arlington</city>
<region>VA</region>
<code>22209</code>
<country>US</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<date year="2013"/>
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<area>SEC</area>
<workgroup>JOSE</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>JWS, JWE, JWK, JWA, JWT, CMS, S/MIME, JOSE, XMPP, ALTO, OAuth</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>
多くのインターネット上のアプリケーションは, ネットワークレイヤーやトランスポートレイヤーでのセキュリティメカニズムに加えて, オブジェクトベースのセキュリティメカニズムを必要とする.
かつては Cryptographic Message Syntax (CMS) が ASN.1 に基づいたバイナリレベルでのセキュアオブジェクトフォーマットを提供していた.
しかしながら時代の変化とともに ASN.1 のようなバイナリオブジェクトエンコーディングは時代遅れとなり, JSON などのテキストベースエンコーディングが主流となった.
本ドキュメントでは, 現在実用化されている様々なアプリケーションレイヤーセキュリティメカニズムをもとに, JSON ベースのセキュアオブジェクトフォーマットの各種ユースケースと要件をまとめる.
</t>
<!--
<t>Many Internet applications have a need for object-based security
mechanisms in addition to security mechanisms at the network layer or
transport layer. In the past, the Cryptographic Message Syntax (CMS) has
provided a binary secure object format based on ASN.1. Over time, the
use of binary object encodings such as ASN.1 has been overtaken by
text-based encodings, for example JavaScript Object Notation. This
document defines a set of use cases and requirements for a secure object
format encoded using JavaScript Object Notation (JSON), drawn from a variety of
application security mechanisms currently in development.</t>
-->
</abstract>
</front>
<middle>
<section anchor="intro-sec" title="Introduction">
<t>
インターネット上のアプリケーションは, インターネットを構成する各レイヤーにおけるセキュリティメカニズムを活用できる.
多くのアプリケーションは, IPSec や TLS などの, チャネルベースのセキュリティに大きく依存している.
これらのセキュリティメカニズムは, アプリケーションデータが流れる IP レイヤーやトランスポートレイヤーにおいてセキュアチャネルを確立するものである.
<xref target="RFC4301"/>
<xref target="RFC5246"/>
しかしながらこれらのセキュリティメカニズムは状況によっては end-to-end のセキュリティを保証しない.
例えば, アプリケーションレイヤーに仲介者が存在する場合は, チャネルベースのセキュリティプロトコルでは, 仲介者同士の間を流れるメッセージを改竄しようとするアタッカーからの攻撃は防ぐことができても, 仲介者自身がメッセージを改竄 / 盗聴することは防げない.
こういったケースでは, オブジェクトベースのセキュリティメカニズムを用いてアプリケーションデータをセキュアオブジェクトに埋め込み, 信頼できない主体がデータを扱ってもセキュリティを確保できるようにする必要がある.
</t>
<!--
<t>Internet applications rest on the layered architecture of the
Internet, and take advantage of security mechanisms at all layers. Many
applications rely primarily on channel-based security technologies such as
IPsec and TLS,
which create a secure channel at the IP layer or transport layer over
which application data can flow <xref target="RFC4301"/><xref
target="RFC5246"/>. These mechanisms, however, cannot provide end-to-end
security in some cases. For example, in protocols with application-layer
intermediaries, channel-based security protocols would protect messages
from attackers between intermediaries, but not from the intermediaries
themselves. These cases require object-based security technologies,
which embed application data within a secure object that can be safely
handled by untrusted entities.</t>
-->
<t>
上記のようなプロトコルとして現在最も広く利用されているのは, Secure/Multipurpose Internet Mail Extensions (S/MIME) である.
Email メッセージは, 通常一連の Mail Transfer Agents (MTA) を仲介者として, 受信者に届けられる.
これら MTA は通常チャネルベースのセキュリティメカニズムを用いて通信を保護する (例: STARTTLS <xref target="RFC3207"/>) が, こういった仕組みは MTA 自身がメッセージを改竄 / 盗聴することを防ぐものではない.
信頼できない MTA が存在する状況でも end-to-end のセキュリティを確保するには, S/MIME を利用してメッセージボディーをセキュアオブジェクトに内包し, 情報の機密性 (confidentiality), 完全性 (integrity), 送信者認証 (data origin authentication) を確保することが有効である.
</t>
<!--
<t>The most well-known example of such a protocol today is the use of
Secure/Multipurpose Internet Mail Extensions (S/MIME) protections within
the email system <xref target="RFC5751"/><xref target="RFC5322"/>. An
email message typically passes through a series of intermediate Mail
Transfer Agents (MTAs) en route to its destination. While these MTAs
often apply channel-based security protections to their interactions
(e.g., STARTTLS <xref target="RFC3207"/>), these protections do not prevent the
MTAs from interfering with the message. In order to provide end-to-end
security protections in the presence of untrusted MTAs, mail users can
use S/MIME to embed message bodies in a secure object format that can
provide confidentiality, integrity, and data origin authentication.</t>
-->
<t>
S/MIME は Cryptographic Message Syntax for secure objects (CMS) <xref target="RFC5652"/> をベースにしている.
CMS は Abstract Syntax Notation 1 (ASN.1) を用いて定義され, 慣習的に ASN.1 Distinguished Encoding Rules (DER) でエンコードされる.
DER では保護されるメッセージと関連パラメーターはバイナリエンコーディングされる. <xref target="ITU.X690.2002"/>
近年では ASN.1 (やその他の汎用オブジェクトに対するバイナリエンコーディング) が利用されるケースは減少し, Extensible Markup Language (XML) <xref target="W3C.REC-xml"/> や JavaScript Object Notation (JSON) <xref target="RFC4627"/> といったテキストベースのフォーマットの利用が増加している.
</t>
<!--
<t>S/MIME is based on the Cryptographic Message Syntax for secure
objects (CMS) <xref target="RFC5652"/>. CMS is defined using Abstract
Syntax Notation 1 (ASN.1) and traditionally encoded using the ASN.1
Distinguished Encoding Rules (DER), which define a binary encoding of
the protected message and associated parameters <xref
target="ITU.X690.2002"/>. In recent years, usage of ASN.1 has decreased
(along with other binary encodings for general objects), while more
applications have come to rely on text-based formats such as the
Extensible Markup Language (XML) <xref target="W3C.REC-xml"/> or the JavaScript Object Notation
(JSON) <xref target="RFC4627"/>.</t>
-->
<t>
最近の多くのアプリケーションは ASN.1 オブジェクトよりも遥かにテキストベースフォーマットのオブジェクトの処理に長けており, そもそも ASN.1 オブジェクトを処理できないものも多い.
オブジェクトベースのセキュリティの実装を単純化するため, IETF JSON Object Signing and Encryption (JOSE) ワーキンググループでは JSON ベースのセキュアオブジェクトフォーマットを策定している.
その名前が示す通り, ここで策定されているのは JSON エンコードされたオブジェクトの機密性 (confidentiality), 完全性 (integrity) を確保するためのフォーマットである.
しかしながら, ワーキンググループ内での議論の結果, JOSE で定義されるフォーマットを利用するアプリケーションごとに, そのフォーマットに対する要件が異なることも分かった.
よって本ドキュメントでは, JOSE フォーマットを利用する可能性のあるアプリケーションを想定し, セキュリティメカニズムとオブジェクトエンコーディングに対する要件をまとめる.
</t>
<!--
<t>Many current applications thus have much more robust support for
processing objects in these text-based formats than ASN.1 objects;
indeed, many lack the ability to process ASN.1 objects at all. To
simplify the addition of object-based security features to these
applications, the IETF JSON Object Signing and Encryption (JOSE) working
group has been chartered to develop a secure object format based on
JSON. While the basic requirements for this object format are
straightforward -- namely, confidentiality and integrity mechanisms,
encoded in JSON -- discussions in the working group indicated that
different applications hoping to use the formats defined by JOSE have
different requirements. This document summarizes the use cases for JOSE
envisioned by those potential applications and the resulting requirements for
security mechanisms and object encodings.</t>
-->
<t>
XML を利用するシステムでは, XML ベースのオブジェクトベースセキュリティメカニズムである XML Digital Signatures および XML Encryption を利用するものもある.
<xref target="W3C.xmldsig-core"/>
<xref target="W3C.xmlenc-core"/>
これらは SAML <xref target="OASIS.saml-core-2.0-os"/> や WS-Federation <xref target="WS-Federation"/> などのセキュリティトークンや CAP 緊急アラートフォーマット <xref target="CAP"/> での利用を想定して定義されたものである.
しかし現実には XML ベースのセキュアオブジェクトフォーマットは ASN.1 と同レベルの複雑性を持ち, ASN.1 を扱えない / 扱いたくないデベロッパーがこういった XML ベースのセキュリティメカニズムを利用することは考えづらい.
こういった背景が, JSON ベースのセキュアオブジェクトフォーマット策定に至る動機となっている.
JSON ベースであれば, 実装や利用も容易であり, 開発者はわずかな労力とツールのみでそれを取り入れることができるであろう.
</t>
<!--
<t>Some systems that use XML have specified the use of XML-based
security mechanisms for object security, namely XML Digital Signatures
and XML Encryption <xref target="W3C.xmldsig-core"/><xref
target="W3C.xmlenc-core"/>. These mechanisms are defined
for use with several security token systems (e.g.,
SAML <xref target="OASIS.saml-core-2.0-os"/> and
WS-Federation <xref target="WS-Federation"/>) and the CAP
emergency alerting format <xref target="CAP"/>. In practice, however,
XML-based secure object formats introduce similar levels of complexity
to ASN.1, so developers that lack the tools or motivation to handle
ASN.1 aren't likely to use XML security either. This situation motivates
the creation of a JSON-based secure object format that is simple enough
to implement and deploy that it can be easily adopted by developers with
minimal effort and tools.</t>
-->
</section>
<section anchor="def-sec" title="Definitions">
<!--
<t>The key words "must", "must NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
-->
<t>この文書は<xref target="RFC4949"/>に記載される標準セキュリティ用語を広範囲に活用するものである.
JOSEとCMSのユースケースは似ていることから, いくつかのCMSのコンセプトについて<xref target="RFC5652"/>を例に説明する.</t>
<!--
<t>This document makes extensive use of standard security terminology
<xref target="RFC4949"/>. In addition, because the use cases for JOSE
and CMS are similar, we will sometimes make analogies to some CMS
concepts <xref target="RFC5652"/>.</t>
-->
<t>JOSEワーキンググループでは３つのJSONオブジェクトフォーマットを定義する.
<!--
<t>The JOSE working group charter calls for the group to define three
basic JSON object formats:
-->
<list style="numbers">
<t>機密性保護オブジェクトフォーマット</t>
<!--<t>Confidentiality-protected object format</t>-->
<t>完全性保護オブジェクトフォーマット</t>
<!--<t>Integrity-protected object format</t>-->
<t>鍵表現フォーマット</t>
<!--<t>A format for expressing keys</t>-->
</list>
この文書では, 上記をそれぞれ"署名済みオブジェクトフォーマット", "暗号化オブジェクトフォーマット", "鍵フォーマット"と呼ぶ.
これらのフォーマットを表現することを目的としたJOSEワーキンググループの仕様はそれぞれJSON Web Signature (JWS)<xref target="I-D.ietf-jose-json-web-signature"/>, JSON Web Encryption (JWE)<xref target="I-D.ietf-jose-json-web-encryption"/>, JSON Web Key (JWK)<xref target="I-D.ietf-jose-json-web-key"/>である.
JWS, JWE, JWKで使用されるアルゴリズムやアルゴリズム識別子はJSON Web Alogrithms (JWA) <xref target="I-D.ietf-jose-json-web-algorithms"/> で定義されている.
<!--In this document, we will refer to these as
the "signed object format",
the "encrypted object format",
and the "key format", respectively.
The JOSE working group items intended to describe these formats are
JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK),
respectively <xref target="I-D.ietf-jose-json-web-signature"/>
<xref target="I-D.ietf-jose-json-web-encryption"/>
<xref target="I-D.ietf-jose-json-web-key"/>.
Algorithms and algorithm identifiers used by JWS, JWE, and JWK are defined in
JSON Web Algorithms (JWA) <xref target="I-D.ietf-jose-json-web-algorithms"/>.-->
</t>
<t>通常, 非対称/対称な処理を区別する必要がない場面では, 共通鍵を使ったメッセージ認証コード(MAC) と公開鍵暗号を含むデジタル署名についても同様に"署名", "シグネチャ"などの用語を用いる</t>
<!--<t>In general, where there is no need to distinguish between asymmetric and
symmetric operations, we will use the terms "signing", "signature", etc.
to denote both true digital signatures involving asymmetric cryptography
as well as message authentication codes using symmetric keys (MACs).</t>-->
<t>セキュアオブジェクトの存続期間には, オブジェクトを生成するエンティティ (例：ペイロードを暗号化もしくは署名する側) とオブジェクトを利用するエンティティ (例：復号化, 検証をする側) の２つの基本的なロールが存在する.
これらのロールをそれぞれ"送信者", "受信者"と呼ぶことにする.
要件やユースケースによってはこれらのロールを単一エンティティが担うことを明記するかもしれないが, 同一ロールに複数のエンティティが存在する可能性があることに留意すること.
たとえば, メッセージは複数の送信者によって署名されたり, 複数の受信者によって復号化される可能性がある.</t>
<!--<t>In the lifespan of a secure object, there are two basic roles, an
entity that creates the object (e.g., encrypting or signing a payload),
and an entity that uses the object (decrypting, verifying). We will
refer to these roles as "sender" and "recipient", respectively. Note
that while some requirements and use cases may refer to these as single
entities, each object may have multiple entities in each role. For
example, a message may be signed by multiple senders, or decrypted by
multiple recipients.</t>-->
</section>
<section anchor="basic-sec" title="Basic Requirements">
<t>
言うまでもなく, 暗号化および署名済みオブジェクトフォーマットに対し, 機密性のためには対称あるいは非対称暗号化, 完全性保護のためにはMACあるいはデジタル署名といった, 適切な暗号メカニズムを用いることで, 必要な保護が形成される.
両方のケースで, 対称および非対称処理の両方のサポートがJOSEフォーマットには必要である.
<list style="symbols">
<t>
JOSE暗号化オブジェクトフォーマットは, 送信者と受信者が対称鍵を共有しているケースでのオブジェクト暗号化をサポートしなければならない.
</t>
<t>
JOSE暗号化オブジェクトフォーマットは, 送信者が受信者の公開鍵のみを所持しているケースでのオブジェクト暗号化をサポートしなければならない.
</t>
<t>
JOSE署名済みオブジェクトフォーマットは, 送信者と受信者が対称鍵のみを共有しているケースでのメッセージ認証コード (MAC) を用いた完全性保護をサポートしなければならない.
</t>
<t>
JOSE署名済みオブジェクトフォーマットは, 受信者が送信者の公開鍵のみを所持しているケースでのデジタル署名を用いた完全性保護をサポートしなければならない.
</t>
</list>
</t>
<!--
<t>Obviously, for the encrypted and signed object formats, the necessary
protections will be created using appropriate cryptographic mechanisms:
symmetric or asymmetric encryption for confidentiality and MACs or
digital signatures for integrity protection. In both cases, it is
necessary for the JOSE format to support both symmetric and asymmetric
operations.<list style="symbols">
<t>The JOSE encrypted object format must support object encryption
in the case where the sender and receiver share a symmetric key.</t>
<t>The JOSE encrypted object format must support object encryption
in the case where the sender has only a public key for the
receiver.</t>
<t>The JOSE signed object format must support integrity protection using
Message Authentication Codes (MACs), for the case where the sender
and receiver share only a symmetric key.</t>
<t>The JOSE signed object format must support integrity protection using
digital signatures, for the case where the receiver has only a
public key for the sender.</t>
</list></t>
-->
<t>
いくつかのアプリケーションでは, JOSEオブジェクトの処理に用いる鍵が, JOSEオブジェクトの中で直接提示されるのではなく, アプリケーションのコンテキストを通じて提示される.
しかし, 混乱を避けるために, 必要なコンテキストが不足しているエンドポイントは, 不足を認識し, 問題なく失敗処理を行える必要がある.
鍵以外, JOSEオブジェクトは事前ネゴシエーションをサポートしない.
全ての暗号パラメータはJOSEオブジェクトの中に直接記述されなければならない.
<list style="symbols">
<t>
JOSE署名済みおよび暗号化オブジェクトフォーマットは, 対象のオブジェクトの処理に必要な鍵を持っているかどうか, そしてその鍵はそのオブジェクト自身によって提示されているか, あるいはなんらかのout-of-bandメカニズムによって提示されているかどうかについて実装が認識するためのプロセスを定義しなければならない.
</t>
<t>
JOSEで利用される各アルゴリズムについて, そのアルゴリズムを使用するJOSEオブジェクトが内包しなければならないパラメータを定義する必要がある.
</t>
</list>
</t>
<!--
<t>In some applications, the key used to process a JOSE object is indicated
by application context, instead of directly in the JOSE object. However,
in order to avoid confusion, endpoints that lack the necessary context need
to be able to recognize this and fail cleanly. Other than keys, JOSE objects
do not support pre-negotiation; all cryptographic parameters must be expressed
directly in the JOSE object.
<list style="symbols">
<t>The JOSE signed and encrypted object formats must define the process
by which an implementation recognizes whether it has the key required
to process a given object, whether the key is specified by the
object or by some out-of-band mechanism.</t>
<t>Each algorithm used for JOSE must define which parameters are
required to be present in a JOSE object using that algorithm.</t>
</list>
</t>
-->
<t>
二つのエンティティが複数のJOSEオブジェクトを交換しようとするケースで, 全てのJOSEオブジェクトで個々にパラメータを記述しなくても済むように, いくつかのパラメータについて事前にネゴシエーションをすることは有用かもしれない.
しかし, 事前ネゴシエーションをサポートしないエンドポイントと混同しないように, これらのケースでは事前にネゴシエーションされたパラメータを使用していることを示すことは有益である.
<list style="symbols">
<t>
オブジェクトの処理に事前ネゴシエーションされたパラメータが使用されることを示すことができるように, 基本のJOSE署名済みおよび暗号化オブジェクトフォーマットを拡張できるようにすべきである.
この拡張は, どのパラメータが使用されるのかを示す手段も提供すべきである.
</t>
</list>
</t>
<!--
<t>In cases where two entities are going to be exchanging several JOSE
objects, it might be helpful to pre-negotiate some parameters so that
they do not have to be signaled in every JOSE object. However,
so as not to confuse endpoints that do not support pre-negotiation,
it is useful to signal when pre-negotiated parameters are in use in those cases.
<list style="symbols">
<t>It should be possible to extend the base
JOSE signed and encrypted object formats
to indicate that pre-negotiated parameters are to be used to
process the object. This extension should also provide a means of indicating of
which parameters are to be used.</t>
</list>
</t>
-->
<t>
鍵フォーマットの目的は, 暗号メッセージ処理用の符号化された鍵を使用するために十分な情報を受信者に提供することである.
そのため, 時には純粋な鍵だけではなく追加のパラメータを含める必要がある.
</t>
<!--
<t>The purpose of the key format is to provide the recipient with
sufficient information to use the encoded key to process cryptographic
messages. Thus it is sometimes necessary to include additional parameters along
with the bare key.</t>
-->
<t>
<list style="symbols">
<t>
JOSE鍵フォーマットは符号化された鍵を使用するために必要な全てのアルゴリズムパラメータを含めることが出来なければならない.
そのパラメータには, アルゴリズムで必要となる追加のパラメータ (例: 楕円曲線パラメータ) とともに, その鍵が使用されるアルゴリズムの識別子も含まれる.
</t>
</list>
</t>
<!--
<t><list style="symbols">
<t>The JOSE key format must enable inclusion of all algorithm parameters
necessary to use the encoded key, including an identifier for the
algorithm with which the key is used as well as any additional
parameters required by the algorithm (e.g., elliptic curve
parameters).</t>
</list></t>
-->
</section>
<section anchor="app-req-sec" title="Requirements on Application Protocols">
<t>
各 JOSE セキュアオブジェクトフォーマット仕様は, 保護対象コンテンツに対する暗号処理を詳細に定め, JOSE オブジェクトの受信者が, 適切に暗号化されたオブジェクトを復号したり, 署名を検証したりできることを保証する.
しかしながら, JOSE を利用する各アプリケーション側でも, 以下のような点については独自に定める必要がある.
<list style="symbols">
<t>保護対象となるアプリケーションコンテンツ</t>
<t>利用される暗号アルゴリズム</t>
<t>エンティティ間での鍵確立手法</t>
<t>利用される鍵が JOSE オブジェクト内に明示的に示されているのか, アプリケーションのコンテキストにより決まるのか</t>
</list>
</t>
<!--
<t>
The JOSE secure object formats describe how cryptographic processing is
done on secured content, ensuring that the recipient an object is able
to properly decrypt an encrypted object or verify a signature. In order
to make use of JOSE, however, applications will need to specify several
aspects of how JOSE is to be used:
<list style="symbols">
<t>What application content is to be protected</t>
<t>Which cryptographic algorithms are to be used</t>
<t>How application protocol entities establish keys</t>
<t>Whether keys are to be explicitly indicated in JOSE objects, or
associated by application context</t>
</list>
</t>
-->
</section>
<section anchor="use-cases-sec" title="Use Cases">
<t>アプリケーションレイヤーのプロトコルについて策定しているワーキンググループにはJOSEデータフォーマットをエンドツーエンドのセキュリティ機能の設計で利用したいという要望を表明しているところもある.
この章では, このようなグループが提案したユースケースをとりまとめ, JOSEオブジェクトフォーマットに求められる要件について説明する.</t>
<!--<t>Several working groups developing application-layer protocols
have expressed a desire to use the JOSE data formats in their
designs for end-to-end security features. In this section, we summarize
the use cases proposed by these groups and discuss the requirements that
they imply for the JOSE object formats.</t>-->
<section anchor="sec-token-sec" title="Security Tokens">
<t>セキュリティトークンはオブジェクトベースのセキュリティではよくあるユースケースである. 例えばSAMLのアサーション <xref target="OASIS.saml-core-2.0-os"/>がある.
セキュリティトークンは発行者から受信者へ対象のエンティティ ("クレーム"または"アサーション") に関する情報を渡すために使われる.
トークンフォーマットのセキュリティ機能により, 受信者はクレームが発行者により発行され, 完全性が保護されているオブジェクトの場合は他のパーティから読み取れないことを検証することができる.</t>
<!--<t>Security tokens are a common use case for object-based security,
for example, SAML assertions <xref target="OASIS.saml-core-2.0-os"/>.
Security tokens are used to convey information about a subject entity
("claims" or "assertions") from an issuer to a recipient. The security
features of a token format enable the recipient to verify that the
claims came from the issuer and, if the object is
confidentiality-protected, that they were not visible to other
parties.</t>-->
<t>セキュリティトークンはOAuth2.0<xref target="RFC6749"/>とそれに含まれるOAuth bearer tokens <xref target="RFC6750"/> などのリソース認可のプロトコルだけでなく, SAML 2.0 <xref target="OASIS.saml-core-2.0-os"/>, WS-Federation <xref target="WS-Federation"/>, Mozilla Persona <xref target="Persona"/>, OpenID Connect <xref target="OpenID.Messages"/> などのフェデレーションプロトコルで利用される.
あるケースでは, セキュリティトークンはクライアント認証やアクセス制御 <xref target="I-D.ietf-oauth-jwt-bearer"/><xref target="I-D.ietf-oauth-saml2-bearer"/>に利用される.</t>
<!--<t>Security tokens are used in federation protocols such as SAML 2.0
<xref target="OASIS.saml-core-2.0-os"/>,
WS-Federation <xref target="WS-Federation"/>,
Mozilla Persona <xref target="Persona"/>,
and OpenID Connect <xref target="OpenID.Messages"/>,
as well as in resource authorization
protocols such as OAuth 2.0 <xref target="RFC6749"/>,
including for OAuth bearer tokens <xref target="RFC6750"/>. In some cases,
security tokens are used for client authentication and for access
control <xref target="I-D.ietf-oauth-jwt-bearer"/><xref
target="I-D.ietf-oauth-saml2-bearer"/>.</t>-->
<t>JSON Web Token (JWT) <xref target="I-D.ietf-oauth-json-web-token"/> はJSONおよびJOSEをベースとしたセキュリティートークンフォーマットである.
JWTはMozilla Persona, OpenID Connect, OAuthと共に利用される.
JWTは限定された場面 (例: HTTPクエリパラメータ) で主に利用されていたためJWTの主要な要件となり, それゆえJOSEは短くURLセーフな形式になっている.</t>
<!--<t>JSON Web Token (JWT) <xref target="I-D.ietf-oauth-json-web-token"/>
is a security token format
based on JSON and JOSE. It is used with Mozilla Persona,
OpenID Connect, and OAuth. Because JWTs are often used in contexts
with limited space (e.g., HTTP query parameters), it is a core
requirement for JWTs, and thus JOSE, to have a compact, URL-safe
representation.</t>-->
</section>
<section anchor="oauth-sec" title="OAuth">
<t>
OAuthプロトコルは, HTTP <xref target="RFC6749"/> を用いた認可トークンの流通と利用のメカニズムを定義している.
保護リソースへアクセスしたいクライアントは, リソースオーナーからの認可を要求する.
このアクセスを許可する場合, リソースオーナーは認可サーバーに対し, クライアントへアクセストークンを発行するよう指示する.
クライアントは, 保護リソースにアクセスしたいとき, 関係するリソースサーバーにそのトークンを提示する.
そしてリソースサーバーは保護リソースへのアクセスを提供する前にそのトークンの妥当性を検証する.
</t>
<!--
<t>The OAuth protocol defines a mechanism for distributing and using
authorization tokens using HTTP <xref target="RFC6749"/>. A Client
that wishes to access a protected resource requests authorization from
the Resource Owner. If the Resource Owner allows this access, he
directs an Authorization Server to issue an access token to the
Client. When the Client wishes to access the protected resource, he
presents the token to the relevant Resource Server, which verifies the
validity of the token before providing access to the protected
resource.</t>
-->
<figure anchor="figOAuth" title="The OAuth process">
<artwork><![CDATA[ +---------------+ +---------------+
| | | |
| Resource |<........>| Authorization |
| Server | | Server |
| | | |
+---------------+ +---------------+
^ |
| |
| |
| |
| |
+------------|--+ +--|------------+
| +----------------+ |
| | | Resource |
| Client | | Owner |
| | | |
+---------------+ +---------------+]]></artwork>
<postamble/>
</figure>
<t>
実質的にこのプロセスは, クライアントおよびリソースオーナー経由で, 認可サーバー(オブジェクトの送信者)からリソースサーバー(受信者)へトークンを移すことである
(リソースオーナーを経由するのはこのプロトコルが利用しているHTTPのメカニズムに起因している).
そこで, 信頼できない中間者経由でアプリケーションオブジェクトを転送するケースが出てくる.
</t>
<!--
<t>In effect, this process moves the token from the Authorization
Server (as a sender of the object) to the Resource Server (recipient),
via the Client as well as the Resource Owner (the latter because of
the HTTP mechanics underlying the protocol). So again we have a case
where an application object is transported via untrusted
intermediaries.</t>
-->
<t>
このアプリケーションには二つの不可欠なセキュリティ要件がある.
完全性とデータ生成元の認証である.
完全性保護は, リソースオーナーとクライアントがトークン内に符合化されたパーミッションを変更できないようするために必要である.
リソースオーナーは究極的には認可を付与するエンティティではあるが, 例えばリソースオーナーが所有していないリソースへのアクセス権の付与も出来てしまうため, 認可トークンの変更に対しては信頼できない.
</t>
<!--
<t>This application has two essential security requirements: Integrity
and data origin authentication. Integrity protection is required so
that the Resource Owner and the Client cannot modify the permission
encoded in the token. Although the Resource Owner is ultimately
the entity that grants authorization, it is not trusted to modify the
authorization token, since this could, for example, grant access to
resources not owned by the Resource Owner.</t>
-->
<t>
データ生成元の認証は, トークンが信頼できる認可サーバーによって生成されたものかどうかをリソースサーバーが検証できるようにするために必要である.
</t>
<!--
<t>Data origin authentication is required so that
the Resource Server can verify that the token was issued by a trusted
Authorization Server.</t>
-->
<t>
認可サーバーがリソースオーナーやクライアントに対してパーミッション情報を不可視としたい場合, 機密性保護も必要となるかもしれない.
例えば, ソーシャルネットワーキングに関連したパーミッションはプライベートな情報と見なされるかもしれない.
しかし, OAuthは下位層で用いているHTTPトランザクションがTLSによって保護されていることを元々要求していることには注意すること.
よってトークンはリソースサーバーとクライアント以外のエンティティに対する機密性保護に関しては既に達成されている.
</t>
<!--
<t>Confidentiality protection may also be needed,
if the Authorization Server is concerned about the visibility of
permissions information to the Resource Owner or Client. For example,
permissions related to social networking might be considered private
information. Note, however, that OAuth already requires that the
underlying HTTP transactions be protected by TLS, so tokens are
already confidentiality-protected from entities other than
the Resource Owner and Client.</t>
-->
<t>
署名と暗号化が対称暗号または非対称暗号のいずれを用いて提供されるのかに関わらず, 機密性および完全性のニーズは, 署名済みおよび暗号化オブジェクトフォーマットの基本要件に合致している.
どちらのメカニズムを採用するかの選択は, 二つのサーバ間の関係, すなわちそれらが対称鍵を共有するのか, 公開鍵のみを共有するのかに依存するだろう.
</t>
<!--
<t>The confidentiality and integrity needs are met by the basic
requirements for signed and encrypted object formats, whether the
signing and encryption are provided using asymmetric or symmetric
cryptography. The choice of which mechanism is applied will depend on
the relationship between the two servers, namely whether they share a
symmetric key or only public keys.</t>
-->
<t>
認証の要件はデプロイの特性にも依存するだろう.
リソースサーバーと認可サーバーの結びつけが相対的に強いところでは, トークンを発行した認可サーバを識別するにはトークンの署名に用いた鍵だけで十分かもしれない.
これは, 認可サーバーの公開鍵, あるいは公開鍵か対称鍵の識別子をプロトコルが伝送することを必要とする.
OAuthでは <spanx style="verb">client_id</spanx> パラメータが, 使用される鍵を識別する.
</t>
<!--
<t>Authentication requirements will also depend on deployment
characteristics. Where there is a relatively strong binding between
the resource server and the authorization server, it may suffice for
the Authorization Server issuing a token to be identified by the key
used to sign the token. This requires that the protocol carry either the
public key of the Authorization Server or an identifier for the public
or symmetric key. In OAuth, the <spanx style="verb">client_id</spanx>
parameter identifies the key to be used.</t>
-->
<t>
リソースサーバーは事前に認可サーバーの鍵を知らないといったような, より高度なケースも存在するかもしれない.
例えば一つのエンティティが(負荷分散のために)複数の認可サーバーをインスタンス化する場合, それらが個々に独立した鍵ペアを持っている例が挙げられる.
このようなケースの場合, 対象の認可サーバーが信頼するエンティティかどうかをリソースサーバーが検証できるように, 認可サーバーの証明書または証明書チェーンを含める必要もあるかもしれない.
</t>
<!--
<t>There may also be more advanced cases, where the Authorization
Server's key is not known in advance to the Resource Server. This may
happen, for instance, if an entity instantiated a collection of
Authorization Servers (say for load balancing), each of which has an
independent key pair. In these cases, it may be necessary to also
include a certificate or certificate chain for the Authorization
Server, so that the Resource Server can verify that the Authorization
Server is an entity that it trusts.</t>
-->
<t>
OAuthにとってHTTPトランスポートはエンコーディングに関して特定の制約を課している.
OAuthプロトコルでは, base64urlエンコーディング <xref target="RFC4648"/> が実施された上で, トークンはHTTP URI <xref target="RFC2616"/> 内のクエリーパラメータとして頻繁にやり取りされる.
URI (従ってクエリパラメータも) の長さには制限が規定されていないが, 実際にはいくつかのユーザーエージェントでは2048文字超のURIは拒否される.
いくつかのモバイルブラウザでは, この制限はさらに小さな値となっている.
そのためこのユースケースでは, JOSEオブジェクトに対して, URIクエリパラメータに含むことが可能なようシンプルであることと同時に, 署名後 (場合によっては暗号化も) でも十分に小さなサイズであることを要求する.
</t>
<!--
<t>The HTTP transport for OAuth imposes a particular constraint on the
encoding. In the OAuth protocol, tokens frequently need to be passed
as query parameters in HTTP URIs <xref target="RFC2616"/>, after
having been base64url encoded <xref target="RFC4648"/>. While there is
no specified limit on the length of URIs (and thus of query
parameters), in practice, URIs of more than 2,048 characters are
rejected by some user agents. For some mobile browsers, this limit is
even smaller. So this use case requires that a JOSE
object have sufficiently small size even after signing, possibly
encrypting, while still being simple to include in an HTTP URI query
parameter.</t>
-->
</section>
<section anchor="fed-sec" title="Federation">
<t>
セキュリティトークンは2つのアイデンティティフェデレーションプロトコルで用いられている.
これら2つの要件は, 前節で述べたものと似ている.
</t>
<!--
<t>Security tokens are used in two federated identity protocols,
which have similar requirements to the general considerations discussed
above:</t>
-->
<t><list style="symbols">
<t>
OpenID Connect <xref target="OpenID.Messages"/> は, OAuth 2.0 をベースとした REST/JSON ベースのシンプルなアイデンティティフェデレーションプロトコルである.
OpenID Connect では, JWT および JOSE フォーマットがセキュリティトークンおよびその他のプロトコルメッセージの保護 (署名およびオプショナルで暗号化) の為に利用されている.
OpenID Connect は, 暗号アルゴリズムのネゴシエーションや鍵情報の配送の為に, JWT/JOSE ヘッダーパラメーターとしては定義されていない要素を利用している.
</t>
<!--
<t>The OpenID Connect protocol <xref target="OpenID.Messages"/>
is a simple, REST/JSON-based
identity federation protocol layered on OAuth 2.0.
It uses the JWT and JOSE formats both
to represent security tokens and to provide security for other
protocol messages (performing signing and optionally encryption).
OpenID Connect negotiates the algorithms to be used and distributes
information about the keys to be used using protocol elements
that are not part of the JWT and JOSE header parameters.</t>
-->
<t>
Mozilla Persona <xref target="Persona"/> は, アイデンティティ情報やアプリケーション情報, 関与する各エンティティの鍵情報などの表現形式として, JOSE JWS オブジェクトとして署名された JWT を利用した, シンプルなシングルサインオン (SSO) プロトコルである.
Persona は鍵配送のために JOSE ヘッダーパラメータではなく JWT メッセージ中の属性を利用する.
</t>
<!--
<t>The Mozilla Persona <xref target="Persona"/> system is a simple
single-sign-on (SSO) protocol that uses JWTs that are signed
JOSE JWS objects to represent information about identities,
applications, and keys for participating entities.
Persona distributes the keys used as claims in JWT messages
and not by using JOSE header parameters.
</t>
-->
</list></t>
</section>
<section anchor="xmpp-sec" title="XMPP">
<t>
Extensible Messaging and Presence Protocol (XMPP) は末端のクライアントから他の端末へXMPP serversの仕様に従ってメッセージを送信するプロトコルである. <xref target="RFC6120"/>
一般的には任意の送信メッセージに2つのサーバが関与する.
あるクライアント(Alice) は他のクライアント (Bob) 宛のメッセージをサーバ(A)へ送信する.
サーバAはBobのIDとDNSによってBobのドメイン(B)を持つサーバを特定し, メッセージをそのサーバへ送信する. その後サーバBはBobへメッセージを送信する.
</t>
<!--<t>The Extensible Messaging and Presence Protocol (XMPP) routes
messages from one end client to another by way of XMPP servers <xref
target="RFC6120"/>. There are typically two servers involved in
delivering any given message: The first client (Alice) sends a message
for another client (Bob) to her server (A). Server A uses Bob's identity
and the DNS to locate the server for Bob's domain (B), then delivers
the message to that server. Server B then routes the message to
Bob.</t>-->
<figure anchor="fig-xmpp" title="Delivering an XMPP message">
<artwork><![CDATA[
+-------+ +----------+ +----------+ +-----+
| Alice |-->| Server A |-->| Server B |-->| Bob |
+-------+ +----------+ +----------+ +-----+]]></artwork>
</figure>
<t>
信頼できない中間者の問題については特にXMPPにとって深刻である. なぜならば, 現時点で多くの適用例では, XMPPドメインの所有者がドメインのサーバの処理を他のエンティティに委託しているためである.
この環境では, ドメイン所有者の個人情報がドメインのオペレーターに露出してしまう明白なリスクが存在する.
XMPPはS/MIMEを利用して端末間セキュリティのメカニズム<xref target="RFC3923"/>を既に定義しているが, キー管理の問題やS/MIMEオブジェクトの処理が難しいこともあり, 普及させることはできなかった.</t>
<!--<t>The untrusted-intermediary problems are especially acute for XMPP
because in many current deployments, the holder of an XMPP domain
outsources the operation of the domain's servers to a different
entity. In this environment, there is a clear risk of exposing the
domain holder's private information to the domain operator. XMPP
already has a defined mechanism for end-to-end security using S/MIME,
but it has failed to gain widespread deployment <xref
target="RFC3923"/>, in part because of key management challenges and
because of the difficulty of processing S/MIME objects.</t>-->
<t>
XMPPワーキンググループはJOSEベースのエンコーディングとより明快なキー管理のシステムを利用した新しい端末間暗号化システムの策定に取り組んでいる. <xref target="I-D.miller-xmpp-e2e"/>
このシステム上で暗号化メッセージを送信するプロセスは２つのステップからなる.
1つ目は, 送信者は対象な Content Encryption Key (CEK)を生成してメッセージコンテンツを暗号化して, 暗号メッセージを届けたい先の受信者へ送信する.
2つ目は, 各受信者は自身の公開鍵を提示することで受信者へ「コールバック」を行い, 送信者は受信者の公開鍵で変換された関連のあるCEKを受け取る.
message to the desired set of recipients. Second, each recipient
"dials back" to the sender, providing his public key; the sender then
responds with the relevant CEK, wrapped with the recipient's public
key.</t>
<!--<t>The XMPP working group is in the process of developing a new
end-to-end encryption system with an encoding based on JOSE and a
clearer key management system <xref target="I-D.miller-xmpp-e2e"/>.
The process of sending an encrypted message in this system involves
two steps: First, the sender generates a symmetric Content Encryption
Key (CEK), encrypts the message content, and sends the encrypted
message to the desired set of recipients. Second, each recipient
"dials back" to the sender, providing his public key; the sender then
responds with the relevant CEK, wrapped with the recipient's public
key.</t>-->
<figure anchor="fig-xmpp-sec" title="Delivering a secure XMPP message">
<artwork><![CDATA[
+-------+ +----------+ +----------+ +-----+
| Alice |<->| Server A |<->| Server B |<->| Bob |
+-------+ +----------+ +----------+ +-----+
| | | |
|------------Encrypted--message--------->|
| | | |
|<---------------Public-key--------------|
| | | |
|---------------Wrapped CEK------------->|
| | | |]]></artwork>
</figure>
<t>
このシステムがJOSEフォーマットから要求する主要な事項は, コンテンツ部の暗号化による機密性保護に加え, 共有鍵より導出したMACによる完全性の検証機能である.
しかしながら, 暗号コンテンツの送受信での鍵交換を区別するためには, JOSE暗号化オブジェクトフォーマットに暗号ペイロードとは区別して共通鍵を含むメッセージを伝達できるような仕組みが要求される.
さらに, 暗号オブジェクトにはコンテンツの暗号化に利用した鍵のタグが必要になる. そうすることで受信者(Bob)は送信者(Alice)へ鍵を含んだメッセージを送信する際にタグを提示することができる.
</t>
<!--<t>The main thing that this system requires from the JOSE formats is
confidentiality protection via content encryption, plus an integrity
check via a MAC derived from the same symmetric key. The separation of
the key exchange from the transmission of the encrypted content,
however, requires that the JOSE encrypted object format allow wrapped
symmetric keys to be carried separately from the encrypted payload. In
addition, the encrypted object will need to have a tag for the key
that was used to encrypt the content, so that the recipient (Bob) can
present the tag to the sender (Alice) when requesting the wrapped
key.</t>-->
<t>XMPPの重要な他の特徴は, 複数の受信者へのメッセージの同時配信を許可していることである.
上記のダイアグラムで言うと, サーバAはサーバB (Bobのサーバ) だけでなくほかのユーザの所有するサーバC, D, Eなどへもメッセージを配信できる.
そのようなケースでは, 上記の仕組みに示される複数の「コールバック」のトランザクションを回避するため, XMPPシステムは受信者の公開鍵をキャッシュすることがあり, それにより鍵はこの後のメッセージの内容と共に送信することができる.
このことによりJOSE暗号オブジェクトフォーマットは複数バージョンものCEKの発行をサポートしなくてはならない. (CMS EnvelopedData structureでは複数の受信者情報の構造を含むことができるが)
</t>
<!--<t>Another important feature of XMPP is that it allows for the
simultaneous delivery of a message to multiple recipients. In the
diagrams above, Server A could deliver the message not only to Server
B (for Bob) but also to Servers C, D, E, etc. for other users. In such
cases, to avoid the multiple "dial back" transactions implied by the
above mechanism, XMPP systems will likely cache public keys for end
recipients, so that wrapped keys can be sent along with content on
future messages. This implies that the JOSE encrypted object format
must support the provision of multiple versions of the same wrapped
CEK (much as a CMS EnvelopedData structure can include multiple
RecipientInfo structures).</t>-->
<t>
XMPPの端末間セキュリティシステムの最新のドラフトでは, 各パーティはXMPPメッセージ伝達システム内にある他パーティの信用情報にもとづいて認証される.
送信者は, "Alice"という識別子宛のメッセージ (具体的には, 鍵交換のためのリクエスト) を受け取ることができ, またその識別子宛のメッセージ (ラップされた鍵情報) を送信できるため, 受信者に認証される.
同様に, 受信者はオリジナルの暗号メッセージと元の鍵交換のリクエストを送ることができるため, 送信者に認証される.
そのため, ここでの認証で要求されるのはXMPPのルーティングが正しく行われることだけでなく, TLSが全てのホップにおいて使われることである.
それに加えて, ３ホップ中いずれかにおいて中間者によってBobになりすまして暗号メッセージの鍵情報を取得できてしまうため, 強い認証強度のTLSチャネルが要求される.
</t>
<!--<t>In the current draft of the XMPP end-to-end security system, each
party is authenticated by virtue of the other party's trust in the
XMPP message routing system. The sender is authenticated to the
receiver because he can receive messages for the identifier "Alice"
(in particular, the request for wrapped keys), and can originate
messages for that identifier (the wrapped key). Likewise, the receiver
is authenticated to the sender because he received the original
encrypted message and originated the request for wrapped key. So the
authentication here requires not only that XMPP routing be done
properly, but also that TLS be used on every hop. Moreover, it
requires that the TLS channels have strong authentication, since a man
in the middle on any of the three hops can masquerade as Bob and
obtain the key material for an encrypted message.</t>-->
<t>
この認証は比較的脆弱 (TLSを用いた３つのホップに依存しているため) でエンドポイントでは検証できない. そのためXMPPワーキンググループは最終受信者のためになんらかのクレデンシャルを導入することも考えられる. そのようなケースでは, そういったクレデンシャルをJOSEオブジェクトと関連づける方法も必要となるであろう.
</t>
<!--<t>Because this authentication is quite weak (depending on the use of
transport-layer security on three hops) and unverifiable by the
endpoints, it is possible that the XMPP working group will integrate
some sort of credentials for end recipients, in which case there would
need to be a way to associate these credentials with JOSE objects.</t>-->
<t>
最終的に, XMPPがJSONではなくXMLベースであることに意味はない.
そのため, JOSEを利用するときは, XMPPはXML内にJSONオブジェクトを含めて送信される.
したがって, JOSEオブジェクトはXMLに含まれても問題ないような方法でエンコードされることが望ましい.
そうでなければ, XMLとしてパースされないように明示するため, 明示的なCDATAの指定をパーサーに対して行わければならない.
この要件を満たすひとつの方法としては, base64urlエンコードをかけることがあげられるが, 中〜大サイズのXMPPメッセージにとっては, これによりかなりのオーバーヘッドを強いる可能性がある.
</t>
<!--<t>Finally, it's worth noting that XMPP is based on XML, not JSON. So
by using JOSE, XMPP will be carrying JSON objects within XML. It is
thus a desirable property for JOSE objects to be encoded in such a way
as to be safe for inclusion in XML. Otherwise, an explicit CDATA
indication must be given to the parser to indicate that it is not to
be parsed as XML. One way to meet this requirement would be to apply
base64url encoding, but for XMPP messages of medium-to-large size,
this could impose a fair degree of overhead.</t>-->
</section>
<section anchor="alto-sec" title="ALTO">
<t>
Application-Layer Traffic Optimization (ALTO) は, エンド端末に対する分散ネットワークトポロジー情報のためのシステムであり,
これによりエンド端末はネットワークへのインパクトを抑えつつ自らの動作を修正することが可能となる <xref target="RFC6708"/> .
ALTOプロトコルは, HTTP <xref target="RFC2616"/> で搬送するJSONオブジェクトの形態でトポロジー情報を分配する <xref target="I-D.ietf-alto-protocol"/> .
元々の版のALTOはシンプルなクライアントサーバプロトコルであり, このケースではHTTPSを単純に使用するだけで十分である <xref target="RFC2818"/> .
しかし, クライアントに到達する前に複数の中間サーバを経由してこれらのJSONオブジェクトが分配されるというALTOのユースケースの議論が始まり,
一方でクライアントがオブジェクトのオリジナルの送信元を認証する機能は依然として維持する必要があった.
元々のALTOプロトコルでも「ALTO情報を取得するALTOクライアントは, その受け取ったALTO情報が適切なALTOサーバーによって生成されたものかどうかの検証ができなければならない」という言及があった.
</t>
<!--
<t>Application-Layer Traffic Optimization (ALTO) is a system for
distributing network topology information to end devices, so that
those devices can modify their behavior to have a lower impact on the
network <xref target="RFC6708"/>. The ALTO protocol
distributes topology information in the form of JSON objects carried
in HTTP <xref target="RFC2616"/><xref
target="I-D.ietf-alto-protocol"/>. The basic version of ALTO is simply
a client-server protocol, so simple use of HTTPS suffices for this
case <xref target="RFC2818"/>. However, there is beginning to be some
discussion of use cases for ALTO in which these JSON objects will be
distributed through a collection of intermediate servers before
reaching the client, while still preserving the ability of the client
to authenticate the original source of the object. Even the base ALTO
protocol notes that "ALTO clients obtaining ALTO information must be
able to validate the received ALTO information to ensure that it was
generated by an appropriate ALTO server."</t>
-->
<t>
このケースでのセキュリティ要件は明確である.
ALTOペイロードを搬送するJOSEオブジェクトは, オリジナルの送信元サーバーのデジタル署名が付随している必要があり,
そしてそのサーバーのアイデンティティを証明できなければならないだろう.
ALTO情報は一般に公開されるものであるため, このケースでは機密性に関する要件はない.
</t>
<!--
<t>In this case, the security requirements are straightforward. JOSE
objects carrying ALTO payloads will need to bear digital signatures
from the originating servers, which will be bound to certificates
attesting to the identities of the servers. There is no requirement
for confidentiality in this case, since ALTO information is generally
public.</t>
-->
<t>
より興味深い議題はエンコーディングに関することである.
ALTOオブジェクトは前述の2つのケースよりもペイロードが大きくなる可能性があり, そのサイズは数メガバイトにまでなると考えられる.
このような大きなオブジェクトの処理は, シングルパスで実施できた方がより高速に処理できる.
そしてそれは, JSON構造内でフィールドが特定の順番であることをJOSEオブジェクトが要求することで可能となるだろう.
</t>
<!--
<t>The more interesting questions are encoding questions. ALTO objects
are likely to be much larger than payloads in the two cases above,
with sizes of up to several megabytes. Processing of such large
objects can be done more quickly if it can be done in a single pass,
which may be possible if JOSE objects require specific orderings of
fields within the JSON structure.</t>
-->
<t>
加えて, ALTOオブジェクトはJSONとしてエンコードされているため, JOSEオブジェクト内に安全に包含することが可能である.
署名済みのJOSEオブジェクトは, 署名とともに署名されたデータを搬送するだろう.
JSONオブジェクトは, JSON文字列内に安全にエンコードされて格納されることが可能という性質を持っている.
これに関する要件は, 不必要な空白は取り除くことだけであり, 例えばbase64urlエンコーディングよりもかなりシンプルな変換である.
このことは, 特定の「JSON-safe」なケースでのJOSEエンコーディングを最適化できるかどうかという議題に繋がる.
</t>
<!--
<t>In addition, because ALTO objects are also encoded as JSON, they
are already safe for inclusion in a JOSE object. Signed JOSE objects
will likely carry the signed data in a string alongside the signature.
JSON objects have the property that they can be safely encoded in JSON
strings. All they require is that unnecessary white space be removed,
a much simpler transformation than, say base64url encoding. This
raises the question of whether it might be possible to optimize the
JOSE encoding for certain "JSON-safe" cases.</t>
-->
<t>
最終的に, 「分離署名 (detached signature)」メカニズム, つまり署名情報を保護対象のコンテンツから分離してエンコードする方法が, ALTOにとっては望ましいかもしれない.
これはALTOプロトコルで, 署名をHTTPSのヘッダ, 署名されたコンテンツをHTTPSのエンティティボディに含めることを可能とするだろう.
</t>
<!--
<t>Finally, it may be desirable for ALTO to have a "detached signature"
mechanism, that is, a way to encode signature information separate
from the protected content. This would allow the ALTO protocol to
include the signature in an HTTPS header, with the signed content as
the HTTPS entity body.</t>
-->
</section>
<section anchor="atoca-sec" title="Emergency Alerting">
<t>
緊急警報 (Emergency alerting) は IP ネットワークの緊急利用を行うものである <xref
target="I-D.ietf-atoca-requirements"/>.
差し迫った危険が察知されると, アラートシステムはユーザーのデバイスにアラートメッセージを送り, 危険を通知する.
ハリケーンやトルネードなどが発生した場合には, その通り道にあたる場所のすべてのデバイスに対してアラートが送られることもある.
</t>
<!--
<t>Emergency alerting is an emerging use case for IP networks <xref
target="I-D.ietf-atoca-requirements"/>. Alerting systems allow
authorities to warn users of impending danger by sending alert
messages to connected devices. For example, in the event of hurricane
or tornado, alerts might be sent to all devices in the path of the
storm.</t>
-->
<t>
アラートシステムへの最大の要件は, アタッカーが誤報を送信することができないようにすることである.
アタッカーによる誤報送信が行われると, アタッカーが広範囲にパニックを起こすことが可能になるであろう.
通常アラートシステムはこういったアタックを防ぐため, メッセージ送信元を厳格に管理し, なおかつメッセージ受信側ではメッセージ送信元の検証を行う.
前者はアラート送信元のローカルセキュリティとして実施され, 後者はアラートメッセージへのデジタル署名 (チャネルベースまたはオブジェクトベース) を用いて実現される.
オブジェクトベースのデジタル署名を採用した場合は, 署名はセキュアオブジェクト内にエンコードされる.
チャネルベースのデジタル署名を採用した場合は, アラートメッセージを認証済かつ完全性が保護されたチャネルを経由して送ることで, "署名済" であるとして扱う.
</t>
<!--
<t>The most critical security requirement for alerting systems is that
it must not be possible for an attacker to send false alerts to
devices. Such a capability would potentially allow an attacker to
create wide-spread panic. In practice, alert systems prevent these
attacks both by controls on sending messages at points where alerts
are originated, as well as by having recipients of alerts verify that
the alert was sent by an authorized source. The former type of control
implemented with local security on hosts from which alerts can be
originated. The latter type implemented by digital signatures on alert