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
1001
1002
1003
1004
1005
|
<pre>Internet Engineering Task Force (IETF) M. Miller
Request for Comments: 7711 Cisco Systems, Inc.
Category: Standards Track P. Saint-Andre
ISSN: 2070-1721 &yet
November 2015
<span class="h1">PKIX over Secure HTTP (POSH)</span>
Abstract
Experience has shown that it is difficult to deploy proper PKIX
certificates for Transport Layer Security (TLS) in multi-tenanted
environments. As a result, domains hosted in such environments often
deploy applications using certificates that identify the hosting
service, not the hosted domain. Such deployments force end users and
peer services to accept a certificate with an improper identifier,
resulting in degraded security. This document defines methods that
make it easier to deploy certificates for proper server identity
checking in non-HTTP application protocols. Although these methods
were developed for use in the Extensible Messaging and Presence
Protocol (XMPP) as a Domain Name Association (DNA) prooftype, they
might also be usable in other non-HTTP application protocols.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc7711">http://www.rfc-editor.org/info/rfc7711</a>.
<span class="grey">Miller & Saint-Andre Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7711">RFC 7711</a> POSH November 2015</span>
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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.
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
<a href="#section-2">2</a>. Terminology .....................................................<a href="#page-4">4</a>
<a href="#section-3">3</a>. Obtaining Verification Material .................................<a href="#page-5">5</a>
<a href="#section-3.1">3.1</a>. Source Domain Possesses PKIX Certificate Information .......<a href="#page-6">6</a>
<a href="#section-3.2">3.2</a>. Source Domain References PKIX Certificate ..................<a href="#page-8">8</a>
<a href="#section-3.3">3.3</a>. Performing Verification ....................................<a href="#page-9">9</a>
<a href="#section-4">4</a>. Secure Delegation ...............................................<a href="#page-9">9</a>
<a href="#section-5">5</a>. Order of Operations ............................................<a href="#page-10">10</a>
<a href="#section-6">6</a>. Caching Results ................................................<a href="#page-11">11</a>
<a href="#section-7">7</a>. Guidance for Server Operators ..................................<a href="#page-12">12</a>
<a href="#section-8">8</a>. Guidance for Protocol Authors ..................................<a href="#page-12">12</a>
<a href="#section-9">9</a>. IANA Considerations ............................................<a href="#page-13">13</a>
<a href="#section-9.1">9.1</a>. Well-Known URI ............................................<a href="#page-13">13</a>
<a href="#section-9.2">9.2</a>. POSH Service Names ........................................<a href="#page-13">13</a>
<a href="#section-10">10</a>. Security Considerations .......................................<a href="#page-14">14</a>
<a href="#section-11">11</a>. References ....................................................<a href="#page-15">15</a>
<a href="#section-11.1">11.1</a>. Normative References .....................................<a href="#page-15">15</a>
<a href="#section-11.2">11.2</a>. Informative References ...................................<a href="#page-16">16</a>
Acknowledgements ..................................................<a href="#page-18">18</a>
Authors' Addresses ................................................<a href="#page-18">18</a>
<span class="grey">Miller & Saint-Andre Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7711">RFC 7711</a> POSH November 2015</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
We begin with a thought experiment.
Imagine that you work on the operations team of a hosting company
that provides instances of the hypothetical "Secure Protocol for
Internet Content Exchange" (SPICE) service for ten thousand different
customer organizations. Each customer wants their instance to be
identified by the customer's domain name (e.g., bar.example.com), not
the hosting company's domain name (e.g., hosting.example.net).
In order to properly secure each customer's SPICE instance via
Transport Layer Security (TLS) [<a href="./rfc5246" title=""The Transport Layer Security (TLS) Protocol Version 1.2"">RFC5246</a>], you need to obtain and
deploy PKIX certificates [<a href="./rfc5280" title=""Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"">RFC5280</a>] containing identifiers such as
bar.example.com, as explained in the "CertID" specification
[<a href="./rfc6125" title=""Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)"">RFC6125</a>]. Unfortunately, you can't obtain and deploy such
certificates because:
o Certification authorities won't issue such certificates to you
because you work for the hosting company, not the customer
organization.
o Customers won't obtain such certificates and then give them (plus
the associated private keys) to you because their legal department
is worried about liability.
o You don't want to install such certificates (plus the associated
private keys) on your servers because your legal department is
worried about liability, too.
o Even if your legal department is happy, this still means managing
one certificate for each customer across the infrastructure,
contributing to a large administrative load.
Given your inability to obtain and deploy public keys / certificates
containing the right identifiers, your back-up approach has always
been to use a certificate containing hosting.example.net as the
identifier. However, more and more customers and end users are
complaining about warning messages in user agents and the inherent
security issues involved with taking a "leap of faith" to accept the
identity mismatch between the source domain (bar.example.com) and the
delegated domain (hosting.example.net) [<a href="./rfc6125" title=""Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)"">RFC6125</a>].
This situation is both insecure and unsustainable. You have
investigated the possibility of using DNS Security [<a href="./rfc4033" title=""DNS Security Introduction and Requirements"">RFC4033</a>] and
DNS-Based Authentication of Named Entities (DANE) [<a href="./rfc6698" title=""The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA"">RFC6698</a>] to solve
the problem. However, your customers and your operations team have
told you that it will be several years before they will be able to
<span class="grey">Miller & Saint-Andre Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7711">RFC 7711</a> POSH November 2015</span>
deploy DNSSEC and DANE for all of your customers (because of tooling
updates, slow deployment of DNSSEC at some top-level domains, etc.).
The product managers in your company are pushing you to find a method
that can be deployed more quickly to overcome the lack of proper
server identity checking for your hosted customers.
One possible approach that your team has investigated is to ask each
customer to provide the public key / certificate for its SPICE
service at a special HTTPS URI on their website
("https://bar.example.com/.well-known/posh/spice.json" is one
possibility). This could be a public key that you generate for the
customer, but because the customer hosts it via HTTPS, any user agent
can find that public key and check it against the public key you
provide during TLS negotiation for the SPICE service (as one added
benefit, the customer never needs to hand you a private key).
Alternatively, the customer can redirect requests for that special
HTTPS URI to an HTTPS URI at your own website, thus making it
explicit that they have delegated the SPICE service to you.
The approach sketched out above, called POSH ("PKIX over Secure
HTTP"), is explained in the remainder of this document. Although
this approach was developed for use in the Extensible Messaging and
Presence Protocol (XMPP) as a prooftype for Domain Name Associations
(DNA) [<a href="./rfc7712" title=""Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP)"">RFC7712</a>], it might be usable by any non-HTTP application
protocol.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
This document inherits security terminology from [<a href="./rfc5280" title=""Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"">RFC5280</a>]. The
terms "source domain", "delegated domain", "derived domain", and
"reference identifier" are used as defined in the "CertID"
specification [<a href="./rfc6125" title=""Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)"">RFC6125</a>].
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
[<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
Additionally, this document uses the following terms:
POSH client: A client that uses the application service and that
uses POSH to obtain material for verifying the service's identity.
POSH server: A server that hosts the application service and that
uses POSH to provide material for verifying its identity.
<span class="grey">Miller & Saint-Andre Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7711">RFC 7711</a> POSH November 2015</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Obtaining Verification Material</span>
Server identity checking (see [<a href="./rfc6125" title=""Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)"">RFC6125</a>]) involves three different
aspects:
1. A proof of the POSH server's identity (in PKIX, this takes the
form of a PKIX end-entity certificate [<a href="./rfc5280" title=""Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"">RFC5280</a>]).
2. Rules for checking the certificate (which vary by application
protocol, although [<a href="./rfc6125" title=""Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)"">RFC6125</a>] attempts to harmonize those rules).
3. The material that a POSH client uses to verify the POSH server's
identity or check the POSH server's proof (in PKIX, this takes
the form of chaining the end-entity certificate back to a trusted
root and performing all validity checks as described in
[<a href="./rfc5280" title=""Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"">RFC5280</a>], [<a href="./rfc6125" title=""Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)"">RFC6125</a>], and the relevant application protocol
specification).
When POSH is used, the first two aspects remain the same: the POSH
server proves its identity by presenting a PKIX certificate
[<a href="./rfc5280" title=""Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"">RFC5280</a>], and the certificate is checked according to the rules
defined in the appropriate application protocol specification (such
as [<a href="./rfc6120" title=""Extensible Messaging and Presence Protocol (XMPP): Core"">RFC6120</a>] for XMPP). However, the POSH client obtains the
material it will use to verify the server's proof by retrieving a
JSON document [<a href="./rfc7159" title=""The JavaScript Object Notation (JSON) Data Interchange Format"">RFC7159</a>] containing hashes of the PKIX certificate
over HTTPS ([<a href="./rfc7230" title=""Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing"">RFC7230</a>] and [<a href="./rfc2818" title=""HTTP Over TLS"">RFC2818</a>]) from a well-known URI [<a href="./rfc5785" title=""Defining Well-Known Uniform Resource Identifiers (URIs)"">RFC5785</a>]
at the source domain. POSH servers MUST use HTTPS. This means that
the POSH client MUST verify the certificate of the HTTPS service at
the source domain in order to securely "bootstrap" into the use of
POSH; specifically, the rules of [<a href="./rfc2818" title=""HTTP Over TLS"">RFC2818</a>] apply to this
"bootstrapping" step to provide a secure basis for all subsequent
POSH operations.
A PKIX certificate is retrieved over secure HTTP in the
following way:
1. The POSH client performs an HTTPS GET request at the source
domain to the path "/.well-known/posh/{servicedesc}.json". The
value of "{servicedesc}" is application-specific; see <a href="#section-8">Section 8</a>
of this document for more details. For example, if the
application protocol is the hypothetical SPICE service, then
"{servicedesc}" could be "spice"; thus, if an application client
were to use POSH to verify an application server for the source
domain "bar.example.com", the HTTPS GET request would be as
follows:
GET /.well-known/posh/spice.json HTTP/1.1
Host: bar.example.com
<span class="grey">Miller & Saint-Andre Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7711">RFC 7711</a> POSH November 2015</span>
2. The source domain HTTPS server responds in one of three ways:
* If it possesses PKIX certificate information for the requested
path, it responds as detailed in <a href="#section-3.1">Section 3.1</a>.
* If it has a reference to where the PKIX certificate
information can be obtained, it responds as detailed in
<a href="#section-3.2">Section 3.2</a>.
* If it does not have any PKIX certificate information or a
reference to such information for the requested path, it
responds with an HTTP 404 Not Found status code [<a href="./rfc7231" title=""Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content"">RFC7231</a>].
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Source Domain Possesses PKIX Certificate Information</span>
If the source domain HTTPS server possesses the certificate
information, it responds to the HTTPS GET request with a success
status code and the message body set to a JSON document [<a href="./rfc7159" title=""The JavaScript Object Notation (JSON) Data Interchange Format"">RFC7159</a>];
the document is a "fingerprints document", i.e., a JSON object with
the following members:
o A "fingerprints" member whose value is a JSON array of fingerprint
descriptors (the member MUST include at least one fingerprint
descriptor).
o An "expires" member whose value is a JSON number specifying the
number of seconds after which the POSH client ought to consider
the keying material to be stale (further explained under
<a href="#section-6">Section 6</a>).
The JSON document returned MUST NOT contain a "url" member, as
described in <a href="#section-3.2">Section 3.2</a>.
Each included fingerprint descriptor is a JSON object, where each
member name is the textual name of a hash function (as listed in
[<a href="#ref-HASH-NAMES">HASH-NAMES</a>]) and its associated value is the base64-encoded
fingerprint hash generated using the named hash function (where the
encoding adheres to the definition in <a href="./rfc4648#section-4">Section 4 of [RFC4648]</a> and
where the padding bits are set to zero).
The fingerprint hash for a given hash algorithm is generated by
performing the named hash function over the DER encoding of the PKIX
X.509 certificate. (This implies that if the certificate expires or
is revoked, the fingerprint value will be out of date.)
<span class="grey">Miller & Saint-Andre Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7711">RFC 7711</a> POSH November 2015</span>
As an example of the fingerprint format, the "sha-256" and "sha-512"
fingerprints are generated by performing the SHA-256 and SHA-512 hash
functions, respectively, over the DER encoding of the PKIX
certificate, as illustrated below. Note that for readability
whitespace has been added to the content portion of the HTTP response
shown below but is not reflected in the Content-Length.
Example Fingerprints Response
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 195
{
"fingerprints": [
{
"sha-256": "4/mggdlVx8A3pvHAWW5sD+qJyMtUHgiRuPjVC48N0XQ=",
"sha-512": "25N+1hB2Vo42l9lSGqw+n3BKFhDHsyork8ou+D9B43TXeJ
1J81mdQEDqm39oR/EHkPBDDG1y5+AG94Kec0xVqA=="
}
],
"expires": 604800
}
The "expires" value is a hint regarding the expiration of the keying
material. It MUST be a non-negative integer. If the "expires"
member has a value of 0 (zero), a POSH client MUST consider the
verification material to be invalid. See <a href="#section-6">Section 6</a> for how to
reconcile this "expires" member with the reference's "expires"
member.
<span class="grey">Miller & Saint-Andre Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7711">RFC 7711</a> POSH November 2015</span>
To indicate alternate PKIX certificates (such as when an existing
certificate will soon expire), the returned fingerprints member MAY
contain multiple fingerprint descriptors. The fingerprints SHOULD be
ordered with the most relevant certificate first as determined by the
application service operator (e.g., the renewed certificate),
followed by the next most relevant certificate (e.g., the certificate
soonest to expire). Here is an example (note that whitespace is
added for readability):
{
"fingerprints": [
{
"sha-256": "4/mggdlVx8A3pvHAWW5sD+qJyMtUHgiRuPjVC48N0XQ",
"sha-512": "25N+1hB2Vo42l9lSGqw+n3BKFhDHsyork8ou+D9B43TXe
J1J81mdQEDqm39oR/EHkPBDDG1y5+AG94Kec0xVqA=="
},
{
"sha-256": "otyLADSKjRDjVpj8X7/hmCAD5C7Qe+PedcmYV7cUncE=",
"sha-512": "MbBD+ausTGJisEXKSynROWrMfHP2xvBnmI79Pr/KXnDyLN
+13Jof8/Uq9fj5HZG8Rk1E2fclcivpGdijUsvHRg=="
}
],
"expires": 806400
}
Matching on any of these fingerprints is acceptable.
Rolling over from one hosting provider to another is best handled by
updating the relevant SRV records, not primarily by updating the POSH
documents themselves.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Source Domain References PKIX Certificate</span>
If the source domain HTTPS server has a reference to the certificate
information, it responds to the HTTPS GET request with a success
status code and message body set to a JSON document. The document is
a "reference document", i.e., a JSON object with the following
members:
o A "url" member whose value is a JSON string specifying the HTTPS
URI where POSH clients can obtain the actual certificate
information. The URI can be a well-known POSH URI as described in
<a href="#section-8">Section 8</a>, but it need not be. (For historical reasons, the
member name is "url", not "uri".)
o An "expires" member whose value is a JSON number specifying the
number of seconds after which the POSH client ought to consider
the delegation to be stale (further explained under <a href="#section-6">Section 6</a>).
<span class="grey">Miller & Saint-Andre Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7711">RFC 7711</a> POSH November 2015</span>
Example Reference Response
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 82
{
"url":"https://hosting.example.net/.well-known/posh/spice.json",
"expires":86400
}
In order to process a reference response, the client performs an
HTTPS GET request for the URI specified in the "url" member value.
The HTTPS server for the URI to which the client has been referred
responds to the request with a JSON document containing fingerprints
as described in <a href="#section-3.1">Section 3.1</a>. The document retrieved from the
location specified by the "url" member MUST NOT itself be a reference
document (i.e., containing a "url" member instead of a "fingerprints"
member), in order to prevent circular delegations.
Note: See <a href="#section-10">Section 10</a> for discussion about HTTPS redirects.
The "expires" value is a hint regarding the expiration of the source
domain's delegation of service to the delegated domain. It MUST be a
non-negative integer. If the "expires" member has a value of 0
(zero), a POSH client MUST consider the delegation invalid. See
<a href="#section-6">Section 6</a> for guidelines about reconciling this "expires" member with
the "expires" member of the fingerprints document.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Performing Verification</span>
The POSH client compares the PKIX information presented by the POSH
server against each fingerprint descriptor object in the POSH
fingerprints document, until a match is found using the hash
functions that the client supports, or until the collection of POSH
verification material is exhausted. If none of the fingerprint
descriptor objects match the POSH server PKIX information, the POSH
client SHOULD reject the connection (however, the POSH client might
still accept the connection if other verification methods are
successful, such as DANE [<a href="./rfc6698" title=""The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA"">RFC6698</a>]).
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Secure Delegation</span>
The delegation from the source domain to the delegated domain can be
considered secure if the credentials offered by the POSH server match
the verification material obtained by the client, regardless of how
the material was obtained.
<span class="grey">Miller & Saint-Andre Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc7711">RFC 7711</a> POSH November 2015</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Order of Operations</span>
In order for the POSH client to perform verification of reference
identifiers without potentially compromising data, POSH operations
MUST be complete before any application-layer data is exchanged for
the source domain. In cases where the POSH client initiates an
application-layer connection, the client SHOULD perform all POSH
retrievals before initiating a connection (naturally, this is not
possible in cases where the POSH client receives instead of initiates
an application-layer connection). For application protocols that use
DNS SRV (including queries for TLSA records in concert with SRV
records as described in [<a href="./rfc7673" title=""Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records"">RFC7673</a>]), the POSH operations ideally ought
to be done in parallel with resolving the SRV records and the
addresses of any targets, similar to the "Happy Eyeballs" approach
for IPv4 and IPv6 [<a href="./rfc6555" title=""Happy Eyeballs: Success with Dual-Stack Hosts"">RFC6555</a>].
The following diagram illustrates the possession flow:
POSH Source POSH
Client Domain Server
------ ------ ------
| | |
| POSH Request | |
|------------------------->| |
| | |
| Return POSH fingerprints | |
|<-------------------------| |
| |
| Service TLS Handshake |
|<===================================================>|
| |
| Service Data |
|<===================================================>|
| |
Figure 1: Order of Events for Possession Flow
<span class="grey">Miller & Saint-Andre Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc7711">RFC 7711</a> POSH November 2015</span>
While the following diagram illustrates the reference flow:
POSH Source Delegated POSH
Client Domain Domain Server
------ ------ ------ ------
| | | |
| POSH Request | | |
|----------------->| | |
| | | |
| Return POSH url | | |
|<-----------------| | |
| | |
| POSH Request | |
|-------------------------------->| |
| | |
| Return POSH fingerprints | |
|<--------------------------------| |
| |
| Service TLS Handshake |
|<===================================================>|
| |
| Service Data |
|<===================================================>|
| |
Figure 2: Order of Events for Reference Flow
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Caching Results</span>
The POSH client MUST NOT cache results (reference or fingerprints)
indefinitely. If the source domain returns a reference, the POSH
client MUST use the lower of the two "expires" values when
determining how long to cache results (i.e., if the reference
"expires" value is lower than the fingerprints "expires" value, honor
the reference "expires" value). Once the POSH client considers the
results stale, it needs to perform the entire POSH operation again,
starting with the HTTPS GET request to the source domain. The POSH
client MAY use a lower value than any provided in the "expires"
member(s), or not cache results at all.
The foregoing considerations apply to the handling of the "expires"
values in POSH documents; naturally, a POSH client MUST NOT consider
an expired PKIX certificate to be valid, in accordance with
[<a href="./rfc5280" title=""Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"">RFC5280</a>].
<span class="grey">Miller & Saint-Andre Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc7711">RFC 7711</a> POSH November 2015</span>
The POSH client SHOULD NOT rely on HTTP caching mechanisms, instead
using the expiration hints provided in the POSH reference document or
fingerprints document. To that end, the HTTPS servers for source
domains and derived domains SHOULD specify a 'Cache-Control' header
indicating a very short duration (e.g., max-age=60) or "no-cache" to
indicate that the response (redirect, reference, or fingerprints) is
not appropriate to cache at the HTTP layer.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Guidance for Server Operators</span>
POSH is intended to ease the operational burden of securing
application services, especially in multi-tenanted environments. It
does so by obviating the need to obtain certificates for hosted
domains, so that an operator can obtain a certificate only for its
hosting service (naturally, this certificate needs to be valid
according to [<a href="./rfc5280" title=""Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"">RFC5280</a>] and contain the proper identifier(s) in
accordance with [<a href="./rfc6125" title=""Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)"">RFC6125</a>] and the relevant application protocol
specification).
However, in order to use POSH, an operator does need to coordinate
with its customers so that the appropriate POSH documents are
provided via HTTPS at a well-known URI at each customer's domain
(i.e., at the source domain), thus ensuring delegation to the
operator's hosting service (i.e., the delegated domain). Because
correct hosting of the POSH document at the source domain is
essential for successful functioning of the POSH "chain", errors at
the source domain will result in authentication problems, certificate
warnings, and other operational issues.
Furthermore, if the POSH document is a reference document instead of
a fingerprints document, the operational burden is further decreased
because the operator does not need to provision its customers with
updated POSH documents when the certificate for the delegated domain
expires or is replaced.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Guidance for Protocol Authors</span>
Protocols that use POSH are expected to register with the "POSH
Service Names" registry defined under <a href="#section-9.2">Section 9.2</a>.
For POSH-using protocols that rely on DNS SRV records [<a href="./rfc2782" title=""A DNS RR for specifying the location of services (DNS SRV)"">RFC2782</a>], the
service name SHOULD be the same as the DNS SRV "Service". As an
example, the POSH service name for XMPP server-to-server connections
would be "xmpp-server" because [<a href="./rfc6120" title=""Extensible Messaging and Presence Protocol (XMPP): Core"">RFC6120</a>] registers a DNS SRV
"Service" of "xmpp-server". One example of the resulting well-known
URI would be "https://example.com/.well-known/posh/xmpp-server.json".
<span class="grey">Miller & Saint-Andre Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc7711">RFC 7711</a> POSH November 2015</span>
For other POSH-using protocols, the service name MAY be any unique
string or identifier for the protocol; for example, it might be a
service name registered with the IANA in accordance with [<a href="./rfc6335" title=""Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry"">RFC6335</a>],
or it might be an unregistered name. As an example, the well-known
URI for the hypothetical SPICE application might be "spice".
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. IANA Considerations</span>
<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>. Well-Known URI</span>
IANA has registered "posh" in the "Well-Known URIs" registry as
defined by [<a href="./rfc5785" title=""Defining Well-Known Uniform Resource Identifiers (URIs)"">RFC5785</a>]. The completed template follows.
URI suffix: posh
Change controller: IETF
Specification: <a href="./rfc7711">RFC 7711</a> (this document)
Related information: The suffix "posh" is expected to be followed by
an additional path component consisting of a service name (say,
"spice") and a file extension of ".json", resulting in a full path
of, for instance, "/.well-known/posh/spice.json". Registration of
service names shall be requested by developers of the relevant
application protocols.
<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>. POSH Service Names</span>
IANA has established the "POSH Service Names" registry within the
"Uniform Resource Identifier (URI) Schemes" group of registries.
The IANA registration policy [<a href="./rfc5226" title="">RFC5226</a>] is Expert Review or IETF
Review (this was chosen instead of the more liberal policy of First
Come First Served to help ensure that POSH services are defined in
ways that are consistent with this specification). One or more
Designated Experts are to be appointed by the IESG or their delegate.
Registration requests are to be sent to the posh@ietf.org mailing
list for review and comment, with an appropriate subject (e.g.,
"Request for POSH service name: example").
Before a period of 14 days has passed, the Designated Expert(s) will
either approve or deny the registration request, communicating this
decision both to the review list and to IANA. Denials should include
an explanation and, if applicable, suggestions as to how to make the
request successful. Registration requests that are undetermined for
a period longer than 21 days can be brought to the IESG's attention
(using the iesg@iesg.org mailing list) for resolution.
<span class="grey">Miller & Saint-Andre Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc7711">RFC 7711</a> POSH November 2015</span>
<span class="h4"><a class="selflink" id="section-9.2.1" href="#section-9.2.1">9.2.1</a>. Registration Template</span>
Service name: The name requested, relative to "/.well-known/posh/";
e.g., a service name of "example" would result in a well-known URI
such as "https://example.com/.well-known/posh/example.json".
Change controller: For Standards Track RFCs, state "IETF". In all
other cases, provide the name and email address of the responsible
party. Other details (e.g., postal address or website URI) may
also be included.
Definition and usage: A brief description that defines the service
name and mentions where and how it is used (e.g., in the context
of a particular application protocol).
Specification: Optionally, reference to a document that specifies
the service or application protocol that uses the service name,
preferably including a URI that can be used to retrieve a copy of
the document. An indication of the relevant sections may also be
included but is not required.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Security Considerations</span>
This document supplements but does not supersede the security
considerations provided in specifications for application protocols
that decide to use POSH (e.g., [<a href="./rfc6120" title=""Extensible Messaging and Presence Protocol (XMPP): Core"">RFC6120</a>] and [<a href="./rfc6125" title=""Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)"">RFC6125</a>] for XMPP).
Specifically, the security of requests and responses sent via HTTPS
depends on checking the identity of the HTTP server in accordance
with [<a href="./rfc2818" title=""HTTP Over TLS"">RFC2818</a>] as well as following the most modern best practices
for TLS as specified in [<a href="./rfc7525" title=""Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)"">RFC7525</a>]. Additionally, the security of
POSH can benefit from other HTTP-hardening protocols, such as HTTP
Strict Transport Security (HSTS) [<a href="./rfc6797" title=""HTTP Strict Transport Security (HSTS)"">RFC6797</a>] and key pinning [<a href="./rfc7469" title=""Public Key Pinning Extension for HTTP"">RFC7469</a>],
especially if the POSH client shares some information with a common
HTTPS implementation (e.g., a platform-default web browser).
Note well that POSH is used by a POSH client to obtain the public key
of a POSH server to which it might connect for a particular
application protocol such as IMAP or XMPP. POSH does not enable a
hosted domain to transfer private keys to a hosting service via
HTTPS. POSH also does not enable a POSH server to engage in
certificate enrollment with a certification authority via HTTPS, as
is done in Enrollment over Secure Transport [<a href="./rfc7030" title=""Enrollment over Secure Transport"">RFC7030</a>].
A web server at the source domain might redirect an HTTPS request to
another HTTPS URI. The location provided in the redirect response
MUST specify an HTTPS URI. Source domains SHOULD use only temporary
redirect mechanisms, such as HTTP status codes 302 (Found) and 307
(Temporary Redirect) [<a href="./rfc7231" title=""Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content"">RFC7231</a>]. Clients MAY treat any redirect as
<span class="grey">Miller & Saint-Andre Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc7711">RFC 7711</a> POSH November 2015</span>
temporary, ignoring the specific semantics for 301 (Moved
Permanently) [<a href="./rfc7231" title=""Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content"">RFC7231</a>] and 308 (Permanent Redirect) [<a href="./rfc7538" title=""The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect)"">RFC7538</a>]. To
protect against circular references, it is RECOMMENDED that POSH
clients follow no more than 10 redirects, although applications or
implementations can require that fewer redirects be followed.
Hash function agility is an important quality to ensure secure
operations in the face of attacks against the fingerprints obtained
within verification material. Because POSH verification material is
relatively short-lived compared to long-lived credentials such as
PKIX end-entity certificates (at least as typically deployed),
entities that deploy POSH are advised to swap out POSH documents if
the hash functions are found to be subject to practical attacks
[<a href="./rfc4270" title=""Attacks on Cryptographic Hashes in Internet Protocols"">RFC4270</a>].
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. References</span>
<span class="h3"><a class="selflink" id="section-11.1" href="#section-11.1">11.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
DOI 10.17487/RFC2119, March 1997,
<<a href="http://www.rfc-editor.org/info/rfc2119">http://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC2818">RFC2818</a>] Rescorla, E., "HTTP Over TLS", <a href="./rfc2818">RFC 2818</a>,
DOI 10.17487/RFC2818, May 2000,
<<a href="http://www.rfc-editor.org/info/rfc2818">http://www.rfc-editor.org/info/rfc2818</a>>.
[<a id="ref-RFC4648">RFC4648</a>] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", <a href="./rfc4648">RFC 4648</a>, DOI 10.17487/RFC4648, October 2006,
<<a href="http://www.rfc-editor.org/info/rfc4648">http://www.rfc-editor.org/info/rfc4648</a>>.
[<a id="ref-RFC5246">RFC5246</a>] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", <a href="./rfc5246">RFC 5246</a>,
DOI 10.17487/RFC5246, August 2008,
<<a href="http://www.rfc-editor.org/info/rfc5246">http://www.rfc-editor.org/info/rfc5246</a>>.
[<a id="ref-RFC5280">RFC5280</a>] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", <a href="./rfc5280">RFC 5280</a>, DOI 10.17487/RFC5280, May 2008,
<<a href="http://www.rfc-editor.org/info/rfc5280">http://www.rfc-editor.org/info/rfc5280</a>>.
[<a id="ref-RFC5785">RFC5785</a>] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
Uniform Resource Identifiers (URIs)", <a href="./rfc5785">RFC 5785</a>,
DOI 10.17487/RFC5785, April 2010,
<<a href="http://www.rfc-editor.org/info/rfc5785">http://www.rfc-editor.org/info/rfc5785</a>>.
<span class="grey">Miller & Saint-Andre Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc7711">RFC 7711</a> POSH November 2015</span>
[<a id="ref-RFC6125">RFC6125</a>] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", <a href="./rfc6125">RFC 6125</a>, DOI 10.17487/RFC6125,
March 2011, <<a href="http://www.rfc-editor.org/info/rfc6125">http://www.rfc-editor.org/info/rfc6125</a>>.
[<a id="ref-RFC7159">RFC7159</a>] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", <a href="./rfc7159">RFC 7159</a>, DOI 10.17487/RFC7159,
March 2014, <<a href="http://www.rfc-editor.org/info/rfc7159">http://www.rfc-editor.org/info/rfc7159</a>>.
[<a id="ref-RFC7230">RFC7230</a>] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Message Syntax and Routing",
<a href="./rfc7230">RFC 7230</a>, DOI 10.17487/RFC7230, June 2014,
<<a href="http://www.rfc-editor.org/info/rfc7230">http://www.rfc-editor.org/info/rfc7230</a>>.
[<a id="ref-RFC7231">RFC7231</a>] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Semantics and Content",
<a href="./rfc7231">RFC 7231</a>, DOI 10.17487/RFC7231, June 2014,
<<a href="http://www.rfc-editor.org/info/rfc7231">http://www.rfc-editor.org/info/rfc7231</a>>.
[<a id="ref-RFC7525">RFC7525</a>] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", <a href="https://www.rfc-editor.org/bcp/bcp195">BCP 195</a>, <a href="./rfc7525">RFC 7525</a>, DOI 10.17487/RFC7525,
May 2015, <<a href="http://www.rfc-editor.org/info/rfc7525">http://www.rfc-editor.org/info/rfc7525</a>>.
<span class="h3"><a class="selflink" id="section-11.2" href="#section-11.2">11.2</a>. Informative References</span>
[<a id="ref-HASH-NAMES">HASH-NAMES</a>]
"Hash Function Textual Names",
<<a href="http://www.iana.org/assignments/hash-function-text-names">http://www.iana.org/assignments/</a>
<a href="http://www.iana.org/assignments/hash-function-text-names">hash-function-text-names</a>>.
[<a id="ref-RFC2782">RFC2782</a>] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", <a href="./rfc2782">RFC 2782</a>,
DOI 10.17487/RFC2782, February 2000,
<<a href="http://www.rfc-editor.org/info/rfc2782">http://www.rfc-editor.org/info/rfc2782</a>>.
[<a id="ref-RFC4033">RFC4033</a>] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
<a href="./rfc4033">RFC 4033</a>, DOI 10.17487/RFC4033, March 2005,
<<a href="http://www.rfc-editor.org/info/rfc4033">http://www.rfc-editor.org/info/rfc4033</a>>.
[<a id="ref-RFC4270">RFC4270</a>] Hoffman, P. and B. Schneier, "Attacks on Cryptographic
Hashes in Internet Protocols", <a href="./rfc4270">RFC 4270</a>,
DOI 10.17487/RFC4270, November 2005,
<<a href="http://www.rfc-editor.org/info/rfc4270">http://www.rfc-editor.org/info/rfc4270</a>>.
<span class="grey">Miller & Saint-Andre Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc7711">RFC 7711</a> POSH November 2015</span>
[<a id="ref-RFC5226">RFC5226</a>] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>, <a href="./rfc5226">RFC 5226</a>,
DOI 10.17487/RFC5226, May 2008,
<<a href="http://www.rfc-editor.org/info/rfc5226">http://www.rfc-editor.org/info/rfc5226</a>>.
[<a id="ref-RFC6120">RFC6120</a>] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", <a href="./rfc6120">RFC 6120</a>, DOI 10.17487/RFC6120,
March 2011, <<a href="http://www.rfc-editor.org/info/rfc6120">http://www.rfc-editor.org/info/rfc6120</a>>.
[<a id="ref-RFC6335">RFC6335</a>] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", <a href="https://www.rfc-editor.org/bcp/bcp165">BCP 165</a>,
<a href="./rfc6335">RFC 6335</a>, DOI 10.17487/RFC6335, August 2011,
<<a href="http://www.rfc-editor.org/info/rfc6335">http://www.rfc-editor.org/info/rfc6335</a>>.
[<a id="ref-RFC6555">RFC6555</a>] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", <a href="./rfc6555">RFC 6555</a>, DOI 10.17487/RFC6555,
April 2012, <<a href="http://www.rfc-editor.org/info/rfc6555">http://www.rfc-editor.org/info/rfc6555</a>>.
[<a id="ref-RFC6698">RFC6698</a>] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", <a href="./rfc6698">RFC 6698</a>, DOI 10.17487/RFC6698,
August 2012, <<a href="http://www.rfc-editor.org/info/rfc6698">http://www.rfc-editor.org/info/rfc6698</a>>.
[<a id="ref-RFC6797">RFC6797</a>] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
Transport Security (HSTS)", <a href="./rfc6797">RFC 6797</a>,
DOI 10.17487/RFC6797, November 2012,
<<a href="http://www.rfc-editor.org/info/rfc6797">http://www.rfc-editor.org/info/rfc6797</a>>.
[<a id="ref-RFC7030">RFC7030</a>] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", <a href="./rfc7030">RFC 7030</a>,
DOI 10.17487/RFC7030, October 2013,
<<a href="http://www.rfc-editor.org/info/rfc7030">http://www.rfc-editor.org/info/rfc7030</a>>.
[<a id="ref-RFC7469">RFC7469</a>] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
Extension for HTTP", <a href="./rfc7469">RFC 7469</a>, DOI 10.17487/RFC7469,
April 2015, <<a href="http://www.rfc-editor.org/info/rfc7469">http://www.rfc-editor.org/info/rfc7469</a>>.
[<a id="ref-RFC7538">RFC7538</a>] Reschke, J., "The Hypertext Transfer Protocol Status
Code 308 (Permanent Redirect)", <a href="./rfc7538">RFC 7538</a>,
DOI 10.17487/RFC7538, April 2015,
<<a href="http://www.rfc-editor.org/info/rfc7538">http://www.rfc-editor.org/info/rfc7538</a>>.
<span class="grey">Miller & Saint-Andre Standards Track [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc7711">RFC 7711</a> POSH November 2015</span>
[<a id="ref-RFC7673">RFC7673</a>] Finch, T., Miller, M., and P. Saint-Andre, "Using
DNS-Based Authentication of Named Entities (DANE) TLSA
Records with SRV Records", <a href="./rfc7673">RFC 7673</a>, DOI 10.17487/RFC7673,
October 2015, <<a href="http://www.rfc-editor.org/info/rfc7673">http://www.rfc-editor.org/info/rfc7673</a>>.
[<a id="ref-RFC7712">RFC7712</a>] Saint-Andre, P., Miller, M., and P. Hancke, "Domain Name
Associations (DNA) in the Extensible Messaging and
Presence Protocol (XMPP)", <a href="./rfc7712">RFC 7712</a>, DOI 10.17487/RFC7712,
November 2015, <<a href="http://www.rfc-editor.org/info/rfc7712">http://www.rfc-editor.org/info/rfc7712</a>>.
Acknowledgements
Thanks to Thijs Alkemade, Philipp Hancke, Joe Hildebrand, and Tobias
Markmann for their implementation feedback, and to Dave Cridland,
Chris Newton, Max Pritikin, and Joe Salowey for their input on the
specification.
During IESG review, Stephen Farrell, Barry Leiba, and Kathleen
Moriarty provided helpful input that resulted in improvements in the
document.
Thanks also to Dave Cridland as document shepherd, Joe Hildebrand as
working group chair, and Ben Campbell as area director.
Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for
employing him during his work on earlier draft versions of this
document.
Authors' Addresses
Matthew Miller
Cisco Systems, Inc.
1899 Wynkoop Street, Suite 600
Denver, CO 80202
United States
Email: mamille2@cisco.com
Peter Saint-Andre
&yet
Email: peter@andyet.com
URI: <a href="https://andyet.com/">https://andyet.com/</a>
Miller & Saint-Andre Standards Track [Page 18]
</pre>
|
