-
Notifications
You must be signed in to change notification settings - Fork 0
/
Bib.xml
5945 lines (3937 loc) · 348 KB
/
Bib.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
<reference anchor="FedRes2016">
<front>
<title>The Federal Reserve Payments Study 2016</title>
<author>
<organization abbrev='Federal Reserve'>Federal Reserve</organization>
</author>
<date month='December' year='2016' />
</front>
<format type="pdf" target="https://www.federalreserve.gov/newsevents/press/other/2016-payments-study-20161222.pdf"/>
</reference>
<!-- RFC2119 Added Fri, 20 Mar 2015 23:31:45 GMT -->
<!-- Source: http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml -->
<reference anchor='RFC2119'>
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>[email protected]</email></address></author>
<date year='1997' month='March' />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
<list>
<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
RFC 2119.
</t></list></t>
<t>
Note that the force of these words is modified by the requirement
level of the document in which they are used.
</t></abstract></front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='http://www.rfc-editor.org/rfc/rfc2119.txt' />
<format type='HTML' octets='17970' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5777' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>
<!-- RFC6066 Added Fri, 20 Mar 2015 23:31:45 GMT -->
<!-- Source: http://xml.resource.org/public/rfc/bibxml/reference.RFC.6066.xml -->
<reference anchor='RFC6066'>
<front>
<title>Transport Layer Security (TLS) Extensions: Extension Definitions</title>
<author initials='D.' surname='Eastlake' fullname='D. Eastlake'>
<organization /></author>
<date year='2011' month='January' />
<abstract>
<t>This document provides specifications for existing TLS extensions. It is a companion document for RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2". The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='6066' />
<format type='TXT' octets='55079' target='http://www.rfc-editor.org/rfc/rfc6066.txt' />
</reference>
<!-- RFC6961 Added Fri, 20 Mar 2015 23:31:45 GMT -->
<!-- Source: http://xml.resource.org/public/rfc/bibxml/reference.RFC.6961.xml -->
<reference anchor='RFC6961'>
<front>
<title>The Transport Layer Security (TLS) Multiple Certificate Status Request Extension</title>
<author initials='Y.' surname='Pettersen' fullname='Y. Pettersen'>
<organization /></author>
<date year='2013' month='June' />
<abstract>
<t>This document defines the Transport Layer Security (TLS) Certificate Status Version 2 Extension to allow clients to specify and support several certificate status methods. (The use of the Certificate Status extension is commonly referred to as "OCSP stapling".) Also defined is a new method based on the Online Certificate Status Protocol (OCSP) that servers can use to provide status information about not only the server's own certificate but also the status of intermediate certificates in the chain.</t></abstract></front>
<seriesInfo name='RFC' value='6961' />
<format type='TXT' octets='21473' target='http://www.rfc-editor.org/rfc/rfc6961.txt' />
</reference>
<!-- RFC6844 Added Fri, 20 Mar 2015 23:31:45 GMT -->
<!-- Source: http://xml.resource.org/public/rfc/bibxml/reference.RFC.6844.xml -->
<reference anchor='RFC6844'>
<front>
<title>DNS Certification Authority Authorization (CAA) Resource Record</title>
<author initials='P.' surname='Hallam-Baker' fullname='P. Hallam-Baker'>
<organization /></author>
<author initials='R.' surname='Stradling' fullname='R. Stradling'>
<organization /></author>
<date year='2013' month='January' />
<abstract>
<t>The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain. CAA Resource Records allow a public Certification Authority to implement additional controls to reduce the risk of unintended certificate mis-issue. This document defines the syntax of the CAA record and rules for processing CAA records by certificate issuers. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='6844' />
<format type='TXT' octets='36848' target='http://www.rfc-editor.org/rfc/rfc6844.txt' />
</reference>
<!-- RFC2986 Added Fri, 20 Mar 2015 23:31:45 GMT -->
<!-- Source: http://xml.resource.org/public/rfc/bibxml/reference.RFC.2986.xml -->
<reference anchor='RFC2986'>
<front>
<title>PKCS #10: Certification Request Syntax Specification Version 1.7</title>
<author initials='M.' surname='Nystrom' fullname='M. Nystrom'>
<organization /></author>
<author initials='B.' surname='Kaliski' fullname='B. Kaliski'>
<organization /></author>
<date year='2000' month='November' />
<abstract>
<t>This memo represents a republication of PKCS #10 v1.7 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 document. This memo provides information for the Internet community.</t></abstract></front>
<seriesInfo name='RFC' value='2986' />
<format type='TXT' octets='27794' target='http://www.rfc-editor.org/rfc/rfc2986.txt' />
</reference>
<!-- RFC5280 Added Fri, 20 Mar 2015 23:31:45 GMT -->
<!-- Source: http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml -->
<reference anchor='RFC5280'>
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
<author initials='D.' surname='Cooper' fullname='D. Cooper'>
<organization /></author>
<author initials='S.' surname='Santesson' fullname='S. Santesson'>
<organization /></author>
<author initials='S.' surname='Farrell' fullname='S. Farrell'>
<organization /></author>
<author initials='S.' surname='Boeyen' fullname='S. Boeyen'>
<organization /></author>
<author initials='R.' surname='Housley' fullname='R. Housley'>
<organization /></author>
<author initials='W.' surname='Polk' fullname='W. Polk'>
<organization /></author>
<date year='2008' month='May' />
<abstract>
<t>This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5280' />
<format type='TXT' octets='352580' target='http://www.rfc-editor.org/rfc/rfc5280.txt' />
</reference>
<!-- RFC6797 Added Wed, 08 Apr 2015 16:19:20 GMT -->
<!-- Source: http://xml.resource.org/public/rfc/bibxml/reference.RFC.6797.xml -->
<reference anchor='RFC6797'>
<front>
<title>HTTP Strict Transport Security (HSTS)</title>
<author initials='J.' surname='Hodges' fullname='J. Hodges'>
<organization /></author>
<author initials='C.' surname='Jackson' fullname='C. Jackson'>
<organization /></author>
<author initials='A.' surname='Barth' fullname='A. Barth'>
<organization /></author>
<date year='2012' month='November' />
<abstract>
<t>This specification defines a mechanism enabling web sites to declare themselves accessible only via secure connections and/or for users to be able to direct their user agent(s) to interact with given sites only over secure connections. This overall policy is referred to as HTTP Strict Transport Security (HSTS). The policy is declared by web sites via the Strict-Transport-Security HTTP response header field and/or by other means, such as user agent configuration, for example. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='6797' />
<format type='TXT' octets='103554' target='http://www.rfc-editor.org/rfc/rfc6797.txt' />
</reference>
<!-- RFC6698 Added Wed, 08 Apr 2015 16:19:20 GMT -->
<!-- Source: http://xml.resource.org/public/rfc/bibxml/reference.RFC.6698.xml -->
<reference anchor='RFC6698'>
<front>
<title>The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA</title>
<author initials='P.' surname='Hoffman' fullname='P. Hoffman'>
<organization /></author>
<author initials='J.' surname='Schlyter' fullname='J. Schlyter'>
<organization /></author>
<date year='2012' month='August' />
<abstract>
<t>Encrypted communication on the Internet often uses Transport Layer Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='6698' />
<format type='TXT' octets='84034' target='http://www.rfc-editor.org/rfc/rfc6698.txt' />
</reference>
<!-- I-D.ietf-websec-key-pinning Added Wed, 08 Apr 2015 16:19:20 GMT -->
<!-- Source: http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-websec-key-pinning.xml -->
<reference anchor='I-D.ietf-websec-key-pinning'>
<front>
<title>Public Key Pinning Extension for HTTP</title>
<author initials='C' surname='Evans' fullname='Chris Evans'>
<organization />
</author>
<author initials='C' surname='Palmer' fullname='Chris Palmer'>
<organization />
</author>
<author initials='R' surname='Sleevi' fullname='Ryan Sleevi'>
<organization />
</author>
<date month='October' day='5' year='2014' />
<abstract><t>This document defines a new HTTP header that allows web host operators to instruct user agents to remember ("pin") the hosts' cryptographic identities over a period of time. During that time, UAs will require that the host presents a certificate chain including at least one Subject Public Key Info structure whose fingerprint matches one of the pinned fingerprints for that host. By effectively reducing the number of trusted authorities who can authenticate the domain during the lifetime of the pin, pinning may reduce the incidence of man-in-the-middle attacks due to compromised Certification Authorities.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-websec-key-pinning-21' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-websec-key-pinning-21.txt' />
</reference>
<!-- RFC5246 Added Fri, 22 May 2015 15:20:45 GMT -->
<!-- Source: http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml -->
<reference anchor='RFC5246'>
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
<author initials='T.' surname='Dierks' fullname='T. Dierks'>
<organization /></author>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'>
<organization /></author>
<date year='2008' month='August' />
<abstract>
<t>This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5246' />
<format type='TXT' octets='222395' target='http://www.rfc-editor.org/rfc/rfc5246.txt' />
</reference>
<!-- RFC1321 Added Fri, 22 May 2015 15:35:58 GMT -->
<!-- Source: http://xml.resource.org/public/rfc/bibxml/reference.RFC.1321.xml -->
<reference anchor='RFC1321'>
<front>
<title abbrev='MD5 Message-Digest Algorithm'>The MD5 Message-Digest Algorithm</title>
<author initials='R.' surname='Rivest' fullname='Ronald L. Rivest'>
<organization>Massachusetts Institute of Technology, (MIT) Laboratory for Computer Science</organization>
<address>
<postal>
<street>545 Technology Square</street>
<street>NE43-324</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139-1986</code>
<country>US</country></postal>
<phone>+1 617 253 5880</phone>
<email>[email protected]</email></address></author>
<date year='1992' month='April' /></front>
<seriesInfo name='RFC' value='1321' />
<format type='TXT' octets='35222' target='http://www.rfc-editor.org/rfc/rfc1321.txt' />
</reference>
<!-- RFC4648 Added Fri, 22 May 2015 15:35:58 GMT -->
<!-- Source: http://xml.resource.org/public/rfc/bibxml/reference.RFC.4648.xml -->
<reference anchor='RFC4648'>
<front>
<title>The Base16, Base32, and Base64 Data Encodings</title>
<author initials='S.' surname='Josefsson' fullname='S. Josefsson'>
<organization /></author>
<date year='2006' month='October' />
<abstract>
<t>This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='4648' />
<format type='TXT' octets='35491' target='http://www.rfc-editor.org/rfc/rfc4648.txt' />
</reference>
<reference anchor="FedRes2016">
<front>
<title>The Federal Reserve Payments Study 2016</title>
<author>
<organization abbrev='Federal Reserve'>Federal Reserve</organization>
</author>
<date month='December' year='2016' />
</front>
<format type="pdf" target="https://www.federalreserve.gov/newsevents/press/other/2016-payments-study-20161222.pdf"/>
</reference><!-- RFC3986 Added Fri, 04 Aug 2017 21:30:20 GMT -->
<!-- Source: http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml -->
<reference anchor='RFC3986' target='http://www.rfc-editor.org/info/rfc3986'>
<front>
<title>Uniform Resource Identifier (URI): Generic Syntax</title>
<author initials='T.' surname='Berners-Lee' fullname='T. Berners-Lee'><organization /></author>
<author initials='R.' surname='Fielding' fullname='R. Fielding'><organization /></author>
<author initials='L.' surname='Masinter' fullname='L. Masinter'><organization /></author>
<date year='2005' month='January' />
<abstract><t>A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='STD' value='66'/>
<seriesInfo name='RFC' value='3986'/>
<seriesInfo name='DOI' value='10.17487/RFC3986'/>
</reference>
<!-- RFC3709 Added Fri, 04 Aug 2017 21:30:20 GMT -->
<!-- Source: http://xml.resource.org/public/rfc/bibxml/reference.RFC.3709.xml -->
<reference anchor='RFC3709' target='http://www.rfc-editor.org/info/rfc3709'>
<front>
<title>Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates</title>
<author initials='S.' surname='Santesson' fullname='S. Santesson'><organization /></author>
<author initials='R.' surname='Housley' fullname='R. Housley'><organization /></author>
<author initials='T.' surname='Freeman' fullname='T. Freeman'><organization /></author>
<date year='2004' month='February' />
<abstract><t>This document specifies a certificate extension for including logotypes in public key certificates and attribute certificates. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='3709'/>
<seriesInfo name='DOI' value='10.17487/RFC3709'/>
</reference>
<!-- RFC3492 Added Fri, 04 Aug 2017 21:30:20 GMT -->
<!-- Source: http://xml.resource.org/public/rfc/bibxml/reference.RFC.3492.xml -->
<reference anchor='RFC3492' target='http://www.rfc-editor.org/info/rfc3492'>
<front>
<title>Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)</title>
<author initials='A.' surname='Costello' fullname='A. Costello'><organization /></author>
<date year='2003' month='March' />
<abstract><t>Punycode is a simple and efficient transfer encoding syntax designed for use with Internationalized Domain Names in Applications (IDNA). It uniquely and reversibly transforms a Unicode string into an ASCII string. ASCII characters in the Unicode string are represented literally, and non-ASCII characters are represented by ASCII characters that are allowed in host name labels (letters, digits, and hyphens). This document defines a general algorithm called Bootstring that allows a string of basic code points to uniquely represent any string of code points drawn from a larger set. Punycode is an instance of Bootstring that uses particular parameter values specified by this document, appropriate for IDNA. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='3492'/>
<seriesInfo name='DOI' value='10.17487/RFC3492'/>
</reference>
<!-- draft-hallambaker-udf Added Fri, 04 Aug 2017 21:30:20 GMT -->
<!-- Source: https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.hallambaker-udf.xml -->
<reference anchor='I-D.hallambaker-udf'>
<front>
<title>Uniform Data Fingerprint (UDF)</title>
<author initials='P' surname='Hallam-Baker' fullname='Phillip Hallam-Baker'>
<organization />
</author>
<date month='May' day='9' year='2017' />
<abstract><t>This document describes means of generating Uniform Data Fingerprint (UDF) values and their presentation as text sequences and as URIs. Cryptographic digests provide a means of uniquely identifying static data without the need for a registration authority. A fingerprint is a form of presenting a cryptographic digest that makes it suitable for use in applications where human readability is required. The UDF fingerprint format improves over existing formats through the introduction of a compact algorithm identifier affording an intentionally limited choice of digest algorithm and the inclusion of an IANA registered MIME Content-Type identifier within the scope of the digest input to allow the use of a single fingerprint format in multiple application domains. Alternative means of rendering fingerprint values are considered including machine-readable codes, word and image lists.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-hallambaker-udf-05' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-hallambaker-udf-05.txt' />
</reference>
<!-- RFC6920 Added Fri, 04 Aug 2017 21:30:20 GMT -->
<!-- Source: http://xml.resource.org/public/rfc/bibxml/reference.RFC.6920.xml -->
<reference anchor='RFC6920' target='http://www.rfc-editor.org/info/rfc6920'>
<front>
<title>Naming Things with Hashes</title>
<author initials='S.' surname='Farrell' fullname='S. Farrell'><organization /></author>
<author initials='D.' surname='Kutscher' fullname='D. Kutscher'><organization /></author>
<author initials='C.' surname='Dannewitz' fullname='C. Dannewitz'><organization /></author>
<author initials='B.' surname='Ohlman' fullname='B. Ohlman'><organization /></author>
<author initials='A.' surname='Keranen' fullname='A. Keranen'><organization /></author>
<author initials='P.' surname='Hallam-Baker' fullname='P. Hallam-Baker'><organization /></author>
<date year='2013' month='April' />
<abstract><t>This document defines a set of ways to identify a thing (a digital object in this case) using the output from a hash function. It specifies a new URI scheme for this purpose, a way to map these to HTTP URLs, and binary and human-speakable formats for these names. The various formats are designed to support, but not require, a strong link to the referenced object, such that the referenced object may be authenticated to the same degree as the reference to it. The reason for this work is to standardise current uses of hash outputs in URLs and to support new information-centric applications and other uses of hash outputs in protocols.</t></abstract>
</front>
<seriesInfo name='RFC' value='6920'/>
<seriesInfo name='DOI' value='10.17487/RFC6920'/>
</reference>
<!-- RFC6763 Added Fri, 04 Aug 2017 21:30:20 GMT -->
<!-- Source: http://xml.resource.org/public/rfc/bibxml/reference.RFC.6763.xml -->
<reference anchor='RFC6763' target='http://www.rfc-editor.org/info/rfc6763'>
<front>
<title>DNS-Based Service Discovery</title>
<author initials='S.' surname='Cheshire' fullname='S. Cheshire'><organization /></author>
<author initials='M.' surname='Krochmal' fullname='M. Krochmal'><organization /></author>
<date year='2013' month='February' />
<abstract><t>This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD.</t></abstract>
</front>
<seriesInfo name='RFC' value='6763'/>
<seriesInfo name='DOI' value='10.17487/RFC6763'/>
</reference>
<!-- RFC6698 Added Fri, 04 Aug 2017 21:30:20 GMT -->
<!-- Source: http://xml.resource.org/public/rfc/bibxml/reference.RFC.6698.xml -->
<reference anchor='RFC6698' target='http://www.rfc-editor.org/info/rfc6698'>
<front>
<title>The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA</title>
<author initials='P.' surname='Hoffman' fullname='P. Hoffman'><organization /></author>
<author initials='J.' surname='Schlyter' fullname='J. Schlyter'><organization /></author>
<date year='2012' month='August' />
<abstract><t>Encrypted communication on the Internet often uses Transport Layer Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6698'/>
<seriesInfo name='DOI' value='10.17487/RFC6698'/>
</reference>
<!-- RFC4398 Added Fri, 04 Aug 2017 21:30:20 GMT -->
<!-- Source: http://xml.resource.org/public/rfc/bibxml/reference.RFC.4398.xml -->
<reference anchor='RFC4398' target='http://www.rfc-editor.org/info/rfc4398'>
<front>
<title>Storing Certificates in the Domain Name System (DNS)</title>
<author initials='S.' surname='Josefsson' fullname='S. Josefsson'><organization /></author>
<date year='2006' month='March' />
<abstract><t>Cryptographic public keys are frequently published, and their authenticity is demonstrated by certificates. A CERT resource record (RR) is defined so that such certificates and related certificate revocation lists can be stored in the Domain Name System (DNS). [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4398'/>
<seriesInfo name='DOI' value='10.17487/RFC4398'/>
</reference>
<!-- draft-hallambaker-udf Added Fri, 04 Aug 2017 21:40:33 GMT -->
<!-- Source: https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.hallambaker-udf.xml -->
<reference anchor='I-D.hallambaker-udf'>
<front>
<title>Uniform Data Fingerprint (UDF)</title>
<author initials='P' surname='Hallam-Baker' fullname='Phillip Hallam-Baker'>
<organization />
</author>
<date month='May' day='9' year='2017' />
<abstract><t>This document describes means of generating Uniform Data Fingerprint (UDF) values and their presentation as text sequences and as URIs. Cryptographic digests provide a means of uniquely identifying static data without the need for a registration authority. A fingerprint is a form of presenting a cryptographic digest that makes it suitable for use in applications where human readability is required. The UDF fingerprint format improves over existing formats through the introduction of a compact algorithm identifier affording an intentionally limited choice of digest algorithm and the inclusion of an IANA registered MIME Content-Type identifier within the scope of the digest input to allow the use of a single fingerprint format in multiple application domains. Alternative means of rendering fingerprint values are considered including machine-readable codes, word and image lists.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-hallambaker-udf-05' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-hallambaker-udf-05.txt' />
</reference>
<!-- draft-hallambaker-mesh-architecture Added Fri, 11 Aug 2017 17:55:27 GMT -->
<!-- Source: https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.hallambaker-mesh-architecture.xml -->
<reference anchor='I-D.hallambaker-mesh-architecture'>
<front>
<title>Mathematical Mesh: Architecture</title>
<author initials='P' surname='Hallam-Baker' fullname='Phillip Hallam-Baker'>
<organization />
</author>
<date month='May' day='9' year='2017' />
<abstract><t>The Mathematical Mesh 'The Mesh' is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. The architecture of the Mesh and examples of typical applications are described.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-hallambaker-mesh-architecture-03' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-hallambaker-mesh-architecture-03.txt' />
</reference>
<!-- draft-hallambaker-udf Added Fri, 11 Aug 2017 17:55:27 GMT -->
<!-- Source: https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.hallambaker-udf.xml -->
<reference anchor='I-D.hallambaker-udf'>
<front>
<title>Uniform Data Fingerprint (UDF)</title>
<author initials='P' surname='Hallam-Baker' fullname='Phillip Hallam-Baker'>
<organization />
</author>
<date month='May' day='9' year='2017' />
<abstract><t>This document describes means of generating Uniform Data Fingerprint (UDF) values and their presentation as text sequences and as URIs. Cryptographic digests provide a means of uniquely identifying static data without the need for a registration authority. A fingerprint is a form of presenting a cryptographic digest that makes it suitable for use in applications where human readability is required. The UDF fingerprint format improves over existing formats through the introduction of a compact algorithm identifier affording an intentionally limited choice of digest algorithm and the inclusion of an IANA registered MIME Content-Type identifier within the scope of the digest input to allow the use of a single fingerprint format in multiple application domains. Alternative means of rendering fingerprint values are considered including machine-readable codes, word and image lists.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-hallambaker-udf-05' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-hallambaker-udf-05.txt' />
</reference>
<!-- draft-hallambaker-prismproof-trust Added Fri, 11 Aug 2017 17:55:27 GMT -->
<!-- Source: https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.hallambaker-prismproof-trust.xml -->
<reference anchor='I-D.hallambaker-prismproof-trust'>
<front>
<title>PRISM Proof Trust Model</title>
<author initials='P' surname='Hallam-Baker' fullname='Phillip Hallam-Baker'>
<organization />
</author>
<date month='October' day='27' year='2014' />
<abstract><t>This paper extends Shanon's concept of a 'work factor' to provide an objective measure of the practical security offered by a protocol or infrastructure design. Considering the hypothetical work factor based on an informed estimate of the probable capabilities of an attacker with unknown resources provides a better indication of the relative strength of protocol designs than the computational work factor of the best known attack. The social work factor is a measure of the trustworthiness of a credential issued in a PKI based on the cost of having obtained the credential through fraud at a certain point in time. Use of the social work factor allows evaluation of Certificate Authority based trust models, peer to peer (Web of Trust) models to be evaluated in the same framework. The analysis shows that each model has clear benefits over the other for some classes of user but most classes of user are served better by a combination of both.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-hallambaker-prismproof-trust-01' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-hallambaker-prismproof-trust-01.txt' />
</reference>
<!-- draft-hallambaker-mesh-architecture Added Fri, 11 Aug 2017 23:05:28 GMT -->
<!-- Source: https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.hallambaker-mesh-architecture.xml -->
<reference anchor='I-D.hallambaker-mesh-architecture'>
<front>
<title>Mathematical Mesh: Architecture</title>
<author initials='P' surname='Hallam-Baker' fullname='Phillip Hallam-Baker'>
<organization />
</author>
<date month='May' day='9' year='2017' />
<abstract><t>The Mathematical Mesh 'The Mesh' is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. The architecture of the Mesh and examples of typical applications are described.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-hallambaker-mesh-architecture-03' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-hallambaker-mesh-architecture-03.txt' />
</reference>
<!-- draft-hallambaker-udf Added Fri, 11 Aug 2017 23:05:28 GMT -->
<!-- Source: https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.hallambaker-udf.xml -->
<reference anchor='I-D.hallambaker-udf'>
<front>
<title>Uniform Data Fingerprint (UDF)</title>
<author initials='P' surname='Hallam-Baker' fullname='Phillip Hallam-Baker'>
<organization />
</author>
<date month='May' day='9' year='2017' />
<abstract><t>This document describes means of generating Uniform Data Fingerprint (UDF) values and their presentation as text sequences and as URIs. Cryptographic digests provide a means of uniquely identifying static data without the need for a registration authority. A fingerprint is a form of presenting a cryptographic digest that makes it suitable for use in applications where human readability is required. The UDF fingerprint format improves over existing formats through the introduction of a compact algorithm identifier affording an intentionally limited choice of digest algorithm and the inclusion of an IANA registered MIME Content-Type identifier within the scope of the digest input to allow the use of a single fingerprint format in multiple application domains. Alternative means of rendering fingerprint values are considered including machine-readable codes, word and image lists.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-hallambaker-udf-05' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-hallambaker-udf-05.txt' />
</reference>
<!-- draft-hallambaker-prismproof-trust Added Fri, 11 Aug 2017 23:05:28 GMT -->
<!-- Source: https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.hallambaker-prismproof-trust.xml -->
<reference anchor='I-D.hallambaker-prismproof-trust'>
<front>
<title>PRISM Proof Trust Model</title>
<author initials='P' surname='Hallam-Baker' fullname='Phillip Hallam-Baker'>
<organization />
</author>
<date month='October' day='27' year='2014' />
<abstract><t>This paper extends Shanon's concept of a 'work factor' to provide an objective measure of the practical security offered by a protocol or infrastructure design. Considering the hypothetical work factor based on an informed estimate of the probable capabilities of an attacker with unknown resources provides a better indication of the relative strength of protocol designs than the computational work factor of the best known attack. The social work factor is a measure of the trustworthiness of a credential issued in a PKI based on the cost of having obtained the credential through fraud at a certain point in time. Use of the social work factor allows evaluation of Certificate Authority based trust models, peer to peer (Web of Trust) models to be evaluated in the same framework. The analysis shows that each model has clear benefits over the other for some classes of user but most classes of user are served better by a combination of both.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-hallambaker-prismproof-trust-01' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-hallambaker-prismproof-trust-01.txt' />
</reference>
<!-- draft-hallambaker-mesh-architecture Added Fri, 11 Aug 2017 23:06:09 GMT -->
<!-- Source: https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.hallambaker-mesh-architecture.xml -->
<reference anchor='I-D.hallambaker-mesh-architecture'>
<front>
<title>Mathematical Mesh: Architecture</title>
<author initials='P' surname='Hallam-Baker' fullname='Phillip Hallam-Baker'>
<organization />
</author>
<date month='May' day='9' year='2017' />
<abstract><t>The Mathematical Mesh 'The Mesh' is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. The architecture of the Mesh and examples of typical applications are described.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-hallambaker-mesh-architecture-03' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-hallambaker-mesh-architecture-03.txt' />
</reference>
<!-- draft-hallambaker-udf Added Fri, 11 Aug 2017 23:06:09 GMT -->
<!-- Source: https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.hallambaker-udf.xml -->
<reference anchor='I-D.hallambaker-udf'>
<front>
<title>Uniform Data Fingerprint (UDF)</title>
<author initials='P' surname='Hallam-Baker' fullname='Phillip Hallam-Baker'>
<organization />
</author>
<date month='May' day='9' year='2017' />
<abstract><t>This document describes means of generating Uniform Data Fingerprint (UDF) values and their presentation as text sequences and as URIs. Cryptographic digests provide a means of uniquely identifying static data without the need for a registration authority. A fingerprint is a form of presenting a cryptographic digest that makes it suitable for use in applications where human readability is required. The UDF fingerprint format improves over existing formats through the introduction of a compact algorithm identifier affording an intentionally limited choice of digest algorithm and the inclusion of an IANA registered MIME Content-Type identifier within the scope of the digest input to allow the use of a single fingerprint format in multiple application domains. Alternative means of rendering fingerprint values are considered including machine-readable codes, word and image lists.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-hallambaker-udf-05' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-hallambaker-udf-05.txt' />
</reference>
<!-- draft-hallambaker-prismproof-trust Added Fri, 11 Aug 2017 23:06:09 GMT -->
<!-- Source: https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.hallambaker-prismproof-trust.xml -->
<reference anchor='I-D.hallambaker-prismproof-trust'>
<front>
<title>PRISM Proof Trust Model</title>
<author initials='P' surname='Hallam-Baker' fullname='Phillip Hallam-Baker'>
<organization />
</author>
<date month='October' day='27' year='2014' />
<abstract><t>This paper extends Shanon's concept of a 'work factor' to provide an objective measure of the practical security offered by a protocol or infrastructure design. Considering the hypothetical work factor based on an informed estimate of the probable capabilities of an attacker with unknown resources provides a better indication of the relative strength of protocol designs than the computational work factor of the best known attack. The social work factor is a measure of the trustworthiness of a credential issued in a PKI based on the cost of having obtained the credential through fraud at a certain point in time. Use of the social work factor allows evaluation of Certificate Authority based trust models, peer to peer (Web of Trust) models to be evaluated in the same framework. The analysis shows that each model has clear benefits over the other for some classes of user but most classes of user are served better by a combination of both.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-hallambaker-prismproof-trust-01' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-hallambaker-prismproof-trust-01.txt' />
</reference>
<!-- draft-hallambaker-mesh-architecture Added Fri, 11 Aug 2017 23:07:22 GMT -->
<!-- Source: https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.hallambaker-mesh-architecture.xml -->
<reference anchor='I-D.hallambaker-mesh-architecture'>
<front>
<title>Mathematical Mesh: Architecture</title>
<author initials='P' surname='Hallam-Baker' fullname='Phillip Hallam-Baker'>
<organization />
</author>
<date month='May' day='9' year='2017' />
<abstract><t>The Mathematical Mesh 'The Mesh' is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. The architecture of the Mesh and examples of typical applications are described.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-hallambaker-mesh-architecture-03' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-hallambaker-mesh-architecture-03.txt' />
</reference>
<!-- draft-hallambaker-udf Added Fri, 11 Aug 2017 23:07:22 GMT -->
<!-- Source: https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.hallambaker-udf.xml -->
<reference anchor='I-D.hallambaker-udf'>
<front>
<title>Uniform Data Fingerprint (UDF)</title>
<author initials='P' surname='Hallam-Baker' fullname='Phillip Hallam-Baker'>
<organization />
</author>
<date month='May' day='9' year='2017' />
<abstract><t>This document describes means of generating Uniform Data Fingerprint (UDF) values and their presentation as text sequences and as URIs. Cryptographic digests provide a means of uniquely identifying static data without the need for a registration authority. A fingerprint is a form of presenting a cryptographic digest that makes it suitable for use in applications where human readability is required. The UDF fingerprint format improves over existing formats through the introduction of a compact algorithm identifier affording an intentionally limited choice of digest algorithm and the inclusion of an IANA registered MIME Content-Type identifier within the scope of the digest input to allow the use of a single fingerprint format in multiple application domains. Alternative means of rendering fingerprint values are considered including machine-readable codes, word and image lists.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-hallambaker-udf-05' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-hallambaker-udf-05.txt' />
</reference>
<!-- draft-hallambaker-prismproof-trust Added Fri, 11 Aug 2017 23:07:22 GMT -->
<!-- Source: https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.hallambaker-prismproof-trust.xml -->
<reference anchor='I-D.hallambaker-prismproof-trust'>
<front>
<title>PRISM Proof Trust Model</title>
<author initials='P' surname='Hallam-Baker' fullname='Phillip Hallam-Baker'>
<organization />
</author>
<date month='October' day='27' year='2014' />
<abstract><t>This paper extends Shanon's concept of a 'work factor' to provide an objective measure of the practical security offered by a protocol or infrastructure design. Considering the hypothetical work factor based on an informed estimate of the probable capabilities of an attacker with unknown resources provides a better indication of the relative strength of protocol designs than the computational work factor of the best known attack. The social work factor is a measure of the trustworthiness of a credential issued in a PKI based on the cost of having obtained the credential through fraud at a certain point in time. Use of the social work factor allows evaluation of Certificate Authority based trust models, peer to peer (Web of Trust) models to be evaluated in the same framework. The analysis shows that each model has clear benefits over the other for some classes of user but most classes of user are served better by a combination of both.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-hallambaker-prismproof-trust-01' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-hallambaker-prismproof-trust-01.txt' />
</reference>
<!-- draft-hallambaker-mesh-architecture Added Fri, 11 Aug 2017 23:13:17 GMT -->
<!-- Source: https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.hallambaker-mesh-architecture.xml -->
<reference anchor='I-D.hallambaker-mesh-architecture'>
<front>
<title>Mathematical Mesh: Architecture</title>
<author initials='P' surname='Hallam-Baker' fullname='Phillip Hallam-Baker'>
<organization />
</author>
<date month='May' day='9' year='2017' />
<abstract><t>The Mathematical Mesh 'The Mesh' is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. The architecture of the Mesh and examples of typical applications are described.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-hallambaker-mesh-architecture-03' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-hallambaker-mesh-architecture-03.txt' />
</reference>
<!-- draft-hallambaker-udf Added Fri, 11 Aug 2017 23:13:17 GMT -->
<!-- Source: https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.hallambaker-udf.xml -->
<reference anchor='I-D.hallambaker-udf'>
<front>
<title>Uniform Data Fingerprint (UDF)</title>
<author initials='P' surname='Hallam-Baker' fullname='Phillip Hallam-Baker'>
<organization />
</author>
<date month='May' day='9' year='2017' />
<abstract><t>This document describes means of generating Uniform Data Fingerprint (UDF) values and their presentation as text sequences and as URIs. Cryptographic digests provide a means of uniquely identifying static data without the need for a registration authority. A fingerprint is a form of presenting a cryptographic digest that makes it suitable for use in applications where human readability is required. The UDF fingerprint format improves over existing formats through the introduction of a compact algorithm identifier affording an intentionally limited choice of digest algorithm and the inclusion of an IANA registered MIME Content-Type identifier within the scope of the digest input to allow the use of a single fingerprint format in multiple application domains. Alternative means of rendering fingerprint values are considered including machine-readable codes, word and image lists.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-hallambaker-udf-05' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-hallambaker-udf-05.txt' />
</reference>
<!-- draft-hallambaker-prismproof-trust Added Fri, 11 Aug 2017 23:13:17 GMT -->
<!-- Source: https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.hallambaker-prismproof-trust.xml -->
<reference anchor='I-D.hallambaker-prismproof-trust'>
<front>
<title>PRISM Proof Trust Model</title>
<author initials='P' surname='Hallam-Baker' fullname='Phillip Hallam-Baker'>
<organization />
</author>
<date month='October' day='27' year='2014' />
<abstract><t>This paper extends Shanon's concept of a 'work factor' to provide an objective measure of the practical security offered by a protocol or infrastructure design. Considering the hypothetical work factor based on an informed estimate of the probable capabilities of an attacker with unknown resources provides a better indication of the relative strength of protocol designs than the computational work factor of the best known attack. The social work factor is a measure of the trustworthiness of a credential issued in a PKI based on the cost of having obtained the credential through fraud at a certain point in time. Use of the social work factor allows evaluation of Certificate Authority based trust models, peer to peer (Web of Trust) models to be evaluated in the same framework. The analysis shows that each model has clear benefits over the other for some classes of user but most classes of user are served better by a combination of both.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-hallambaker-prismproof-trust-01' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-hallambaker-prismproof-trust-01.txt' />
</reference>
<!-- draft-hallambaker-mesh-architecture Added Fri, 11 Aug 2017 23:15:16 GMT -->
<!-- Source: https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.hallambaker-mesh-architecture.xml -->
<reference anchor='I-D.hallambaker-mesh-architecture'>
<front>
<title>Mathematical Mesh: Architecture</title>
<author initials='P' surname='Hallam-Baker' fullname='Phillip Hallam-Baker'>
<organization />
</author>
<date month='May' day='9' year='2017' />
<abstract><t>The Mathematical Mesh 'The Mesh' is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. The architecture of the Mesh and examples of typical applications are described.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-hallambaker-mesh-architecture-03' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-hallambaker-mesh-architecture-03.txt' />
</reference>
<!-- draft-hallambaker-udf Added Fri, 11 Aug 2017 23:15:16 GMT -->
<!-- Source: https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.hallambaker-udf.xml -->
<reference anchor='I-D.hallambaker-udf'>
<front>
<title>Uniform Data Fingerprint (UDF)</title>
<author initials='P' surname='Hallam-Baker' fullname='Phillip Hallam-Baker'>
<organization />
</author>
<date month='May' day='9' year='2017' />
<abstract><t>This document describes means of generating Uniform Data Fingerprint (UDF) values and their presentation as text sequences and as URIs. Cryptographic digests provide a means of uniquely identifying static data without the need for a registration authority. A fingerprint is a form of presenting a cryptographic digest that makes it suitable for use in applications where human readability is required. The UDF fingerprint format improves over existing formats through the introduction of a compact algorithm identifier affording an intentionally limited choice of digest algorithm and the inclusion of an IANA registered MIME Content-Type identifier within the scope of the digest input to allow the use of a single fingerprint format in multiple application domains. Alternative means of rendering fingerprint values are considered including machine-readable codes, word and image lists.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-hallambaker-udf-05' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-hallambaker-udf-05.txt' />
</reference>
<!-- draft-hallambaker-prismproof-trust Added Fri, 11 Aug 2017 23:15:16 GMT -->
<!-- Source: https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.hallambaker-prismproof-trust.xml -->
<reference anchor='I-D.hallambaker-prismproof-trust'>
<front>
<title>PRISM Proof Trust Model</title>
<author initials='P' surname='Hallam-Baker' fullname='Phillip Hallam-Baker'>
<organization />
</author>
<date month='October' day='27' year='2014' />
<abstract><t>This paper extends Shanon's concept of a 'work factor' to provide an objective measure of the practical security offered by a protocol or infrastructure design. Considering the hypothetical work factor based on an informed estimate of the probable capabilities of an attacker with unknown resources provides a better indication of the relative strength of protocol designs than the computational work factor of the best known attack. The social work factor is a measure of the trustworthiness of a credential issued in a PKI based on the cost of having obtained the credential through fraud at a certain point in time. Use of the social work factor allows evaluation of Certificate Authority based trust models, peer to peer (Web of Trust) models to be evaluated in the same framework. The analysis shows that each model has clear benefits over the other for some classes of user but most classes of user are served better by a combination of both.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-hallambaker-prismproof-trust-01' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-hallambaker-prismproof-trust-01.txt' />
</reference>
<!-- draft-hallambaker-mesh-architecture Added Fri, 11 Aug 2017 23:15:51 GMT -->
<!-- Source: https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.hallambaker-mesh-architecture.xml -->
<reference anchor='I-D.hallambaker-mesh-architecture'>
<front>
<title>Mathematical Mesh: Architecture</title>
<author initials='P' surname='Hallam-Baker' fullname='Phillip Hallam-Baker'>
<organization />
</author>
<date month='May' day='9' year='2017' />
<abstract><t>The Mathematical Mesh 'The Mesh' is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. The architecture of the Mesh and examples of typical applications are described.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-hallambaker-mesh-architecture-03' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-hallambaker-mesh-architecture-03.txt' />
</reference>
<!-- draft-hallambaker-udf Added Fri, 11 Aug 2017 23:15:51 GMT -->
<!-- Source: https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.hallambaker-udf.xml -->
<reference anchor='I-D.hallambaker-udf'>
<front>
<title>Uniform Data Fingerprint (UDF)</title>
<author initials='P' surname='Hallam-Baker' fullname='Phillip Hallam-Baker'>
<organization />
</author>
<date month='May' day='9' year='2017' />
<abstract><t>This document describes means of generating Uniform Data Fingerprint (UDF) values and their presentation as text sequences and as URIs. Cryptographic digests provide a means of uniquely identifying static data without the need for a registration authority. A fingerprint is a form of presenting a cryptographic digest that makes it suitable for use in applications where human readability is required. The UDF fingerprint format improves over existing formats through the introduction of a compact algorithm identifier affording an intentionally limited choice of digest algorithm and the inclusion of an IANA registered MIME Content-Type identifier within the scope of the digest input to allow the use of a single fingerprint format in multiple application domains. Alternative means of rendering fingerprint values are considered including machine-readable codes, word and image lists.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-hallambaker-udf-05' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-hallambaker-udf-05.txt' />
</reference>
<!-- draft-hallambaker-prismproof-trust Added Fri, 11 Aug 2017 23:15:51 GMT -->
<!-- Source: https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.hallambaker-prismproof-trust.xml -->
<reference anchor='I-D.hallambaker-prismproof-trust'>
<front>
<title>PRISM Proof Trust Model</title>
<author initials='P' surname='Hallam-Baker' fullname='Phillip Hallam-Baker'>
<organization />
</author>
<date month='October' day='27' year='2014' />
<abstract><t>This paper extends Shanon's concept of a 'work factor' to provide an objective measure of the practical security offered by a protocol or infrastructure design. Considering the hypothetical work factor based on an informed estimate of the probable capabilities of an attacker with unknown resources provides a better indication of the relative strength of protocol designs than the computational work factor of the best known attack. The social work factor is a measure of the trustworthiness of a credential issued in a PKI based on the cost of having obtained the credential through fraud at a certain point in time. Use of the social work factor allows evaluation of Certificate Authority based trust models, peer to peer (Web of Trust) models to be evaluated in the same framework. The analysis shows that each model has clear benefits over the other for some classes of user but most classes of user are served better by a combination of both.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-hallambaker-prismproof-trust-01' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-hallambaker-prismproof-trust-01.txt' />
</reference>
<!-- draft-hallambaker-mesh-architecture Added Fri, 11 Aug 2017 23:18:05 GMT -->
<!-- Source: https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.hallambaker-mesh-architecture.xml -->
<reference anchor='I-D.hallambaker-mesh-architecture'>
<front>
<title>Mathematical Mesh: Architecture</title>
<author initials='P' surname='Hallam-Baker' fullname='Phillip Hallam-Baker'>
<organization />
</author>
<date month='May' day='9' year='2017' />
<abstract><t>The Mathematical Mesh 'The Mesh' is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. The architecture of the Mesh and examples of typical applications are described.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-hallambaker-mesh-architecture-03' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-hallambaker-mesh-architecture-03.txt' />
</reference>
<!-- draft-hallambaker-udf Added Fri, 11 Aug 2017 23:18:05 GMT -->
<!-- Source: https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.hallambaker-udf.xml -->
<reference anchor='I-D.hallambaker-udf'>
<front>
<title>Uniform Data Fingerprint (UDF)</title>
<author initials='P' surname='Hallam-Baker' fullname='Phillip Hallam-Baker'>
<organization />
</author>
<date month='May' day='9' year='2017' />
<abstract><t>This document describes means of generating Uniform Data Fingerprint (UDF) values and their presentation as text sequences and as URIs. Cryptographic digests provide a means of uniquely identifying static data without the need for a registration authority. A fingerprint is a form of presenting a cryptographic digest that makes it suitable for use in applications where human readability is required. The UDF fingerprint format improves over existing formats through the introduction of a compact algorithm identifier affording an intentionally limited choice of digest algorithm and the inclusion of an IANA registered MIME Content-Type identifier within the scope of the digest input to allow the use of a single fingerprint format in multiple application domains. Alternative means of rendering fingerprint values are considered including machine-readable codes, word and image lists.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-hallambaker-udf-05' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-hallambaker-udf-05.txt' />
</reference>