idnits 2.17.1 draft-foudil-securitytxt-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 11 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 09, 2018) is 2261 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5322' is defined on line 559, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Foudil 3 Internet-Draft 4 Intended status: Informational Y. Shafranovich 5 Expires: August 13, 2018 Nightwatch Cybersecurity 6 February 09, 2018 8 A Method for Web Security Policies 9 draft-foudil-securitytxt-03 11 Abstract 13 When security risks in web services are discovered by independent 14 security researchers who understand the severity of the risk, they 15 often lack the channels to disclose them properly. As a result, 16 security issues may be left unreported. security.txt defines a 17 standard to help organizations describe the process for security 18 researchers to disclose security vulnerabilities securely. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 13, 2018. 37 Copyright Notice 39 Copyright (c) 2018 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Note to Readers . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. The Specification . . . . . . . . . . . . . . . . . . . . . . 3 59 3.1. Comments . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.2. Separate Fields . . . . . . . . . . . . . . . . . . . . . 4 61 3.3. Contact: . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.4. Encryption: . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.5. Signature: . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.6. Policy: . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.7. Acknowledgments: . . . . . . . . . . . . . . . . . . . . 6 66 3.8. Hiring: . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.9. Example . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 4. Location of the security.txt file . . . . . . . . . . . . . . 7 69 4.1. Web-based services . . . . . . . . . . . . . . . . . . . 7 70 4.2. Filesystems . . . . . . . . . . . . . . . . . . . . . . . 8 71 4.3. Internal hosts . . . . . . . . . . . . . . . . . . . . . 8 72 4.4. Extensibility . . . . . . . . . . . . . . . . . . . . . . 8 73 5. File Format Description . . . . . . . . . . . . . . . . . . . 8 74 6. Security considerations . . . . . . . . . . . . . . . . . . . 9 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 76 7.1. Well-Known URIs registry . . . . . . . . . . . . . . . . 10 77 7.2. Registry for security.txt Header Fields . . . . . . . . . 10 78 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 81 9.2. Informative References . . . . . . . . . . . . . . . . . 13 82 Appendix A. Note to Readers . . . . . . . . . . . . . . . . . . 13 83 Appendix B. Document History . . . . . . . . . . . . . . . . . . 14 84 B.1. Since draft-foudil-securitytxt-00 . . . . . . . . . . . . 14 85 B.2. Since draft-foudil-securitytxt-01 . . . . . . . . . . . . 14 86 B.3. Since draft-foudil-securitytxt-02 . . . . . . . . . . . . 15 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 89 1. Introduction 91 1.1. Motivation 93 Many security researchers encounter situations where they are unable 94 to responsibly disclose security issues to companies because there is 95 no course of action laid out. security.txt is designed to help assist 96 in this process by making it easier for companies to designate the 97 preferred steps for researchers to take when trying to reach out. 99 As per section 4 of [RFC2142], there is an existing convention of 100 using the email address for communications 101 regarding security issues. That convention provides only a single, 102 email-based channel of communication for security issues per domain, 103 and does not provide a way for domain owners to publish information 104 about their security disclosure policies. 106 In this document, we propose a richer, machine-parsable and more 107 extensible way for companies to communicate information about their 108 security disclosure policies, which is not limited to email and also 109 allows for additional features such as encryption. 111 1.2. Terminology 113 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 114 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 115 and "OPTIONAL" are to be interpreted as described in [RFC2119]. 117 2. Note to Readers 119 *Note to the RFC Editor:* Please remove this section prior to 120 publication. 122 Development of this draft takes place on Github at: 123 https://github.com/securitytxt/security-txt 125 3. The Specification 127 security.txt is a text file that SHOULD be located under the /.well- 128 known/ path ("/.well-known/security.txt") [RFC5785] for web 129 properties. If it is not possible to place the security.txt file in 130 the /.well-known/ path or setup a redirect, web-based services MAY 131 place the file in the top-level path as a fall back option. For web- 132 based services, the instructions MUST be accessible via the Hypertext 133 Transfer Protocol [RFC1945] as a resource of Internet Media Type 134 "text/plain" with the default charset parameter set to "utf-8" per 135 section 4.1.3 of [RFC2046]. For file systems and version control 136 repositories a .security.txt file SHOULD be placed in the root 137 directory. 139 This text file contains multiple directives with different values. 140 The "directive" is the first part of a field all the way up to the 141 colon ("Contact:"). Directives are case-insensitive. The "value" 142 comes after the directive ("https://example.com/security"). A 143 "field" always consists of a directive and a value ("Contact: 145 https://example.com/security"). A security.txt file can have an 146 unlimited number of fields. It is important to note that you need a 147 separate line for every field. One MUST NOT chain multiple values 148 for a single directive. Everything MUST be in a separate field. 150 A security.txt file MUST only apply to the domain in the URI used to 151 retrieve it, not to any of its subdomains or parent domains. 153 # The following only applies to example.com. 154 https://example.com/.well-known/security.txt 156 # This only applies to subdomain.example.com. 157 https://subdomain.example.com/.well-known/security.txt 159 # This security.txt file applies to IPv4 address of 192.0.2.0. 160 http://192.0.2.0/.well-known/security.txt 162 # This security.txt file applies to IPv6 address of 2001:db8:8:4::2. 163 http://[2001:db8:8:4::2]/.well-known/security.txt 165 3.1. Comments 167 Comments can be added using the # symbol: 169 # This is a comment. 171 You MAY use one or more comments as descriptive text immediately 172 before the field. Parsers can then associate the comments with the 173 respective field. 175 3.2. Separate Fields 177 A separate line is required for every new value and field. You MUST 178 NOT chain everything into a single field. Every line MUST end either 179 with a carriage return and line feed characters (CRLF / %x0D %x0A) or 180 just a line feed character (LF / %x0A). 182 3.3. Contact: 184 Add an address that researchers MAY use for reporting security 185 issues. The value can be an email address, a phone number and/or a 186 contact page with more information. The "Contact:" directive MUST 187 always be present in a security.txt file. URIs SHOULD be loaded over 188 HTTPS. Security email addresses SHOULD use the conventions defined 189 in section 4 of [RFC2142], but there is no requirement for this 190 directive to be an email address. 192 The value MUST follow the general syntax described in [RFC3986]. 193 This means that "mailto" and "tel" URI schemes MUST be used when 194 specifying email addresses and telephone numbers. 196 The precedence is in listed order. The first field is the preferred 197 method of contact. In the example below, the e-mail address is the 198 preferred method of contact. 200 Contact: mailto:security@example.com 201 Contact: tel:+1-201-555-0123 202 Contact: https://example.com/security-contact.html 204 3.4. Encryption: 206 This directive allows you to point to an encryption key that you want 207 security researchers to use for encrypted communication. You MUST 208 NOT directly add your key to the field, instead the value of this 209 field MUST be a URI pointing to a location where the key can be 210 retrieved from. If the key is being retrieved from a website, then 211 the key MUST be loaded over HTTPS. 213 When it comes to verifying the authenticity of the key, it is always 214 the security researcher's responsibility to make sure the key being 215 specified is indeed one they trust. Researchers MUST NOT assume that 216 this key is used to generate the signature file referenced in 217 Section 3.5. 219 Example of a PGP key available from a web server: 221 Encryption: https://example.com/pgp-key.txt 223 Example of a PGP key available from an OPENPGPKEY DNS record under 224 "security@example.com" (as per [RFC7553] and [RFC7929]): 226 Encryption: dns:5d2d3ceb7abe552344276d47d36._openpgpkey.example.com?type=OPENPGPKEY 228 3.5. Signature: 230 In order to ensure the authenticity of the security.txt file one 231 SHOULD use the "Signature:" directive, which allows you to link to an 232 external signature by specifying the full URI where the signature is 233 located as per [RFC3986]. External signature files SHOULD be named 234 "security.txt.sig" and also be placed under the /.well-known/ path. 235 External signature files SHOULD be loaded over HTTPS. 237 When it comes to verifying the authenticity of the file, it is always 238 the security researcher's responsibility to make sure the key being 239 specified is indeed one they trust. 241 Here is an example of an external signature file. 243 Signature: https://example.com/.well-known/security.txt.sig 245 3.6. Policy: 247 With the Policy directive, you can link to where your security policy 248 and/or disclosure policy is located. This can help security 249 researchers understand what you are looking for and how to report 250 security vulnerabilities. 252 Policy: https://example.com/security-policy.html 254 3.7. Acknowledgments: 256 This directive allows you to link to a page where security 257 researchers are recognized for their reports. The page SHOULD list 258 individuals or companies that disclosed security vulnerabilities and 259 worked with you to remediate the issue. 261 Acknowledgments: https://example.com/hall-of-fame.html 263 Example security acknowledgments page: 265 We would like to thank the following researchers: 267 (2017-04-15) Frank Denis - Reflected cross-site scripting 268 (2017-01-02) Alice Quinn - SQL injection 269 (2016-12-24) John Buchner - Stored cross-site scripting 270 (2016-06-10) Anna Richmond - A server configuration issue 272 3.8. Hiring: 274 The "Hiring" directive is for linking to the vendor's security- 275 related job positions. 277 Hiring: https://example.com/jobs.html 279 3.9. Example 280 # Our security address 281 Contact: mailto:security@example.com 283 # Our PGP key 284 Encryption: https://example.com/pgp-key.txt 286 # Our security policy 287 Policy: https://example.com/security-policy.html 289 # Our security acknowledgments page 290 Acknowledgments: https://example.com/hall-of-fame.html 292 # Verify this security.txt file 293 Signature: https://example.com/.well-known/security.txt.sig 295 4. Location of the security.txt file 297 External 298 +----------------------------------------------------------------+ 299 | Default | 300 | +-----------------------------+ +-----------------+ | 301 | | | Redirect | | | 302 | | /.well-known/security.txt <----------+ /security.txt | | 303 | | | | | | 304 | +-----------------------------+ +-----------------+ | 305 | | 306 +----------------------------------------------------------------+ 308 Internal 309 +------------------------+ 310 | | 311 | +------------------+ | 312 | | | | 313 | | /.security.txt | | 314 | | | | 315 | +------------------+ | 316 | | 317 +------------------------+ 319 4.1. Web-based services 321 Web-based services SHOULD place the security.txt file under the 322 /.well-known/ path; e.g. https://example.com/.well-known/ 323 security.txt. A security.txt file located under the top-level path 324 SHOULD either redirect to the security.txt file under the /.well- 325 known/ path or be used as a fall back. 327 4.2. Filesystems 329 File systems SHOULD place the security.txt file under the root 330 directory; e.g., /.security.txt, C:.security.txt. 332 user:/$ l 333 .security.txt 334 example-directory-1/ 335 example-directory-2/ 336 example-directory-3/ 337 example-file 339 4.3. Internal hosts 341 A .security.txt file SHOULD be placed in the root directory of an 342 internal host to trigger incident response. 344 4.4. Extensibility 346 Like many other formats and protocols, this format may need to be 347 extended over time to fit the ever-changing landscape of the 348 Internet. Therefore, extensibility is provided via an IANA registry 349 for headers fields as defined in Section 7.2. Any fields registered 350 via that process MUST be considered optional. To encourage 351 extensibility and interoperability, implementors MUST ignore any 352 fields they do not explicitly support. 354 5. File Format Description 356 The expected file format of the security.txt file is plain text (MIME 357 type "text/plain") as defined in section 4.1.3 of [RFC2046] and is 358 encoded using UTF-8 [RFC3629] in Net-Unicode form [RFC5198]. 360 The following is an ABNF definition of the security.txt format, using 361 the conventions defined in [RFC5234]. 363 body = *line (contact-field eol) *line 365 line = *1(field / comment) eol 367 eol = *WSP \[CR\] LF 369 field = contact-field / 370 encryption-field / 371 acknowledgments-field / 372 ext-field 374 fs = ":" 376 comment = "#" *(WSP / VCHAR / %xA0-E007F) 378 contact-field = "Contact" fs SP (email / uri / phone) 380 email = 382 phone = "+" *1(DIGIT / "-" / "(" / ")" / SP) 384 uri = 386 encryption-field = "Encryption" fs SP uri 388 signature-field = "Signature" fs SP uri 390 policy-field = "Policy" fs SP uri 392 acknowledgments-field = "Acknowledgments" fs SP uri 394 hiring-field = "Hiring" fs SP uri 396 ext-field = field-name fs SP unstructured 398 field-name = 400 unstructured = 402 "ext-field" refers to extension fields, which are discussed in 403 Section 4.4 405 6. Security considerations 407 Organizations creating security.txt files will need to consider 408 several security-related issues. These include exposure to sensitive 409 information and attacks where limited access to a server could grant 410 the ability to modify the contents of the security.txt file or affect 411 how it is served. Organizations SHOULD also monitor their 412 security.txt files regularly to detect tampering. 414 To ensure the authenticity of the security.txt file, organizations 415 SHOULD sign the file and include the signature using the "Signature:" 416 directive. 418 As stated in Section 3.4 and Section 3.5, both encryption keys and 419 external signature files SHOULD be loaded over HTTPS. 421 Websites MUST reserve the security.txt namespace to ensure no third- 422 party can create a page with the "security.txt" name. 424 7. IANA Considerations 426 example.com is used in this document following the uses indicated in 427 [RFC2606]. 429 192.0.2.0 and 2001:db8:8:4::2 are used in this document following the 430 uses indicated in [RFC6890]. 432 7.1. Well-Known URIs registry 434 The "Well-Known URIs" registry should be updated with the following 435 additional values (using the template from [RFC5785]): 437 URI suffix: security.txt 439 URI suffix: security.txt.sig 441 Change controller: IETF 443 Specification document(s): this document 445 7.2. Registry for security.txt Header Fields 447 IANA is requested to create the "security.txt Header Fields" registry 448 in accordance with [RFC8126]. This registry will contain header 449 fields for use in security.txt files, defined by this specification. 451 New registrations or updates MUST be published in accordance with the 452 "Specification Required" guidelines as described in section 4.6 of 453 [RFC8126]. Any new field thus registered is considered optional by 454 this specification unless a new version of this specification is 455 published. 457 New registrations and updates MUST contain the following information: 459 1. Name of the field being registered or updated 461 2. Short description of the field 463 3. Whether the field can appear more than once 465 4. The document in which the specification of the field is published 467 5. New or updated status, which MUST be one of: current: The field 468 is in current use deprecated: The field is in current use, but 469 its use is discouraged historic: The field is no longer in 470 current use 472 An update may make a notation on an existing registration indicating 473 that a registered field is historical or deprecated if appropriate. 475 The initial registry contains these values: 477 Field Name: Acknowledgment 478 Description: link to page where security researchers are recognized 479 Multiple Appearances: Yes 480 Published in: this document 481 Status: current 483 Field Name: Contact 484 Description: contact information to use for reporting security issues 485 Multiple Appearances: Yes 486 Published in: this document 487 Status: current 489 Field Name: Encryption 490 Description: link to a key to be used for encrypted communication 491 Multiple Appearances: Yes 492 Published in: this document 493 Status: current 495 Field Name: Signature 496 Description: signature used to verify the authenticity of the file 497 Multiple Appearances: No 498 Published in: this document 499 Status: current 501 Field Name: Policy 502 Description: link to security policy page 503 Multiple Appearances: No 504 Published in: this document 505 Status: current 507 8. Contributors 509 The editors would like to acknowledge the help provided during the 510 development of this document by Tom Hudson, Joel Margolis, Jobert 511 Abma, Gerben Janssen van Doorn, Austin Heap, Justin Calmus, and Casey 512 Ellis. 514 9. References 516 9.1. Normative References 518 [RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext 519 Transfer Protocol -- HTTP/1.0", RFC 1945, 520 DOI 10.17487/RFC1945, May 1996, . 523 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 524 Extensions (MIME) Part Two: Media Types", RFC 2046, 525 DOI 10.17487/RFC2046, November 1996, . 528 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 529 Requirement Levels", BCP 14, RFC 2119, 530 DOI 10.17487/RFC2119, March 1997, . 533 [RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and 534 Functions", RFC 2142, DOI 10.17487/RFC2142, May 1997, 535 . 537 [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS 538 Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999, 539 . 541 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 542 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 543 2003, . 545 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 546 Resource Identifier (URI): Generic Syntax", STD 66, 547 RFC 3986, DOI 10.17487/RFC3986, January 2005, 548 . 550 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 551 Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, 552 . 554 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 555 Specifications: ABNF", STD 68, RFC 5234, 556 DOI 10.17487/RFC5234, January 2008, . 559 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 560 DOI 10.17487/RFC5322, October 2008, . 563 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 564 Uniform Resource Identifiers (URIs)", RFC 5785, 565 DOI 10.17487/RFC5785, April 2010, . 568 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 569 "Special-Purpose IP Address Registries", BCP 153, 570 RFC 6890, DOI 10.17487/RFC6890, April 2013, 571 . 573 [RFC7553] Faltstrom, P. and O. Kolkman, "The Uniform Resource 574 Identifier (URI) DNS Resource Record", RFC 7553, 575 DOI 10.17487/RFC7553, June 2015, . 578 [RFC7929] Wouters, P., "DNS-Based Authentication of Named Entities 579 (DANE) Bindings for OpenPGP", RFC 7929, 580 DOI 10.17487/RFC7929, August 2016, . 583 9.2. Informative References 585 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 586 Writing an IANA Considerations Section in RFCs", BCP 26, 587 RFC 8126, DOI 10.17487/RFC8126, June 2017, 588 . 590 Appendix A. Note to Readers 592 *Note to the RFC Editor:* Please remove this section prior to 593 publication. 595 Development of this draft takes place on Github at 596 https://github.com/securitytxt/security-txt 598 Appendix B. Document History 600 *Note to the RFC Editor:* Please remove this section prior to 601 publication. 603 B.1. Since draft-foudil-securitytxt-00 605 o Moved to use IETF's markdown tools for draft updates 607 o Added table of contents and a fuller list of references 609 o Moved file to .well-known URI and added IANA registration (#3) 611 o Added extensibility with an IANA registry for fields (#34) 613 o Added text explaining relationship to RFC 2142 / security@ email 614 address (#25) 616 o Scope expanded to include internal hosts, domains, IP addresses 617 and file systems 619 o Support for digital signatures added (#19) 621 The full list of changes can be viewed via the IETF document tracker: 622 https://tools.ietf.org/html/draft-foudil-securitytxt-01 624 B.2. Since draft-foudil-securitytxt-01 626 o Added appendix with pointer to Github and document history 628 o Added external signature file to the well known URI registry (#59) 630 o Added policy field (#53) 632 o Added diagram explaining the location of the file on public vs. 633 internal systems 635 o Added recommendation that external signature files should use 636 HTTPS (#55) 638 o Added recommendation that organizations should monitor their 639 security.txt files (#14) 641 The full list of changes can be viewed via the IETF document tracker: 642 https://tools.ietf.org/html/draft-foudil-securitytxt-02 644 B.3. Since draft-foudil-securitytxt-02 646 o Use "mailto" and "tel" (#62) 648 o Fix typo in the "Example" section (#64) 650 o Clarified that the root directory is a fall back option (#72) 652 o Defined content-type for the response (#68) 654 o Clarify the scope of the security.txt file (#69) 656 o Cleaning up text based on the NITS tools suggestions (#82) 658 o Added clarification for newline values 660 o Clarified the encryption field language, added examples of DNS- 661 stored encryption keys (#28 and #94) 663 Full list of changes can be viewed via the IETF document tracker: 664 https://tools.ietf.org/html/draft-foudil-securitytxt-03 666 Authors' Addresses 668 Edwin Foudil 670 Email: contact@edoverflow.com 672 Yakov Shafranovich 673 Nightwatch Cybersecurity 675 Email: yakov+ietf@nightwatchcybersecurity.com