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