idnits 2.17.1 draft-hallambaker-mesh-app-00.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 18, 2017) is 2405 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 856 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hallam-Baker 3 Internet-Draft Comodo Group Inc. 4 Intended status: Informational September 18, 2017 5 Expires: March 22, 2018 7 Mathematical Mesh: Application Profiles 8 draft-hallambaker-mesh-app-00 10 Abstract 12 The use of the Mathematical Mesh to manage cryptographic keys for use 13 with Mail and SSH is described. The format of the application 14 profiles is described with examples. 16 This document is also available online at 17 http://prismproof.org/Documents/draft-hallambaker-mesh-app.html [1] . 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on March 22, 2018. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 2.2. Related Specifications . . . . . . . . . . . . . . . . . 3 57 2.3. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 3 58 2.4. Implementation Status . . . . . . . . . . . . . . . . . . 3 59 3. Mesh Application Profiles . . . . . . . . . . . . . . . . . . 4 60 4. Catalog Profiles . . . . . . . . . . . . . . . . . . . . . . 4 61 4.1. Catalog Example . . . . . . . . . . . . . . . . . . . . . 4 62 4.2. Credentials . . . . . . . . . . . . . . . . . . . . . . . 5 63 4.2.1. Credentials Example . . . . . . . . . . . . . . . . . 6 64 4.3. Bookmarks . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4.4. Contacts . . . . . . . . . . . . . . . . . . . . . . . . 7 66 4.4.1. Contacts Example . . . . . . . . . . . . . . . . . . 7 67 4.5. Calendar . . . . . . . . . . . . . . . . . . . . . . . . 7 68 5. Mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 5.1. Mail Example . . . . . . . . . . . . . . . . . . . . . . 9 70 6. SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 6.1. SSH Example . . . . . . . . . . . . . . . . . . . . . . . 10 72 7. Catalog Application Profiles . . . . . . . . . . . . . . . . 10 73 7.1. Shared . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 7.1.1. Structure: ApplicationProfileCatalog . . . . . . . . 10 75 7.1.2. Structure: CatalogEntry . . . . . . . . . . . . . . . 10 76 7.1.3. Structure: TypedData . . . . . . . . . . . . . . . . 11 77 7.2. Credential Catalog . . . . . . . . . . . . . . . . . . . 11 78 7.2.1. Structure: CredentialProfile . . . . . . . . . . . . 11 79 7.2.2. Structure: CredentialProfilePrivate . . . . . . . . . 11 80 7.2.3. Structure: CredentialEntry . . . . . . . . . . . . . 11 81 7.3. Bookmark Catalog . . . . . . . . . . . . . . . . . . . . 12 82 7.3.1. Structure: BookmarkProfile . . . . . . . . . . . . . 12 83 7.3.2. Structure: BookmarkProfilePrivate . . . . . . . . . . 12 84 7.3.3. Structure: BookmarkEntry . . . . . . . . . . . . . . 12 85 7.4. Contact Catalog . . . . . . . . . . . . . . . . . . . . . 12 86 7.4.1. Structure: ContactProfile . . . . . . . . . . . . . . 12 87 7.4.2. Structure: ContactProfilePrivate . . . . . . . . . . 13 88 7.4.3. Structure: ContactEntry . . . . . . . . . . . . . . . 13 89 7.4.4. Structure: PersonalName . . . . . . . . . . . . . . . 13 90 7.4.5. Structure: Address . . . . . . . . . . . . . . . . . 13 91 7.4.6. Structure: Internet . . . . . . . . . . . . . . . . . 14 92 7.4.7. Structure: Postal . . . . . . . . . . . . . . . . . . 14 93 7.4.8. Structure: ContactPerson . . . . . . . . . . . . . . 14 94 7.4.9. Structure: ContactOrganization . . . . . . . . . . . 14 95 7.5. Mail Application Profile Objects . . . . . . . . . . . . 15 96 7.5.1. Structure: MailProfile . . . . . . . . . . . . . . . 15 97 7.5.2. Structure: MailDevicePublic . . . . . . . . . . . . . 15 98 7.5.3. Structure: MailProfilePrivate . . . . . . . . . . . . 15 99 7.5.4. Structure: MailDevicePrivate . . . . . . . . . . . . 16 100 7.6. SSH Application Profile Objects . . . . . . . . . . . . . 16 101 7.6.1. Structure: SSHProfile . . . . . . . . . . . . . . . . 16 102 7.6.2. Structure: SSHDevicePublic . . . . . . . . . . . . . 17 103 7.6.3. Structure: SSHProfilePrivate . . . . . . . . . . . . 17 104 7.6.4. Structure: HostEntry . . . . . . . . . . . . . . . . 17 105 7.6.5. Structure: SSHDevicePrivate . . . . . . . . . . . . . 17 106 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 107 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 108 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 109 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 110 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 111 11.2. Informative References . . . . . . . . . . . . . . . . . 18 112 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 19 113 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 115 1. Introduction 117 2. Definitions 119 This section presents the related specifications and standard, the 120 terms that are used as terms of art within the documents and the 121 terms used as requirements language. 123 2.1. Requirements Language 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in [RFC2119] . 129 2.2. Related Specifications 131 The related specifications are described in the Mesh Architecture 132 specification [draft-hallambaker-mesh-architecture] 134 2.3. Defined Terms 136 No terms of art are defined. 138 2.4. Implementation Status 140 The implementation status of the reference code base is described in 141 the companion document [draft-hallambaker-mesh-developer] . 143 3. Mesh Application Profiles 145 (Pull piece from Mesh Reference to here) 147 4. Catalog Profiles 149 Catalog profiles are used to synchronize encrypted data sets across 150 devices. The catalog data model is restricted so as to permit a 151 common set of management tools to be used to access and maintain 152 profiles containing different types of data (bookmarks, credentials, 153 contacts, etc.). Catalogs do not contain per device data. A catalog 154 may not be shared with every device in the user?s profile but all the 155 data in a catalog is available to all the devices with which it is 156 shared. 158 The management operations supported are: 160 Synchronization Permit user to add, delete and update entries from 161 multiple devices with minimal surprise. The mechanism is designed 162 to be reasonably robust if network connectivity is lost during an 163 attempted update. 165 Labelling Allow entries to be grouped into hierarchical categories 166 defined by the user. An entry may be added to more than one 167 category at once. 169 Each catalog entry SHOULD contain exactly one timestamp field of time 170 Added, Updated or Deleted. If present, the timestamp entries and the 171 entry identifiers are used to merge catalog profiles that have been 172 updated separately leading to an inconsistent state. 174 Applications SHOULD specify a timestamp field on every entry unless 175 it is known that update inconsistency cannot occur. For example, 176 when initially populating a catalog. 178 4.1. Catalog Example 180 Alice creates a new bookmarks profile which is shared between her 181 laptop and her phone. The initial profile is empty: 183 { 184 "BookmarkProfilePrivate": { 185 "Entries": []}} 187 Figure 1 189 Alice adds a bookmark entry to her profile on the browser on her 190 laptop: 192 { 193 "BookmarkProfilePrivate": { 194 "Entries": [{ 195 "Added": "2017-09-18T13:01:28Z", 196 "Title": "First Site", 197 "Uri": "http://example.com/"}]}} 199 Figure 2 201 Later, Alice is attempting to connect to a site on her phone but has 202 no network connection. She decides to bookmark the site instead. 204 { 205 "BookmarkProfilePrivate": { 206 "Entries": [{ 207 "Added": "2017-09-18T14:36:06Z", 208 "Title": "Second Site", 209 "Uri": "https://example.com/"}]}} 211 Figure 3 213 At this point, the profiles on Alice's two devices are out of sync. 214 When the phone is finally able to connect to the network, the 215 profiles are merged: 217 { 218 "BookmarkProfilePrivate": { 219 "Entries": [{ 220 "Added": "2017-09-18T13:01:28Z", 221 "Title": "First Site", 222 "Uri": "http://example.com/"}, 223 { 224 "Added": "2017-09-18T14:36:06Z", 225 "Title": "Second Site", 226 "Uri": "https://example.com/"}]}} 228 Figure 4 230 4.2. Credentials 232 A credentials catalog contains access credentials, typically 233 usernames and passwords, for a set of network resources such as Web 234 sites that do not support the use of Mesh device profile data for 235 authentication. 237 Mesh/Credential enabled applications SHOULD offer to generate strong 238 passwords for the user if the AutoGenerate field is set to true in 239 the credential profile. Since the use of automatically generated 240 passwords is likely to be inconvenient for users unless all the 241 applications on all the devices they might use support Mesh/ 242 Credential profiles, applications MUST NOT automatically generate 243 passwords unless the user has affirmatively indicated that they want 244 to use them. 246 Further Work: Credential entries MAY specify that the credential is 247 restricted to use with certain protocols (Web browsing, SFTP, etc.) 248 and/or certain authentication mechanisms but the precise means of 249 identifying both is not currently defined. 251 4.2.1. Credentials Example 253 { 254 "CredentialProfilePrivate": { 255 "AutoGenerate": true, 256 "Entries": [{ 257 "Sites": ["luggage.example.net"], 258 "Username": "Alice", 259 "Password": "12345"}, 260 { 261 "Label": ["Linux"], 262 "Sites": ["host.example.net"], 263 "Username": "BitAlice", 264 "Password": "password", 265 "Protocol": "ssh"}], 266 "NeverAsk": ["secure.example.com", 267 "bank.example.com"]}} 269 Figure 5 271 4.3. Bookmarks 273 A bookmarks catalog contains a collection of bookmarks that have been 274 saved for later use. While the ability share bookmarks between 275 groups of users has obvious advantages, at present, the 276 implementation and specification are only written with the use of a 277 single user have been considered. 279 A bookmark entry contains the URI of the target and a title. If the 280 book mark entry is a HTML resource, the title is taken from the 281 element in the document header. If network and storage 282 resources permit, catalog entries MAY include a favicon value for 283 easy identification. 285 Further Work: Bookmark entries MAY contain details describing the 286 security properties of the connection to protect against downgrade 287 attack. For example, information from HTTP strict security [RFC6797] 288 and key pinning headers [RFC7460] . 290 tbs 292 4.4. Contacts 294 A contacts catalog contains a collection of contacts. The 295 ContactEntry object contains the usual fields for describing the 296 person or organization the entry refers to, and means of contact 297 (Internet, Postal). 299 One significant deviation from existing formats is that the fact that 300 people change names (e.g. marriage) is captured and that means of 301 contact MAY be scoped to a particular organization. 303 4.4.1. Contacts Example 305 { 306 "ContactProfilePrivate": { 307 "Entries": [{ 308 "Personals": [{ 309 "First": "Alice"}], 310 "Internets": [{ 311 "Uri": "mailto:alice@example.com"}]}, 312 { 313 "Personals": [{ 314 "First": "Bob"}], 315 "Internets": [{ 316 "Uri": "mailto:bob@example.com"}]}]}} 318 Figure 6 320 4.5. Calendar 322 It is generally acknowledged that representation of calendar 323 information is a ?difficult? problem. Since it is the author?s 324 experience that such problems almost invariably arise from an attempt 325 to make use of an inadequate data model, the format for exchange of 326 calendar information is currently undefined. 328 Further Work: Two major causes of difficulty are the use of local 329 time zones and daylight savings, the definition of which are 330 capricious at best. When a recurring meeting is specified it is 331 vital that the time zone in which the meeting is to recur is 332 specified explicitly. Attempts to normalize meetings to a single 333 time zone will inevitably fail when the definition of time changes 334 between the time the meeting is called and the meeting is held. 336 Another major limitation in existing formats is the lack of 337 understanding that when the user travels, at least some part of their 338 context for scheduling also changes. It should be possible to 339 integrate all parts of the user?s schedule to offer alerts and 340 reminders appropriate to their current location. 342 5. Mail 344 Mesh Mail profiles serve two distinct purposes: 346 o To provision a user?s devices with the credentials, network 347 configuration and cryptographic keys necessary to support use of 348 mail and end-to-end mail security enhancements. 350 o To publish necessary information for use by mail senders. 352 o While the principle focus of Mesh/Mail is to support exchange of 353 mail over SMTP protocol, any infrastructure that provides a 354 mechanism for publishing a recipient?s public keys for use by 355 senders can, at least in principle, also publish information 356 describing the user?s mail capabilities including the ability to 357 support new messaging protocols. 359 o The use of end-to-end secure protocols requires the generation and 360 use of at least one public key pair for signature and encryption. 361 Best current practices require the use of separate keypairs for 362 signature and encryption and if practical separate signature keys 363 for each device. 365 o Since S/MIME and OpenPGP as currently specified do not support the 366 use of Proxy Re-Encryption (recryption) to enable separate the use 367 of separate decryption keys for each device, a single encryption 368 keypair is used. A mail profile must therefore contain an 369 encrypted copy of the corresponding decryption key for each 370 device. 372 o Further Work: Support Signal etc. At present the profiles are not 373 differentiated on a per device level. It is likely that it would 374 be useful to specify that certain devices are to carry a complete 375 copy of the user?s mail while others should only carry messages 376 from the last few weeks or months. It is also likely that it 377 would be useful to be able to mark certain selections as being 378 likely to be most useful offline. 380 5.1. Mail Example 382 6. SSH 384 The Secure Shell (SSH) transport layer protocol [RFC4253] is widely 385 used as a mechanism for securing access to remote hosts. In addition 386 to providing a terminal connection to a remote host, SSH also 387 supports file transfer and remote access (VPN) functionality. It is 388 also used to provide remote procedure call (RPC) capabilities in 389 applications such as Git. 391 While SSH permits a high level of security to be achieved, achieving 392 a high security configuration requires a considerable degree of 393 attention to detail. Numerous ?how to? guides found on the Internet 394 advise the user to engage in many unsafe practices. These include: 396 Using a single private key for authentication for every machine to be 397 used as a client. 399 Emailing a copy of the authentication key to yourself to transfer it 400 to a new machine. (Alternatively use of insecure FTP, copying the 401 data to /temp, etc.) 403 Of equal concern was the fact that none of the guides mentioned any 404 form of maintenance activity such as deleting authentication keys for 405 a decommissioned device or performing a rekey operation in the case 406 that a device is compromised. 408 Configuring SSH securely is a non-trivial task because SSH is the 409 tool through which the administrator will be connecting to secure 410 their system. This is a bootstrap problem: It is easy to solve the 411 problem of SSH configuration once we have SSH configured for use. To 412 enable SSH access to a machine without creating an insecure path 413 first is not a trivial matter. 415 A Mesh/SSH profile contains three sets of information: 417 o A set of the user?s public authentication keys. This is used to 418 generate auth_hosts files and equivalents to enable the user to 419 access machines. 421 o A set of hosts known to the user. This is encrypted as it shows 422 the machines that the user at least is likely to visit. This is 423 used to generate known_hosts files and equivalents to enable the 424 user to authenticate hosts. 426 o A set of device key entries. The entry for each host is 427 encrypted. This is used to create the private key file(s) for the 428 user on each of their devices. 430 6.1. SSH Example 432 7. Catalog Application Profiles 434 Catalogues are application profiles that consist of a set of related 435 information (contacts, passwords, bookmarks) but do not contain any 436 cryptographic private keys or device specific data. These 437 restrictions allow management of these profiles to be simplified. 439 7.1. Shared 441 The following objects are common to multiple profiles. 443 7.1.1. Structure: ApplicationProfileCatalog 445 Inherits: ApplicationProfile 447 Base class for all application profiles that are tied to an account 448 profile 450 AccountIdentifier: String (Optional) The account to which this 451 profile is bound 453 PersonalUDF: String (Optional) The person to which this profile is 454 bound 456 7.1.2. Structure: CatalogEntry 458 ID: String (Optional) Unique identifier for the entry. If present, 459 overrides the identifier specified in the entry. 461 Added: DateTime (Optional) The time the site was added 463 Updated: DateTime (Optional) The last time the entry was updated 465 Deleted: DateTime (Optional) The last time the entry was updated 467 Label: String [0..Many] Labels identifying the group(s) that the 468 entry is filed under 470 Source: TypedData [0..Many] Source data for the entry 472 7.1.3. Structure: TypedData 474 ContentType: String (Optional) IANA Content Type identifier 476 Data: Binary (Optional) The described data 478 7.2. Credential Catalog 480 Profile for recording access credentials for Web sites and other 481 projects. Currently this is limited to usernames and passwords but 482 could expand to include other credential forms. 484 7.2.1. Structure: CredentialProfile 486 Inherits: ApplicationProfileCatalog 488 Stores usernames and passwords. There are no public fields. 490 [No fields] 492 7.2.2. Structure: CredentialProfilePrivate 494 Inherits: ApplicationProfilePrivate 496 Private part of the profile. 498 AutoGenerate: Boolean (Optional) If true, a client MAY offer to 499 automatically generate strong (i.e. not memorable) passwords for a 500 user. A user would not normally want to use this feature unless 501 they have access to Mesh password management on every device they 502 use to browse the Web 504 Entries: CredentialEntry [0..Many] A list of password credential 505 entries. 507 NeverAsk: String [0..Many] A list of domain names of sites for which 508 clients MUST NOT ask to store passwords for. 510 7.2.3. Structure: CredentialEntry 512 Inherits: CatalogEntry 514 Username password entry for a single site 516 Sites: String [0..Many] DNS name of site *.example.com matches 517 www.example.com etc. 519 Username: String (Optional) Case sensitive username 520 Password: String (Optional) Case sensitive password. 522 Protocol: String (Optional) Protocol identifier, e.g. http, sftp, 523 ssh, etc. 525 7.3. Bookmark Catalog 527 Profile for recording Web site bookmarks and related information. 529 7.3.1. Structure: BookmarkProfile 531 Inherits: ApplicationProfileCatalog 533 Stores Web site bookmarks in a hierarchical 535 [No fields] 537 7.3.2. Structure: BookmarkProfilePrivate 539 Inherits: ApplicationProfilePrivate 541 Private part of the profile. 543 Entries: BookmarkEntry [0..Many] The bookmark entries 545 7.3.3. Structure: BookmarkEntry 547 Inherits: CatalogEntry 549 Bookmark entry for a single site 551 Title: String (Optional) The resource name 553 Uri: String (Optional) The resource identifier 555 ImageUDF: String [0..Many] UDF fingerprint of related favicon image 557 7.4. Contact Catalog 559 Profile for recording user contact information 561 7.4.1. Structure: ContactProfile 563 Inherits: ApplicationProfileCatalog 565 Stores Web site bookmarks in a hierarchical 567 [No fields] 569 7.4.2. Structure: ContactProfilePrivate 571 Inherits: ApplicationProfilePrivate 573 Private part of the profile. 575 Entries: ContactEntry [0..Many] The contact entries 577 7.4.3. Structure: ContactEntry 579 Inherits: CatalogEntry 581 Contact entry 583 Personals: PersonalName [0..Many] 585 Personals: PersonalName [0..Many] 587 MeshUDFs: String [0..Many] List of mesh profiles fingerprints for 588 the user. 590 Internets: Internet [0..Many] List of Internet, telephone, etc 591 addresses for contacting this party 593 Postals: Postal [0..Many] List of postal addresses for this party 595 7.4.4. Structure: PersonalName 597 First: String (Optional) 599 First: String (Optional) 601 Last: String (Optional) 603 Last: String (Optional) 605 Midle: String (Optional) 607 7.4.5. Structure: Address 609 Label: String [0..Many] Labels identifying the modes in which the 610 label may be used e.g. Home, Business, Mobile 612 Attributes: String [0..Many] Attributes describing the mode in which 613 the contact address may be used. 615 7.4.6. Structure: Internet 617 Inherits: Address 619 Inherits: Address 621 Uri: String (Optional) The resource identifier describing the mode 622 of contact 624 7.4.7. Structure: Postal 626 Inherits: Address 628 Inherits: Address 630 Adressee: String (Optional) The postal name 632 Street: String (Optional) Street name and number 634 Town: String (Optional) Name of town or city 636 Region: String (Optional) State, county, department or other 637 government unit. 639 Country: String (Optional) The country name 641 Code: String (Optional) The ISO 3 letter country code 643 7.4.8. Structure: ContactPerson 645 Inherits: ContactEntry 647 Contact entry for a single person 649 FullName: String (Optional) The name of the person 651 Organization: String [0..Many] The name of the organizations the 652 person is associated with 654 7.4.9. Structure: ContactOrganization 656 Inherits: ContactEntry 658 Contact entry for a single organization 660 FullName: String (Optional) The name of the organization 662 7.5. Mail Application Profile Objects 664 Profiles that describe mail user agent configuration 666 7.5.1. Structure: MailProfile 668 Inherits: ApplicationProfile 670 Public profile describes mail receipt policy. Private describes 671 Sending policy 673 EncryptionPGP: PublicKey (Optional) The current OpenPGP encryption 674 key 676 EncryptionSMIME: PublicKey (Optional) The current S/MIME encryption 677 key 679 7.5.2. Structure: MailDevicePublic 681 Contains public device description 683 Inherits: ApplicationDevicePublic 685 [No fields] 687 7.5.3. Structure: MailProfilePrivate 689 Inherits: ApplicationProfilePrivate 691 Describes a mail account configuration 693 Private profile contains connection settings for the inbound and 694 outbound mail server(s) and cryptographic private keys. Public 695 profile may contain security policy information for the sender. 697 EmailAddress: String (Optional) The RFC822 Email address. [e.g. 698 "alice@example.com"] 700 ReplyToAddress: String (Optional) The RFC822 Reply toEmail address. 701 [e.g. "alice@example.com"] 703 When set, allows a sender to tell the receiver that replies to 704 this account should be directed to this address. 706 DisplayName: String (Optional) The Display Name. [e.g. "Alice 707 Example"] 709 AccountName: String (Optional) The Account Name for display to the 710 app user [e.g. "Work Account"] 712 Inbound: Connection [0..Many] The Inbound Mail Connection(s). This 713 is typically IMAP4 or POP3 715 If multiple connections are specified, the order in the sequence 716 indicates the preference order. 718 Outbound: Connection [0..Many] The Outbound Mail Connection(s). 719 This is typically SMTP/SUBMIT 721 If multiple connections are specified, the order in the sequence 722 indicates the preference order. 724 Sign: PublicKey [0..Many] The public keypair(s) for signing and 725 decrypting email. 727 If multiple public keys are specified, the order indicates 728 preference. 730 Encrypt: PublicKey [0..Many] The public keypairs for encrypting and 731 decrypting email. 733 If multiple public keys are specified, the order indicates 734 preference. 736 7.5.4. Structure: MailDevicePrivate 738 Private data specific to the device 740 Inherits: ApplicationDevicePrivate 742 [No fields] 744 7.6. SSH Application Profile Objects 746 Profiles that describe SSH user agent configuration 748 7.6.1. Structure: SSHProfile 750 Application profile for SSH. This is an initial cut of the profile 751 and will need revision. In particular, a sysadmin with a very large 752 number of hosts they are accessing will need some means of avoiding 753 combinatorial explosion. 755 Inherits: ApplicationProfile 757 [No fields] 759 7.6.2. Structure: SSHDevicePublic 761 Contains public device description 763 Inherits: ApplicationDevicePublic 765 Inherits: ApplicationDevicePublic 767 PublicKey: PublicKey (Optional) Public authentication key for a 768 device. 770 7.6.3. Structure: SSHProfilePrivate 772 Private portion or profile. 774 Inherits: ApplicationProfilePrivate 776 Inherits: ApplicationProfilePrivate 778 Account: String (Optional) The account to which the profile is bound 780 HostEntries: HostEntry [0..Many] Hosts bound to the profile 782 7.6.4. Structure: HostEntry 784 Describe a host connected to the SSH profile. This is a machine that 785 the user will access using the credential. 787 Inherits: Entry 789 Inherits: Entry 791 Address: String (Optional) The DNS address or IP address of the host 793 AlgorithmID: String (Optional) The SSH Algorithm identifier 795 PublicKey: String (Optional) The Base64 encoded public key 797 7.6.5. Structure: SSHDevicePrivate 799 Private data specific to the device 801 Inherits: ApplicationDevicePrivate 803 Inherits: ApplicationDevicePrivate 804 DevicePrivateKey: PublicKey (Optional) A private keypair or keypair 805 contribution created for exclusive use of this device. 807 KeyUDF: String (Optional) Fingerprint of device that this key 808 corresponds to. 810 8. Acknowledgements 812 Your name could appear here. 814 9. Security Considerations 816 [This is just a sketch for the present.] 818 10. IANA Considerations 820 [TBS list out all the code points that require an IANA registration] 822 11. References 824 11.1. Normative References 826 [draft-hallambaker-mesh-architecture] 827 Hallam-Baker, P., "Mathematical Mesh: Architecture", 828 draft-hallambaker-mesh-architecture-03 (work in progress), 829 May 2017. 831 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 832 Requirement Levels", BCP 14, RFC 2119, 833 DOI 10.17487/RFC2119, March 1997. 835 [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 836 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 837 January 2006. 839 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 840 Transport Security (HSTS)", RFC 6797, 841 DOI 10.17487/RFC6797, November 2012. 843 [RFC7460] Chandramouli, M., Claise, B., Schoening, B., Quittek, J., 844 and T. Dietz, "Monitoring and Control MIB for Power and 845 Energy", RFC 7460, DOI 10.17487/RFC7460, March 2015. 847 11.2. Informative References 849 [draft-hallambaker-mesh-developer] 850 Hallam-Baker, P., "Mathematical Mesh: Reference 851 Implementation", draft-hallambaker-mesh-developer-04 (work 852 in progress), September 2017. 854 11.3. URIs 856 [1] http://prismproof.org/Documents/draft-hallambaker-mesh-app.html 858 Author's Address 860 Phillip Hallam-Baker 861 Comodo Group Inc. 863 Email: philliph@comodo.com