From nobody Sun Jun 3 20:39:53 2018 Return-Path: X-Original-To: suit@ietf.org Delivered-To: suit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 939A41200A0; Sun, 3 Jun 2018 20:39:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: suit@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152808358455.20892.2040053845976676560@ietfa.amsl.com> Date: Sun, 03 Jun 2018 20:39:44 -0700 Archived-At: Subject: [Suit] I-D Action: draft-ietf-suit-architecture-00.txt X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.22 List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2018 03:39:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Software Updates for Internet of Things WG of the IETF. Title : A Firmware Update Architecture for Internet of Things Devices Authors : Brendan Moran Milosch Meriac Hannes Tschofenig Filename : draft-ietf-suit-architecture-00.txt Pages : 18 Date : 2018-06-03 Abstract: Vulnerabilities with Internet of Things (IoT) devices have raised the need for a solid and secure firmware update mechanism that is also suitable for constrained devices. Incorporating such update mechanism to fix vulnerabilities, to update configuration settings as well as adding new functionality is recommended by security experts. This document lists requirements and describes an architecture for a firmware update mechanism suitable for IoT devices. The architecture is agnostic to the transport of the firmware images and associated meta-data. This version of the document assumes asymmetric cryptography and a public key infrastructure. Future versions may also describe a symmetric key approach for very constrained devices. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-suit-architecture/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-suit-architecture-00 https://datatracker.ietf.org/doc/html/draft-ietf-suit-architecture-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 4 04:10:35 2018 Return-Path: X-Original-To: suit@ietf.org Delivered-To: suit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB60C12D93F; Mon, 4 Jun 2018 04:10:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: suit@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152811062665.20908.9231697583091629075@ietfa.amsl.com> Date: Mon, 04 Jun 2018 04:10:26 -0700 Archived-At: Subject: [Suit] I-D Action: draft-ietf-suit-information-model-00.txt X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.22 List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2018 11:10:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Software Updates for Internet of Things WG of the IETF. Title : Firmware Updates for Internet of Things Devices - An Information Model for Manifests Authors : Brendan Moran Hannes Tschofenig Henk Birkholz Jaime Jimenez Filename : draft-ietf-suit-information-model-00.txt Pages : 19 Date : 2018-06-03 Abstract: Vulnerabilities with Internet of Things (IoT) devices have raised the need for a solid and secure firmware update mechanism that is also suitable for constrained devices. Incorporating such update mechanism to fix vulnerabilities, to update configuration settings as well as adding new functionality is recommended by security experts. One component of such a firmware update is the meta-data, or manifest, that describes the firmware image(s) and offers appropriate protection. This document describes all the information that must be present in the manifest. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-suit-information-model/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-suit-information-model-00 https://datatracker.ietf.org/doc/html/draft-ietf-suit-information-model-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 4 08:08:28 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 675C912DA05 for ; Mon, 4 Jun 2018 08:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nordicsemi.no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5zT0qSSneWh for ; Mon, 4 Jun 2018 08:08:20 -0700 (PDT) Received: from ironport02.nordicsemi.no (mx02.nordicsemi.no [194.19.86.151]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C625127077 for ; Mon, 4 Jun 2018 08:08:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nordicsemi.no; l=94786; s=default; t=1528124899; h=from:to:cc:subject:date:message-id:mime-version; bh=LtO8IX7szbKPDkNUtMqZ8tWA6fIalNWMra8wOCbA6II=; b=saLaipq/D/cgUv8B7yxwmd/esK+4kYpmyOOWaLWtmrZWch5eneFzvxaW 2UVUmART73Covg4E1NlaMu5Tw9aPctv4qKXjkO3B+t2UKcw9ERpMUlVJn csAle96XcmvosgKBlzYQyQp0EvGvWV8h/tptCrnHZGBLwBes+G0xMA3/O g=; X-IronPort-AV: E=Sophos;i="5.49,476,1520895600"; d="scan'208,217";a="4406402" From: =?iso-8859-1?Q?R=F8nningstad=2C_=D8yvind?= To: "suit@ietf.org" CC: =?iso-8859-1?Q?Kvamtr=F8=2C_Frank_Audun?= Thread-Topic: [Suit] Internal handover of updates inside a device Thread-Index: AdP8E1VsGXiTFQGrQLiSywEWFhbbYg== Date: Mon, 4 Jun 2018 15:08:17 +0000 Message-ID: <992b7f82695c449f8cf485c97b57d7cb@nordicsemi.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.9.200.83] Content-Type: multipart/alternative; boundary="_000_992b7f82695c449f8cf485c97b57d7cbnordicsemino_" MIME-Version: 1.0 Archived-At: Subject: [Suit] Internal handover of updates inside a device X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2018 15:08:27 -0000 --_000_992b7f82695c449f8cf485c97b57d7cbnordicsemino_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We have been exploring how updates would be passed between implementations = ("parties") inside a system, and how the manifest format can help with that= . Below is a manifest format together with a short description of the updat= e procedure and some restrictions on the format not captured by the CDDL. At the bottom are a number of user stories as well as how the format and re= strictions fulfil the user stories. Highlights: * We propose moving metadata about the preprocessing of payloads and ma= nifests out of the parent manifest. This is to facilitate handing responsib= ilities between parties, and it has the added benefits of making the format= simpler, and not tying it to COSE. * After thinking quite a bit about it, we think we found a satisfactory= way to support multiple payloads. Each payload will have its own timestamp= and set of conditions to be met before they can be installed. * Aliases has been promoted to resourceLocations, which holds all URIs.= Dependencies and payloads contain only the hash, used to look up the URI i= n the list. This simplifies the incorporation of aliases. * Conditions have been divided into PreConditions (all of which are che= cked at the very beginning) and PostConditions (all of which are checked at= the very end), because the start and finish of the update are well-defined= points in time, that are critical for the robustness of the update. Thanks for the great work on the documents, we tried to adapt, but also wan= ted to send this in time for the hackathon. Do you plan to release a serial= ization format as well, or to keep it out of scope? Anyway, hopefully this = is helpful. Unfortunately we cannot participate in the hackathon in person, but we will= try to join online as much as possible. Best regards, =D8yvind and Frank Manifest format (CDDL) [alt5] TimeStamp =3D uint .size 8 Uuid =3D bstr .size 16 StorageIdentifier =3D bstr ComponentIdentifier =3D bstr UriList =3D { + int =3D> tstr } UriList =3D { + int =3D> tstr } DigestInfo =3D [ size: uint, digestAlgorithm: uint, digest: bstr ] IdCondition =3D [vendor: 1 / class: 2 / device: 3, id: = Uuid] TimeCondition =3D [installAfter: 4 / bestBefore: 5, time: = Timestamp] ImageCondition =3D [currentContent: 6 / notCurrentContent: 7, digest: = DigestInfo / nil, location: StorageIdentifier] CustomCondition =3D [nint, parameters: = bstr] PreCondition =3D IdCondition / TimeCondition / ImageCondition / CustomCond= ition PostCondition =3D ImageCondition / CustomCondition ResourceLocation =3D [ resourceLocationVersion: 1, digestInfo: DigestInfo, encoding: bstr, location: UriList ] PayloadInfo =3D [ subject: StorageIdentifier, timestamp: Timestamp, digest: bstr ] ManifestInfo =3D [ component: ComponentIdentifier, digest: bstr ] Manifest =3D [ manifestVersion: 1, resourceLocations: [ * ResourceLocation ], preConditions: [ * PreCondition ], dependencies: [ * ManifestInfo ], payloads: [ * PayloadInfo ], postConditions: [ * PostCondition ], text: { * int =3D> tstr } / nil, extensions: { * int =3D> bstr } / nil ] The update procedure All manifests must be authenticated (signed), e.g. by being wrapped in a CO= SE_Sign or COSE_Mac. The format does not mandate COSE-specific types. A received manifest or payload might be encoded in multiple steps like sign= ature, encryption, compression etc. Signing, encryption, compression and ot= her encodings are implementation-dependent, but when encrypting and/or sign= ing a manifest, it must happen in the following order (any step can be skip= ped) during creation: 1. Compress/diff/other encoding 2. Encrypt 3. Sign which then happen in reverse during parsing: 1. Check signature 2. Decrypt 3. Decompress/patch/other decoding Operations like signing, encryption, compression etc. can be applied to bot= h manifests and payloads. Any encoding (e.g. delta patching) can be support= ed either through ResourceInfo::encoding or through a custom wrapper type (= analogous to the COSE types) for the payload/manifest. It is recommended that the update process involves multiple passes of the m= anifest, e.g.: 1. For each manifest, validate the serialization and check the validity = of StorageIdentifiers and ComponentIdentifiers. Check timestamps and preCon= ditions. This can hopefully be accomplished without writing to flash storag= e. 2. Retrieve payloads and validate them. This does not involve irreversib= le change. 3. Install payloads 4. Check postConditions. I.e. strive to validate as much as possible before any flash writes happen,= and as much as possible before irreversible change happens. If any check fails, or if any procedure cannot be completed, the whole upda= te must be aborted, and changes reverted if possible. Restrictions and Clarifications about the types PreCondition: * preConditions are always checked against the state before the entire = update started. PostCondition: * All postConditions lists included in the update must pass before the = update is complete. * All postConditions lists included in the update are checked against t= he state after all manifests are installed. Manifest * Dependencies must be installed in the order they appear in the depend= encies list. * Payloads must be installed in the order they appear in the payloads l= ist. * All dependencies must be installed before any payloads are installed * A dependency is installed when the referenced Manifest is completely = installed. I.e. the dependency tree is traversed depth-first. * A Manifest is installed when all its payloads are installed. ResourceLocation * If a single list of ResourceLocations contains two entries with the s= ame digestInfo::digest, their entire digestInfo and encoding entries must a= lso be identical. This ensures that digests referred to in PayloadInfo and = ManifestInfo are unambiguous. * The parser can use ResourceLocation::encoding to understand the encod= ing of the referenced manifest or payload. * The format of ResourceLocation::encoding is implementation-dependent. * When a resource is successfully received or retrieved, its digest mus= t be checked. PayloadInfo * The PayloadInfo::digest can be used to look up an entry in the resour= ceLocations list by matching it with ResourceLocation::digestInfo.digest. * The value in PayloadInfo::timestamp must be at least one greater than= the stored timestamp for this StorageIdentifier. This must be checked imme= diately before the payload is installed. * After the PayloadInfo has been installed, the stored timestamp for th= is StorageIdentifier is overwritten with the value in PayloadInfo::timestam= p. This must happen before the next payload's timestamp is checked. StorageIdentifier * The format of StorageIdentifier is implementation-dependent, but must= give enough information to unambiguously point to a certain string of byte= s, including its size, inside the image. Multiple StorageIdentifiers can po= int to the same byte string, or overlapping byte strings, with no restricti= ons. I.e.: * Imagine an update was stored with StorageIdentifier "app/5/1/0/sto= re_metadata". Note that StorageIdentifiers don't have to be text, and don't= have to look like paths. In an ImageCondition, the StorageIdentifier "app"= , "app/5", "app/5/1", "app/5/1/0", or "app/5/1/0/load_metadata" might all r= esolve to the same content received in the update. ANY aliasing scheme is a= llowed. * Updates to different StorageIdentifiers can cause incrementation o= f the same stored timestamp. Any mapping from StorageIdentifier to stored t= imestamp is allowed. IdCondition * A device's vendorID, classID, and deviceID should be static within th= e same ComponentIdentifier. TimeCondition * These conditions require a secure clock providing a current time. * These conditions are unrelated to PayloadInfo::timestamp. * installAfter fails if the current time is less than the required time= . * bestBefore fails if the current time is more than the required time. ImageCondition * The condition refers to the state of the image at the time it is chec= ked. * ImageCondition::digest represents the hash of the expected content. * DigestInfo::size represents the expected length of the content. * If ImageCondition::digest is nil only the existence of the location i= s checked, not the content. * The total size of the byte string pointed to by the StorageIdentifier= must equal the content length reported in the ImageCondition. To check onl= y a part of the byte string content, define a new StorageIdentifier that po= ints to the relevant part. * notCurrentContent is the inverse of currentContent, i.e.: * A notCurrentContent condition will pass for any state currentConte= nt would fail for. * A notCurrentContent condition will fail for any state currentConte= nt would pass for. ComponentIdentifier * The format of ComponentIdentifier is implementation-dependent but is = intended to refer to components that the current party does not have direct= write access to. "party" here means an implementation of the standard. ManifestInfo * The ManifestInfo::digest can be used to look up an entry in the resou= rceLocations list by matching it with ResourceInfo::digestInfo.digest. * If the manifest referred to by the ComponentIdentifier will be instal= led by a different party, the handover will involve some or all of the foll= owing: * The transmitting party transfers the digest and encoding from the = relevant ManifestInfo, together with an instruction such as "Validate", "In= stall", or "Abort". Which instructions are available will be implementation= -dependent, but "Install" or something to that effect is needed. * The receiving party must immediately start carrying out the instru= ction and report back any success or failure. The receiving party needs to = retrieve or receive the manifest referenced by the digest and encoding it r= eceived, as well as any dependency manifests or payloads. This can happen t= hrough any channel, e.g. the transmitting part retrieves it on behalf of th= e receiving party. * The transmitting party transfers a list of ResourceLocations, eith= er preemptively or when asked. The receiving party may: * Use the list to find the URI associated with the digest receive= d in the first point. * Use the list to supplement the lists in any manifest(s) it reso= lves. * Pass the list on to other parties. Appendix: User Stories 1. I want to use a different signing wrapper. 2. I want to use a different encryption wrapper. 3. I want to use a custom wrapper for encoding. 4. I want the signing, encryption, and decoding metadata to be parsed by= another party than parses the rest of the manifest. 5. I want to prevalidate as much as I can before writing anything to fla= sh, to prevent unnecessary flash wear. 6. I want to prevalidate as much as I can before doing irreversible chan= ge. 7. I want to be able to easily concatenate lists of aliases to have only= a single lookup table for digest -> URI. 8. I want to explicitly validate the post-update state e.g. support fall= back or rollback. 9. I want to keep multiple parallel monotonic counters to support the de= vice containing multiple independent firmwares. 10. I want to be able to check for existence of a firmware without checki= ng the contents. 11. I want to be able to check that something has been successfully remov= ed/changed. 12. I want to be able to merge dependencies if they are signed by the sam= e entity. To reduce complexity and space used for manifests. 13. I want to independently identify and reference external components (c= omponents managed by other parties). 14. I want to do easily do rudimentary version/compatibility checks more = complex than the monotonic counter. Appendix: Resolutions of user stories 1. Resolved by moving signing, encryption and encoding out of scope of t= he specification. It is assumed that the user will implement it as nested w= rappers like COSE_Sign>. 2. Resolved as for 1. 3. Resolved as for 1. 4. Resolved as for 1. 5. Resolved by the fact that PreConditions are always checked against th= e state before the update started. 6. Resolved as for 5. 7. Resolved by Manifest::resourceLocations being the only list containin= g URIs that are looked up by digest. 8. Resolved by PostConditions and the fact that they are all applied to = the state after all payloads. 9. Resolved by the PayloadInfo::timestamp being tied to the StorageIdent= ifier. 10. Resolved by ImageCondition::digest being nil. 11. Resolved by ImageCondition::notCurrentContent. 12. Resolved by having a list of payloads instead of a single payload. 13. Resolved by the ComponentIdentifier. 14. Resolved by aliasing of StorageIdentifiers. --_000_992b7f82695c449f8cf485c97b57d7cbnordicsemino_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

We have been exploring how upda= tes would be passed between implementations (“parties”) inside = a system, and how the manifest format can help with that. Below is a manife= st format together with a short description of the update procedure and some restrictions on the format not captured by the C= DDL.

 

At the bottom are a number of u= ser stories as well as how the format and restrictions fulfil the user stor= ies.

 

Highlights:

  • We propose moving metadata about the preprocessing of = payloads and manifests out of the parent manifest. This is to facilitate ha= nding responsibilities between parties, and it has the added benefits of ma= king the format simpler, and not tying it to COSE.
  • After thinking quite a bit about it, we think we found= a satisfactory way to support multiple payloads. Each payload will have it= s own timestamp and set of conditions to be met before they can be installe= d.
  • Aliases has been promoted to resourceLocations, which = holds all URIs. Dependencies and payloads contain only the hash, used to lo= ok up the URI in the list. This simplifies the incorporation of aliases.
  • Conditions have been divided into PreConditions (all o= f which are checked at the very beginning) and PostConditions (all of which= are checked at the very end), because the start and finish of the update a= re well-defined points in time, that are critical for the robustness of the update.

=  

Thanks for the great work on th= e documents, we tried to adapt, but also wanted to send this in time for th= e hackathon. Do you plan to release a serialization format as well, or to k= eep it out of scope? Anyway, hopefully this is helpful.

=  

Unfortunately we cannot partici= pate in the hackathon in person, but we will try to join online as much as = possible.

 

Best regards,

=D8yvind and Frank

 

 

Manifest format (CDDL) [alt5]

 

TimeStamp        &nb= sp;  =3D uint .size 8

Uuid         &n= bsp;      =3D bstr .size 16

StorageIdentifier   =3D bstr

ComponentIdentifier =3D bstr

= UriList            &= nbsp;=3D { + int =3D> tstr }

= UriList           &n= bsp; =3D { + int =3D> tstr }

=  

DigestInfo =3D [

    size:      =       uint,

    digestAlgorithm: uint,<= /p>

    digest:     &nbs= p;    bstr

]

 

IdCondition     =3D [vendor: 1 / class: = 2 / device: 3,         id: &nb= sp;       Uuid]

TimeCondition   =3D [installAfter: 4 / bestBefore:= 5,          time:  =      Timestamp]

ImageCondition  =3D [currentContent: 6 / notCurrentCont= ent: 7, digest:     DigestInfo / nil, location: Storage= Identifier]

CustomCondition =3D [nint,     &nbs= p;            &= nbsp;           &nbs= p;      parameters: bstr]

 

PreCondition  =3D IdCondition / TimeCondition / ImageCo= ndition / CustomCondition

PostCondition =3D ImageCondition / CustomCondition

 

ResourceLocation =3D [

    resourceLocationVersion: 1,

    digestInfo: DigestInfo,=

    encoding:   bstr,

    location:   UriList<= /span>

]

 

PayloadInfo =3D [

    subject:    StorageIdentif= ier,

    timestamp:  Timestamp,

    digest:     bstr=

]

 

ManifestInfo =3D [

    component:  ComponentIdentifier,

    digest:     bstr=

]

 

Manifest =3D [

    manifestVersion:   1,

    resourceLocations: [ * ResourceLocation ]= ,

    preConditions:     [ = * PreCondition ],

    dependencies:    &nbs= p; [ * ManifestInfo ],

    payloads:     &n= bsp;    [ * PayloadInfo ],

    postConditions:    [ * Pos= tCondition ],

    text:      =         { * int =3D> tstr } / nil,

    extensions:     =    { * int =3D> bstr } / nil

]

 

 

The update procedure

 

All manifests must be authentic= ated (signed), e.g. by being wrapped in a COSE_Sign or COSE_Mac. The format= does not mandate COSE-specific types.

 

A received manifest or payload = might be encoded in multiple steps like signature, encryption, compression = etc. Signing, encryption, compression and other encodings are implementatio= n-dependent, but when encrypting and/or signing a manifest, it must happen in the following order (any step can be= skipped) during creation:

  1. Compress/diff/other encoding
    2. Encrypt
  2. Sign

which then happen in reverse du= ring parsing:

  1. Check signature
  2. Decrypt
  3. Decompress/patch/other decoding
    4. =

 

Operations like signing, encryp= tion, compression etc. can be applied to both manifests and payloads. Any e= ncoding (e.g. delta patching) can be supported either through ResourceInfo:= :encoding or through a custom wrapper type (analogous to the COSE types) for the payload/manifest.

 

It is recommended that the upda= te process involves multiple passes of the manifest, e.g.:

  1. For each manifest, validate the serialization and chec= k the validity of StorageIdentifiers and ComponentIdentifiers. Check timest= amps and preConditions. This can hopefully be accomplished without writing = to flash storage.
  2. Retrieve payloads and validate them. This does not inv= olve irreversible change.
  3. Install payloads
  4. Check postConditions.

 

I.e. strive to validate as much= as possible before any flash writes happen, and as much as possible before= irreversible change happens.

 

If any check fails, or if any p= rocedure cannot be completed, the whole update must be aborted, and changes= reverted if possible.

 

 

Restrictions and Clarificati= ons about the types

 

PreCondition:=

  • preConditions are always checked against the state bef= ore the entire update started.

 

PostCondition:

  • All postConditions lists included in the update must p= ass before the update is complete.
  • All postConditions lists included in the update are ch= ecked against the state after all manifests are installed.

 

Manifest

  • Dependencies must be installed in the order they appea= r in the dependencies list.
  • Payloads must be installed in the order they appear in= the payloads list.
  • All dependencies must be installed before any payloads= are installed
  • A dependency is installed when the referenced Manifest= is completely installed. I.e. the dependency tree is traversed depth-first= .
  • A Manifest is installed when all its payloads are inst= alled.

 

ResourceLocation

  • If a single list of ResourceLocations contains two ent= ries with the same digestInfo::digest, their entire digestInfo and encoding= entries must also be identical. This ensures that digests referred to in P= ayloadInfo and ManifestInfo are unambiguous.
  • The parser can use ResourceLocation::encoding to under= stand the encoding of the referenced manifest or payload.=
  • The format of ResourceLocation::encoding is implementa= tion-dependent.
  • When a resource is successfully received or retrieved,= its digest must be checked.

 

PayloadInfo

  • The PayloadInfo::digest can be used to look up an entr= y in the resourceLocations list by matching it with ResourceLocation::diges= tInfo.digest.
  • The value in PayloadInfo::timestamp must be at least o= ne greater than the stored timestamp for this StorageIdentifier. This must = be checked immediately before the payload is installed.
  • After the PayloadInfo has been installed, the stored t= imestamp for this StorageIdentifier is overwritten with the value in Payloa= dInfo::timestamp. This must happen before the next payload's timestamp is c= hecked.

 

StorageIdentifier

  • The format of StorageIdentifier is implementation-depe= ndent, but must give enough information to unambiguously point to a certain= string of bytes, including its size, inside the image. Multiple StorageIde= ntifiers can point to the same byte string, or overlapping byte strings, with no restrictions. I.e.:
    • Imagine an update was stored with StorageIdentifier &q= uot;app/5/1/0/store_metadata". Note that StorageIdentifiers don't have= to be text, and don't have to look like paths. In an ImageCondition, the S= torageIdentifier "app", "app/5", "app/5/1", "app/5/1/0", or "app/5/1/0/load_metadata" might all re= solve to the same content received in the update. ANY aliasing scheme is al= lowed.
    • Updates to different StorageIdentifiers can cause incr= ementation of the same stored timestamp. Any mapping from StorageIdentifier= to stored timestamp is allowed.

 

IdCondition

  • A device's vendorID, classID, and deviceID should be s= tatic within the same ComponentIdentifier.

 

TimeCondition=

  • These conditions require a secure clock providing a cu= rrent time.
  • These conditions are unrelated to PayloadInfo::timesta= mp.
  • installAfter fails if the current time is less than th= e required time.
  • bestBefore fails if the current time is more than the = required time.

 

ImageCondition

  • The condition refers to the state of the image at the = time it is checked.
  • ImageCondition::digest represents the hash of the expe= cted content.
  • DigestInfo::size represents the expected length of the= content.
  • If ImageCondition::digest is nil only the existence of= the location is checked, not the content.
  • The total size of the byte string pointed to by the St= orageIdentifier must equal the content length reported in the ImageConditio= n. To check only a part of the byte string content, define a new StorageIde= ntifier that points to the relevant part.
  • notCurrentContent is the inverse of currentContent, i.= e.:
    • A notCurrentContent condition will pass for any state = currentContent would fail for.
    • A notCurrentContent condition will fail for any state = currentContent would pass for.

 

ComponentIdentifier<= /span>

  • The format of ComponentIdentifier is implementation-de= pendent but is intended to refer to components that the current party does = not have direct write access to. "party" here means an implementa= tion of the standard.

 

ManifestInfo<= /p>

  • The ManifestInfo::digest can be used to look up an ent= ry in the resourceLocations list by matching it with ResourceInfo::digestIn= fo.digest.
  • If the manifest referred to by the ComponentIdentifier= will be installed by a different party, the handover will involve some or = all of the following:
    • The transmitting party transfers the digest and encodi= ng from the relevant ManifestInfo, together with an instruction such as &qu= ot;Validate", "Install", or "Abort". Which instruc= tions are available will be implementation-dependent, but "Install&quo= t; or something to that effect is needed.
    • The receiving party must immediately start carrying ou= t the instruction and report back any success or failure. The receiving par= ty needs to retrieve or receive the manifest referenced by the digest and e= ncoding it received, as well as any dependency manifests or payloads. This can happen through any channel, e.g= . the transmitting part retrieves it on behalf of the receiving party.=
    • The transmitting party transfers a list of ResourceLoc= ations, either preemptively or when asked. The receiving party may:
      • Use the list to find the URI associated with the diges= t received in the first point.
      • Use the list to supplement the lists in any manifest(s= ) it resolves.
      • Pass the list on to other parties.

 

Appendix: User Stories<= /o:p>

 

  1. I want to use a different signing wrapper.<= /span>
  2. I want to use a different encryption wrapper.
  3. I want to use a custom wrapper for encoding.
  4. I want the signing, encryption, and decoding metadata = to be parsed by another party than parses the rest of the manifest.
  5. I want to prevalidate as much as I can before writing = anything to flash, to prevent unnecessary flash wear.
  6. I want to prevalidate as much as I can before doing ir= reversible change.
  7. I want to be able to easily concatenate lists of alias= es to have only a single lookup table for digest -> URI.
  8. I want to explicitly validate the post-update state e.= g. support fallback or rollback.
  9. I want to keep multiple parallel monotonic counters to= support the device containing multiple independent firmwares.
  10. I want to be able to check for existence of a firmware= without checking the contents.
  11. I want to be able to check that something has been suc= cessfully removed/changed.
  12. I want to be able to merge dependencies if they are si= gned by the same entity. To reduce complexity and space used for manifests.=
  13. I want to independently identify and reference externa= l components (components managed by other parties).
    14. <= li class=3D"MsoListParagraph" style=3D"margin-left:19.95pt;mso-list:l17 lev= el1 lfo11"> I want to do easily do rudimentary version/compatibili= ty checks more complex than the monotonic counter.

     

     

    Appendix: Resolutions of use= r stories

     

    1. Resolved by moving signing, encryption and encoding ou= t of scope of the specification. It is assumed that the user will implement= it as nested wrappers like COSE_Sign<COSE_Encrypt<Payload_blob>&g= t;.
    2. Resolved as for 1.
    3. Resolved as for 1.
    4. Resolved as for 1.
    5. Resolved by the fact that PreConditions are always che= cked against the state before the update started.
      6. Resolved as for 5.
    6. Resolved by Manifest::resourceLocations being the only= list containing URIs that are looked up by digest.
      7. <= li class=3D"MsoListParagraph" style=3D"margin-left:17.85pt;mso-list:l9 leve= l1 lfo22"> Resolved by PostConditions and the fact that they are = all applied to the state after all payloads.
    7. Resolved by the PayloadInfo::timestamp being tied to t= he StorageIdentifier.
    8. Resolved by ImageCondition::digest being nil.
    9. Resolved by ImageCondition::notCurrentContent.
    10. Resolved by having a list of payloads instead of a sin= gle payload.
    11. Resolved by the ComponentIdentifier.=
    12. Resolved by aliasing of StorageIdentifiers.=
--_000_992b7f82695c449f8cf485c97b57d7cbnordicsemino_-- From nobody Mon Jun 4 08:16:14 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7C4212DA0A for ; Mon, 4 Jun 2018 08:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6sXVUmgMDKa for ; Mon, 4 Jun 2018 08:15:58 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BF4512DA08 for ; Mon, 4 Jun 2018 08:15:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 40667300A0E for ; Mon, 4 Jun 2018 11:15:55 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id gKglK3a1t93d for ; Mon, 4 Jun 2018 11:15:50 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 8C3BF300445 for ; Mon, 4 Jun 2018 11:15:50 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <238EC1AC-D898-472D-A951-2AD1438C6004@vigilsec.com> Date: Mon, 4 Jun 2018 11:16:11 -0400 To: suit@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Suit] COSE_Sign vs. COSE_Mac X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2018 15:16:00 -0000 I am struggling to see a case where COSE_Mac provides acceptable = protection. With a MAC, the sender and the recipient must use the same = key. This means that any recipient can make a modification and produce = a valid MAC for the modified object. With a digital signature, the sender uses a private key, and the = recipients use a public key, so the recipients cannot produce modified = objects. Why accept this possibility? Russ From nobody Mon Jun 4 08:24:08 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB73212DA0D for ; Mon, 4 Jun 2018 08:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KphxrpzSQ6M6 for ; Mon, 4 Jun 2018 08:24:04 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0043.outbound.protection.outlook.com [104.47.2.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08D6212DA0A for ; Mon, 4 Jun 2018 08:24:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YPspNGTI4V8f8/x3nmYfba13yvDVXQLc7Vh1dtwzMuQ=; b=k4hmNYNH7s6mSfS/GQVZSmRj+1RioUP6EPTQPLAKzoeEa78TaIfBRxEXxUfY4RZ2TZ97Iw0rf5nlM5FQmn+pKBwMn5SGtb+bug8/W68Cf0vdjEq+6jsvIiAv/rr0zK93QhwTKqVJ50uTlOIvoQ0qOnNz/MkvPEsVKQ69+LZ93KY= Received: from AM4PR0802MB2260.eurprd08.prod.outlook.com (10.172.217.150) by AM4PR0802MB2292.eurprd08.prod.outlook.com (10.172.218.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.820.11; Mon, 4 Jun 2018 15:24:01 +0000 Received: from AM4PR0802MB2260.eurprd08.prod.outlook.com ([fe80::15ab:db2e:593b:b5e0]) by AM4PR0802MB2260.eurprd08.prod.outlook.com ([fe80::15ab:db2e:593b:b5e0%4]) with mapi id 15.20.0820.015; Mon, 4 Jun 2018 15:24:01 +0000 From: Brendan Moran To: Russ Housley CC: "suit@ietf.org" Thread-Topic: [Suit] COSE_Sign vs. COSE_Mac Thread-Index: AQHT/Bb8ynYYrycVqEW8/gFj26U6OaRQN/OA Date: Mon, 4 Jun 2018 15:24:01 +0000 Message-ID: <168ED9F9-15CF-457B-850A-77196D423D08@arm.com> References: <238EC1AC-D898-472D-A951-2AD1438C6004@vigilsec.com> In-Reply-To: <238EC1AC-D898-472D-A951-2AD1438C6004@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.8.2) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brendan.Moran@arm.com; x-originating-ip: [217.140.96.140] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0802MB2292; 7:VluKCMWzPVgdI2ZVyc9zrlvjqtq0M/ONqoC6RjLXAK5eK0ugp6uVk5orJ2KUlrvs6nl3BLjr5PhJp03mCKUBz8lipUBaGajroxnT2S9Cy4OGZ8NLV6rQHmi19vwdBjAxsikvqVzQAcwbw5FaEUoRTKYTzFpqLzTlRp40rU1686XG9bSqKgZ7V292gqvyqWXB9Ryc77PUaLiJZqBXR2Iw8w6N1wLwI3SfQ9oxqzAUKRdI+mA3a9HVlbrnuY35sjZb x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:AM4PR0802MB2292; x-ms-traffictypediagnostic: AM4PR0802MB2292: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(3231254)(944501410)(52105095)(93006095)(93001095)(10201501046)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:AM4PR0802MB2292; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0802MB2292; x-forefront-prvs: 069373DFB6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(366004)(396003)(39380400002)(39860400002)(346002)(376002)(199004)(189003)(40434004)(3280700002)(2900100001)(3660700001)(72206003)(14454004)(57306001)(2906002)(5890100001)(97736004)(5250100002)(33656002)(50226002)(8936002)(8676002)(3846002)(99286004)(81166006)(478600001)(5660300001)(83716003)(53936002)(76176011)(25786009)(966005)(486006)(81156014)(6436002)(82746002)(66066001)(36756003)(186003)(316002)(6916009)(4326008)(53546011)(106356001)(305945005)(6506007)(68736007)(86362001)(446003)(102836004)(7736002)(105586002)(2616005)(476003)(6116002)(229853002)(59450400001)(11346002)(26005)(6512007)(6246003)(6486002)(6306002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0802MB2292; H:AM4PR0802MB2260.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: vigO6Rl0X4XnNz73PFAObf/DDdbhV7k3z6IhjFziVMbQQUNoPdwDZtU9luVpL2AY29YopaTAHgSm0gX8mi9lx/+RC2PjQUO0oS4CCtw683Kts7sHFzMt2WG5gL0HglOPVv+7/lu1x3Bh2rcOBhl3pr5jBGlANJeQpqv2NEknLtvt9yWvzFz7yMEYJ+if8T42 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <964760EF8793E84FA09BF78E6C6115B0@eurprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 6fc6da25-fd93-4c87-9f4c-08d5ca2f335a X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6fc6da25-fd93-4c87-9f4c-08d5ca2f335a X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jun 2018 15:24:01.6331 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0802MB2292 Archived-At: Subject: Re: [Suit] COSE_Sign vs. COSE_Mac X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2018 15:24:07 -0000 This is a solution that is intended to address a segment of devices that ca= nnot use public-key due to code size or processing overhead, and cannot use= hash-based signatures due to data overhead. Provided that every device has= a unique PSK, COSE_Mac provides adequate security. However, it introduces = significant key management overhead. Thanks, Brendan > On 4 Jun 2018, at 16:16, Russ Housley wrote: > > I am struggling to see a case where COSE_Mac provides acceptable protecti= on. With a MAC, the sender and the recipient must use the same key. This = means that any recipient can make a modification and produce a valid MAC fo= r the modified object. > > With a digital signature, the sender uses a private key, and the recipien= ts use a public key, so the recipients cannot produce modified objects. > > Why accept this possibility? > > Russ > > _______________________________________________ > Suit mailing list > Suit@ietf.org > https://www.ietf.org/mailman/listinfo/suit IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Mon Jun 4 08:52:25 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0524A129495 for ; Mon, 4 Jun 2018 08:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKmFktoWbm_Q for ; Mon, 4 Jun 2018 08:52:22 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A8F8126CAC for ; Mon, 4 Jun 2018 08:52:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 37016300A11 for ; Mon, 4 Jun 2018 11:52:20 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id G-Po4wLM5pss for ; Mon, 4 Jun 2018 11:52:18 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id B64FF300445; Mon, 4 Jun 2018 11:52:18 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <168ED9F9-15CF-457B-850A-77196D423D08@arm.com> Date: Mon, 4 Jun 2018 11:52:19 -0400 Cc: "suit@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <238EC1AC-D898-472D-A951-2AD1438C6004@vigilsec.com> <168ED9F9-15CF-457B-850A-77196D423D08@arm.com> To: Brendan Moran X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Suit] COSE_Sign vs. COSE_Mac X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2018 15:52:24 -0000 Brendan: That is a significant key management burden. I would like to explore = the assertion that hash-based signatures have too much data overhead. = Are you saying that they can buffer the firmware load, but not the = signature value? Russ > On Jun 4, 2018, at 11:24 AM, Brendan Moran = wrote: >=20 > This is a solution that is intended to address a segment of devices = that cannot use public-key due to code size or processing overhead, and = cannot use hash-based signatures due to data overhead. Provided that = every device has a unique PSK, COSE_Mac provides adequate security. = However, it introduces significant key management overhead. >=20 > Thanks, > Brendan >=20 >> On 4 Jun 2018, at 16:16, Russ Housley wrote: >>=20 >> I am struggling to see a case where COSE_Mac provides acceptable = protection. With a MAC, the sender and the recipient must use the same = key. This means that any recipient can make a modification and produce = a valid MAC for the modified object. >>=20 >> With a digital signature, the sender uses a private key, and the = recipients use a public key, so the recipients cannot produce modified = objects. >>=20 >> Why accept this possibility? >>=20 >> Russ >>=20 >> _______________________________________________ >> Suit mailing list >> Suit@ietf.org >> https://www.ietf.org/mailman/listinfo/suit >=20 > IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy = the information in any medium. Thank you. From nobody Mon Jun 4 08:59:52 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2421D127A03 for ; Mon, 4 Jun 2018 08:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.018 X-Spam-Level: X-Spam-Status: No, score=-1.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_SORBS_DUL=0.001, RDNS_DYNAMIC=0.982, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bergzand.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PO74nYtq63VY for ; Mon, 4 Jun 2018 08:59:48 -0700 (PDT) Received: from mail.bergzand.net (84-245-11-206.dsl.cambrium.nl [84.245.11.206]) by ietfa.amsl.com (Postfix) with ESMTP id BFB52127666 for ; Mon, 4 Jun 2018 08:59:47 -0700 (PDT) Received: from [IPv6:2001:470:78ad:5::1006] (unknown [IPv6:2001:470:78ad:5::1006]) by mail.bergzand.net (Postfix) with ESMTPSA id D37222AD4C for ; Mon, 4 Jun 2018 18:10:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bergzand.net; s=mail; t=1528128631; bh=YgFtAveSG8kajyHYj5BEHhy7iKm8el7iQdMPG5+YnLQ=; h=Subject:To:References:From:Date:In-Reply-To; b=Z9lFy1s6OkcJ+Z7Xy5IWPfXsdTj3iZPt1y3bkS0prqoEM8D6IFVGumwM9nCOjxe0f 3M1N/5geXNu8r/aZwlla33DwuwVKc2sRHpY00UuBWhjLhAvlvmTxistAMk0OX95rUP tPkTXrjUV/mnNBTiAXf0oVgprodyXVDDz4eEy480= To: suit@ietf.org References: <238EC1AC-D898-472D-A951-2AD1438C6004@vigilsec.com> <168ED9F9-15CF-457B-850A-77196D423D08@arm.com> From: Koen Zandberg Openpgp: preference=signencrypt Autocrypt: addr=koen@bergzand.net; prefer-encrypt=mutual; keydata= xsFNBFfiUE0BEAC2GQfspM4LKuFBsuBVG5f8iKIg3SQIeyK5tG+fHrLYIt+qXIrya1rxX4MQ iGtJmG0F+iVOAZZXLvT3nd1L7jIvT83fUULRKsxGeq8swHhHRdtyiSNDCdpY3Z0PmF6nyoEV kevB5FHQPLWZIMdvX324ihJ1qN34yIBBy+Q2rk2FP8Dn0PDHcCwiY9PCzurpNDcEjQ2EdsO2 pFAUy8m04A0H9pH3Up/o6xhsQsbt4Q9U1YuGJiUpMXXBq+6hufafRtRjPIypr4LCYAVaKsds R5GxLcFrNXiMxDf3tVTrF2PebXhepamDbG7ujpiYZ5x8fKEFvrUJSM2Qz+agf0JqsueXowy7 nwNrcn9ygShydizAZ34OSphGCxnmJ6j6aTp/bo77GXJnvT3hACYHX7vmTg6ODII9pLQCYda4 ML2rL6u06oLnvyoC2Q7RQKgfMSDgA3Vx+yeWI4IoxmtNXjnFvrfGCIY347rhjBrQL4Za1xuL uw0YggCCIH1Qp6z+MNXcIuHEeS5HJJsUQlN6OfBwCWI2hfToilo+/7xv4sIc6+aknLhmE3H2 FuDYFh3Z7TUoLL3K/Jcx3ndmsajh3UNsnYPxiOLkFIKJgDfQg+Xi7eqVSaBslSPNjsw78lNc qkCSOZXuDfd7h4cuvn6m+VdFz2yRLoOhZPxc2jBd9QxSsXBIqwARAQABzSFLb2VuIFphbmRi ZXJnIDxrb2VuQGJlcmd6YW5kLm5ldD7CwYAEEwEIACoCGwMCHgECF4AFCwkIBwMFFQoJCAsF FgIDAQACGQEFAlnbfXQFCQPaYKcACgkQaVaPK/gRSic0iQ/+LKC7IPJKkbVh8JhVOHEFp5kt 3h1DtpNzQLqHaOOCqGubUgig+QQOmyHexmd10m3JddLxfjujC36KYTl5+NkO7GGzlcHcL8dI w0jPASrUbP/AJ4UYP8dit6ONHrbf7Zy511beoF57LoOG07+cCY7YbN8pilsLMel8Hxl5tUq4 oGg92Fx7g6SQ5oVW5OBhyQSSImydK+MZTbpKgCpZ8hZYWVpIfQQYZnbC0cS16HZnNpSoqcUv AR0/QjtGu2ffISE5xJ+Ovj4yK1N38WgJm0+lE2hXnaRQ60F8aowCNVEbJFS67iOjI8bT6joe mIpHWqZOj79LzqIQBl2H3PmZRy30+teUumqFw2PEMid9mvfIG+PjgW8NVOyaxeErYYHTSYor iZhCKENHChNVoiD4qW8hFBLEwwx/Cubf+Sf8QRvl6k4O79LO9qKmgomITXTUueuoduFGwl9B YQlAnrB3KVmz7mmYnaGaR43MuxLwyDa03HUCeo1WIXgQviQqm2ypjTbIdX0/i+lXrpv0qtoY rlV0kNFVOKi40QrK3haA3RoifdYww9GjuW72arUnTMszEgEXLIzLczthv/FpT5X9V+IEYNo0 uZs05it+/6Yshsffcw2LWE+/b8zZNfBIl6+yXeX4WhdLDJ2NUCb/xPukZi/XVFd4A3GyIWq/ IfYtK/B5TtXOwU0EV+JQTQEQAK0MNhuCK0k78+WcrGp7iZbMeXkUkcEzsmXu1mctHoqpxONs ibgNeBFL+xCuhiPkpEeBARvaj3pychH8Ckp+hv1XFYONEsSPEhPAl1Qn+d3zXwqfjjOV2J5s iIJhmZdtzi7ovJn4r03Z7KEOXF3qxNYHreXjjzwUV57ukHBZAYZ2ExGTOtt3wd0fLEJ8JChC D6+FSVpbZrxgjfYC/QeGNGLbNa0BsbZe5e9x/u1A1WyfN3/yqM3BJtdg6EWkkXTbMLJZhCkR 5Nt2tbFw8MBrFR4qt7ShAy9r5QD21bga1m7zu+jjti3HJ8Yc3LyaU87cGlbbZmQPLwPgea6A xtBCnkTqfJZVFApbXHmCsDK+26E9258rlVsYRx326ZpLJ5erRZqnPZT/9GF1OWS6vcYk5eVI sC3MGN6KvFVxIxwFnW7zXKS96q3Ge9CRg/pNO/ibSrQVqrpJyA0NEyB5Z/dngLKKKlfgLLW5 ga+cZ0puQKE2jCCKdiq9ZGdyEXb3ME2JDxHo0b6RzrHsYVdeAXaifOqDMlPUn7faeSTJgjkT uZhKQ27P6QIx4xQs/KOTeNE8/uZ3nXieCdpPdnrzSk55HipVvaWdHpcO/eWeakb6B7MnKjQM 2Bg7adi73G8hUMutg0CN/IFsn/Pkws9jE/n84O5ieBOmvaQbs2MeWG0+E3TPABEBAAHCwWUE GAEIAA8CGwwFAlnbfV8FCQPaYJIACgkQaVaPK/gRSifyAg//eoupx8C0GiIfRdzCQuqGuDs9 ZfplXMzuNx8Mn8Y6TlMpBHlet5HX++MHlAeNiFqsYI6JWpZFtWbYWucPIZl3Vom2lfJwgWVq eUxMHf4vklcCIXptDZoJCTfDb2LQArKSD7mVHlVT3whkLHYqQKi+UypG1nVNiJ7secI9GAKS oiAXg8RQbyyHppNhbyIqTKwlrzCEriUKv3swCK4Y7he0LhMl/UNy1LsHp3FY1GFBnx7n75hN qwYMdIppVdn6vN7eCcSCpifvEh3AOCANB33zZZ7nGcrlwKyb91bmLpCJk4w8/xY2CBd5UOD9 5l29Qx9FPozvRWjMuuPGFyQlOEVIeHhQgt3fUuILxkZsycAmw/C3gj3PMXCYvB6tYC9HBXc8 AsTeX4g9fE6cP/R6AWRFNCrjCr/aWJzBBJvUO2EQrQDpU+5gsotAvQJxt6UKSDs9u0uP8yaG 1Lqe64SEPW34kCMCbEVCm5nbWHyppv459EDA9I0nUHutqymnis0SW++N628HSTzkxkku+qck JkDom7xGbICrtknEtuy0v5DaxLP3l6/j6SB83VyPoLJ+dB2QWH82wM/SMUegpDvfldsi2KhC kzC37F2pSpZler/ZAzhChh3DzYSxtR8a3sII8ywNaO3sNz6NKHgsJtkuqOQOEytohRxaOSG1 RF89pwgstsY= Message-ID: <932b5b21-dc56-b316-0c0d-28d43c4cec42@bergzand.net> Date: Mon, 4 Jun 2018 17:59:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VEkIyZDbyytC2I9WEk7ecJRzRYMBexEni" Archived-At: Subject: Re: [Suit] COSE_Sign vs. COSE_Mac X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2018 15:59:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VEkIyZDbyytC2I9WEk7ecJRzRYMBexEni Content-Type: multipart/mixed; boundary="h7WBB8RlDzGbIbmvEi7wrnVKnbgkjEYIy"; protected-headers="v1" From: Koen Zandberg To: suit@ietf.org Message-ID: <932b5b21-dc56-b316-0c0d-28d43c4cec42@bergzand.net> Subject: Re: [Suit] COSE_Sign vs. COSE_Mac References: <238EC1AC-D898-472D-A951-2AD1438C6004@vigilsec.com> <168ED9F9-15CF-457B-850A-77196D423D08@arm.com> In-Reply-To: --h7WBB8RlDzGbIbmvEi7wrnVKnbgkjEYIy Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Russ, My 2 cents for this scenario: the device I'm currently developing for (samr21-xplained pro) takes around 8 seconds for ed25519 signature verification (TweetNaCl implementation). An HMAC based verification would be a lot faster here (saving me battery power). If you like I can provide you some numbers on flash requirements for both HMAC and public-key implementations. Thanks, Koen On 06/04/2018 05:52 PM, Russ Housley wrote: > Brendan: > > That is a significant key management burden. I would like to explore t= he assertion that hash-based signatures have too much data overhead. Are= you saying that they can buffer the firmware load, but not the signature= value? > > Russ > > >> On Jun 4, 2018, at 11:24 AM, Brendan Moran wro= te: >> >> This is a solution that is intended to address a segment of devices th= at cannot use public-key due to code size or processing overhead, and can= not use hash-based signatures due to data overhead. Provided that every d= evice has a unique PSK, COSE_Mac provides adequate security. However, it = introduces significant key management overhead. >> >> Thanks, >> Brendan >> >>> On 4 Jun 2018, at 16:16, Russ Housley wrote: >>> >>> I am struggling to see a case where COSE_Mac provides acceptable prot= ection. With a MAC, the sender and the recipient must use the same key. = This means that any recipient can make a modification and produce a vali= d MAC for the modified object. >>> >>> With a digital signature, the sender uses a private key, and the reci= pients use a public key, so the recipients cannot produce modified object= s. >>> >>> Why accept this possibility? >>> >>> Russ >>> >>> _______________________________________________ >>> Suit mailing list >>> Suit@ietf.org >>> https://www.ietf.org/mailman/listinfo/suit >> IMPORTANT NOTICE: The contents of this email and any attachments are c= onfidential and may also be privileged. If you are not the intended recip= ient, please notify the sender immediately and do not disclose the conten= ts to any other person, use it for any purpose, or store or copy the info= rmation in any medium. Thank you. > _______________________________________________ > Suit mailing list > Suit@ietf.org > https://www.ietf.org/mailman/listinfo/suit --h7WBB8RlDzGbIbmvEi7wrnVKnbgkjEYIy-- --VEkIyZDbyytC2I9WEk7ecJRzRYMBexEni Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEM1a0jNDzUUT3pcy6CJWok+bSmFsFAlsVYe0ACgkQCJWok+bS mFtulQ//WLdDt+PKoVbAjtIBDDvcG3aTinXo3+SoXtL8Jal+AS8h7h3keWi8oUqs nULQXdQKZCdU0y9wM7A9RY8sgEsC7D/iDpJg28Xa5EKK7QcVgyNmwiPKGdY/onFs J+ibJKF+O5DTrFam8+owRyZggu3rbpOfTXvWLcHmSBvlIvsAzx3nsPpNFJVqTn3B 6CDgY8KRl93Djv44vlI+OhY6ZyNCS/syCqG2e75GyTbAJErtX0N+Z/rexT7oStDO M2wCffVw8QmjU9q3jJmAyNJdwv9Y9LreLZgx5uA5tSov0g3ypeWQRukC7Y+Pnwbm rWRmpsdflv3PTZ5TbjeoSaPORZLVa03h5XiaivtDDHeSqRLOQybu16V7/GsnRf1z 8DkWql+OkG33uawtTGr+Lbog4YbyFQKKOUpmgTQMkxejOuOiT3s0UuLBD5UyeWpY A028K+G9ysY9mWhjvYLALfCe0mmiNsiqVI0lDGEIFz5oyuUqgzqW7JX3IJ5LmvE2 enEs0ib8BXgUFQ7tp31GwMmWtXiTFDAVLB6MMi4WDcdklsEda/dHUCLQx4mp4GOM CMp9GkuqMiZWB9NPV7HhuKDVbp61UgmSMbyjg/MiJ/R6siePvXfMkR752YsgIvGo M8Qh/O0foB6SK+nLD2BULCr5ipeLhQRSFUquBTcVZ3m6MpYPifQ= =ktI3 -----END PGP SIGNATURE----- --VEkIyZDbyytC2I9WEk7ecJRzRYMBexEni-- From nobody Mon Jun 4 12:51:05 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E22130DD9 for ; Mon, 4 Jun 2018 12:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iG9WPbAzE5Km for ; Mon, 4 Jun 2018 12:51:02 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DE26130DC0 for ; Mon, 4 Jun 2018 12:51:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 03413300A0E for ; Mon, 4 Jun 2018 15:51:00 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id xH3euvm3WhI3 for ; Mon, 4 Jun 2018 15:50:58 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id B26C330042A; Mon, 4 Jun 2018 15:50:58 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <932b5b21-dc56-b316-0c0d-28d43c4cec42@bergzand.net> Date: Mon, 4 Jun 2018 15:50:59 -0400 Cc: suit@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <238EC1AC-D898-472D-A951-2AD1438C6004@vigilsec.com> <168ED9F9-15CF-457B-850A-77196D423D08@arm.com> <932b5b21-dc56-b316-0c0d-28d43c4cec42@bergzand.net> To: Koen Zandberg X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Suit] COSE_Sign vs. COSE_Mac X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2018 19:51:04 -0000 Koen: I was pushing back on the hash-based signature part of the statement = from Brandan. The hash-based signature algorithms use small private and = public keys, and it has low computational cost; however, the signatures = are quite large. Depending on the depth of the tree used by the signer, = the computational cost will be a few times greater than HMAC, but it = would eliminate the need to have a different file for each device. Russ > On Jun 4, 2018, at 11:59 AM, Koen Zandberg wrote: >=20 > Hi Russ, >=20 > My 2 cents for this scenario: the device I'm currently developing for > (samr21-xplained pro) takes around 8 seconds for ed25519 signature > verification (TweetNaCl implementation). An HMAC based verification > would be a lot faster here (saving me battery power). If you like I = can > provide you some numbers on flash requirements for both HMAC and > public-key implementations. >=20 > Thanks, > Koen >=20 >=20 > On 06/04/2018 05:52 PM, Russ Housley wrote: >> Brendan: >>=20 >> That is a significant key management burden. I would like to explore = the assertion that hash-based signatures have too much data overhead. = Are you saying that they can buffer the firmware load, but not the = signature value? >>=20 >> Russ >>=20 >>=20 >>> On Jun 4, 2018, at 11:24 AM, Brendan Moran = wrote: >>>=20 >>> This is a solution that is intended to address a segment of devices = that cannot use public-key due to code size or processing overhead, and = cannot use hash-based signatures due to data overhead. Provided that = every device has a unique PSK, COSE_Mac provides adequate security. = However, it introduces significant key management overhead. >>>=20 >>> Thanks, >>> Brendan >>>=20 >>>> On 4 Jun 2018, at 16:16, Russ Housley wrote: >>>>=20 >>>> I am struggling to see a case where COSE_Mac provides acceptable = protection. With a MAC, the sender and the recipient must use the same = key. This means that any recipient can make a modification and produce = a valid MAC for the modified object. >>>>=20 >>>> With a digital signature, the sender uses a private key, and the = recipients use a public key, so the recipients cannot produce modified = objects. >>>>=20 >>>> Why accept this possibility? >>>>=20 >>>> Russ >>>>=20 >>>> _______________________________________________ >>>> Suit mailing list >>>> Suit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/suit >>> IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy = the information in any medium. Thank you. >> _______________________________________________ >> Suit mailing list >> Suit@ietf.org >> https://www.ietf.org/mailman/listinfo/suit >=20 >=20 > _______________________________________________ > Suit mailing list > Suit@ietf.org > https://www.ietf.org/mailman/listinfo/suit From nobody Mon Jun 4 13:18:46 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98ECC130DE4 for ; Mon, 4 Jun 2018 13:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQ_bSat7Fb_K for ; Mon, 4 Jun 2018 13:18:35 -0700 (PDT) Received: from mx6.haw-public.haw-hamburg.de (mx6.haw-public.haw-hamburg.de [141.22.6.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10586130E21 for ; Mon, 4 Jun 2018 13:18:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.49,476,1520895600"; d="scan'208";a="64353391" Received: from hub02.mailcluster.haw-hamburg.de ([141.22.24.51]) by mail6.is.haw-hamburg.de with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Jun 2018 22:18:32 +0200 Received: from CAS04.mailcluster.haw-hamburg.de (2002:8d16:183f::8d16:183f) by HUB02.mailcluster.haw-hamburg.de (2002:8d16:1833::8d16:1833) with Microsoft SMTP Server (TLS) id 14.3.399.0; Mon, 4 Jun 2018 22:18:31 +0200 Received: from [192.168.178.22] (141.22.250.35) by haw-mailer.haw-hamburg.de (141.22.24.63) with Microsoft SMTP Server (TLS) id 14.3.399.0; Mon, 4 Jun 2018 22:18:32 +0200 To: References: <238EC1AC-D898-472D-A951-2AD1438C6004@vigilsec.com> <168ED9F9-15CF-457B-850A-77196D423D08@arm.com> <47a6002fceb54829a95a10bf3adb32ea@HUB01.mailcluster.haw-hamburg.de> From: "Thomas C. Schmidt" Message-ID: <34786b07-8831-8a3c-caea-8e73d91115c1@haw-hamburg.de> Date: Mon, 4 Jun 2018 22:18:32 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <47a6002fceb54829a95a10bf3adb32ea@HUB01.mailcluster.haw-hamburg.de> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [141.22.250.35] Archived-At: Subject: Re: [Suit] COSE_Sign vs. COSE_Mac X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2018 20:18:45 -0000 Hi Koen, On 04/06/2018 17:59, Koen Zandberg wrote: > My 2 cents for this scenario: the device I'm currently developing for > (samr21-xplained pro) takes around 8 seconds for ed25519 signature > verification (TweetNaCl implementation). Could this work be significantly flawed? We've done the same Edwards curve on the same board with RIOT for SIGCOMM '15 and an ID-based authentication scheme: 3 sec verification, 1 sec generation. See https://conferences.sigcomm.org/sigcomm/2015/pdf/papers/p603.pdf It could be much faster when optimized in assembly code. Cheers, Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://inet.haw-hamburg.de/members/schmidt Fon: +49-40-42875-8452 ° From nobody Tue Jun 5 02:32:00 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90026130F29 for ; Tue, 5 Jun 2018 02:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsoyetFCVb-U for ; Tue, 5 Jun 2018 02:31:56 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F276130E61 for ; Tue, 5 Jun 2018 02:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w559VqnK008180 for ; Tue, 5 Jun 2018 11:31:52 +0200 (CEST) Received: from [172.18.144.187] (unknown [46.183.103.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 410RQZ5hKkzDX6X; Tue, 5 Jun 2018 11:31:50 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Carsten Bormann In-Reply-To: <152808358455.20892.2040053845976676560@ietfa.amsl.com> Date: Tue, 5 Jun 2018 11:31:36 +0200 X-Mao-Original-Outgoing-Id: 549883894.5458159-8d13e0100876643e55da0a259b637cae Content-Transfer-Encoding: quoted-printable Message-Id: References: <152808358455.20892.2040053845976676560@ietfa.amsl.com> To: suit@ietf.org X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: [Suit] draft-ietf-suit-architecture-00.txt X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 09:31:59 -0000 I had a quick look at this while preparing for the Interop. Summary: needs work. The sections are rather inhomogeneous. The introduction seems to = believe this is all about authentication, while Section 3.9 onwards and = 4 seem to know that this is really all about authorization. The = introduction claims to be done with just three players, while it later = becomes clear there are so many more. etc. We probably need to make up = our minds which of these are part of the =E2=80=9Carchitecture=E2=80=9D = and which ones are just enabled by the architecture (which may not need = to describe every single step of validating an authorization). The term =E2=80=9Cclaim=E2=80=9D is heavily misused. A claim is just = that, a claim. An instruction to a device to do something is not a = claim (at least not without the information what the audience of this = instruction is =E2=80=94 =E2=80=9Call X are instructed to=E2=80=A6=E2=80=9D= is indeed a claim). In any case, claims (containing instructions or = not) always need to be evaluated in the authorization framework of the = entity trying to make use of the claim. Another example of the seeming naivet=C3=A9 of the introduction: = Rollback needs to be properly authorized, not summarily prevented. (Like any other firmware state change, a.k.a. =E2=80=9Cupgrade=E2=80=9D.) Most importantly, we need to be very clear what expressions such as = =E2=80=9Csigning the manifest=E2=80=9D actually mean, i.e., what exactly = is the claim that is signed by that signature. I also have some editorial comments I=E2=80=99ll send directly to the = authors. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jun 5 03:05:13 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B145C130F69 for ; Tue, 5 Jun 2018 03:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KiQNtLL1i1WA for ; Tue, 5 Jun 2018 03:05:08 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0041.outbound.protection.outlook.com [104.47.2.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B93C2130F30 for ; Tue, 5 Jun 2018 03:05:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=s6Mghar6nC9ZyNQHuSinkNoAwgb9/fVAcorqELuK6uU=; b=AR3oweo44vniwrO0DYKlOBJ2WUERr5g9Uu2xLUB6kI6wOpdDJYHj5nqJW+5MfLBEhg9TA6vkpsJAtkEp9k9FUb6kycbGAJl0FjKkk6BYV7WFci5jqS2Zjz21nzwBioXs4JoHJ6LJbSX0ouDSOaW5delJVQ3w45sz909bx3X6ds0= Received: from AM4PR0802MB2260.eurprd08.prod.outlook.com (10.172.217.150) by AM4PR0802MB2289.eurprd08.prod.outlook.com (10.172.218.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.841.13; Tue, 5 Jun 2018 10:05:05 +0000 Received: from AM4PR0802MB2260.eurprd08.prod.outlook.com ([fe80::15ab:db2e:593b:b5e0]) by AM4PR0802MB2260.eurprd08.prod.outlook.com ([fe80::15ab:db2e:593b:b5e0%4]) with mapi id 15.20.0841.011; Tue, 5 Jun 2018 10:05:05 +0000 From: Brendan Moran To: Russ Housley CC: "suit@ietf.org" Thread-Topic: [Suit] COSE_Sign vs. COSE_Mac Thread-Index: AQHT/Bb8ynYYrycVqEW8/gFj26U6OaRQN/OAgAAH6ICAAQGQAA== Date: Tue, 5 Jun 2018 10:05:05 +0000 Message-ID: <4DB5E7CC-0103-4D46-8165-B22944AD72C2@arm.com> References: <238EC1AC-D898-472D-A951-2AD1438C6004@vigilsec.com> <168ED9F9-15CF-457B-850A-77196D423D08@arm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.8.2) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brendan.Moran@arm.com; x-originating-ip: [217.140.96.140] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0802MB2289; 7:bPfHwbV7QWYEvaG/4H6Gv3cjWExRLQyYEN5a0mhJN6fcpyx+ugrEDuuaudiXjhFkb+5x4Fiymg4qrcUD3EEN0xNwHVhaHvOoFjnWV0PxX8k27avoZhkcT6LLAKrCG+mMNGYxdti/m8wcKqRuTkSQpDlVLmTwqmoOhPJArvBKGUMj5zVh96Zrnt491RBb9azGN1h56q9pYkjLTK4guWxiko5YelW+mxv0kUAv2l9fET0ngCdEcOfDWeuSVLyzIk8O x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:AM4PR0802MB2289; x-ms-traffictypediagnostic: AM4PR0802MB2289: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(180628864354917); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:AM4PR0802MB2289; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0802MB2289; x-forefront-prvs: 0694C54398 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39380400002)(396003)(376002)(39850400004)(346002)(189003)(199004)(40434004)(53936002)(6436002)(86362001)(6512007)(8936002)(2900100001)(5890100001)(966005)(25786009)(81156014)(6486002)(105586002)(81166006)(36756003)(229853002)(478600001)(5660300001)(476003)(11346002)(2616005)(486006)(4326008)(2906002)(83716003)(50226002)(6246003)(5250100002)(446003)(72206003)(97736004)(6306002)(33656002)(316002)(3846002)(66066001)(6116002)(26005)(186003)(102836004)(59450400001)(53546011)(68736007)(6506007)(76176011)(8676002)(82746002)(106356001)(305945005)(99286004)(14454004)(3280700002)(6916009)(3660700001)(57306001)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0802MB2289; H:AM4PR0802MB2260.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: cQsNZ7YCmFPoTpTtgucuDFXn21s4RH9aQMIU9HdLiHrPZ0EeQ3ZGIdprBTte+6AE2lmSzhClvQmimwltIZTJhOOnccr3jA26qpKNgM5154WolPyanhlgegftsXavSSQ4yfs2td+JmiMTEVx/f+lYF9Gm4Ag6J4ijxXWOJ+hH4ROgPwPVtR76YCM6kOxc5+Zv spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <4392D0FF38A4C7479831FC35EAD1B5DA@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 0ae74325-b8f3-4a71-06a1-08d5cacbcfa4 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0ae74325-b8f3-4a71-06a1-08d5cacbcfa4 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2018 10:05:05.2317 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0802MB2289 Archived-At: Subject: Re: [Suit] COSE_Sign vs. COSE_Mac X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 10:05:12 -0000 SGkgUnVzcywNCkl0IGRlcGVuZHMgb24gdGhlIHNpemUgb2YgdGhlIHBheWxvYWQuIFdoZW4gd2Xi gJlyZSB0YWxraW5nIGFib3V0IHdob2xlLWltYWdlIHVwZGF0ZXMsIGl04oCZcyBjb21wbGV0ZWx5 IHJlYXNvbmFibGUsIGhvd2V2ZXIgdGhhdCB3b27igJl0IGFsd2F5cyBiZSB0aGUgY2FzZS4gSWYg d2UgaGF2ZSBkaWZmIGltYWdlcywgdGhleSBjYW4gYmUgcXVpdGUgc21hbGwsIGRlcGVuZGluZyBv biB0aGUgc2NvcGUgb2YgdGhlIGNoYW5nZS4gQSAyS2lCIHNpZ25hdHVyZSBvbiBhIDJLaUIgY29t cHJlc3NlZCBkaWZmIG1heSBiZSBhIGRlYWwtYnJlYWtlciBvbiBsb3ctYmFuZHdpZHRoIG5ldHdv cmtzLg0KDQpCcmVuZGFuDQoNCj4gT24gNCBKdW4gMjAxOCwgYXQgMTc6NTIsIFJ1c3MgSG91c2xl eSA8aG91c2xleUB2aWdpbHNlYy5jb20+IHdyb3RlOg0KPg0KPiBCcmVuZGFuOg0KPg0KPiBUaGF0 IGlzIGEgc2lnbmlmaWNhbnQga2V5IG1hbmFnZW1lbnQgYnVyZGVuLiAgSSB3b3VsZCBsaWtlIHRv IGV4cGxvcmUgdGhlIGFzc2VydGlvbiB0aGF0IGhhc2gtYmFzZWQgc2lnbmF0dXJlcyBoYXZlIHRv byBtdWNoIGRhdGEgb3ZlcmhlYWQuICBBcmUgeW91IHNheWluZyB0aGF0IHRoZXkgY2FuIGJ1ZmZl ciB0aGUgZmlybXdhcmUgbG9hZCwgYnV0IG5vdCB0aGUgc2lnbmF0dXJlIHZhbHVlPw0KPg0KPiBS dXNzDQo+DQo+DQo+PiBPbiBKdW4gNCwgMjAxOCwgYXQgMTE6MjQgQU0sIEJyZW5kYW4gTW9yYW4g PEJyZW5kYW4uTW9yYW5AYXJtLmNvbT4gd3JvdGU6DQo+Pg0KPj4gVGhpcyBpcyBhIHNvbHV0aW9u IHRoYXQgaXMgaW50ZW5kZWQgdG8gYWRkcmVzcyBhIHNlZ21lbnQgb2YgZGV2aWNlcyB0aGF0IGNh bm5vdCB1c2UgcHVibGljLWtleSBkdWUgdG8gY29kZSBzaXplIG9yIHByb2Nlc3Npbmcgb3Zlcmhl YWQsIGFuZCBjYW5ub3QgdXNlIGhhc2gtYmFzZWQgc2lnbmF0dXJlcyBkdWUgdG8gZGF0YSBvdmVy aGVhZC4gUHJvdmlkZWQgdGhhdCBldmVyeSBkZXZpY2UgaGFzIGEgdW5pcXVlIFBTSywgQ09TRV9N YWMgcHJvdmlkZXMgYWRlcXVhdGUgc2VjdXJpdHkuIEhvd2V2ZXIsIGl0IGludHJvZHVjZXMgc2ln bmlmaWNhbnQga2V5IG1hbmFnZW1lbnQgb3ZlcmhlYWQuDQo+Pg0KPj4gVGhhbmtzLA0KPj4gQnJl bmRhbg0KPj4NCj4+PiBPbiA0IEp1biAyMDE4LCBhdCAxNjoxNiwgUnVzcyBIb3VzbGV5IDxob3Vz bGV5QHZpZ2lsc2VjLmNvbT4gd3JvdGU6DQo+Pj4NCj4+PiBJIGFtIHN0cnVnZ2xpbmcgdG8gc2Vl IGEgY2FzZSB3aGVyZSBDT1NFX01hYyBwcm92aWRlcyBhY2NlcHRhYmxlIHByb3RlY3Rpb24uICBX aXRoIGEgTUFDLCB0aGUgc2VuZGVyIGFuZCB0aGUgcmVjaXBpZW50IG11c3QgdXNlIHRoZSBzYW1l IGtleS4gIFRoaXMgbWVhbnMgdGhhdCBhbnkgcmVjaXBpZW50IGNhbiBtYWtlIGEgbW9kaWZpY2F0 aW9uIGFuZCBwcm9kdWNlIGEgdmFsaWQgTUFDIGZvciB0aGUgbW9kaWZpZWQgb2JqZWN0Lg0KPj4+ DQo+Pj4gV2l0aCBhIGRpZ2l0YWwgc2lnbmF0dXJlLCB0aGUgc2VuZGVyIHVzZXMgYSBwcml2YXRl IGtleSwgYW5kIHRoZSByZWNpcGllbnRzIHVzZSBhIHB1YmxpYyBrZXksIHNvIHRoZSByZWNpcGll bnRzIGNhbm5vdCBwcm9kdWNlIG1vZGlmaWVkIG9iamVjdHMuDQo+Pj4NCj4+PiBXaHkgYWNjZXB0 IHRoaXMgcG9zc2liaWxpdHk/DQo+Pj4NCj4+PiBSdXNzDQo+Pj4NCj4+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IFN1aXQgbWFpbGluZyBsaXN0 DQo+Pj4gU3VpdEBpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc3VpdA0KPj4NCj4+IElNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlz IGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28g YmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhl IGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9y IHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4N Cj4NCg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFu eSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2Vk LiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8g YW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29w eSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K From nobody Tue Jun 5 05:30:08 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC84130FFB for ; Tue, 5 Jun 2018 05:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-gfssmgYJ78 for ; Tue, 5 Jun 2018 05:30:05 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D677130FEA for ; Tue, 5 Jun 2018 05:30:04 -0700 (PDT) Received: from Jude (216.53.143.123) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 5 Jun 2018 05:27:08 -0700 From: Jim Schaad To: 'Brendan Moran' , 'Russ Housley' CC: References: <238EC1AC-D898-472D-A951-2AD1438C6004@vigilsec.com> <168ED9F9-15CF-457B-850A-77196D423D08@arm.com> In-Reply-To: <168ED9F9-15CF-457B-850A-77196D423D08@arm.com> Date: Tue, 5 Jun 2018 08:29:44 -0400 Message-ID: <00a301d3fcc8$ea4733f0$bed59bd0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQH+/tRipfR+pENBpwPC3qGeuzNlEwIPaeyEo+sYIPA= Content-Language: en-us X-Originating-IP: [216.53.143.123] Archived-At: Subject: Re: [Suit] COSE_Sign vs. COSE_Mac X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 12:30:08 -0000 I would assume that the key management can be localized to the installation That is the file can be signed from the manufacturer to the company and then the PSK work can be done inside of the company. Strip the COSE_Sign and switch to COSE_Mac. Given that one could have run a one time protocol to derive the update PSK, I don't see that this is going to give a significant loss of security. The main issue is that one would need to scope the use of PSKs to a small area with the SUIT manager doing the PSK computation Jim > -----Original Message----- > From: Suit On Behalf Of Brendan Moran > Sent: Monday, June 4, 2018 11:24 AM > To: Russ Housley > Cc: suit@ietf.org > Subject: Re: [Suit] COSE_Sign vs. COSE_Mac > > This is a solution that is intended to address a segment of devices that cannot > use public-key due to code size or processing overhead, and cannot use > hash-based signatures due to data overhead. Provided that every device has > a unique PSK, COSE_Mac provides adequate security. However, it introduces > significant key management overhead. > > Thanks, > Brendan > > > On 4 Jun 2018, at 16:16, Russ Housley wrote: > > > > I am struggling to see a case where COSE_Mac provides acceptable > protection. With a MAC, the sender and the recipient must use the same > key. This means that any recipient can make a modification and produce a > valid MAC for the modified object. > > > > With a digital signature, the sender uses a private key, and the recipients > use a public key, so the recipients cannot produce modified objects. > > > > Why accept this possibility? > > > > Russ > > > > _______________________________________________ > > Suit mailing list > > Suit@ietf.org > > https://www.ietf.org/mailman/listinfo/suit > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended recipient, > please notify the sender immediately and do not disclose the contents to any > other person, use it for any purpose, or store or copy the information in any > medium. Thank you. > > _______________________________________________ > Suit mailing list > Suit@ietf.org > https://www.ietf.org/mailman/listinfo/suit From nobody Tue Jun 5 05:41:44 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70A09131070 for ; Tue, 5 Jun 2018 05:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDlQRf4afPsN for ; Tue, 5 Jun 2018 05:41:21 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B041131058 for ; Tue, 5 Jun 2018 05:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w55CfIfi018758 for ; Tue, 5 Jun 2018 14:41:18 +0200 (CEST) Received: from [172.27.29.110] (unknown [195.37.142.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 410WdB3GGpzDX8v; Tue, 5 Jun 2018 14:41:18 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Carsten Bormann In-Reply-To: <152811062665.20908.9231697583091629075@ietfa.amsl.com> Date: Tue, 5 Jun 2018 14:41:13 +0200 X-Mao-Original-Outgoing-Id: 549895271.49439-ba4f85ab9f61906d81ddcf7776a8747c Content-Transfer-Encoding: quoted-printable Message-Id: <771CABDA-0BEC-4237-8EC4-F821CB8B577D@tzi.org> References: <152811062665.20908.9231697583091629075@ietfa.amsl.com> To: suit@ietf.org X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: [Suit] draft-ietf-suit-information-model-00.txt X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 12:41:34 -0000 I also read the information model draft. The lead-in up to 3.4 (included) is actually already quite good. In 3.5, the air gets a bit thin =E2=80=94 these are less about = requirements than about justifications for some design decisions. Unfortunately, the justifications are not all holding water. 4 is a very weird information model. Why is a manifest a list of = =E2=80=9Cfields=E2=80=9D? Some of the fields reference each other =E2=80=94 wouldn=E2=80=99t using = a tree structure be a better representation of the underlying = abstractions (and also be easier to process, as it maps directly into a = data model)? I have no idea from the text what a =E2=80=9CPrecursor Image Digest = Condition=E2=80=9D could be. =E2=80=9CDigests=E2=80=9D is a map =E2=80=94 what are the map keys? Can=E2=80=99t even parse 4.14. The whole thing needs to be based more on *types*. =20 Types can avoid the repetition between 4.3 and 4.4. They also are needed to be sure what exactly is *in* a field. (If you think types is more of a data model term, you can think *terms* = instead.) Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jun 5 12:06:28 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6B6E1292F1 for ; Tue, 5 Jun 2018 12:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IiLNmOAIPL9X for ; Tue, 5 Jun 2018 12:06:23 -0700 (PDT) Received: from GCC01-DM2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0125.outbound.protection.outlook.com [23.103.201.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B1631292AD for ; Tue, 5 Jun 2018 12:06:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qz28vMBCvhUin9WfQQO2qGaz9D7OOVGOx6hQGj1qzgo=; b=PPKfKcmQNBPKRqGzLPkcgKfrUlDCIiYfiUVQmAxgUoIuOoYYGSAYqCVJJZzOhSUTZ3NoSM+mAyk1kkZEl4Uf0LjWEwOX0gD2DseIUEl0N6iHaeqaNcjR86vpP6u8PoeFp6fGGkZYurluUYJZ1jNvX+UsE/5tCeL1zx9Lc9XLGm4= Received: from BL0PR0901MB2306.namprd09.prod.outlook.com (52.132.18.148) by BL0PR0901MB2307.namprd09.prod.outlook.com (52.132.18.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.841.13; Tue, 5 Jun 2018 19:06:22 +0000 Received: from BL0PR0901MB2306.namprd09.prod.outlook.com ([fe80::7411:7883:79be:f22c]) by BL0PR0901MB2306.namprd09.prod.outlook.com ([fe80::7411:7883:79be:f22c%5]) with mapi id 15.20.0841.011; Tue, 5 Jun 2018 19:06:21 +0000 From: "Waltermire, David A. (Fed)" To: "suit@ietf.org" Thread-Topic: IETF SUIT WG Virtual Interim Meeting Thread-Index: AdP8/5ixldh0q3PtSp6NxJyOVUnTCw== Date: Tue, 5 Jun 2018 19:06:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [129.6.224.58] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL0PR0901MB2307; 7:OIjDDvJnUfklhquLy51hgMUdnEh+N1ZOpqT/5570HY/lF9GieNVM5kKWH4wxF/qrornz7ILLfWENrkXsk9Csg3Q0/NEJzw4U8LL2lruldflineC/NSeZNeIz5GG/1WDxxfmK8N5y48OYITk17tIJtcpmOwoGe8vZ4DisZwJ0DKr4J9cdfQmuxDi1Bc2cgcTRN/Fmy7gUSNmBytoAg9A7TZrX3flbkiRlXZOBzv1bTAxuCsgy64T1mc+5XbgyIvcY x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BL0PR0901MB2307; x-ms-traffictypediagnostic: BL0PR0901MB2307: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(94707916325470); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:BL0PR0901MB2307; BCL:0; PCL:0; RULEID:; SRVR:BL0PR0901MB2307; x-forefront-prvs: 0694C54398 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(396003)(39380400002)(366004)(376002)(39860400002)(53434003)(189003)(199004)(2501003)(6916009)(316002)(59450400001)(14454004)(5250100002)(86362001)(7696005)(99286004)(486006)(7736002)(2351001)(2906002)(106356001)(105586002)(16799955002)(33656002)(5640700003)(6506007)(97736004)(6436002)(478600001)(55016002)(53936002)(6306002)(305945005)(9686003)(2900100001)(66066001)(8936002)(5660300001)(1730700003)(102836004)(74316002)(186003)(68736007)(3846002)(551544002)(6116002)(25786009)(81156014)(26005)(966005)(3280700002)(476003)(3660700001)(81166006)(114624004)(8676002)(217873001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR0901MB2307; H:BL0PR0901MB2306.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) x-microsoft-antispam-message-info: ho67+4zmmqaXXvxverox14rctVrUyPZ/RCU8aGnMk+0DOQEDl8AKJGjXmCyoUNM+5cEur1UcFINYYjBF+BDUwXdrSpWhBA/EBftyeRCUkxvGSKaOOcrh6U3mBPoRdXuLqWNRpmN19kofeRD/2R/PHkV3EPeJlDkwRPYDZn1Scm6fN0+k6xIt9t31Z61Riuau spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 256cd9fa-8eaa-4cdf-ba83-08d5cb176d37 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 256cd9fa-8eaa-4cdf-ba83-08d5cb176d37 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2018 19:06:21.7136 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR0901MB2307 Archived-At: Subject: [Suit] IETF SUIT WG Virtual Interim Meeting X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 19:06:27 -0000 Just a reminder, we will be having a SUIT WG Virtual Interim meeting on Wed= nesday this week. Here are the Webex details: SUIT WG Virtual Interim Meeting Wednesday, June 6, 2018 10:00 am Eastern Daylight Time (GMT-04:00) | 1 hour https://ietf.webex.com/ietf/j.php?MTID=3Dmf4fb7c7ba8779017f344346b7bcab5a3 Meeting number (access code): 319 828 258 Meeting password: xuZpJVc3 Telephone: +1 650-479-3208 Regards, Dave From nobody Tue Jun 5 12:14:35 2018 Return-Path: X-Original-To: suit@ietf.org Delivered-To: suit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 143F8130DC7 for ; Tue, 5 Jun 2018 12:14:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152822607307.19148.11518657174195114736.idtracker@ietfa.amsl.com> Date: Tue, 05 Jun 2018 12:14:33 -0700 From: IETF Secretariat Archived-At: Subject: [Suit] Milestones changed for suit WG X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 19:14:34 -0000 Changed milestone "Adopt "Architecture" document as WG item.", resolved as "Done". Changed milestone "Adopt a manifest information model as a WG item.", resolved as "Done". Changed milestone "Calendar item: First interoperability event at IETF 101.", resolved as "Done". URL: https://datatracker.ietf.org/wg/suit/about/ From nobody Wed Jun 6 02:27:41 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA85D130EDB for ; Wed, 6 Jun 2018 02:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6yE-3FN_6u0z for ; Wed, 6 Jun 2018 02:27:31 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0079.outbound.protection.outlook.com [104.47.0.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A172130ED7 for ; Wed, 6 Jun 2018 02:27:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WUKLpm5tmTdhbjG9dz6wnoWAdN2YAQDrqIWw/AdZKnA=; b=YKNjLh1lDAuEkhnV7LY51ZDC+y/X1mYHF73zVwh8rKoF0BukqjO5VX5nzmhMaN1sB/FsokI19NwW3NTcQWvIPWaIQcMmM1RCevkXf2RNvKMT3RC91MxuYbWyYvz7gju/ZCL9rBWyHN3gX9sWi6NLoGuXx8yv0cuDWu/0+1vm5SQ= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1744.eurprd08.prod.outlook.com (10.168.67.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.820.14; Wed, 6 Jun 2018 09:27:28 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35%4]) with mapi id 15.20.0820.015; Wed, 6 Jun 2018 09:27:28 +0000 From: Hannes Tschofenig To: "suit@ietf.org" Thread-Topic: SUIT Architecture -- Operating modes Thread-Index: AdP9eHteSzrUiKgdQTO0D4Kr/wumzQ== Date: Wed, 6 Jun 2018 09:27:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [195.37.142.77] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1744; 7:5vnPcw0XnFv6WHlDEenxL6w7NkByKS3vonjdbtY9p9J/qXbeqtienmApBHRqDb3+37sbDGpJXbLa09qEEN2YAZqIgDgWa8uSOk9DVAaCtDzLLVZmwBVnnz4sJ4pvdsbbj37MUu6b8P0pwJqhQN2hyy+fmqVF5NL/YF3SwjSSAdD35RA1gGGBsjAsMcCE2QL0b9YdmdjOS6SnKfKi8oR/xAFxaaQsuQjjgM2UY8voP4Biby6q44ozC7bILfuNn+KI x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1744; x-ms-traffictypediagnostic: VI1PR0801MB1744: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB1744; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1744; x-forefront-prvs: 06952FC175 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(346002)(39380400002)(376002)(39860400002)(53754006)(189003)(199004)(40434004)(3846002)(53936002)(26005)(99286004)(25786009)(6506007)(2900100001)(486006)(7696005)(5250100002)(6916009)(476003)(105586002)(86362001)(5660300001)(5890100001)(102836004)(186003)(106356001)(59450400001)(2501003)(6306002)(14454004)(9686003)(8936002)(33656002)(55016002)(72206003)(561944003)(6436002)(5640700003)(2906002)(74316002)(2351001)(966005)(7736002)(3280700002)(8676002)(68736007)(66066001)(305945005)(3660700001)(97736004)(478600001)(6116002)(1730700003)(81156014)(81166006)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1744; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: NsiIPoYTyuFaEDy19yw9kFycB5klil56iNapHwoauUsQZwaiU4rjeOaZAVr/Hm9pKvBcXv5K+wg2l0H0wYB9IbqNeQ99N1v6iEkRIuKjrlmYD4ZwhsdRpwjTGd8bxN5cWfV3pPr1MzGjAhZc9ZjHYUKkMs+im2DsYV206T/A2E9y6Xuc/hw9Wjl1kszxkksf spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 696f433b-59f1-4bee-60ff-08d5cb8fb8c1 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 696f433b-59f1-4bee-60ff-08d5cb8fb8c1 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jun 2018 09:27:28.2142 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1744 Archived-At: Subject: [Suit] SUIT Architecture -- Operating modes X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 09:27:38 -0000 Hi all, at the virtual interim meeting earlier this year Dave suggested terminology= , which was based on ITU-T work for firmware updates: - Device Core: stores/uses software/firmware, i.e., the IoT device itself - Communicator: checks software/firmware status of device and initiates update as needed May or may not be on the device itself - Status Tracker: tracks update status of devices under its administration - Firmware Server: distributes software/firmware packages to devices May or may not be combined with Status Tracker At IETF#101 we talked about the following three categories for firmware upd= ate interactions: - Client-initiated: IoT device polls for updates and downloads image when i= t wants - Server-initiated: Server pushes update to a device - Hybrid: Server pushes notification of availability of an update to a devi= ce, and the client then downloads the image when it wants. In https://tools.ietf.org/html/draft-ietf-suit-architecture-00 Brendan and = I made a proposal for a new terminology. Here is the relevant text: ----- 3.10. Operating modes There are three broad classifications of update operating modes. * Self initiated * Third-party initiated * Hybrid Self initiated updates take the form of a proactive IoT device that checks for updates. Third-party initiated updates are triggered by an actor other than the IoT device, be it a server, a peer, or a user. Hybrid updates are those that require agreement from both the target IoT device and another actor. Third-party initiated updates are important to consider because timing of updates may need to be tightly controlled in some high- reliability environments. An IoT device goes through several steps in the course of an update, each of which can be self-initiated or third-party initiated, or hybrid. An IoT device may go through the following steps, though this is not a comprehensive list. * Notification * Pre-authorisation * Dependency resolution * Download * Installation The notification step consists informing an IoT device that an update is available. This can be accomplished via polling (self-initiated), push notifications (third-party initiated), or more complex mechanisms. The pre-authorisation step involves verifying the update authority and making a determination that the device is prepared to initiate the fetching and processing of updates. If the device has all information that is necessary to make this determination, then the pre-authorisation may be self-initiated. However, the device can wait for instruction to begin (third-party initiated). Hybrid approaches are possible as well. A dependency resolution phase is needed when more than one component can be updated or when a differential update is used. The necessary dependencies must be available prior to installation. The download step is the process of acquiring a local copy of the payload. When the download is self-initiated, this means that the IoT device chooses when a download occurs and initiates the download process. When a download is third-party initiated, this means that either the remote service tells the IoT device when to download or that it initiates the transfer directly to the IoT device. For example, a download from an HTTP server is initiated locally. A transfer to a LwM2M Firmware Update resource [LwM2M] is initiated remotely. Installation is the act of processing the payload into a format that the IoT device can recognise. Each of these steps may require different permissions expressed in claims and may be implemented in a variety of ways. ---- Offline feedback from Dave indicates that it did not help improve clarify. Hence, I am going it a new try. Let me know what you think. ----- 3.10. Operating modes There are three broad classifications of update operating modes. * Client-initiated Update * Server-initiated Update * Hybrid Update Client-initiated updates take the form of a Communicator on a Device Core proactively checking for new firmware imagines provided by Firmware Serve= rs. Server-initiated updates are important to consider because timing of updates may need to be tightly controlled in some high- reliability environments. In this case the Communicator, potentially in coordination with the Status Tracker, determines what IoT devices need qualify for a firmware update. Once those devices have been selected the Firmware Server distributes updates to those Device Cores. Note: This assumes that the Firmware Server is able to reach the Device C= ores, which may require Device Cores to keep reachability information at the Co= mmunicator and / or at the Firmware Server up-to-date. This may also require keeping= state at NATs and stateful packet filtering firewalls alive. Hybrid updates are those that require an interaction between the Device C= ore and the Firmware Server / Communicator. The Communicator pushes notificat= ions of availability of an update to the Device Core, and the Device Core then downloads the image from the Firmware Server when it wants. An alternative approach is to consider the steps an IoT device has to go= through in the course of an update: * Notification * Pre-authorisation * Dependency resolution * Download * Installation The notification step consists of the Communicator informing the Device = Core that an update is available. This can be accomplished via polling (clien= t-initiated), push notifications (server-initiated), or more complex mechanisms. The pre-authorisation step involves verifying whether the entity signing the manifest is indeed authorized to perform an update. The Device Core must also determine whether it should fetching and processing of the firmware image (unless it has been attached already to the manifest itse= lf). A dependency resolution phase is needed when more than one component can be updated or when a differential update is used. The necessary dependencies must be available prior to installation. The download step is the process of acquiring a local copy of the firmware image. When the download is client-initiated, this means that = the IoT device chooses when a download occurs and initiates the download process. When a download is server-party initiated, this means that either the Communicator / Firmware Server tells the IoT device when to download or that it initiates the transfer directly to the IoT device= . For example, a download from an HTTP-based Firmware Server is client-ini= tiated. A transfer to a LwM2M Firmware Update resource [LwM2M] is server-initiat= ed. If the Device Core has downloaded a new firmware image and is ready to install it it may need to wait for a trigger from a Communicator to install the firmware update, may trigger the update automatically, or may go through a more complex decision making process to determine the appropriate timing for an update (such as delaying the update process to a later time when end users are less impacted by the update p= rocess). Installation is the act of processing the payload into a format that the IoT device can recognise and the bootloader is responsible for then booting from the newly installed firmware image. Each of these steps may require different permissions. ---- Is this any better? Writing the text above I noticed that the Communicator and the Status Tracker have some overlapping functionality. Both entities need to know about the status of the device. Also it would be good to know what "initiates update" for the communicator actually needs. Finally, the term "Device Core" sounds a bit strange. Would it be better to call it 'update service' or just refer to IoT device? Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Wed Jun 6 02:36:41 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45CC4130EE8 for ; Wed, 6 Jun 2018 02:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylBQJo8cukTZ for ; Wed, 6 Jun 2018 02:36:29 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0727.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe45::727]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86060130E76 for ; Wed, 6 Jun 2018 02:36:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=i5njf2IDmLfSb9G6PhhE44oJXdOdQC6poGgrIubqrus=; b=eajNn9AF6ochOULVBIt1+BbADuJrwJApjt9LJSiHCGW77brT0NAFEV6ffwsnnN1ptbVlUcTMhwEvt8bIuOD1R218Ib4eDUdck+fz1oHEnctS3A2CJAkqCcKy69/U2+m6dc3ubR8LHfv2UF2qpwiI/cIUBYJsH5kRn7lZZ12OY5s= Received: from CY4PR21MB0774.namprd21.prod.outlook.com (10.173.192.20) by CY4PR21MB0774.namprd21.prod.outlook.com (10.173.192.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.841.7; Wed, 6 Jun 2018 09:36:27 +0000 Received: from CY4PR21MB0774.namprd21.prod.outlook.com ([fe80::3519:5771:4c24:b065]) by CY4PR21MB0774.namprd21.prod.outlook.com ([fe80::3519:5771:4c24:b065%9]) with mapi id 15.20.0841.011; Wed, 6 Jun 2018 09:36:27 +0000 From: Dave Thaler To: Hannes Tschofenig , "suit@ietf.org" Thread-Topic: SUIT Architecture -- Operating modes Thread-Index: AdP9eHteSzrUiKgdQTO0D4Kr/wumzQAAL6IA Date: Wed, 6 Jun 2018 09:36:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=dthaler@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-06-06T09:36:27.4504174Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [203.69.98.253] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0774; 7:4nYWpMxgB14uVENh5LPr7VaYte/w46Se6vYcHvCNwPyPJ126BK+q6IRSI3wXkAJSRFWnlznVPNURiS6MIa2DgUjNNE2UFEIXzjVLNxpw2VSJ2Se9nQvz2ADyfQd4FkiUeVtLlJcHdCVZozbBH+6N5gYWLALIqVmNXyR06Mn3UojfSR8tp0/reqGgsVPDn+W975ehpBM49Iy1LB6zA1qUWYynapnpHIdONImt/oTfKCt/BKXpsAu3tkM7EN0wAKX+ x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:CY4PR21MB0774; x-ms-traffictypediagnostic: CY4PR21MB0774: authentication-results: spf=none (sender IP is ) smtp.mailfrom=dthaler@microsoft.com; x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(189930954265078)(219752817060721); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231254)(2018427008)(944501410)(52105095)(3002001)(10201501046)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123564045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:CY4PR21MB0774; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0774; x-forefront-prvs: 06952FC175 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39860400002)(346002)(39380400002)(396003)(366004)(189003)(199004)(13464003)(40434004)(53754006)(561944003)(6436002)(3280700002)(5250100002)(446003)(53546011)(6506007)(316002)(59450400001)(476003)(11346002)(110136005)(7736002)(66066001)(76176011)(68736007)(305945005)(2900100001)(6306002)(5660300001)(2501003)(102836004)(8676002)(86362001)(5890100001)(97736004)(6246003)(14454004)(486006)(186003)(26005)(25786009)(53936002)(99286004)(10290500003)(81156014)(229853002)(966005)(9686003)(8936002)(10090500001)(575784001)(3660700001)(7696005)(8990500004)(478600001)(33656002)(22452003)(74316002)(6116002)(55016002)(105586002)(2906002)(81166006)(106356001)(86612001)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0774; H:CY4PR21MB0774.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: L0bmtTl61ibMl/XcyEBwMP6wis7sZ6P84g9otcWcecFuPh9gLWOMl7l9cTiacDm00RXB7vXJwJ3Jax97b992WFQEcCvwRgf5n/dSyKaWBtoCJSprTC0B5shg7xkB2s73hrI3LCS0Zvpn1ieejiwg08FZUb08BiTcs39j+iSfySYlwQcK4gwP9hy1B9JF8JWn spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 4c8a5943-48d5-4221-884d-08d5cb90fa60 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4c8a5943-48d5-4221-884d-08d5cb90fa60 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jun 2018 09:36:27.7401 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0774 Archived-At: Subject: Re: [Suit] SUIT Architecture -- Operating modes X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 09:36:38 -0000 A short version of my feedback can be summarized as: > When a download is third-party initiated, this means that > either the remote service tells the IoT device when to download or > that it initiates the transfer directly to the IoT device. =20 I find it very confusing to convolute these different concepts into the sam= e term "third-party initiated", and especially to have the step be "download" even when it is transferred d= irectly rather than initiated by the device. That's why I liked the taxonomy presented at IETF 101 which I found to be f= ar more clear. The notification of an update can be device initiated (pull) or remotely in= itiated (push). The transfer of the actual image can also be device initiated (pull) or rem= otely initiated (push). The three cases are (I think the other combination doesn't make sense): 1) Push notification, push image 2) Push notification, pull image 3) Pull notification, pull image I find the text in the document now confusing and doesn't match the IETF 10= 1 discussion. Dave -----Original Message----- From: Suit On Behalf Of Hannes Tschofenig Sent: Wednesday, June 6, 2018 5:27 PM To: suit@ietf.org Subject: [Suit] SUIT Architecture -- Operating modes Hi all, at the virtual interim meeting earlier this year Dave suggested terminology= , which was based on ITU-T work for firmware updates: - Device Core: stores/uses software/firmware, i.e., the IoT device itself - Communicator: checks software/firmware status of device and initiates upd= ate as needed May or may not be on the device itself - Status Tracker: tracks update status of devices under its administration - Firmware Server: distributes software/firmware packages to devices May or may not be combined with Status Tracker At IETF#101 we talked about the following three categories for firmware upd= ate interactions: - Client-initiated: IoT device polls for updates and downloads image when i= t wants - Server-initiated: Server pushes update to a device - Hybrid: Server pushes notification of availability of an update to a devi= ce, and the client then downloads the image when it wants. In https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools= .ietf.org%2Fhtml%2Fdraft-ietf-suit-architecture-00&data=3D02%7C01%7Cdthaler= %40microsoft.com%7Cfdbcbf2e3be442dc544208d5cb8fc354%7C72f988bf86f141af91ab2= d7cd011db47%7C1%7C1%7C636638740682287207&sdata=3DZ8JJlDZINiolbZmqINLWCMEaWT= 1%2BcUkAGQpBqfhjvCw%3D&reserved=3D0 Brendan and I made a proposal for a new= terminology. Here is the relevant text: ----- 3.10. Operating modes There are three broad classifications of update operating modes. * Self initiated * Third-party initiated * Hybrid Self initiated updates take the form of a proactive IoT device that checks for updates. Third-party initiated updates are triggered by an actor other than the IoT device, be it a server, a peer, or a user. Hybrid updates are those that require agreement from both the target IoT device and another actor. Third-party initiated updates are important to consider because timing of updates may need to be tightly controlled in some high- reliability environments. An IoT device goes through several steps in the course of an update, each of which can be self-initiated or third-party initiated, or hybrid. An IoT device may go through the following steps, though this is not a comprehensive list. * Notification * Pre-authorisation * Dependency resolution * Download * Installation The notification step consists informing an IoT device that an update is available. This can be accomplished via polling (self-initiated), push notifications (third-party initiated), or more complex mechanisms. The pre-authorisation step involves verifying the update authority and making a determination that the device is prepared to initiate the fetching and processing of updates. If the device has all information that is necessary to make this determination, then the pre-authorisation may be self-initiated. However, the device can wait for instruction to begin (third-party initiated). Hybrid approaches are possible as well. A dependency resolution phase is needed when more than one component can be updated or when a differential update is used. The necessary dependencies must be available prior to installation. The download step is the process of acquiring a local copy of the payload. When the download is self-initiated, this means that the IoT device chooses when a download occurs and initiates the download process. When a download is third-party initiated, this means that either the remote service tells the IoT device when to download or that it initiates the transfer directly to the IoT device. For example, a download from an HTTP server is initiated locally. A transfer to a LwM2M Firmware Update resource [LwM2M] is initiated remotely. Installation is the act of processing the payload into a format that the IoT device can recognise. Each of these steps may require different permissions expressed in claims and may be implemented in a variety of ways. ---- Offline feedback from Dave indicates that it did not help improve clarify. Hence, I am going it a new try. Let me know what you think. ----- 3.10. Operating modes There are three broad classifications of update operating modes. * Client-initiated Update * Server-initiated Update * Hybrid Update Client-initiated updates take the form of a Communicator on a Device Core proactively checking for new firmware imagines provided by Firmware Serve= rs. Server-initiated updates are important to consider because timing of updates may need to be tightly controlled in some high- reliability environments. In this case the Communicator, potentially in coordination with the Status Tracker, determines what IoT devices need qualify for a firmware update. Once those devices have been selected the Firmware Server distributes updates to those Device Cores. Note: This assumes that the Firmware Server is able to reach the Device C= ores, which may require Device Cores to keep reachability information at the Co= mmunicator and / or at the Firmware Server up-to-date. This may also require keeping= state at NATs and stateful packet filtering firewalls alive. Hybrid updates are those that require an interaction between the Device C= ore and the Firmware Server / Communicator. The Communicator pushes notificat= ions of availability of an update to the Device Core, and the Device Core then downloads the image from the Firmware Server when it wants. An alternative approach is to consider the steps an IoT device has to go= through in the course of an update: * Notification * Pre-authorisation * Dependency resolution * Download * Installation The notification step consists of the Communicator informing the Device = Core that an update is available. This can be accomplished via polling (clien= t-initiated), push notifications (server-initiated), or more complex mechanisms. The pre-authorisation step involves verifying whether the entity signing the manifest is indeed authorized to perform an update. The Device Core must also determine whether it should fetching and processing of the firmware image (unless it has been attached already to the manifest itse= lf). A dependency resolution phase is needed when more than one component can be updated or when a differential update is used. The necessary dependencies must be available prior to installation. The download step is the process of acquiring a local copy of the firmware image. When the download is client-initiated, this means that = the IoT device chooses when a download occurs and initiates the download process. When a download is server-party initiated, this means that either the Communicator / Firmware Server tells the IoT device when to download or that it initiates the transfer directly to the IoT device= . For example, a download from an HTTP-based Firmware Server is client-ini= tiated. A transfer to a LwM2M Firmware Update resource [LwM2M] is server-initiat= ed. If the Device Core has downloaded a new firmware image and is ready to install it it may need to wait for a trigger from a Communicator to install the firmware update, may trigger the update automatically, or may go through a more complex decision making process to determine the appropriate timing for an update (such as delaying the update process to a later time when end users are less impacted by the update p= rocess). Installation is the act of processing the payload into a format that the IoT device can recognise and the bootloader is responsible for then booting from the newly installed firmware image. Each of these steps may require different permissions. ---- Is this any better? Writing the text above I noticed that the Communicator and the Status Track= er have some overlapping functionality. Both entities need to know about th= e status of the device. Also it would be good to know what "initiates updat= e" for the communicator actually needs. Finally, the term "Device Core" sounds a bit strange. Would it be better to= call it 'update service' or just refer to IoT device? Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. _______________________________________________ Suit mailing list Suit@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf= .org%2Fmailman%2Flistinfo%2Fsuit&data=3D02%7C01%7Cdthaler%40microsoft.com%7= Cfdbcbf2e3be442dc544208d5cb8fc354%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C= 1%7C636638740682287207&sdata=3DW0Ak6fX0oHbALgg5XxU0YiN9z%2Ber18j7sUJbjfbqow= 8%3D&reserved=3D0 From nobody Wed Jun 6 02:49:12 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8835E130ED0 for ; Wed, 6 Jun 2018 02:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6s_njilGlmQ4 for ; Wed, 6 Jun 2018 02:49:03 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0077.outbound.protection.outlook.com [104.47.1.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37F9E130EDB for ; Wed, 6 Jun 2018 02:49:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rcwfaiVNrNKt8yeZg12eL0qlnJWuHm4jqlOpDJ9T0TA=; b=bXRdB3ty5tT4JP0xp+dC+aPndlnBcqYYh1LojA2RVtFABhGrXfSmtCbNlwq9Un4nmNiT/ABkTuT6imsoaKd/ffxKsRuIO/rtZTZoZksL8WzPUgpn7ebN5r4QrqEESfGROFj2Bg4bDbJqs3plZTBiWVwsRkNM8G5RWQmVtb74Wb8= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB2093.eurprd08.prod.outlook.com (10.173.75.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.841.13; Wed, 6 Jun 2018 09:49:00 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35%4]) with mapi id 15.20.0820.015; Wed, 6 Jun 2018 09:49:00 +0000 From: Hannes Tschofenig To: Carsten Bormann , "suit@ietf.org" Thread-Topic: [Suit] draft-ietf-suit-architecture-00.txt Thread-Index: AQHT/LAS5zNT24RkpUuxISKjf7a3EqRS+28w Date: Wed, 6 Jun 2018 09:49:00 +0000 Message-ID: References: <152808358455.20892.2040053845976676560@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [195.37.142.77] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB2093; 7:7CxNHeoahITQwUDd9O9eVvwUYXD96Rxn7+hgd3Rq10n55hijBHdxyVinf9kWH+sq2fG2BQilo8oxVMx6KBbDphy5x7VPvzEF1h9fSoU1SKISWesPLjySsM5JCwVVBzNO7TQovJODQfCPhi7hfy5BhXTNgN8Ihcpa0EUDx3jBJXwo8uqWoOvhDVMEfNZJKgvWq29iH+VHmhp6HO9mOfEdbIOiXadUa4QqeDyo6Cd8YKbf0e/hm6+d0mUvRdCEZSaO x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB2093; x-ms-traffictypediagnostic: VI1PR0801MB2093: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB2093; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB2093; x-forefront-prvs: 06952FC175 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(39860400002)(346002)(39380400002)(366004)(13464003)(199004)(189003)(40434004)(105586002)(3280700002)(14454004)(446003)(72206003)(966005)(486006)(2906002)(97736004)(99286004)(81156014)(81166006)(478600001)(8676002)(3660700001)(186003)(305945005)(86362001)(9686003)(11346002)(229853002)(68736007)(561944003)(76176011)(7736002)(476003)(7696005)(53936002)(55016002)(33656002)(6436002)(102836004)(2501003)(66066001)(53546011)(5250100002)(59450400001)(2900100001)(6306002)(316002)(6246003)(5890100001)(25786009)(26005)(3846002)(74316002)(6116002)(106356001)(8936002)(110136005)(6506007)(5660300001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB2093; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: AuQzDEr0dRfQoYMbnvwOW3WZoL5D4AXMbqI9+3EqXhfc1v3bW+aLtAAOVPSSqe+2WECAzKvVMyqNK/1c+2a053HWJDCI/EdON0p9jnMcwNnFkqc89x7KFVKeJGcBdnUqb8o27ZX6pFRNnPiwwOSESnI62h8+E7HEm/UJoWTMT84WwLMVx+REfr2tzP+3YTbV spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 767d3b90-cc24-4f00-d2e5-08d5cb92bac6 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 767d3b90-cc24-4f00-d2e5-08d5cb92bac6 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jun 2018 09:49:00.0642 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB2093 Archived-At: Subject: Re: [Suit] draft-ietf-suit-architecture-00.txt X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 09:49:10 -0000 SGkgQ2Fyc3RlbiwNCg0KIEEgZmV3IHJlbWFya3MgYmVsb3c6DQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBTdWl0IFttYWlsdG86c3VpdC1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgQ2Fyc3RlbiBCb3JtYW5uDQpTZW50OiAwNSBKdW5lIDIwMTggMTE6MzINClRvOiBz dWl0QGlldGYub3JnDQpTdWJqZWN0OiBbU3VpdF0gZHJhZnQtaWV0Zi1zdWl0LWFyY2hpdGVjdHVy ZS0wMC50eHQNCg0KSSBoYWQgYSBxdWljayBsb29rIGF0IHRoaXMgd2hpbGUgcHJlcGFyaW5nIGZv ciB0aGUgSW50ZXJvcC4NCg0KU3VtbWFyeTogbmVlZHMgd29yay4NCg0KVGhlIHNlY3Rpb25zIGFy ZSByYXRoZXIgaW5ob21vZ2VuZW91cy4gIFRoZSBpbnRyb2R1Y3Rpb24gc2VlbXMgdG8gYmVsaWV2 ZSB0aGlzIGlzIGFsbCBhYm91dCBhdXRoZW50aWNhdGlvbiwgd2hpbGUgU2VjdGlvbiAzLjkgb253 YXJkcyBhbmQgNCBzZWVtIHRvIGtub3cgdGhhdCB0aGlzIGlzIHJlYWxseSBhbGwgYWJvdXQgYXV0 aG9yaXphdGlvbi4gIFRoZSBpbnRyb2R1Y3Rpb24gY2xhaW1zIHRvIGJlIGRvbmUgd2l0aCBqdXN0 IHRocmVlIHBsYXllcnMsIHdoaWxlIGl0IGxhdGVyIGJlY29tZXMgY2xlYXIgdGhlcmUgYXJlIHNv IG1hbnkgbW9yZS4gZXRjLiAgV2UgcHJvYmFibHkgbmVlZCB0byBtYWtlIHVwIG91ciBtaW5kcyB3 aGljaCBvZiB0aGVzZSBhcmUgcGFydCBvZiB0aGUg4oCcYXJjaGl0ZWN0dXJl4oCdIGFuZCB3aGlj aCBvbmVzIGFyZSBqdXN0IGVuYWJsZWQgYnkgdGhlIGFyY2hpdGVjdHVyZSAod2hpY2ggbWF5IG5v dCBuZWVkIHRvIGRlc2NyaWJlIGV2ZXJ5IHNpbmdsZSBzdGVwIG9mIHZhbGlkYXRpbmcgYW4gYXV0 aG9yaXphdGlvbikuDQoNCltIYW5uZXNdIFRoZSBpbnRyb2R1Y3Rpb24gaXMgdmVyeSBzaG9ydCBh bmQgb25seSBmb2N1c2VzIG9uIHRoZSBtYWluIGFzcGVjdHMgdG8gYXZvaWQgdG9vIG11Y2ggcmVw ZXRpdGlvbi4gSSBhZGRlZCBhbiBpdGVtIGFib3V0IGF1dGhvcml6YXRpb24gdG8gdGhlIGJ1bGxl dCBsaXN0LiBIZXJlIGlzIHRoZSBuZXcgdGV4dDoNCi0tLS0NClRoZSBmaXJtd2FyZSB1cGRhdGUg cHJvY2VzcyBoYXMgdG8gZW5zdXJlIHRoYXQNCg0KLSBUaGUgZmlybXdhcmUgaW1hZ2UgaXMgYXV0 aGVudGljYXRlZCBhbmQgYXR0ZW1wdHMgdG8gZmxhc2ggYSBtYWxpY2lvdXMgZmlybXdhcmUgaW1h Z2UgYXJlIHByZXZlbnRlZC4NCi0gQ2hhbmdlcyB0byBhbiBJb1QgZGV2aWNlLCBhcyBwYXJ0IG9m IHRoZSBmaXJtd2FyZSB1cGRhdGUgcHJvY2VzcywgYXJlIHByb3Blcmx5IGF1dGhvcml6ZWQuDQot IFRoZSBmaXJtd2FyZSBpbWFnZSBjYW4gYmUgY29uZmlkZW50aWFsaXR5IHByb3RlY3RlZCBzbyB0 aGF0IGF0dGVtcHRzIGJ5IGFuIGFkdmVyc2FyeSB0byByZWNvdmVyIHRoZSBwbGFpbnRleHQgYmlu YXJ5IGNhbiBiZSBwcmV2ZW50ZWQuIE9idGFpbmluZyB0aGUgcGxhaW50ZXh0IGJpbmFyeSBpcyBv ZnRlbiBvbmUgb2YgdGhlIGZpcnN0IHN0ZXBzIGZvciBhbiBhdHRhY2sgdG8gbW91bnQgYW4gYXR0 YWNrLg0KLS0tLQ0KDQpUaGUgaW50cm9kdWN0aW9uIHNlY3Rpb24gaXRzZWxmIGRvZXMgbm90IHNh eSBhbnl0aGluZyBhYm91dCB0aGUgaW52b2x2ZWQgZW50aXRpZXMgYnV0IHRoZSB0ZXJtaW5vbG9n eSBsaXN0cyBzb21lIG9mIHRoZW0uIEkgaGF2ZSBqdXN0IHBvc3RlZCBhIG1haWwgYWJvdXQgdGhl IHRlcm1pbm9sb2d5IERhdmUgaGFzIGJlZW4gc3VnZ2VzdGVkLiBIaXMgdGVybWlub2xvZ3kgcHJv cG9zYWwgaW5jbHVkZXMgbW9yZSBlbnRpdGllcy4NCg0KVGhlIHRlcm0g4oCcY2xhaW3igJ0gaXMg aGVhdmlseSBtaXN1c2VkLiAgQSBjbGFpbSBpcyBqdXN0IHRoYXQsIGEgY2xhaW0uICBBbiBpbnN0 cnVjdGlvbiB0byBhIGRldmljZSB0byBkbyBzb21ldGhpbmcgaXMgbm90IGEgY2xhaW0gKGF0IGxl YXN0IG5vdCB3aXRob3V0IHRoZSBpbmZvcm1hdGlvbiB3aGF0IHRoZSBhdWRpZW5jZSBvZiB0aGlz IGluc3RydWN0aW9uIGlzIOKAlCDigJxhbGwgWCBhcmUgaW5zdHJ1Y3RlZCB0b+KApuKAnSBpcyBp bmRlZWQgYSBjbGFpbSkuICBJbiBhbnkgY2FzZSwgY2xhaW1zIChjb250YWluaW5nIGluc3RydWN0 aW9ucyBvciBub3QpIGFsd2F5cyBuZWVkIHRvIGJlIGV2YWx1YXRlZCBpbiB0aGUgYXV0aG9yaXph dGlvbiBmcmFtZXdvcmsgb2YgdGhlIGVudGl0eSB0cnlpbmcgdG8gbWFrZSB1c2Ugb2YgdGhlIGNs YWltLg0KDQpbSGFubmVzXSBBY3R1YWxseSwgd2UgcHV0IHRoaXMgc3Ryb25nZXIgZm9jdXMgb24g Y2xhaW1zIGluIHRoZSBkb2N1bWVudCBiZWNhdXNlIHlvdSBoYXZlIGJlZW4gdXNpbmcgdGhlc2Ug dGVybXMuIFdlIHdpbGwgdHJ5IHRvIHNjYWxlIGRvd24gb24gdGhlIGNsYWltIHVzYWdlIGFnYWlu Lg0KDQpBbm90aGVyIGV4YW1wbGUgb2YgdGhlIHNlZW1pbmcgbmFpdmV0w6kgb2YgdGhlIGludHJv ZHVjdGlvbjogUm9sbGJhY2sgbmVlZHMgdG8gYmUgcHJvcGVybHkgYXV0aG9yaXplZCwgbm90IHN1 bW1hcmlseSBwcmV2ZW50ZWQuDQooTGlrZSBhbnkgb3RoZXIgZmlybXdhcmUgc3RhdGUgY2hhbmdl LCBhLmsuYS4g4oCcdXBncmFkZeKAnS4pDQoNCltIYW5uZXNdIFRoZSByZXF1aXJlbWVudHMgc2Vj dGlvbiBzYXlzICJSb2xsYmFjayBhdHRhY2tzIG11c3QgYmUgcHJldmVudGVkIi4gQXJlIHlvdSBz YXlpbmcgdGhhdCB3ZSBzaG91bGQgaW5zdGVhZCBzYXkgdGhhdCB0aGV5IG5lZWQgdG8gYmUgcHJv cGVybHkgYXV0aG9yaXplZCBidXQgbm90IHByZXZlbnRlZD8NCg0KTW9zdCBpbXBvcnRhbnRseSwg d2UgbmVlZCB0byBiZSB2ZXJ5IGNsZWFyIHdoYXQgZXhwcmVzc2lvbnMgc3VjaCBhcyDigJxzaWdu aW5nIHRoZSBtYW5pZmVzdOKAnSBhY3R1YWxseSBtZWFuLCBpLmUuLCB3aGF0IGV4YWN0bHkgaXMg dGhlIGNsYWltIHRoYXQgaXMgc2lnbmVkIGJ5IHRoYXQgc2lnbmF0dXJlLg0KDQpbSGFubmVzXSBJ IGJlbGlldmUgdGhlIGRldGFpbHMgb2YgdGhlIHNpZ25pbmcgcHJvY2VzcyB3aWxsIGJlIGRldGFp bGVkIGluIHRoZSBhY3R1YWwgc29sdXRpb24gZG9jdW1lbnQuDQoNCg0KSSBhbHNvIGhhdmUgc29t ZSBlZGl0b3JpYWwgY29tbWVudHMgSeKAmWxsIHNlbmQgZGlyZWN0bHkgdG8gdGhlIGF1dGhvcnMu DQoNCkdyw7zDn2UsIENhcnN0ZW4NCg0KQ2lhbw0KSGFubmVzDQoNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClN1aXQgbWFpbGluZyBsaXN0DQpTdWl0 QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N1aXQNCklN UE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNo bWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91 IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhl ciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGlu Zm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCg== From nobody Wed Jun 6 02:58:34 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77B3D130EDB for ; Wed, 6 Jun 2018 02:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVnMcHzOhebo for ; Wed, 6 Jun 2018 02:58:28 -0700 (PDT) Received: from mail-ua0-f169.google.com (mail-ua0-f169.google.com [209.85.217.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CAAE130ED0 for ; Wed, 6 Jun 2018 02:58:28 -0700 (PDT) Received: by mail-ua0-f169.google.com with SMTP id m21-v6so3690529uan.0 for ; Wed, 06 Jun 2018 02:58:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=N+7OXH7GPkgOKNitNa8Vqc8wH9PCxDP4knVKOUzPFmg=; b=d6+b2bI8/QG7pL4KpGL31ZPFRA5lAbeHMU7po3Hn7QYMXMMOn2uJ78wUZoL9XCOFNq gNMPgNO1SXvhjkBCthOyq9h3d0di6reEqWNEz+YRazDmtOJLyHRrLzuR7wKMsS5MJFuU YxQ9X7A1adDbnwfT2+fZTenqZdSSFtBtwoFHVVjykS9rNOSoa/cOpK9+ROMO/vKuBK64 FZ9DKOZJRYUrkWsbfOqYQ3Soi4cVpOg08UtlTMA7nSQsArocViSrd08bpSPDJ23yyBPr kvkeahyqoEZ1Dce2/5SxTv2vqjQ/57Rn5xk3P0nvm7njuCqc6xGpVT494Olfw5FJ6Ihq d+Yw== X-Gm-Message-State: APt69E3WFU6ddGqkMM8I/06yLIifXm2wqqFFi6S211IM4BBEGLNJawzt bVwFT6Mv43pXLsU4rXAZezDq8A4zubkfnB1FCnc= X-Google-Smtp-Source: ADUXVKKSAZp/tu5UHldFzGEvM6wqqHFl1XjhA+cU8syLhUthIW/gzml2cLtKp2roeKFy7tD0nE+G07+6R2iM23OW3j0= X-Received: by 2002:ab0:1723:: with SMTP id j35-v6mr1501274uaf.154.1528279107117; Wed, 06 Jun 2018 02:58:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Emmanuel Baccelli Date: Wed, 6 Jun 2018 11:58:13 +0200 Message-ID: To: suit@ietf.org Content-Type: multipart/alternative; boundary="0000000000004c2555056df6351e" Archived-At: Subject: Re: [Suit] SUIT Architecture -- Operating modes X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 09:58:32 -0000 --0000000000004c2555056df6351e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dave On Wed, Jun 6, 2018 at 11:37 AM Dave Thaler wrote: > > The notification of an update can be device initiated (pull) or remotely > initiated (push). > The transfer of the actual image can also be device initiated (pull) or > remotely initiated (push). > The three cases are (I think the other combination doesn't make sense): > 1) Push notification, push image > 2) Push notification, pull image > 3) Pull notification, pull image > > In my opinion, this is also potentially clearer. One comment though: does case 1 really make sense? If the image is pushed anyways, there is arguably no need for prior notification. Or are we implicitly mixing "notification" with "pre-authorization" aspects= ? Emmanuel > > -----Original Message----- > From: Suit On Behalf Of Hannes Tschofenig > Sent: Wednesday, June 6, 2018 5:27 PM > To: suit@ietf.org > Subject: [Suit] SUIT Architecture -- Operating modes > > Hi all, > > at the virtual interim meeting earlier this year Dave suggested > terminology, which was based on ITU-T work for firmware updates: > > - Device Core: stores/uses software/firmware, i.e., the IoT device itself > > - Communicator: checks software/firmware status of device and initiates > update as needed May or may not be on the device itself > > - Status Tracker: tracks update status of devices under its administratio= n > > - Firmware Server: distributes > software/firmware packages to devices > May or may not be combined with Status Tracker > > At IETF#101 we talked about the following three categories for firmware > update interactions: > > - Client-initiated: IoT device polls for updates and downloads image when > it wants > - Server-initiated: Server pushes update to a device > - Hybrid: Server pushes notification of availability of an update to a > device, and the client then > downloads the image when it wants. > > In > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.= ietf.org%2Fhtml%2Fdraft-ietf-suit-architecture-00&data=3D02%7C01%7Cdthaler%= 40microsoft.com%7Cfdbcbf2e3be442dc544208d5cb8fc354%7C72f988bf86f141af91ab2d= 7cd011db47%7C1%7C1%7C636638740682287207&sdata=3DZ8JJlDZINiolbZmqINLWCMEaWT1= %2BcUkAGQpBqfhjvCw%3D&reserved=3D0 > Brendan and I made a proposal for a new terminology. Here is the relevant > text: > > ----- > > 3.10. Operating modes > > There are three broad classifications of update operating modes. > > * Self initiated > * Third-party initiated > * Hybrid > > Self initiated updates take the form of a proactive IoT device that > checks for updates. Third-party initiated updates are triggered by > an actor other than the IoT device, be it a server, a peer, or a > user. Hybrid updates are those that require agreement from both the > target IoT device and another actor. > > Third-party initiated updates are important to consider because > timing of updates may need to be tightly controlled in some high- > reliability environments. > > An IoT device goes through several steps in the course of an update, > each of which can be self-initiated or third-party initiated, or > hybrid. An IoT device may go through the following steps, though > this is not a comprehensive list. > > * Notification > * Pre-authorisation > * Dependency resolution > * Download > * Installation > > The notification step consists informing an IoT device that an update > is available. This can be accomplished via polling (self-initiated), > push notifications (third-party initiated), or more complex > mechanisms. > > The pre-authorisation step involves verifying the update authority > and making a determination that the device is prepared to initiate > the fetching and processing of updates. If the device has all > information that is necessary to make this determination, then the > pre-authorisation may be self-initiated. However, the device can > wait for instruction to begin (third-party initiated). Hybrid > approaches are possible as well. > > A dependency resolution phase is needed when more than one component > can be updated or when a differential update is used. The necessary > dependencies must be available prior to installation. > > The download step is the process of acquiring a local copy of the > payload. When the download is self-initiated, this means that the > IoT device chooses when a download occurs and initiates the download > process. When a download is third-party initiated, this means that > either the remote service tells the IoT device when to download or > that it initiates the transfer directly to the IoT device. For > example, a download from an HTTP server is initiated locally. A > transfer to a LwM2M Firmware Update resource [LwM2M] is initiated > remotely. > > Installation is the act of processing the payload into a format that > the IoT device can recognise. > > Each of these steps may require different permissions expressed in > claims and may be implemented in a variety of ways. > > ---- > > Offline feedback from Dave indicates that it did not help improve clarify= . > Hence, I am going it a new try. Let me know what you think. > > > ----- > > 3.10. Operating modes > > There are three broad classifications of update operating modes. > > * Client-initiated Update > * Server-initiated Update > * Hybrid Update > > Client-initiated updates take the form of a Communicator on a Device Co= re > proactively checking for new firmware imagines provided by Firmware > Servers. > > Server-initiated updates are important to consider because > timing of updates may need to be tightly controlled in some high- > reliability environments. In this case the Communicator, potentially in > coordination with the Status Tracker, determines what IoT devices need > qualify for a firmware update. Once those devices have been selected th= e > Firmware Server distributes updates to those Device Cores. > > Note: This assumes that the Firmware Server is able to reach the Device > Cores, > which may require Device Cores to keep reachability information at the > Communicator > and / or at the Firmware Server up-to-date. This may also require > keeping state at > NATs and stateful packet filtering firewalls alive. > > Hybrid updates are those that require an interaction between the Device > Core > and the Firmware Server / Communicator. The Communicator pushes > notifications > of availability of an update to the Device Core, and the Device Core th= en > downloads the image from the Firmware Server when it wants. > > An alternative approach is to consider the steps an IoT device has to > go through > in the course of an update: > > * Notification > * Pre-authorisation > * Dependency resolution > * Download > * Installation > > The notification step consists of the Communicator informing the Devic= e > Core > that an update is available. This can be accomplished via polling > (client-initiated), > push notifications (server-initiated), or more complex > mechanisms. > > The pre-authorisation step involves verifying whether the entity signi= ng > the manifest is indeed authorized to perform an update. The Device Cor= e > must also determine whether it should fetching and processing of the > firmware image (unless it has been attached already to the manifest > itself). > > A dependency resolution phase is needed when more than one component > can be updated or when a differential update is used. The necessary > dependencies must be available prior to installation. > > The download step is the process of acquiring a local copy of the > firmware image. When the download is client-initiated, this means tha= t > the > IoT device chooses when a download occurs and initiates the download > process. When a download is server-party initiated, this means that > either the Communicator / Firmware Server tells the IoT device when > to download or that it initiates the transfer directly to the IoT > device. > For example, a download from an HTTP-based Firmware Server is > client-initiated. > A transfer to a LwM2M Firmware Update resource [LwM2M] is > server-initiated. > > If the Device Core has downloaded a new firmware image and is ready to > install it it may need to wait for a trigger from a Communicator to > install the firmware update, may trigger the update automatically, or > may go through a more complex decision making process to determine > the appropriate timing for an update (such as delaying the update > process to a later time when end users are less impacted by the update > process). > > Installation is the act of processing the payload into a format that > the IoT device can recognise and the bootloader is responsible for the= n > booting from the newly installed firmware image. > > Each of these steps may require different permissions. > > ---- > > Is this any better? > > Writing the text above I noticed that the Communicator and the Status > Tracker have some overlapping functionality. Both entities need to know > about the status of the device. Also it would be good to know what > "initiates update" for the communicator actually needs. > > Finally, the term "Device Core" sounds a bit strange. Would it be better > to call it 'update service' or just refer to IoT device? > > Ciao > Hannes > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > > _______________________________________________ > Suit mailing list > Suit@ietf.org > > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ie= tf.org%2Fmailman%2Flistinfo%2Fsuit&data=3D02%7C01%7Cdthaler%40microsoft.com= %7Cfdbcbf2e3be442dc544208d5cb8fc354%7C72f988bf86f141af91ab2d7cd011db47%7C1%= 7C1%7C636638740682287207&sdata=3DW0Ak6fX0oHbALgg5XxU0YiN9z%2Ber18j7sUJbjfbq= ow8%3D&reserved=3D0 > > _______________________________________________ > Suit mailing list > Suit@ietf.org > https://www.ietf.org/mailman/listinfo/suit > --0000000000004c2555056df6351e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Dave

On Wed, Jun 6, 2018 at 11:37 AM Dave Thaler <dthaler=3D40microsoft.com@dmarc.ietf.org&g= t; wrote:

The notification of an update can be device initiated (pull) or remotely in= itiated (push).
The transfer of the actual image can also be device initiated (pull) or rem= otely initiated (push).
The three cases are (I think the other combination doesn't make sense):=
1) Push notification, push image
2) Push notification, pull image
3) Pull notification, pull image


In my opinion, this is also potentiall= y clearer.
One comment though: does case 1 really make sense?
If the image is pushed anyways, there is arguably no need for prior = notification.
Or are we implicitly mixing "notification"= ; with "pre-authorization" aspects?

Emma= nuel



=C2=A0

-----Original Message-----
From: Suit <s= uit-bounces@ietf.org> On Behalf Of Hannes Tschofenig
Sent: Wednesday, June 6, 2018 5:27 PM
To: suit@ietf.org Subject: [Suit] SUIT Architecture -- Operating modes

Hi all,

at the virtual interim meeting earlier this year Dave suggested terminology= , which was based on ITU-T work for firmware updates:

- Device Core: stores/uses software/firmware, i.e., the IoT device itself
- Communicator: checks software/firmware status of device and initiates upd= ate as needed May or may not be on the device itself

- Status Tracker: tracks update status of devices under its administration<= br>
- Firmware Server: distributes
software/firmware packages to devices
May or may not be combined with Status Tracker

At IETF#101 we talked about the following three categories for firmware upd= ate interactions:

- Client-initiated: IoT device polls for updates and downloads image when i= t wants
- Server-initiated: Server pushes update to a device
- Hybrid: Server pushes notification of availability of an update to a devi= ce, and the client then
=C2=A0 downloads the image when it wants.

In https://na01.safelinks.protection.outlook.com/?url=3D= https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-suit-architecture-00&d= ata=3D02%7C01%7Cdthaler%40microsoft.com%7Cfdbcbf2e3be442dc544208d5cb8fc354%= 7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636638740682287207&sdata= =3DZ8JJlDZINiolbZmqINLWCMEaWT1%2BcUkAGQpBqfhjvCw%3D&reserved=3D0 Br= endan and I made a proposal for a new terminology. Here is the relevant tex= t:

-----

3.10.=C2=A0 Operating modes

=C2=A0 =C2=A0There are three broad classifications of update operating mode= s.

=C2=A0 =C2=A0* Self initiated
=C2=A0 =C2=A0* Third-party initiated
=C2=A0 =C2=A0* Hybrid

=C2=A0 =C2=A0Self initiated updates take the form of a proactive IoT device= that
=C2=A0 =C2=A0checks for updates.=C2=A0 Third-party initiated updates are tr= iggered by
=C2=A0 =C2=A0an actor other than the IoT device, be it a server, a peer, or= a
=C2=A0 =C2=A0user.=C2=A0 Hybrid updates are those that require agreement fr= om both the
=C2=A0 =C2=A0target IoT device and another actor.

=C2=A0 =C2=A0Third-party initiated updates are important to consider becaus= e
=C2=A0 =C2=A0timing of updates may need to be tightly controlled in some hi= gh-
=C2=A0 =C2=A0reliability environments.

=C2=A0 =C2=A0An IoT device goes through several steps in the course of an u= pdate,
=C2=A0 =C2=A0each of which can be self-initiated or third-party initiated, = or
=C2=A0 =C2=A0hybrid.=C2=A0 An IoT device may go through the following steps= , though
=C2=A0 =C2=A0this is not a comprehensive list.

=C2=A0 =C2=A0* Notification
=C2=A0 =C2=A0* Pre-authorisation
=C2=A0 =C2=A0* Dependency resolution
=C2=A0 =C2=A0* Download
=C2=A0 =C2=A0* Installation

=C2=A0 =C2=A0The notification step consists informing an IoT device that an= update
=C2=A0 =C2=A0is available.=C2=A0 This can be accomplished via polling (self= -initiated),
=C2=A0 =C2=A0push notifications (third-party initiated), or more complex =C2=A0 =C2=A0mechanisms.

=C2=A0 =C2=A0The pre-authorisation step involves verifying the update autho= rity
=C2=A0 =C2=A0and making a determination that the device is prepared to init= iate
=C2=A0 =C2=A0the fetching and processing of updates.=C2=A0 If the device ha= s all
=C2=A0 =C2=A0information that is necessary to make this determination, then= the
=C2=A0 =C2=A0pre-authorisation may be self-initiated.=C2=A0 However, the de= vice can
=C2=A0 =C2=A0wait for instruction to begin (third-party initiated).=C2=A0 H= ybrid
=C2=A0 =C2=A0approaches are possible as well.

=C2=A0 =C2=A0A dependency resolution phase is needed when more than one com= ponent
=C2=A0 =C2=A0can be updated or when a differential update is used.=C2=A0 Th= e necessary
=C2=A0 =C2=A0dependencies must be available prior to installation.

=C2=A0 =C2=A0The download step is the process of acquiring a local copy of = the
=C2=A0 =C2=A0payload.=C2=A0 When the download is self-initiated, this means= that the
=C2=A0 =C2=A0IoT device chooses when a download occurs and initiates the do= wnload
=C2=A0 =C2=A0process.=C2=A0 When a download is third-party initiated, this = means that
=C2=A0 =C2=A0either the remote service tells the IoT device when to downloa= d or
=C2=A0 =C2=A0that it initiates the transfer directly to the IoT device.=C2= =A0 For
=C2=A0 =C2=A0example, a download from an HTTP server is initiated locally.= =C2=A0 A
=C2=A0 =C2=A0transfer to a LwM2M Firmware Update resource [LwM2M] is initia= ted
=C2=A0 =C2=A0remotely.

=C2=A0 =C2=A0Installation is the act of processing the payload into a forma= t that
=C2=A0 =C2=A0the IoT device can recognise.

=C2=A0 =C2=A0Each of these steps may require different permissions expresse= d in
=C2=A0 =C2=A0claims and may be implemented in a variety of ways.

----

Offline feedback from Dave indicates that it did not help improve clarify.<= br> Hence, I am going it a new try. Let me know what you think.


-----

3.10.=C2=A0 Operating modes

=C2=A0 =C2=A0There are three broad classifications of update operating mode= s.

=C2=A0 * Client-initiated Update
=C2=A0 * Server-initiated Update
=C2=A0 * Hybrid Update

=C2=A0 Client-initiated updates take the form of a Communicator on a Device= Core
=C2=A0 proactively checking for new firmware imagines provided by Firmware = Servers.

=C2=A0 Server-initiated updates are important to consider because
=C2=A0 timing of updates may need to be tightly controlled in some high- =C2=A0 reliability environments. In this case the Communicator, potentially= in
=C2=A0 coordination with the Status Tracker, determines what IoT devices ne= ed
=C2=A0 qualify for a firmware update. Once those devices have been selected= the
=C2=A0 Firmware Server distributes updates to those Device Cores.

=C2=A0 Note: This assumes that the Firmware Server is able to reach the Dev= ice Cores,
=C2=A0 which may require Device Cores to keep reachability information at t= he Communicator
=C2=A0 and / or at the Firmware Server up-to-date. This may also require ke= eping state at
=C2=A0 NATs and stateful packet filtering firewalls alive.

=C2=A0 Hybrid updates are those that require an interaction between the Dev= ice Core
=C2=A0 and the Firmware Server / Communicator. The Communicator pushes noti= fications
=C2=A0 of availability of an update to the Device Core, and the Device Core= then
=C2=A0 downloads the image from the Firmware Server when it wants.

=C2=A0 =C2=A0An alternative approach is to consider the steps an IoT device= has to go through
=C2=A0 =C2=A0in the course of an update:

=C2=A0 =C2=A0* Notification
=C2=A0 =C2=A0* Pre-authorisation
=C2=A0 =C2=A0* Dependency resolution
=C2=A0 =C2=A0* Download
=C2=A0 =C2=A0* Installation

=C2=A0 =C2=A0The notification step consists of the Communicator informing t= he Device Core
=C2=A0 =C2=A0that an update is available. This can be accomplished via poll= ing (client-initiated),
=C2=A0 =C2=A0push notifications (server-initiated), or more complex
=C2=A0 =C2=A0mechanisms.

=C2=A0 =C2=A0The pre-authorisation step involves verifying whether the enti= ty signing
=C2=A0 =C2=A0the manifest is indeed authorized to perform an update. The De= vice Core
=C2=A0 =C2=A0must also determine whether it should fetching and processing = of the
=C2=A0 =C2=A0firmware image (unless it has been attached already to the man= ifest itself).

=C2=A0 =C2=A0A dependency resolution phase is needed when more than one com= ponent
=C2=A0 =C2=A0can be updated or when a differential update is used.=C2=A0 Th= e necessary
=C2=A0 =C2=A0dependencies must be available prior to installation.

=C2=A0 =C2=A0The download step is the process of acquiring a local copy of = the
=C2=A0 =C2=A0firmware image.=C2=A0 When the download is client-initiated, t= his means that the
=C2=A0 =C2=A0IoT device chooses when a download occurs and initiates the do= wnload
=C2=A0 =C2=A0process.=C2=A0 When a download is server-party initiated, this= means that
=C2=A0 =C2=A0either the Communicator / Firmware Server tells the IoT device= when
=C2=A0 =C2=A0to download or that it initiates the transfer directly to the = IoT device.
=C2=A0 =C2=A0For example, a download from an HTTP-based Firmware Server is = client-initiated.
=C2=A0 =C2=A0A transfer to a LwM2M Firmware Update resource [LwM2M] is serv= er-initiated.

=C2=A0 =C2=A0If the Device Core has downloaded a new firmware image and is = ready to
=C2=A0 =C2=A0install it it may need to wait for a trigger from a Communicat= or to
=C2=A0 =C2=A0install the firmware update, may trigger the update automatica= lly, or
=C2=A0 =C2=A0may go through a more complex decision making process to deter= mine
=C2=A0 =C2=A0the appropriate timing for an update (such as delaying the upd= ate
=C2=A0 =C2=A0process to a later time when end users are less impacted by th= e update process).

=C2=A0 =C2=A0Installation is the act of processing the payload into a forma= t that
=C2=A0 =C2=A0the IoT device can recognise and the bootloader is responsible= for then
=C2=A0 =C2=A0booting from the newly installed firmware image.

=C2=A0 =C2=A0Each of these steps may require different permissions.

----

Is this any better?

Writing the text above I noticed that the Communicator and the Status Track= er have some overlapping functionality. Both entities need to know about th= e status of the device. Also it would be good to know what "initiates = update" for the communicator actually needs.

Finally, the term "Device Core" sounds a bit strange. Would it be= better to call it 'update service' or just refer to IoT device?
Ciao
Hannes


IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you.

_______________________________________________
Suit mailing list
Suit@ietf.org
https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.= ietf.org%2Fmailman%2Flistinfo%2Fsuit&data=3D02%7C01%7Cdthaler%40microso= ft.com%7Cfdbcbf2e3be442dc544208d5cb8fc354%7C72f988bf86f141af91ab2d7cd011db4= 7%7C1%7C1%7C636638740682287207&sdata=3DW0Ak6fX0oHbALgg5XxU0YiN9z%2Ber18= j7sUJbjfbqow8%3D&reserved=3D0

_______________________________________________
Suit mailing list
Suit@ietf.org
https://www.ietf.org/mailman/listinfo/suit
--0000000000004c2555056df6351e-- From nobody Wed Jun 6 02:59:28 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46E39128BAC for ; Wed, 6 Jun 2018 02:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1xNO7XGIyad for ; Wed, 6 Jun 2018 02:59:23 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2C5A130EE4 for ; Wed, 6 Jun 2018 02:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w569xHER014390; Wed, 6 Jun 2018 11:59:18 +0200 (CEST) Received: from client-0196.vpn.uni-bremen.de (client-0196.vpn.uni-bremen.de [134.102.107.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4113zn5zh9zDXK9; Wed, 6 Jun 2018 11:59:17 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Carsten Bormann In-Reply-To: Date: Wed, 6 Jun 2018 11:59:16 +0200 Cc: "suit@ietf.org" X-Mao-Original-Outgoing-Id: 549971954.8840851-61f92bb28cccee4bfac267407f5f8b4f Content-Transfer-Encoding: quoted-printable Message-Id: <61F22FA5-9E3B-4F4D-A3A2-29A48685E35E@tzi.org> References: <152808358455.20892.2040053845976676560@ietfa.amsl.com> To: Hannes Tschofenig X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Suit] draft-ietf-suit-architecture-00.txt X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 09:59:26 -0000 On Jun 6, 2018, at 11:49, Hannes Tschofenig = wrote: >=20 > [Hannes] Actually, we put this stronger focus on claims in the = document because you have been using these terms. We will try to scale = down on the claim usage again. That is not the right direction of fixing this. =20 The point is to actually define what precisely is being claimed, without = resorting to diffuse context-dependent language. =20 Once you do this, the security improves immensely, because the signed = item can no longer be misused in a different context. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jun 6 03:20:37 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 547F5130EDB for ; Wed, 6 Jun 2018 03:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0TtlRcw4ij1L for ; Wed, 6 Jun 2018 03:20:24 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10087.outbound.protection.outlook.com [40.107.1.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59D35129C6B for ; Wed, 6 Jun 2018 03:20:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=t8zMlSo+VHzTiP7T4ha3sBZPzoEw4tdrgTmYen32EfY=; b=bbLJlCIUVawkDMWIA+a0i9jfx672ydgQc/+ZJeCuM7pf6r1Qehk047pRBjEc/T6Py62YBqJusXok/sgd8eRMoFYlRtM5oGzGNcRHxOb7F4HwWmaQ5jsnd+25JYfIIKSSyWej8Ih7wl8Z5GzevBunFucfF+17QUZlXstHc5VacUs= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1502.eurprd08.prod.outlook.com (10.167.210.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.841.14; Wed, 6 Jun 2018 10:20:20 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35%4]) with mapi id 15.20.0820.015; Wed, 6 Jun 2018 10:20:20 +0000 From: Hannes Tschofenig To: Dave Thaler , "suit@ietf.org" Thread-Topic: SUIT Architecture -- Operating modes Thread-Index: AdP9eHteSzrUiKgdQTO0D4Kr/wumzQAAL6IAAAGddXA= Date: Wed, 6 Jun 2018 10:20:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [195.37.142.77] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1502; 7:vJy+9v0xG/fCqBR4YoJoSPWllWRl83Z8nWbeNPBpEjE2piZtd0GEt2/d3M2MNhb2IH0QhYxNFLutx0DrVyPQzb2kH3wGHy7zw/7yoDLOgnqw9Xel00H+Aq8Rmg4/Y7ScjFRxMqtWwZI6ZJx7C1kc+Afj6WxKKfYumbdfFvT3GJLs9Dib6Fhw3tg5Ye7/pAkJWDYVPm3O576xC5wreSHefsIFspFVz+ob4KGYyYle2HkoPXRfwU2DixaTuDCt9U1G x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1502; x-ms-traffictypediagnostic: VI1PR0801MB1502: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(189930954265078)(219752817060721); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB1502; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1502; x-forefront-prvs: 06952FC175 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(366004)(39860400002)(396003)(39380400002)(53754006)(40434004)(189003)(199004)(13464003)(575784001)(86362001)(81156014)(966005)(7736002)(110136005)(6116002)(305945005)(72206003)(478600001)(81166006)(3846002)(14454004)(9686003)(186003)(6246003)(53936002)(8676002)(316002)(26005)(229853002)(6436002)(6306002)(2501003)(5250100002)(5890100001)(2906002)(2900100001)(3660700001)(11346002)(97736004)(45080400002)(446003)(105586002)(7696005)(66066001)(68736007)(3280700002)(99286004)(476003)(486006)(106356001)(74316002)(33656002)(5660300001)(53546011)(6506007)(25786009)(55016002)(561944003)(8666007)(102836004)(76176011)(8936002)(1511001)(59450400001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1502; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: AJLEDyTPm7N6jKUPf7w+HODgFiXYGn0tQTSjUHdB4YGhWdqmRf1vRfUrT7M2o9WAwi6dq6L/SbGxkhff67J+FfRBIJxIauBiaqPZOqcpp05S6zWtt0f6r32BiL7IQRDbuC2X6GwfuDcEPNXFwVgsKN8CUi5YY0v0jGRRAScZfrl3TNaxolIjlrAu1qsG9/lN spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 90822148-e301-4f38-d91a-08d5cb971b51 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 90822148-e301-4f38-d91a-08d5cb971b51 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jun 2018 10:20:20.0704 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1502 Archived-At: Subject: Re: [Suit] SUIT Architecture -- Operating modes X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 10:20:33 -0000 Hi Dave, In my new text proposal I did not use the term "third party initiated" anym= ore. I used the terminology suggested at the IETF meeting. Are you sure you looked at the correct text? Ciao Hannes -----Original Message----- From: Dave Thaler [mailto:dthaler@microsoft.com] Sent: 06 June 2018 11:36 To: Hannes Tschofenig; suit@ietf.org Subject: RE: SUIT Architecture -- Operating modes A short version of my feedback can be summarized as: > When a download is third-party initiated, this means that > either the remote service tells the IoT device when to download or > that it initiates the transfer directly to the IoT device. I find it very confusing to convolute these different concepts into the sam= e term "third-party initiated", and especially to have the step be "download" even when it is transferred d= irectly rather than initiated by the device. That's why I liked the taxonomy presented at IETF 101 which I found to be f= ar more clear. The notification of an update can be device initiated (pull) or remotely in= itiated (push). The transfer of the actual image can also be device initiated (pull) or rem= otely initiated (push). The three cases are (I think the other combination doesn't make sense): 1) Push notification, push image 2) Push notification, pull image 3) Pull notification, pull image I find the text in the document now confusing and doesn't match the IETF 10= 1 discussion. Dave -----Original Message----- From: Suit On Behalf Of Hannes Tschofenig Sent: Wednesday, June 6, 2018 5:27 PM To: suit@ietf.org Subject: [Suit] SUIT Architecture -- Operating modes Hi all, at the virtual interim meeting earlier this year Dave suggested terminology= , which was based on ITU-T work for firmware updates: - Device Core: stores/uses software/firmware, i.e., the IoT device itself - Communicator: checks software/firmware status of device and initiates upd= ate as needed May or may not be on the device itself - Status Tracker: tracks update status of devices under its administration - Firmware Server: distributes software/firmware packages to devices May or may not be combined with Status Tracker At IETF#101 we talked about the following three categories for firmware upd= ate interactions: - Client-initiated: IoT device polls for updates and downloads image when i= t wants - Server-initiated: Server pushes update to a device - Hybrid: Server pushes notification of availability of an update to a devi= ce, and the client then downloads the image when it wants. In https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools= .ietf.org%2Fhtml%2Fdraft-ietf-suit-architecture-00&data=3D02%7C01%7Cdthaler= %40microsoft.com%7Cfdbcbf2e3be442dc544208d5cb8fc354%7C72f988bf86f141af91ab2= d7cd011db47%7C1%7C1%7C636638740682287207&sdata=3DZ8JJlDZINiolbZmqINLWCMEaWT= 1%2BcUkAGQpBqfhjvCw%3D&reserved=3D0 Brendan and I made a proposal for a new= terminology. Here is the relevant text: ----- 3.10. Operating modes There are three broad classifications of update operating modes. * Self initiated * Third-party initiated * Hybrid Self initiated updates take the form of a proactive IoT device that checks for updates. Third-party initiated updates are triggered by an actor other than the IoT device, be it a server, a peer, or a user. Hybrid updates are those that require agreement from both the target IoT device and another actor. Third-party initiated updates are important to consider because timing of updates may need to be tightly controlled in some high- reliability environments. An IoT device goes through several steps in the course of an update, each of which can be self-initiated or third-party initiated, or hybrid. An IoT device may go through the following steps, though this is not a comprehensive list. * Notification * Pre-authorisation * Dependency resolution * Download * Installation The notification step consists informing an IoT device that an update is available. This can be accomplished via polling (self-initiated), push notifications (third-party initiated), or more complex mechanisms. The pre-authorisation step involves verifying the update authority and making a determination that the device is prepared to initiate the fetching and processing of updates. If the device has all information that is necessary to make this determination, then the pre-authorisation may be self-initiated. However, the device can wait for instruction to begin (third-party initiated). Hybrid approaches are possible as well. A dependency resolution phase is needed when more than one component can be updated or when a differential update is used. The necessary dependencies must be available prior to installation. The download step is the process of acquiring a local copy of the payload. When the download is self-initiated, this means that the IoT device chooses when a download occurs and initiates the download process. When a download is third-party initiated, this means that either the remote service tells the IoT device when to download or that it initiates the transfer directly to the IoT device. For example, a download from an HTTP server is initiated locally. A transfer to a LwM2M Firmware Update resource [LwM2M] is initiated remotely. Installation is the act of processing the payload into a format that the IoT device can recognise. Each of these steps may require different permissions expressed in claims and may be implemented in a variety of ways. ---- Offline feedback from Dave indicates that it did not help improve clarify. Hence, I am going it a new try. Let me know what you think. ----- 3.10. Operating modes There are three broad classifications of update operating modes. * Client-initiated Update * Server-initiated Update * Hybrid Update Client-initiated updates take the form of a Communicator on a Device Core proactively checking for new firmware imagines provided by Firmware Serve= rs. Server-initiated updates are important to consider because timing of updates may need to be tightly controlled in some high- reliability environments. In this case the Communicator, potentially in coordination with the Status Tracker, determines what IoT devices need qualify for a firmware update. Once those devices have been selected the Firmware Server distributes updates to those Device Cores. Note: This assumes that the Firmware Server is able to reach the Device C= ores, which may require Device Cores to keep reachability information at the Co= mmunicator and / or at the Firmware Server up-to-date. This may also require keeping= state at NATs and stateful packet filtering firewalls alive. Hybrid updates are those that require an interaction between the Device C= ore and the Firmware Server / Communicator. The Communicator pushes notificat= ions of availability of an update to the Device Core, and the Device Core then downloads the image from the Firmware Server when it wants. An alternative approach is to consider the steps an IoT device has to go= through in the course of an update: * Notification * Pre-authorisation * Dependency resolution * Download * Installation The notification step consists of the Communicator informing the Device = Core that an update is available. This can be accomplished via polling (clien= t-initiated), push notifications (server-initiated), or more complex mechanisms. The pre-authorisation step involves verifying whether the entity signing the manifest is indeed authorized to perform an update. The Device Core must also determine whether it should fetching and processing of the firmware image (unless it has been attached already to the manifest itse= lf). A dependency resolution phase is needed when more than one component can be updated or when a differential update is used. The necessary dependencies must be available prior to installation. The download step is the process of acquiring a local copy of the firmware image. When the download is client-initiated, this means that = the IoT device chooses when a download occurs and initiates the download process. When a download is server-party initiated, this means that either the Communicator / Firmware Server tells the IoT device when to download or that it initiates the transfer directly to the IoT device= . For example, a download from an HTTP-based Firmware Server is client-ini= tiated. A transfer to a LwM2M Firmware Update resource [LwM2M] is server-initiat= ed. If the Device Core has downloaded a new firmware image and is ready to install it it may need to wait for a trigger from a Communicator to install the firmware update, may trigger the update automatically, or may go through a more complex decision making process to determine the appropriate timing for an update (such as delaying the update process to a later time when end users are less impacted by the update p= rocess). Installation is the act of processing the payload into a format that the IoT device can recognise and the bootloader is responsible for then booting from the newly installed firmware image. Each of these steps may require different permissions. ---- Is this any better? Writing the text above I noticed that the Communicator and the Status Track= er have some overlapping functionality. Both entities need to know about th= e status of the device. Also it would be good to know what "initiates updat= e" for the communicator actually needs. Finally, the term "Device Core" sounds a bit strange. Would it be better to= call it 'update service' or just refer to IoT device? Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. _______________________________________________ Suit mailing list Suit@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf= .org%2Fmailman%2Flistinfo%2Fsuit&data=3D02%7C01%7Cdthaler%40microsoft.com%7= Cfdbcbf2e3be442dc544208d5cb8fc354%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C= 1%7C636638740682287207&sdata=3DW0Ak6fX0oHbALgg5XxU0YiN9z%2Ber18j7sUJbjfbqow= 8%3D&reserved=3D0 IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Wed Jun 6 03:27:05 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D4C130EE5 for ; Wed, 6 Jun 2018 03:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKbvvbCpsjZD for ; Wed, 6 Jun 2018 03:26:58 -0700 (PDT) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4EC6130E5F for ; Wed, 6 Jun 2018 03:26:58 -0700 (PDT) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1fQVeZ-001sVM-Dg>; Wed, 06 Jun 2018 12:26:55 +0200 Received: from ze304.pia.fu-berlin.de ([87.77.227.4] helo=mw-x1.zedat.fu-berlin.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1fQVeZ-000xqc-7V>; Wed, 06 Jun 2018 12:26:55 +0200 Date: Wed, 6 Jun 2018 12:26:53 +0200 From: Matthias Waehlisch To: Dave Thaler cc: Hannes Tschofenig , "suit@ietf.org" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) X-X-Sender: waehl@mail.zedat.fu-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Originating-IP: 87.77.227.4 Archived-At: Subject: Re: [Suit] SUIT Architecture -- Operating modes X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 10:27:02 -0000 On Wed, 6 Jun 2018, Dave Thaler wrote: > The notification of an update can be device initiated (pull) or remotely initiated (push). > The transfer of the actual image can also be device initiated (pull) or remotely initiated (push). > in general I agree with this classification but just wondering about "initiated". How would you map a remotely initiated pull, e.g., someone logs in to the IoT device to trigger the update? Cheers matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl From nobody Wed Jun 6 06:14:58 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF6B130EFB for ; Wed, 6 Jun 2018 06:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3E6gG1CvPkcI for ; Wed, 6 Jun 2018 06:14:45 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0111.outbound.protection.outlook.com [104.47.37.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A107E130E8D for ; Wed, 6 Jun 2018 06:14:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uas9QBQk17ZhtKsCa2tsrVRfpygdoHeaePmCpX+IY10=; b=pBs/ZMTZWQUAnt2Hk/SZxBMhn+oztBJ6g2P5tlwDGcm9xHfuLjH8bGrp0zhinvp+u8Zf27zFGQEJEMtM8AA5nTW3d6I3H6t32XNhBc7g3anTnKc0TDqtBw3x/DS0s7OgB27Tcneg5w9KsR44uFsTMRpwpfiDiTn23iiumaT02NI= Received: from CY4PR21MB0774.namprd21.prod.outlook.com (10.173.192.20) by CY4PR21MB0774.namprd21.prod.outlook.com (10.173.192.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.841.7; Wed, 6 Jun 2018 13:14:43 +0000 Received: from CY4PR21MB0774.namprd21.prod.outlook.com ([fe80::3519:5771:4c24:b065]) by CY4PR21MB0774.namprd21.prod.outlook.com ([fe80::3519:5771:4c24:b065%9]) with mapi id 15.20.0841.011; Wed, 6 Jun 2018 13:14:43 +0000 From: Dave Thaler To: Hannes Tschofenig , "suit@ietf.org" Thread-Topic: SUIT Architecture -- Operating modes Thread-Index: AdP9eHteSzrUiKgdQTO0D4Kr/wumzQAAL6IAAAGddXAABh5XYA== Date: Wed, 6 Jun 2018 13:14:43 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=dthaler@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-06-06T13:14:45.5426473Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [203.69.98.254] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0774; 7:Bx/XfLNZqZYCdORsaUCvUivwr0PY8SgRdf+pfi66/98nbyfCMj9X1eCUq/GQAx3BFnV+SusBFdCHCcr0Z+Gv868IUvFJ2C/qFKf+10InAtE2mB0D7CAnf6M9l72pH+whSuKBm0qN4ogcIuaCew11Bx7IvatjjQXl9dUzKoEJ5NXht4bO4Kpzyq94RA8VHBDd9ydc3RuqeDFnj/U3rwj1cnLqZnYcJsi5PqCyRbRGApU1X6g1FHeqqG3658U8piTO x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:CY4PR21MB0774; x-ms-traffictypediagnostic: CY4PR21MB0774: authentication-results: spf=none (sender IP is ) smtp.mailfrom=dthaler@microsoft.com; x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(180628864354917)(89211679590171)(189930954265078)(219752817060721); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231254)(2018427008)(944501410)(52105095)(3002001)(10201501046)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123564045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:CY4PR21MB0774; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0774; x-forefront-prvs: 06952FC175 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39380400002)(346002)(39860400002)(376002)(366004)(189003)(199004)(13464003)(40434004)(53754006)(561944003)(6436002)(3280700002)(5250100002)(446003)(316002)(6506007)(53546011)(59450400001)(476003)(11346002)(110136005)(7736002)(66066001)(76176011)(68736007)(305945005)(2900100001)(86362001)(6306002)(2501003)(5660300001)(8676002)(102836004)(6246003)(5890100001)(99286004)(97736004)(14454004)(486006)(186003)(26005)(25786009)(53936002)(10290500003)(81156014)(229853002)(966005)(9686003)(8936002)(10090500001)(575784001)(3660700001)(7696005)(8990500004)(478600001)(33656002)(22452003)(74316002)(55016002)(6116002)(105586002)(2906002)(81166006)(3846002)(106356001)(86612001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0774; H:CY4PR21MB0774.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: LdGzjcnnTSN5TB9ySKCBErPIaXqWyEWO5C/nqHwHWB+MzRv9Hth7GymDTl4qJJnqVU6JcPrWHkxMdOmlwvLCZ/zgDOy7IBDmdpsat956g8a3CdkJ60GySiHEZ+RORKvvoughby9Pn2w0JcSNw5b8V7iurWwTiHhPGmjwIDdAljTYYfQJyVoC74AUpoBPzYLK spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: b290ec8b-31e0-40c3-7925-08d5cbaf782f X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: b290ec8b-31e0-40c3-7925-08d5cbaf782f X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jun 2018 13:14:43.7304 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0774 Archived-At: Subject: Re: [Suit] SUIT Architecture -- Operating modes X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 13:14:54 -0000 It is an improvement, yes. It still uses the word "download" though even f= or transfers where a server pushes the image to the device. I think a more direction-a= gnostic term like "file transfer" would be better. Dave -----Original Message----- From: Hannes Tschofenig =20 Sent: Wednesday, June 6, 2018 6:20 PM To: Dave Thaler ; suit@ietf.org Subject: RE: SUIT Architecture -- Operating modes Hi Dave, In my new text proposal I did not use the term "third party initiated" anym= ore. I used the terminology suggested at the IETF meeting. Are you sure you looked at the correct text? Ciao Hannes -----Original Message----- From: Dave Thaler [mailto:dthaler@microsoft.com] Sent: 06 June 2018 11:36 To: Hannes Tschofenig; suit@ietf.org Subject: RE: SUIT Architecture -- Operating modes A short version of my feedback can be summarized as: > When a download is third-party initiated, this means that either the=20 > remote service tells the IoT device when to download or that it=20 > initiates the transfer directly to the IoT device. I find it very confusing to convolute these different concepts into the sam= e term "third-party initiated", and especially to have the step be "downloa= d" even when it is transferred directly rather than initiated by the device= . That's why I liked the taxonomy presented at IETF 101 which I found to be f= ar more clear. The notification of an update can be device initiated (pull) or remotely in= itiated (push). The transfer of the actual image can also be device initiated (pull) or rem= otely initiated (push). The three cases are (I think the other combination doesn't make sense): 1) Push notification, push image 2) Push notification, pull image 3) Pull notification, pull image I find the text in the document now confusing and doesn't match the IETF 10= 1 discussion. Dave -----Original Message----- From: Suit On Behalf Of Hannes Tschofenig Sent: Wednesday, June 6, 2018 5:27 PM To: suit@ietf.org Subject: [Suit] SUIT Architecture -- Operating modes Hi all, at the virtual interim meeting earlier this year Dave suggested terminology= , which was based on ITU-T work for firmware updates: - Device Core: stores/uses software/firmware, i.e., the IoT device itself - Communicator: checks software/firmware status of device and initiates upd= ate as needed May or may not be on the device itself - Status Tracker: tracks update status of devices under its administration - Firmware Server: distributes software/firmware packages to devices May or may not be combined with Status Tracker At IETF#101 we talked about the following three categories for firmware upd= ate interactions: - Client-initiated: IoT device polls for updates and downloads image when i= t wants - Server-initiated: Server pushes update to a device - Hybrid: Server pushes notification of availability of an update to a devi= ce, and the client then downloads the image when it wants. In https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools= .ietf.org%2Fhtml%2Fdraft-ietf-suit-architecture-00&data=3D02%7C01%7Cdthaler= %40microsoft.com%7Cfdbcbf2e3be442dc544208d5cb8fc354%7C72f988bf86f141af91ab2= d7cd011db47%7C1%7C1%7C636638740682287207&sdata=3DZ8JJlDZINiolbZmqINLWCMEaWT= 1%2BcUkAGQpBqfhjvCw%3D&reserved=3D0 Brendan and I made a proposal for a new= terminology. Here is the relevant text: ----- 3.10. Operating modes There are three broad classifications of update operating modes. * Self initiated * Third-party initiated * Hybrid Self initiated updates take the form of a proactive IoT device that checks for updates. Third-party initiated updates are triggered by an actor other than the IoT device, be it a server, a peer, or a user. Hybrid updates are those that require agreement from both the target IoT device and another actor. Third-party initiated updates are important to consider because timing of updates may need to be tightly controlled in some high- reliability environments. An IoT device goes through several steps in the course of an update, each of which can be self-initiated or third-party initiated, or hybrid. An IoT device may go through the following steps, though this is not a comprehensive list. * Notification * Pre-authorisation * Dependency resolution * Download * Installation The notification step consists informing an IoT device that an update is available. This can be accomplished via polling (self-initiated), push notifications (third-party initiated), or more complex mechanisms. The pre-authorisation step involves verifying the update authority and making a determination that the device is prepared to initiate the fetching and processing of updates. If the device has all information that is necessary to make this determination, then the pre-authorisation may be self-initiated. However, the device can wait for instruction to begin (third-party initiated). Hybrid approaches are possible as well. A dependency resolution phase is needed when more than one component can be updated or when a differential update is used. The necessary dependencies must be available prior to installation. The download step is the process of acquiring a local copy of the payload. When the download is self-initiated, this means that the IoT device chooses when a download occurs and initiates the download process. When a download is third-party initiated, this means that either the remote service tells the IoT device when to download or that it initiates the transfer directly to the IoT device. For example, a download from an HTTP server is initiated locally. A transfer to a LwM2M Firmware Update resource [LwM2M] is initiated remotely. Installation is the act of processing the payload into a format that the IoT device can recognise. Each of these steps may require different permissions expressed in claims and may be implemented in a variety of ways. ---- Offline feedback from Dave indicates that it did not help improve clarify. Hence, I am going it a new try. Let me know what you think. ----- 3.10. Operating modes There are three broad classifications of update operating modes. * Client-initiated Update * Server-initiated Update * Hybrid Update Client-initiated updates take the form of a Communicator on a Device Core proactively checking for new firmware imagines provided by Firmware Serve= rs. Server-initiated updates are important to consider because timing of updates may need to be tightly controlled in some high- reliability environments. In this case the Communicator, potentially in coordination with the Status Tracker, determines what IoT devices need qualify for a firmware update. Once those devices have been selected the Firmware Server distributes updates to those Device Cores. Note: This assumes that the Firmware Server is able to reach the Device C= ores, which may require Device Cores to keep reachability information at the Co= mmunicator and / or at the Firmware Server up-to-date. This may also require keeping= state at NATs and stateful packet filtering firewalls alive. Hybrid updates are those that require an interaction between the Device C= ore and the Firmware Server / Communicator. The Communicator pushes notificat= ions of availability of an update to the Device Core, and the Device Core then downloads the image from the Firmware Server when it wants. An alternative approach is to consider the steps an IoT device has to go= through in the course of an update: * Notification * Pre-authorisation * Dependency resolution * Download * Installation The notification step consists of the Communicator informing the Device = Core that an update is available. This can be accomplished via polling (clien= t-initiated), push notifications (server-initiated), or more complex mechanisms. The pre-authorisation step involves verifying whether the entity signing the manifest is indeed authorized to perform an update. The Device Core must also determine whether it should fetching and processing of the firmware image (unless it has been attached already to the manifest itse= lf). A dependency resolution phase is needed when more than one component can be updated or when a differential update is used. The necessary dependencies must be available prior to installation. The download step is the process of acquiring a local copy of the firmware image. When the download is client-initiated, this means that = the IoT device chooses when a download occurs and initiates the download process. When a download is server-party initiated, this means that either the Communicator / Firmware Server tells the IoT device when to download or that it initiates the transfer directly to the IoT device= . For example, a download from an HTTP-based Firmware Server is client-ini= tiated. A transfer to a LwM2M Firmware Update resource [LwM2M] is server-initiat= ed. If the Device Core has downloaded a new firmware image and is ready to install it it may need to wait for a trigger from a Communicator to install the firmware update, may trigger the update automatically, or may go through a more complex decision making process to determine the appropriate timing for an update (such as delaying the update process to a later time when end users are less impacted by the update p= rocess). Installation is the act of processing the payload into a format that the IoT device can recognise and the bootloader is responsible for then booting from the newly installed firmware image. Each of these steps may require different permissions. ---- Is this any better? Writing the text above I noticed that the Communicator and the Status Track= er have some overlapping functionality. Both entities need to know about th= e status of the device. Also it would be good to know what "initiates updat= e" for the communicator actually needs. Finally, the term "Device Core" sounds a bit strange. Would it be better to= call it 'update service' or just refer to IoT device? Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. _______________________________________________ Suit mailing list Suit@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf= .org%2Fmailman%2Flistinfo%2Fsuit&data=3D02%7C01%7Cdthaler%40microsoft.com%7= Cfdbcbf2e3be442dc544208d5cb8fc354%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C= 1%7C636638740682287207&sdata=3DW0Ak6fX0oHbALgg5XxU0YiN9z%2Ber18j7sUJbjfbqow= 8%3D&reserved=3D0 IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Wed Jun 6 10:52:41 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B43130F85 for ; Wed, 6 Jun 2018 10:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n228FMUylZ-0 for ; Wed, 6 Jun 2018 10:52:33 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9C35130F89 for ; Wed, 6 Jun 2018 10:52:32 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 68AE320090 for ; Wed, 6 Jun 2018 14:05:59 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id CF2BD74; Wed, 6 Jun 2018 13:51:56 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id CCB7B3F for ; Wed, 6 Jun 2018 13:51:56 -0400 (EDT) From: Michael Richardson To: suit@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Suit] SUIT Architecture -- Operating modes X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 17:52:38 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Emmanuel Baccelli wrote: >> The notification of an update can be device initiated (pull) or remo= tely >> initiated (push). >> The transfer of the actual image can also be device initiated (pull)= or >> remotely initiated (push). >> The three cases are (I think the other combination doesn't make sens= e): >> 1) Push notification, push image >> 2) Push notification, pull image >> 3) Pull notification, pull image > In my opinion, this is also potentially clearer. > One comment though: does case 1 really make sense? > If the image is pushed anyways, there is arguably no need for prior > notification. If the push notification allows the device to respond with, "thanks, but no= thanks, I'm already there", or "thanks, but it does not apply to me", then it makes sen= se. > Or are we implicitly mixing "notification" with "pre-authorization" a= spects? tell me more about pre-authorization... I didn't understand why there was a "pre-" part. In my example above, I think it fell into notification. >> The notification step consists informing an IoT device that an update >> is available. This can be accomplished via polling (self-initiated), >> push notifications (third-party initiated), or more complex >> mechanisms. >>=20 >> The pre-authorisation step involves verifying the update authority >> and making a determination that the device is prepared to initiate >> the fetching and processing of updates. If the device has all >> information that is necessary to make this determination, then the >> pre-authorisation may be self-initiated. However, the device can >> wait for instruction to begin (third-party initiated). Hybrid >> approaches are possible as well. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWxgfPICLcPvd0N1lAQK+mAgAk/qJL8s+1S9/51/0OhW7qzfuBN1BSmok AyZhSzyiCZJP0jffiEyMpG81m8lDYxBA0CA5XmhnfR/6U5LXTwBu+H4tP2VIIpR/ QGXtXgPPqLomL7fFGvFKOREzCq4K7qd47S3F3Z2E4kFPWMsbk7oYd1MgAyv4xSDP NghCybDovZOOQPmnCp5sQB32H0Bcm3xGQ6/PPudru+zQJGcC0/JuR2Rml357GEXd Kj4I8/a9B8dNm2zxW6O67DwIhaNihmbpMRaaM8od6BT7MzzyUnizOqIxyOx6AgH8 J70VoKbvkhUcqtU891p3ojoUGWVGbdREmPkjTxKw7DA0LlOvkWgoEw== =0ACk -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 6 11:52:59 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 480FE130FB2 for ; Wed, 6 Jun 2018 11:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxtNqYIgnVPL for ; Wed, 6 Jun 2018 11:52:37 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7011130F96 for ; Wed, 6 Jun 2018 11:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w56IqWUM008831 for ; Wed, 6 Jun 2018 20:52:32 +0200 (CEST) Received: from [172.18.144.189] (unknown [46.183.103.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 411Hq43K0JzDXPy; Wed, 6 Jun 2018 20:52:31 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 550003947.0322829-708b8783a75c61bddc417312a1ae2150 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Wed, 6 Jun 2018 20:52:28 +0200 Message-Id: <6D1B1813-C565-4DF3-AD39-0D6F852CA7F2@tzi.org> To: suit@ietf.org X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: [Suit] Design team meeting on Thu Jun 15, 1130Z..1300Z X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 18:52:56 -0000 At the SUIT hackathon, we had a pretty productive discussion about the = architecture and information model documents =E2=80=94 unfortunately, = the time ran out. So we want to continue this discussion over the Web, = and have chosen Thu 15th at 13:30..15:00 CEST on = https://jitsi.tools.ietf.org/suit-dt for that. Because this is too close now, this cannot officially be a = continuation of the virtual interim we had today (during the hackathon), = so we have chosen to label this as a design team meeting. The WG is = invited, so if you want to hear Henk, Brendan and me quibble about = terminology, please join :-). [Terminology *is* important here, though.] Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jun 7 05:23:55 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA991130E5F for ; Thu, 7 Jun 2018 05:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALJPCUMFLNFt for ; Thu, 7 Jun 2018 05:23:48 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BC00130F61 for ; Thu, 7 Jun 2018 05:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w57CNgXw013746 for ; Thu, 7 Jun 2018 14:23:42 +0200 (CEST) Received: from sev.fritz.box (p5B3D0271.dip0.t-ipconnect.de [91.61.2.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 411l7y4pBszDXYY; Thu, 7 Jun 2018 14:23:42 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Carsten Bormann In-Reply-To: <6D1B1813-C565-4DF3-AD39-0D6F852CA7F2@tzi.org> Date: Thu, 7 Jun 2018 14:23:42 +0200 X-Mao-Original-Outgoing-Id: 550067020.5256701-87f59c1823e8e420ccf34dcf17f93467 Content-Transfer-Encoding: quoted-printable Message-Id: <975B3474-B7A8-4C9E-AABD-452A81CF80FB@tzi.org> References: <6D1B1813-C565-4DF3-AD39-0D6F852CA7F2@tzi.org> To: suit@ietf.org X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Suit] Design team meeting on Thu Jun 14, 1130Z..1300Z X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 12:23:54 -0000 Thursday is, of course, Jun 14 (not 15th). Teaches me to use tools for = hard things like calendar invitations=E2=80=A6 (1130Z to 1300Z, where Z is an abbreviation for UTC, is correct =E2=80=94 = about 167 hours from now.) Gr=C3=BC=C3=9Fe, Carsten > On Jun 6, 2018, at 20:52, Carsten Bormann wrote: >=20 > At the SUIT hackathon, we had a pretty productive discussion about the = architecture and information model documents =E2=80=94 unfortunately, = the time ran out. So we want to continue this discussion over the Web, = and have chosen >=20 > Thu 15th at 13:30..15:00 CEST on = https://jitsi.tools.ietf.org/suit-dt >=20 > for that. Because this is too close now, this cannot officially be a = continuation of the virtual interim we had today (during the hackathon), = so we have chosen to label this as a design team meeting. The WG is = invited, so if you want to hear Henk, Brendan and me quibble about = terminology, please join :-). [Terminology *is* important here, though.] >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > Suit mailing list > Suit@ietf.org > https://www.ietf.org/mailman/listinfo/suit >=20 >=20 From nobody Thu Jun 7 09:05:59 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BEF6130F56 for ; Thu, 7 Jun 2018 09:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=linaro.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Ss3VSQSt8pS for ; Thu, 7 Jun 2018 09:05:53 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E272130FA3 for ; Thu, 7 Jun 2018 09:05:52 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id n7-v6so13563080itn.1 for ; Thu, 07 Jun 2018 09:05:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=ddIwS0/DrKKE4dK7QDF4SETSF5MZoWj8Jm/EduxgwOM=; b=jFwTLxLrpoy5Hze5dAbq07vQCsQkgc1RhJ7KmWUyKYdgt1XfyU68zwW3Fnco2+TATR QADNWHVC/Xo30EhTRY3F7PcWcdRJTQZeRt76ab2N6ezg1RIrUxNjNvB3pYgOC9PtOsdK yOPK5+sSkosHkTErJ5AeDTij9d5T7c34c6mUs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=ddIwS0/DrKKE4dK7QDF4SETSF5MZoWj8Jm/EduxgwOM=; b=pg+TaLXRiFRLIb2zF5vIFQfpzl77lyAmWl7Kg10QlrE0xXJ/3ac6yrEh7qxgvMR462 CXM2hXDmRlvTHMAxNatd1Ro4e/lkLDOCWTXubMcdzJvcGnJpGQapbvm1VBwHrO7HXPP1 WrW4Gv4+9i2j64kctgqPZWLNIOGkmTZ6HYgMUfjTF3Y4P9Qy1gc7e47dYeAk+S82NNTH HXX21IfUN5XoCu0/6AYq19iETXtGfqOTCaY7aCsknNQour+MIUeCfGkxkaWxQkdNFWoN eISxRxDbIqeFn3doMd6NJvPl+ta36+yySDBev7Jc+SZWYwVt7AUec14HWadM4//K7SDf gwrg== X-Gm-Message-State: APt69E0H4R/hna77h6mpqjmNtItbM4LLdGIKtjG0G1S3g/tQ4dg8n5J3 H/0tv4cmStZOJ2+nePoeeSZwu8NexYs= X-Google-Smtp-Source: ADUXVKLcszo4VOhUFPqpFUXtqZ3uYNVwrEciM/zQsK/NxWXiRQHlU0QZpnh3Xzmam36laUk35Owy0g== X-Received: by 2002:a24:714:: with SMTP id f20-v6mr2488088itf.76.1528387551425; Thu, 07 Jun 2018 09:05:51 -0700 (PDT) Received: from davidb.org ([2601:283:4300:987c::9]) by smtp.gmail.com with ESMTPSA id k1-v6sm7737796iob.9.2018.06.07.09.05.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Jun 2018 09:05:50 -0700 (PDT) Date: Thu, 7 Jun 2018 10:05:49 -0600 From: David Brown To: Koen Zandberg Cc: suit@ietf.org Message-ID: <20180607160549.GA11744@davidb.org> References: <238EC1AC-D898-472D-A951-2AD1438C6004@vigilsec.com> <168ED9F9-15CF-457B-850A-77196D423D08@arm.com> <932b5b21-dc56-b316-0c0d-28d43c4cec42@bergzand.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <932b5b21-dc56-b316-0c0d-28d43c4cec42@bergzand.net> User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: Re: [Suit] COSE_Sign vs. COSE_Mac X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 16:05:56 -0000 On Mon, Jun 04, 2018 at 05:59:41PM +0200, Koen Zandberg wrote: >My 2 cents for this scenario: the device I'm currently developing for >(samr21-xplained pro) takes around 8 seconds for ed25519 signature >verification (TweetNaCl implementation). An HMAC based verification >would be a lot faster here (saving me battery power). If you like I can >provide you some numbers on flash requirements for both HMAC and >public-key implementations. I think this more points out that there is a need for a better ed25519 implementation for this kind of scenario. On my mcu (120Mhz Cortex M7), TweetNaCl takes 1-2 seconds for a signature verification. It is nice because it is only about 3kb of code. The other implementation I have, from NaCl, takes on the order of 20-30ms for the same verification. However, it is about 130Kb of code, which makes it unreasonable to use in many situations. What would be nice to have would be something in between. A little bit larger code, but that runs faster than TweetNaCl. There is a https://munacl.cryptojedi.org/faq.shtml microNaCl library that tries to do this. However, it seems to be largely hand-written assembly, and targeted to very specific mcus. For this MCU, RSA code (using mbed TLS) is about 12Kb of code, and takes 400-500ms to do the signature verification. Gut feeling is that Ed25519 could be implemented with similar code size and performance, or slightly better. I don't really have the depth of understanding needed to produce this implementation, however, but maybe someone does. David From nobody Thu Jun 7 09:07:44 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C36E4131167 for ; Thu, 7 Jun 2018 09:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=linaro.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9uyshd831f9X for ; Thu, 7 Jun 2018 09:07:30 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85A131310EC for ; Thu, 7 Jun 2018 09:07:29 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id u4-v6so13561207itg.0 for ; Thu, 07 Jun 2018 09:07:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=HQi7nuS+PVaCN2/BncxdjjbL8KTCIYYtnnfa1MrW34k=; b=DuUCk/Z9q1lmtuKzoVdTgYjeEXXmaML4P5rpOOLXLbZTOrNUC+QA4C1Hkqd056cPlR 7rYA/fvnFqfFIxraBNkySJz/5mzYqx4/Ax6JfgNQ0JwIBZTWymN83renBr5ioCvh6iWl 74IINndOGRsPgVMK3jMdHcqoplWucYBogpU0I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=HQi7nuS+PVaCN2/BncxdjjbL8KTCIYYtnnfa1MrW34k=; b=Flp39zadVWa+0Hi4BzoMZ1cyFYzJI8e0RiJNMB0xebxftDdurSTSVtIg5hZBdbtmeP JZyoImbW6/qd2aXKWvbIp1uhrTs2Ej6qF5sLEMTtOMDHD7g2gVfqa+ucnQLsSz/Q8kWa ucCQZIQoAS1fXIkd57iHLG2iSjqsbdpFp60gqtNv4uTIClVfSvgEJ+44bl7/RVkVvv/8 o8qN/uLv8cBcTa0DtgICbN6BazxMD4pbTGL7oe2RSca2zbl7HlFbFgNI8Tdp49F5GcHp ormcYUefWxyl3p+PsZgIbWsU70QRzo4jpMCa/czKj3TPk2SmRblIKjjowEfnc0bIOgkS nLbA== X-Gm-Message-State: APt69E0XV+GL7tAISaRYVLykQzz8gtR4IC0Kdhbfg8kaTqIlTbH+vFIV SJjcTCYsHlzeYkU/PRV3/jwlVWWxqTI= X-Google-Smtp-Source: ADUXVKKbhYvyr+fKoa7ZVxyQsh9XVg7l8gaZS8uuVWil3KJWhfluihfrPflLf0Qz40S78QIFNcKsDw== X-Received: by 2002:a24:2c03:: with SMTP id i3-v6mr2448455iti.90.1528387648858; Thu, 07 Jun 2018 09:07:28 -0700 (PDT) Received: from davidb.org ([2601:283:4300:987c::9]) by smtp.gmail.com with ESMTPSA id u132-v6sm1037351itb.20.2018.06.07.09.07.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Jun 2018 09:07:28 -0700 (PDT) Date: Thu, 7 Jun 2018 10:07:26 -0600 From: David Brown To: "Thomas C. Schmidt" Cc: suit@ietf.org Message-ID: <20180607160726.GB11744@davidb.org> References: <238EC1AC-D898-472D-A951-2AD1438C6004@vigilsec.com> <168ED9F9-15CF-457B-850A-77196D423D08@arm.com> <47a6002fceb54829a95a10bf3adb32ea@HUB01.mailcluster.haw-hamburg.de> <34786b07-8831-8a3c-caea-8e73d91115c1@haw-hamburg.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <34786b07-8831-8a3c-caea-8e73d91115c1@haw-hamburg.de> User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: Re: [Suit] COSE_Sign vs. COSE_Mac X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 16:07:42 -0000 On Mon, Jun 04, 2018 at 10:18:32PM +0200, Thomas C. Schmidt wrote: >> My 2 cents for this scenario: the device I'm currently developing for >> (samr21-xplained pro) takes around 8 seconds for ed25519 signature >> verification (TweetNaCl implementation). > >Could this work be significantly flawed? > >We've done the same Edwards curve on the same board with RIOT for >SIGCOMM '15 and an ID-based authentication scheme: 3 sec verification, 1 >sec generation. > >See https://conferences.sigcomm.org/sigcomm/2015/pdf/papers/p603.pdf > >It could be much faster when optimized in assembly code. I don't think assembly is really what is needed, but is more about pre-computed tables and the algorithms used for the underlying EC operations. David From nobody Thu Jun 7 10:45:32 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8518131178 for ; Thu, 7 Jun 2018 10:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pg9NqCUORmHO for ; Thu, 7 Jun 2018 10:44:57 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15CFD131171 for ; Thu, 7 Jun 2018 10:44:57 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id l25-v6so12762210ioh.12 for ; Thu, 07 Jun 2018 10:44:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=2ZX5ZBzlOp8AETw5mk8NdOsU9FWt8IV5KnwvOWEcoEs=; b=k0Q4Uta27VAV4Z2w9kVfXkk+ZSdntT6B/yOHLW1PEVgPqjY0bce00oWVZ+PSQfvb2L ElTL1Bj+5Rbl5BjcBECQbeCu0Xsthf1xQwdq9AmXFzRK/5MqPZ8ZbjR7TpYgNr630Fq2 6K3hjTvtTX3zQjHR2lAy6zz/J9E3ayMmHyyJ+WPqm2WZFFmTZP0nd5LSG2hYFtTF12sQ x/BP6hojMkPap+odIRsTtdU4hnrRiut439Nk6ByZtaQn9EpWX/mvdvkyoEropW0X1AM4 Dq0JEBwZY+ZO+t0ZIubhK/owNc+NFKx0vRVekPpVF0WeOZRrKoSafoPkyP9CA1bHoeaS X2DQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=2ZX5ZBzlOp8AETw5mk8NdOsU9FWt8IV5KnwvOWEcoEs=; b=MWa9wONBQ7iuzGMAvgDvgNcTNn3mcyyfxq87zIgdGriWrh03yX6/iAL69WuHjjPqjz kv1zVOyMprTi0uwVHWVIsNf/B8c8DqC3psngrSYquXazisTpD84+haunAYEoSYvR4Vom 8BtRTrsR2CBUJ1vGsRA9gmD0WiNvRyQyCgqH+L1HFIA2quwgUIYt3+LQa6GBCx20vSEU HfwZVt72vajLbvAig8xr432cFUXDtbPbDE1pRiAd7hIuWwDvX2+FtCamvPDZ56+QZpg8 504mtK4b9klnDFlwKgkyk/1m8/sTpCQqIOkhwrE8jKdB7DXaKaHSXhusKrrnWuDGtPD2 vjwg== X-Gm-Message-State: APt69E1ymuVDx/pC0RnQRBQss5/dAFkGXKAE4TjgPwH2qrJzCK4MNuYp Ceea8c7iSo9rxT8g2clSiR/kyRFQY3TFhURT2ieFOYW5 X-Google-Smtp-Source: ADUXVKKkkcFjPCbxoN8LNWWo61ilY52W8OvMzVeU3utOg6P3hLjqzeLOMK4UyM6EAPXjV/gi6Q0UYznO63G4+kYLzW4= X-Received: by 2002:a6b:2653:: with SMTP id m80-v6mr2399139iom.301.1528393496029; Thu, 07 Jun 2018 10:44:56 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:b88a:0:0:0:0:0 with HTTP; Thu, 7 Jun 2018 10:44:55 -0700 (PDT) From: Basavaraj Patil Date: Thu, 7 Jun 2018 12:44:55 -0500 Message-ID: To: suit@ietf.org Content-Type: multipart/alternative; boundary="0000000000006875a3056e10d77c" Archived-At: Subject: [Suit] Question about SUIT WG deliverable X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 17:45:09 -0000 --0000000000006875a3056e10d77c Content-Type: text/plain; charset="UTF-8" Sec 7 of I-D: draft-ietf-suit-architecture-00 shows an example flow depicting the end-2-end process of firmware updates of an IoT device. Will the SUIT WG develop the protocol/signaling that is depicted in Fig 4 of the I-D? -- Basavaraj Patil --0000000000006875a3056e10d77c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Sec 7 of I-D:=C2=A0draft-ietf-suit-architec= ture-00 shows an example flow depicting the end-2-end process of firmware u= pdates of an IoT device.=C2=A0

Will the SUIT WG develop = the protocol/signaling that is depicted in Fig 4 of the I-D?

--
Basavaraj Patil
--0000000000006875a3056e10d77c-- From nobody Thu Jun 7 11:32:56 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B991131176 for ; Thu, 7 Jun 2018 11:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bz3n-HsKjrAD for ; Thu, 7 Jun 2018 11:32:37 -0700 (PDT) Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A063A130FC1 for ; Thu, 7 Jun 2018 11:32:36 -0700 (PDT) Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w57IWWo3030325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 7 Jun 2018 20:32:33 +0200 Received: from [192.168.16.50] (134.102.43.163) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.399.0; Thu, 7 Jun 2018 20:32:27 +0200 To: References: From: Henk Birkholz Message-ID: Date: Thu, 7 Jun 2018 20:28:20 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [134.102.43.163] Archived-At: Subject: Re: [Suit] Question about SUIT WG deliverable X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 18:32:54 -0000 Hello Basavaraj, to establish a basis, I will quote the 2nd last paragraph of the charter. > This group does not aim to create a standard for a generic application software > update mechanism, but instead this group will focus on firmware development > practices in the embedded industry. Software update solutions that target > updating software other than the firmware binaries (e.g., applications) are > also out of scope. This might seem to imply that conveyance seems to be mostly out of scope. The interaction model in the architecture seems most certainly to indicate otherwise. And I think there is a very good reason for this. The content of the manifest depends on its applications. If it is declarative guidance to be consumed by the target only, it can be minimal and very specific. If it is created in work-flows and distributed by entities that discover, validate, trust, pull/poll (or some hybrid of it) it in a way that is is a container for the actual firmware, it might require different conveyance procedures (and manifest content) than if it would "just" be pointing to the correct firmware (e.g. via URI) and acts as a type of imperative guidance to where to discover which payload that fits your "to-be-updated" thing appropriately at a given time. In a nutshell, SUIT might not mandate or even create specific protocols to achieve successful update campaigns. But depending on the application of the manifest, there might be multiple work-flows / interaction models and trust relationships defined by the SUIT WG in order to get that done reliably and trustworthy. This is an answer of a single individual. Dear WG, please comment about anything that might be wrong about what I just wrote :) Viele Grüße. Henk On 06/07/2018 07:44 PM, Basavaraj Patil wrote: > > Sec 7 of I-D: draft-ietf-suit-architecture-00 shows an example flow > depicting the end-2-end process of firmware updates of an IoT device. > > Will the SUIT WG develop the protocol/signaling that is depicted in Fig > 4 of the I-D? > > -- > Basavaraj Patil > > > _______________________________________________ > Suit mailing list > Suit@ietf.org > https://www.ietf.org/mailman/listinfo/suit > From nobody Thu Jun 7 13:50:28 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD08B12F1AB for ; Thu, 7 Jun 2018 13:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRyizU8lBJJq for ; Thu, 7 Jun 2018 13:50:18 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3907130DC1 for ; Thu, 7 Jun 2018 13:50:17 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id u4-v6so14675870itg.0 for ; Thu, 07 Jun 2018 13:50:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AMN7heFW+TOz0+YgWhypCOIq7IBomE2tT+l+ipZPTZ0=; b=I8V68bd35XqrFWWUMKtxcAorazckoO2WtAsGmwNQlbVca2/LTyZ6AKi8jEddPXgbdc dbFfZCmcMKqVzNIJal8Go4JyO2EtlXEe+jQfK+oyRTNmGHkFIoHXCYJ0gKybtE0Cpsi4 tSYUvK+A9PjmEhtB7ujMtretJXLjLjGads5YtBPW63I9y9ihNdxNEsnQ7wbpx/zbI2kz PscRW5b1250YomuXRAksOUpBLdctGO6LHGsNMXNUTwY/z7/OdCkSnzdlB3bfYYqA/tD4 CrO3NTOOPt4+MFFxvEGui8fvgU811QeDiABVPvUlDeCHuHYFAR0Xg/XVZJWaPcDAqAUz e2bA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AMN7heFW+TOz0+YgWhypCOIq7IBomE2tT+l+ipZPTZ0=; b=AmIV/Rt8ofxRMoiA9Ph9ploe8ocUlbAZJOzbw/kPyg0BCgk8BHFRgdApxGQ4lKTnTd WcKcnedWL76e09ndxdevq8f060+Rq6JffGSAHbS5eI10iFHtk1NNsC6UomTtlRvqru71 /j1ndIBXXNjFD/Mj+F7b0oXzKrPlFr3hZsbl2P63tG9B2f6rxT1Hk2zkoItSDqKlc++j sV/gOiRxf55WGt0zUDA72JuqjYcPmc1hoNVj1lex530MPxOI16mchT5qjk4Cl7nLpB7T YN4EalwcDlSZCDxRQe0Tl3+Iew7uZOUO0Gm9PhT3uFax7i2dh4aiZ1eaElTyGigt0SYb U8aA== X-Gm-Message-State: APt69E23aejXSlkwI6tg9yY/YacYSJxeFBjCdrOSkQgRDXVch+0EiXPR C61Ot2fSrbL2M5syAhixazZ4AZzbqFhsfgJLSA/jhwah X-Google-Smtp-Source: ADUXVKJtbua4RdlMIfc9uHaKPiGxjh1lVDi3Y19iF9HKkGypQHhBHGWGBAl1m+Z6x/8bX5UE2XwsB3EUf55vKiLnhrc= X-Received: by 2002:a24:148f:: with SMTP id 137-v6mr3159641itg.58.1528404617000; Thu, 07 Jun 2018 13:50:17 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:b88a:0:0:0:0:0 with HTTP; Thu, 7 Jun 2018 13:50:16 -0700 (PDT) In-Reply-To: References: From: Basavaraj Patil Date: Thu, 7 Jun 2018 15:50:16 -0500 Message-ID: To: Henk Birkholz Cc: suit@ietf.org Content-Type: multipart/alternative; boundary="00000000000044fc7e056e136eab" Archived-At: Subject: Re: [Suit] Question about SUIT WG deliverable X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 20:50:25 -0000 --00000000000044fc7e056e136eab Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Henk. While the charter itself is clear about not defining a protocol between the device and the server(s) that store the firmware images, I think it will be a shortcoming. The charter statement: " This group will not define any new transport or discovery mechanisms, but may describe how to use existing mechanisms within the architecture. " may alleviate the problem to some extent. However in the absence of a well defined protocol (in addition to the current goals of the charter), problems of interoperability and lack of adoption are what I fear. It would make sense to at the very least have a recommended protocol and approach that aligns with Fig 4 of the architecture. Rgds, -Basavaraj On Thu, Jun 7, 2018 at 1:28 PM, Henk Birkholz < henk.birkholz@sit.fraunhofer.de> wrote: > Hello Basavaraj, > > to establish a basis, I will quote the 2nd last paragraph of the charter. > > This group does not aim to create a standard for a generic application >> software >> update mechanism, but instead this group will focus on firmware >> development >> practices in the embedded industry. Software update solutions that targe= t >> updating software other than the firmware binaries (e.g., applications) >> are >> also out of scope. >> > > This might seem to imply that conveyance seems to be mostly out of scope. > The interaction model in the architecture seems most certainly to indicat= e > otherwise. > > And I think there is a very good reason for this. The content of the > manifest depends on its applications. If it is declarative guidance to be > consumed by the target only, it can be minimal and very specific. If it i= s > created in work-flows and distributed by entities that discover, validate= , > trust, pull/poll (or some hybrid of it) it in a way that is is a containe= r > for the actual firmware, it might require different conveyance procedures > (and manifest content) than if it would "just" be pointing to the correct > firmware (e.g. via URI) and acts as a type of imperative guidance to wher= e > to discover which payload that fits your "to-be-updated" thing > appropriately at a given time. > > In a nutshell, SUIT might not mandate or even create specific protocols t= o > achieve successful update campaigns. But depending on the application of > the manifest, there might be multiple work-flows / interaction models and > trust relationships defined by the SUIT WG in order to get that done > reliably and trustworthy. > > This is an answer of a single individual. Dear WG, please comment about > anything that might be wrong about what I just wrote :) > > Viele Gr=C3=BC=C3=9Fe. > > Henk > > > > > On 06/07/2018 07:44 PM, Basavaraj Patil wrote: > >> >> Sec 7 of I-D: draft-ietf-suit-architecture-00 shows an example flow >> depicting the end-2-end process of firmware updates of an IoT device. >> >> Will the SUIT WG develop the protocol/signaling that is depicted in Fig = 4 >> of the I-D? >> >> -- >> Basavaraj Patil >> >> >> _______________________________________________ >> Suit mailing list >> Suit@ietf.org >> https://www.ietf.org/mailman/listinfo/suit >> >> > _______________________________________________ > Suit mailing list > Suit@ietf.org > https://www.ietf.org/mailman/listinfo/suit > --=20 Basavaraj Patil --00000000000044fc7e056e136eab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Henk.=C2=A0

While the charter it= self is clear about not defining a protocol between the device and the serv= er(s) that store the firmware images, I think it will be a shortcoming.=C2= =A0
The charter statement:
"
Thi= s group will not define any new transport or discovery mechanisms,but may descri= be how to use existing mechanisms within the architecture.
"
may alleviate the problem to some extent.= =C2=A0

However in the absence of a well defined pr= otocol (in addition to the current goals of the charter), problems of inter= operability and lack of adoption are what I fear.=C2=A0
It would = make sense to at the very least have a recommended protocol and approach th= at aligns with Fig 4 of the architecture.=C2=A0

Rg= ds,
-Basavaraj



On Thu, Jun 7, 2018 at 1:2= 8 PM, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>= wrote:
Hello Basavaraj,

to establish a basis, I will quote the 2nd last paragraph of the charter.
This group does not aim to create a standard for a generic application soft= ware
update mechanism, but instead this group will focus on firmware development=
practices in the embedded industry. Software update solutions that target updating software other than the firmware binaries (e.g., applications) are=
also out of scope.

This might seem to imply that conveyance seems to be mostly out of scope. T= he interaction model in the architecture seems most certainly to indicate o= therwise.

And I think there is a very good reason for this. The content of the manife= st depends on its applications. If it is declarative guidance to be consume= d by the target only, it can be minimal and very specific. If it is created= in work-flows and distributed by entities that discover, validate, trust, = pull/poll (or some hybrid of it) it in a way that is is a container for the= actual firmware, it might require different conveyance procedures (and man= ifest content) than if it would "just" be pointing to the correct= firmware (e.g. via URI) and acts as a type of imperative guidance to where= to discover which payload that fits your "to-be-updated" thing a= ppropriately at a given time.

In a nutshell, SUIT might not mandate or even create specific protocols to = achieve successful update campaigns. But depending on the application of th= e manifest, there might be multiple work-flows / interaction models and tru= st relationships defined by the SUIT WG in order to get that done reliably = and trustworthy.

This is an answer of a single individual. Dear WG, please comment about any= thing that might be wrong about what I just wrote :)

Viele Gr=C3=BC=C3=9Fe.

Henk




On 06/07/2018 07:44 PM, Basavaraj Patil wrote:

Sec 7 of I-D:=C2=A0draft-ietf-suit-architecture-00 shows an example fl= ow depicting the end-2-end process of firmware updates of an IoT device.
Will the SUIT WG develop the protocol/signaling that is depicted in Fig 4 o= f the I-D?

--
Basavaraj Patil


_______________________________________________
Suit mailing list
Suit@ietf.org
https://www.ietf.org/mailman/listinfo/suit


_______________________________________________
Suit mailing list
Suit@ietf.org
https://www.ietf.org/mailman/listinfo/suit



--
Basavaraj Patil
--00000000000044fc7e056e136eab-- From nobody Fri Jun 8 03:22:14 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C4A2130E6C for ; Fri, 8 Jun 2018 03:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKlWU4Np7_WQ for ; Fri, 8 Jun 2018 03:22:09 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60055.outbound.protection.outlook.com [40.107.6.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35EA6130E5E for ; Fri, 8 Jun 2018 03:22:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Q4tDzqd+hEg//yZhDD0HhKRSUTep9s1nV1q/MHViwdA=; b=buoujNcRz5lqUQ/CgE3DrCoUr1/4+esby7tpHiR0wqgnBbtexgkfzhnv2cRE1G11bCGnN6NJD7+qLH+9wehLdjvt0H/+VRX8c5Tun662OiGt12SPMHjiSRKEHOHLzP8/hpgt0zy6ffocx5J+6nABmto0b1DtRbSicFBjan/dpN8= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1325.eurprd08.prod.outlook.com (10.167.197.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.841.15; Fri, 8 Jun 2018 10:22:05 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35%4]) with mapi id 15.20.0841.015; Fri, 8 Jun 2018 10:22:05 +0000 From: Hannes Tschofenig To: Russ Housley , "suit@ietf.org" Thread-Topic: [Suit] draft-housley-suit-cose-hash-sig-00 Thread-Index: AQHT+Clq7AlzFr9/c0GuUxBxtsXX/qRWNBLQ Date: Fri, 8 Jun 2018 10:22:05 +0000 Message-ID: References: <152769328559.27675.9111953735277048667.idtracker@ietfa.amsl.com> <3FAC68D9-C9A0-4A57-A233-E695D58BAA11@vigilsec.com> In-Reply-To: <3FAC68D9-C9A0-4A57-A233-E695D58BAA11@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.115.197] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1325; 7:DdilSVfDH5fZHQYWhCJ2OQT8of+Zky8GfWqA6rgMWNGfOz6kW/tzTY8rvLyFuIKGZrQNLBUJ+29SBUY2+LNijlYNngwCfhnruAJ+bEdedWIEhOzKNdoLkYQKLKUlLNwawPNxHlZFvIzeCn7vdJwKOVzRUdr3fFKo2ABXF6YsOIeJ/FwZp+uTkdnNsGxNBKFoe3hGYnRXB3ZTphFmGA1Tfnw2yH6YsWrq/BFoctQSvNkzHRhWo1qHoA0YIf9oqyIl x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1325; x-ms-traffictypediagnostic: VI1PR0801MB1325: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(120809045254105)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB1325; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1325; x-forefront-prvs: 06973FFAD3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(39860400002)(396003)(346002)(366004)(376002)(40434004)(189003)(199004)(33656002)(606006)(74316002)(186003)(105586002)(446003)(6116002)(790700001)(106356001)(11346002)(2900100001)(25786009)(3660700001)(54896002)(3280700002)(236005)(53386004)(102836004)(476003)(8676002)(9686003)(53936002)(6246003)(478600001)(7736002)(26005)(97736004)(8936002)(486006)(81156014)(81166006)(6306002)(7696005)(5250100002)(99286004)(316002)(86362001)(2501003)(59450400001)(55016002)(72206003)(76176011)(53546011)(2906002)(6506007)(966005)(14971765001)(6436002)(1680700002)(14454004)(3846002)(66066001)(110136005)(68736007)(5890100001)(5660300001)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1325; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: DZNgFaRSOEG8t4iFHtyJIskm4nbSZmlTCdMStWXhjXvq/SvEqRoIwYJfZqBGVCQuRG+iRU9Lo+pmltHwDgbDOyBIv+auKGX2azzMhN1WK2evSYBT6XzbhnA5un/0M0PbfVkjOzxEIhM8K8yPRFYqIFpdySlMWq6S/6WhpEw7ZruQIsW84G6gSLv1JNm6w/mg spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB2112E5603A4848DEB6DBEAAAFA7B0VI1PR0801MB2112_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 759eb07a-ac2e-44a2-6eb0-08d5cd29af21 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 759eb07a-ac2e-44a2-6eb0-08d5cd29af21 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2018 10:22:05.7609 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1325 Archived-At: Subject: Re: [Suit] draft-housley-suit-cose-hash-sig-00 X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2018 10:22:13 -0000 --_000_VI1PR0801MB2112E5603A4848DEB6DBEAAAFA7B0VI1PR0801MB2112_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Following the discussion at the virtual interim meeting (where I couldn't r= aise my remark) I wanted to state that I believe that this work fits nicely= in SUIT given that a well identified use case with this technology is the = SUIT firmware update. I am also hoping that more folks join us at a future hackathon/interop even= t and integrate/implement this mechanism as well. From: Suit [mailto:suit-bounces@ietf.org] On Behalf Of Russ Housley Sent: 30 May 2018 17:18 To: suit@ietf.org Subject: [Suit] draft-housley-suit-cose-hash-sig-00 In London, I advocated the use of hash-based signatures. To dates, no one = had written down how to use hash-based signatures with CBOR and COSE. So, = I wrote an Internet-Draft. Please review and comment. Thanks, Russ From: internet-drafts@ietf.org Subject: New Version Notification for draft-housley-suit-cose-hash-sig-00.t= xt Date: May 30, 2018 at 11:14:45 AM EDT To: "Russ Housley" > A new version of I-D, draft-housley-suit-cose-hash-sig-00.txt has been successfully submitted by Russ Housley and posted to the IETF repository. Name: draft-housley-suit-cose-hash-sig Revision: 00 Title: Use of the Hash-based Signature Algorithm with CBOR Ob= ject Signing and Encryption (COSE) Document date: 2018-05-30 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/internet-drafts/draft-housley-suit-cos= e-hash-sig-00.txt Status: https://datatracker.ietf.org/doc/draft-housley-suit-cose-ha= sh-sig/ Htmlized: https://tools.ietf.org/html/draft-housley-suit-cose-hash-si= g-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-housley-suit-co= se-hash-sig Abstract: This document specifies the conventions for using the Leighton-Micali Signature (LMS) algorithm for digital signatures with the CBOR Object Signing and Encryption (COSE) syntax. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_VI1PR0801MB2112E5603A4848DEB6DBEAAAFA7B0VI1PR0801MB2112_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Following the discussion = at the virtual interim meeting (where I couldn’t raise my remark) I w= anted to state that I believe that this work fits nicely in SUIT given that a well identified use case with this technology is the SUIT fir= mware update.

I am also hoping that mor= e folks join us at a future hackathon/interop event and integrate/implement= this mechanism as well.

 

From: Suit [mailto:suit-bounces@ietf.org] On Behalf Of Russ Housley
Sent: 30 May 2018 17:18
To: suit@ietf.org
Subject: [Suit] draft-housley-suit-cose-hash-sig-00

 

In London, I advocated the use of hash-based signatu= res.  To dates, no one had written down how to use hash-based signatur= es with CBOR and COSE.  So, I wrote an Internet-Draft.

 

Please review and comment.

 

Thanks,

  Russ

 



From: internet-drafts@ietf.org<= /span>

Subject: New Version Notification for draft-housley= -suit-cose-hash-sig-00.txt

Date: May 30, 2018 at 11:14:45 AM EDT

To: "Russ Housley" <hous= ley@vigilsec.com>

 


A new version of I-D, draft-housley-suit-cose-hash-sig-00.txt
has been successfully submitted by Russ Housley and posted to the
IETF repository.

Name:      &nb= sp;      draft-housley-suit-cose-hash-sig Revision:      = ;   00
Title:      &n= bsp;        Use of the Hash-based= Signature Algorithm with CBOR Object Signing and Encryption (COSE)
Document date:     =      2018-05-30
Group:      &n= bsp;      Individual Submission
Pages:      &n= bsp;       10
URL:            https://www.ietf.org/internet-drafts/draft-housley-suit-cose-hash= -sig-00.txt
Status:         https://datatra= cker.ietf.org/doc/draft-housley-suit-cose-hash-sig/
Htmlized:       https://tools.ietf.org/html/= draft-housley-suit-cose-hash-sig-00
Htmlized:       https://datatracker.i= etf.org/doc/html/draft-housley-suit-cose-hash-sig


Abstract:
  This document specifies the conventions for using the Leighton-= Micali
  Signature (LMS) algorithm for digital signatures with the CBOR = Object
  Signing and Encryption (COSE) syntax.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_VI1PR0801MB2112E5603A4848DEB6DBEAAAFA7B0VI1PR0801MB2112_-- From nobody Tue Jun 12 09:23:14 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C55B4129C6B for ; Tue, 12 Jun 2018 09:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3AR6tsrtLm1 for ; Tue, 12 Jun 2018 09:23:05 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3303A12D949 for ; Tue, 12 Jun 2018 09:23:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 248D8300A3D for ; Tue, 12 Jun 2018 12:23:01 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 7qWlhVZTVKuO for ; Tue, 12 Jun 2018 12:22:59 -0400 (EDT) Received: from a860b60074bd.home (pool-71-127-50-4.washdc.fios.verizon.net [71.127.50.4]) by mail.smeinc.net (Postfix) with ESMTPSA id C95F1300A1E for ; Tue, 12 Jun 2018 12:22:59 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_A0EBA363-C453-4DC5-9F3F-7EA93325E139" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <55479761-6831-43EC-B70B-4B52434ECF8B@vigilsec.com> References: <152882050403.9242.9815145590799694652.idtracker@ietfa.amsl.com> To: suit@ietf.org Date: Tue, 12 Jun 2018 12:23:00 -0400 X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Suit] Fwd: New Version Notification for draft-housley-suit-cose-hash-sig-01.txt X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 16:23:11 -0000 --Apple-Mail=_A0EBA363-C453-4DC5-9F3F-7EA93325E139 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This handles some minor comments received in private email. Russ > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-housley-suit-cose-hash-sig-01.txt > Date: June 12, 2018 at 12:21:44 PM EDT > To: "Russ Housley" >=20 >=20 > A new version of I-D, draft-housley-suit-cose-hash-sig-01.txt > has been successfully submitted by Russ Housley and posted to the > IETF repository. >=20 > Name: draft-housley-suit-cose-hash-sig > Revision: 01 > Title: Use of the Hash-based Signature Algorithm with = CBOR Object Signing and Encryption (COSE) > Document date: 2018-06-12 > Group: Individual Submission > Pages: 10 > URL: = https://www.ietf.org/internet-drafts/draft-housley-suit-cose-hash-sig-01.t= xt > Status: = https://datatracker.ietf.org/doc/draft-housley-suit-cose-hash-sig/ > Htmlized: = https://tools.ietf.org/html/draft-housley-suit-cose-hash-sig-01 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-housley-suit-cose-hash-sig > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-housley-suit-cose-hash-sig-01 >=20 > Abstract: > This document specifies the conventions for using the = Leighton-Micali > Signature (LMS) algorithm for digital signatures with the CBOR = Object > Signing and Encryption (COSE) syntax. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_A0EBA363-C453-4DC5-9F3F-7EA93325E139 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This handles some minor comments received in private = email.

Russ


From: internet-drafts@ietf.org
Subject: = New Version = Notification for draft-housley-suit-cose-hash-sig-01.txt
Date: = June 12, 2018 at 12:21:44 PM = EDT
To: = "Russ Housley" <housley@vigilsec.com>


A new version = of I-D, draft-housley-suit-cose-hash-sig-01.txt
has been = successfully submitted by Russ Housley and posted to the
IETF repository.

Name: = draft-housley-suit-cose-hash-sig
Revision: 01
Title:= = Use of the Hash-based Signature Algorithm with CBOR Object = Signing and Encryption (COSE)
Document date: = 2018-06-12
Group: Individual Submission
Pages:= = 10
URL: =            https://www.ietf.org/internet-drafts/draft-housley-suit-cose-ha= sh-sig-01.txt
Status: =         https://datatracker.ietf.org/doc/draft-housley-suit-cose-hash-s= ig/
Htmlized:       https://tools.ietf.org/html/draft-housley-suit-cose-hash-sig-01=
Htmlized:       https://datatracker.ietf.org/doc/html/draft-housley-suit-cose-h= ash-sig
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-housley-suit-cose-has= h-sig-01

Abstract:
=   This document specifies the conventions for using the = Leighton-Micali
  Signature (LMS) algorithm for = digital signatures with the CBOR Object
=   Signing and Encryption (COSE) syntax.




Please note that = it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


= --Apple-Mail=_A0EBA363-C453-4DC5-9F3F-7EA93325E139-- From nobody Wed Jun 13 07:23:58 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC517130E30 for ; Wed, 13 Jun 2018 07:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rE8xgWW0RJ8o for ; Wed, 13 Jun 2018 07:23:55 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-am5eur03on0619.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe08::619]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9974C130E29 for ; Wed, 13 Jun 2018 07:23:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=q3+Ea3iLPYh28qw/bAqcetAwFeB6lBHiggSWI47/JQE=; b=ccLcNNL1R5amEB4fgf344dabek21I4fr9fiiQXq3lIyX5CyLGTQ65IvEKcF1rIgppBiPJNTp6mLw8zF/hb50c5ioSfCXOJe4ixPQ/vEJ7ZU0uBg/C4nanXx+VRum/RcS9UKZRG7EhqwmZarQ8stoO7xNb8UBGKffA6vnIqwVB4o= Received: from AM4PR0802MB2260.eurprd08.prod.outlook.com (10.172.217.150) by AM4PR0802MB2161.eurprd08.prod.outlook.com (10.172.217.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.14; Wed, 13 Jun 2018 14:23:52 +0000 Received: from AM4PR0802MB2260.eurprd08.prod.outlook.com ([fe80::15ab:db2e:593b:b5e0]) by AM4PR0802MB2260.eurprd08.prod.outlook.com ([fe80::15ab:db2e:593b:b5e0%4]) with mapi id 15.20.0863.010; Wed, 13 Jun 2018 14:23:52 +0000 From: Brendan Moran To: suit Thread-Topic: [Suit] New preliminary information model draft Thread-Index: AQHUAyInd5ozUMAdYkWIuIPZHOppjw== Date: Wed, 13 Jun 2018 14:23:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.8.2) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brendan.Moran@arm.com; x-originating-ip: [217.140.96.140] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0802MB2161; 7:aNX9a0Zcc97+kjofJLNPgDQOJ+WPWd3kAVNQ1YlEDTQDCeDVM13s5TG2HDK41WpSgOVhUP4643eHNQOGUvx3f12ufPk7m/H0bOlTIafPrmMhHxiExinokwy6YA1veJb2Muyg4+Tl34K1n6+3qf9BrFYA4BfABVDfd3XSEhrCmbI4lCcMUMVopeknycH55PbJgFgGYk6CUu/a6e29CpUMKRHr4sihpbfqByJN7Letn6Bst61gcnJaXkm1AfpmQRwW x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant X-MS-Office365-Filtering-Correlation-Id: 21685c24-18ca-434f-ab9f-08d5d13949a6 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:AM4PR0802MB2161; x-ms-traffictypediagnostic: AM4PR0802MB2161: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231254)(944501410)(52105095)(10201501046)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123558120)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:AM4PR0802MB2161; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0802MB2161; x-forefront-prvs: 07025866F6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(39380400002)(396003)(376002)(346002)(366004)(40434004)(199004)(189003)(5890100001)(36756003)(25786009)(102836004)(6486002)(5250100002)(6436002)(236005)(57306001)(6116002)(3846002)(53936002)(6512007)(82746002)(68736007)(54896002)(6506007)(106356001)(86362001)(26005)(6306002)(105586002)(97736004)(486006)(14454004)(33656002)(59450400001)(478600001)(2616005)(7736002)(72206003)(476003)(5660300001)(966005)(8936002)(1857600001)(186003)(66066001)(83716003)(606006)(99286004)(2900100001)(3280700002)(2906002)(50226002)(81156014)(8676002)(316002)(81166006)(6916009)(3660700001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0802MB2161; H:AM4PR0802MB2260.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 1nocvMV/wXcRm5jaxpR5NPHJOFwPek1KS5dO48t5QWSm46WlonPMNRG5ro12k6hQoy8XB07oel/CW0b4fFWwDA0uLVM28G4YrI23grMmQvr3uxZL1zdMB4dgsN7FK1pOOYZ/hKDNMXFdvtrOarxB1w3nhgHlS0EgaQ3cb5aMuLowkcOwgkYc1FHM5le9q20C spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_A48809A5E7CE4404B39DA1702C672923armcom_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 21685c24-18ca-434f-ab9f-08d5d13949a6 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jun 2018 14:23:52.0672 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0802MB2161 Archived-At: Subject: [Suit] New preliminary information model draft X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 14:23:58 -0000 --_000_A48809A5E7CE4404B39DA1702C672923armcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBoYXZlIHVwbG9hZGVkIGEgbmV3IGluZm9ybWF0aW9uIG1vZGVsIGRyYWZ0IHRvIHRoZSBzdWl0 LXdnIHJlcG86DQpodHRwczovL2dpdGh1Yi5jb20vc3VpdC13Zy9pbmZvcm1hdGlvbi1tb2RlbC9i bG9iL3YwMS9kcmFmdC1pZXRmLXN1aXQtaW5mb3JtYXRpb24tbW9kZWwubWQNCg0KWW91IGNhbiBz ZWUgdGhlIGRpZmYgdXNpbmcgR2l0aHVi4oCZcyBjb21wYXJpc29uIHRvb2w6DQpodHRwczovL2dp dGh1Yi5jb20vc3VpdC13Zy9pbmZvcm1hdGlvbi1tb2RlbC9jb21wYXJlL21hc3Rlci4uLnYwMQ0K DQpCZXN0IFJlZ2FyZHMsDQpCcmVuZGFuDQoNCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50 cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQg bWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lw aWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlz Y2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1 cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRo YW5rIHlvdS4NCg== --_000_A48809A5E7CE4404B39DA1702C672923armcom_ Content-Type: text/html; charset="utf-8" Content-ID: <0CC20658998BC64083C4EB8ED4E6D07C@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkkgaGF2ZSB1cGxvYWRlZCBhIG5ldyBpbmZvcm1h dGlvbiBtb2RlbCBkcmFmdCB0byB0aGUgc3VpdC13ZyByZXBvOiZuYnNwOw0KPGRpdiBjbGFzcz0i Ij48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vc3VpdC13Zy9pbmZvcm1hdGlvbi1tb2RlbC9i bG9iL3YwMS9kcmFmdC1pZXRmLXN1aXQtaW5mb3JtYXRpb24tbW9kZWwubWQiIGNsYXNzPSIiPmh0 dHBzOi8vZ2l0aHViLmNvbS9zdWl0LXdnL2luZm9ybWF0aW9uLW1vZGVsL2Jsb2IvdjAxL2RyYWZ0 LWlldGYtc3VpdC1pbmZvcm1hdGlvbi1tb2RlbC5tZDwvYT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPllvdSBjYW4gc2VlIHRoZSBkaWZm IHVzaW5nIEdpdGh1YuKAmXMgY29tcGFyaXNvbiB0b29sOjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vc3VpdC13Zy9pbmZvcm1hdGlvbi1tb2RlbC9jb21w YXJlL21hc3Rlci4uLnYwMSIgY2xhc3M9IiI+aHR0cHM6Ly9naXRodWIuY29tL3N1aXQtd2cvaW5m b3JtYXRpb24tbW9kZWwvY29tcGFyZS9tYXN0ZXIuLi52MDE8L2E+PC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5CZXN0IFJlZ2FyZHMsPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPkJyZW5kYW48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFp bCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHBy aXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250 ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLA0KIG9yIHN0 b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_A48809A5E7CE4404B39DA1702C672923armcom_-- From nobody Wed Jun 13 11:12:12 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 245C8130F69 for ; Wed, 13 Jun 2018 11:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFUjKyMsvVfz for ; Wed, 13 Jun 2018 11:12:07 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F6D8130E06 for ; Wed, 13 Jun 2018 11:12:07 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 771D020090 for ; Wed, 13 Jun 2018 14:25:57 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 0F5BD53; Wed, 13 Jun 2018 14:09:11 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0C0EB4F for ; Wed, 13 Jun 2018 14:09:11 -0400 (EDT) From: Michael Richardson To: suit X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Suit] draft-housley-suit-cose-hash-sig X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 18:12:10 -0000 --=-=-= Content-Type: text/plain I have read the -01 draft today. I have not read [HASHSIG] yet. I thought I'd try reading this first, to see what questions I had. I have implemented COSE Sign1 with ECDSA in Ruby, so I have a grasp of what we are trying to plug hash-sig *into*. Suggestions: 1) would the structure show in section 3 be easier if it was described by CDDL? I'm rather unclear about this. 2) I din't understand section 4, where it says: o If the 'key_ops' field is present, it MUST include 'sign' when creating a hash-based signature. o If the 'key_ops' field is present, it MUST include 'verify' when verifying a hash-based signature. Clearly this is not something that travels over the network. Is this somehow indicating how to understand if one is dealing a public (verify) key or a private (sign) key? 3) the variations: LMS_SHA256_M32_H20, and LMOTS_SHA256_N32_W2, etc. are listed, but I don't know if they need to be carried in the signature structure somehow. 4) I thought that perhaps we'd need CBOR or COSE specific way to transport the signatures. I guess I shall read HASHSIG to find out what the signatures look like. I understand draft-mcgrew-hash-sigs-11 is being advanced by CFRG. I believe that SUIT should adopt this document, and should do so in the current state. I would like to have some examples in CBOR/COSE worked out with private keys available in the appendices. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWyFdxICLcPvd0N1lAQIz3Qf/dXoMUw9oObyYH8jDCN8ppL/xotu+EdDZ BoXZWBrq1Lu5Ok2BeS2Kn+BWqdkFnuZPlCa4gyci8tGJDK3F3D0eCWBH7zKB2nuR vEnFn+4+DQmwDq+1oyO107GcEjulekKdCJBV3UiBVBUGbpiJBg7bbkZVbeX+2ce2 NhvGgm5TGdnvR2UAhpPjmKLDM4GmT2PEfZ50eu2B4TYgc+oTO0B+J8+QtnWSr5sP KngrFGXigVs/XsagnxjL+DZGrlKFq9c+gg/S4t0hDeDZqjqCZWuhRra4nYAiicpX 5eCulUJilxE10Qo1o6dJf/cQw2QAtM0AGfEcbWw9QeuE3a/BuF57SQ== =RSWJ -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 13 11:19:54 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EFC7130F75 for ; Wed, 13 Jun 2018 11:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWNW3jt2SEUl for ; Wed, 13 Jun 2018 11:19:51 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36CF4130F69 for ; Wed, 13 Jun 2018 11:19:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 0920F300A3E for ; Wed, 13 Jun 2018 14:19:49 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 1b0HyBW9d8B6 for ; Wed, 13 Jun 2018 14:19:47 -0400 (EDT) Received: from a860b60074bd.home (pool-71-127-50-4.washdc.fios.verizon.net [71.127.50.4]) by mail.smeinc.net (Postfix) with ESMTPSA id 8B82F3004FE; Wed, 13 Jun 2018 14:19:47 -0400 (EDT) From: Russ Housley Message-Id: <20C674CE-D177-498C-BC1C-CD5D2A01DC7F@vigilsec.com> Content-Type: multipart/signed; boundary="Apple-Mail=_B9E51B36-4B05-487F-819E-736E35969168"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 13 Jun 2018 14:19:49 -0400 In-Reply-To: <31676.1528913351@localhost> Cc: suit To: Michael Richardson References: <31676.1528913351@localhost> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Suit] draft-housley-suit-cose-hash-sig X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 18:19:53 -0000 --Apple-Mail=_B9E51B36-4B05-487F-819E-736E35969168 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Michael: Thanks for reading. I think you need to look at [HASHSIG]. It uses XDR = [RFC4506] to represent the signatures. The XXDR structures are in = Section 7 of [HASHSIG]. Russ > On Jun 13, 2018, at 2:09 PM, Michael Richardson = wrote: >=20 >=20 > I have read the -01 draft today. > I have not read [HASHSIG] yet. > I thought I'd try reading this first, to see what questions I had. >=20 > I have implemented COSE Sign1 with ECDSA in Ruby, so I have a grasp of > what we are trying to plug hash-sig *into*. >=20 >=20 > Suggestions: > 1) would the structure show in section 3 be easier if it was described = by > CDDL? I'm rather unclear about this. >=20 > 2) I din't understand section 4, where it says: > o If the 'key_ops' field is present, it MUST include 'sign' when > creating a hash-based signature. >=20 > o If the 'key_ops' field is present, it MUST include 'verify' > when verifying a hash-based signature. >=20 > Clearly this is not something that travels over the network. Is this > somehow indicating how to understand if one is dealing a public = (verify) key > or a private (sign) key? >=20 > 3) the variations: LMS_SHA256_M32_H20, and LMOTS_SHA256_N32_W2, etc. = are > listed, but I don't know if they need to be carried in the signature > structure somehow. >=20 > 4) I thought that perhaps we'd need CBOR or COSE specific way to = transport > the signatures. I guess I shall read HASHSIG to find out what the > signatures look like. >=20 > I understand draft-mcgrew-hash-sigs-11 is being advanced by CFRG. > I believe that SUIT should adopt this document, and should do so in = the > current state. >=20 > I would like to have some examples in CBOR/COSE worked out with = private keys > available in the appendices. >=20 > -- > ] Never tell me the odds! | ipv6 mesh = networks [ > ] Michael Richardson, Sandelman Software Works | network = architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on = rails [ >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > _______________________________________________ > Suit mailing list > Suit@ietf.org > https://www.ietf.org/mailman/listinfo/suit --Apple-Mail=_B9E51B36-4B05-487F-819E-736E35969168 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iF0EARECAB0WIQRJuTEKFXbtfFQz5huK5O7Q9ZwRywUCWyFgRQAKCRCK5O7Q9ZwR y/+TAKDu39hciVjBY0GtU85hq3HetFEmxwCfe6K22omGKY9LahfIFjyhD+6sFcw= =48Q2 -----END PGP SIGNATURE----- --Apple-Mail=_B9E51B36-4B05-487F-819E-736E35969168-- From nobody Wed Jun 13 12:03:35 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68C2F130E88 for ; Wed, 13 Jun 2018 12:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNZTQwp93trE for ; Wed, 13 Jun 2018 12:03:31 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44B3B126CB6 for ; Wed, 13 Jun 2018 12:03:31 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 13 Jun 2018 12:00:28 -0700 From: Jim Schaad To: 'Michael Richardson' , 'suit' References: <31676.1528913351@localhost> In-Reply-To: <31676.1528913351@localhost> Date: Wed, 13 Jun 2018 12:03:22 -0700 Message-ID: <04f401d40349$33a58b10$9af0a130$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHwZWPvfC0oH/KJpPKzh2KFlMHiSaQlxdig Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Suit] draft-housley-suit-cose-hash-sig X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 19:03:34 -0000 > -----Original Message----- > From: Suit On Behalf Of Michael Richardson > Sent: Wednesday, June 13, 2018 11:09 AM > To: suit > Subject: [Suit] draft-housley-suit-cose-hash-sig > > > I have read the -01 draft today. > I have not read [HASHSIG] yet. > I thought I'd try reading this first, to see what questions I had. > > I have implemented COSE Sign1 with ECDSA in Ruby, so I have a grasp of > what we are trying to plug hash-sig *into*. > > > Suggestions: > 1) would the structure show in section 3 be easier if it was described by > CDDL? I'm rather unclear about this. No - this are not CBOR structures they are pure binary strings > > 2) I din't understand section 4, where it says: > o If the 'key_ops' field is present, it MUST include 'sign' when > creating a hash-based signature. > > o If the 'key_ops' field is present, it MUST include 'verify' > when verifying a hash-based signature. > > Clearly this is not something that travels over the network. Is this somehow > indicating how to understand if one is dealing a public (verify) key or a private > (sign) key? The key_ops field can be considered to potentially be transported over a network. It is part of the COSE_Key object rather than part of the COSE_Sign1 object. > > 3) the variations: LMS_SHA256_M32_H20, and LMOTS_SHA256_N32_W2, > etc. are > listed, but I don't know if they need to be carried in the signature > structure somehow. See the [HASHSIG] draft. It is encoded into the signature structure and the key type is in the public key structure. > > 4) I thought that perhaps we'd need CBOR or COSE specific way to transport > the signatures. I guess I shall read HASHSIG to find out what the > signatures look like. We have that. This is looking at a signature just like ECDSA would produce. This is a different "ECDSA" replacement. > > I understand draft-mcgrew-hash-sigs-11 is being advanced by CFRG. > I believe that SUIT should adopt this document, and should do so in the > current state. > > I would like to have some examples in CBOR/COSE worked out with private > keys available in the appendices. Always a good thing to have. Jim > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | network architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > From nobody Thu Jun 14 04:06:39 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79CCA130E11 for ; Thu, 14 Jun 2018 04:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U1GYetIAFuGf for ; Thu, 14 Jun 2018 04:06:36 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12B71130E0A for ; Thu, 14 Jun 2018 04:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w5EB6Wjx019171 for ; Thu, 14 Jun 2018 13:06:32 +0200 (CEST) Received: from [192.168.217.114] (p5DC7E3F3.dip0.t-ipconnect.de [93.199.227.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41615h0jNRzDXP6; Thu, 14 Jun 2018 13:06:32 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Carsten Bormann In-Reply-To: Date: Thu, 14 Jun 2018 13:06:31 +0200 X-Mao-Original-Outgoing-Id: 550667190.191422-7ca7aa9780712806125dc536ba3e8f09 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: suit X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Suit] New preliminary information model draft X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 11:06:39 -0000 =E2=80=A6 and, if you are interested in this, you may want to take part = in the informal web call we are having in about 23 minutes at > 13:30..15:00 CEST on https://jitsi.tools.ietf.org/suit-dt Gr=C3=BC=C3=9Fe, Carsten > On Jun 13, 2018, at 16:23, Brendan Moran = wrote: >=20 > I have uploaded a new information model draft to the suit-wg repo:=20 > = https://github.com/suit-wg/information-model/blob/v01/draft-ietf-suit-info= rmation-model.md >=20 > You can see the diff using Github=E2=80=99s comparison tool: > https://github.com/suit-wg/information-model/compare/master...v01 >=20 > Best Regards, > Brendan >=20 > IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy = the information in any medium. Thank you. > _______________________________________________ > Suit mailing list > Suit@ietf.org > https://www.ietf.org/mailman/listinfo/suit From nobody Thu Jun 14 04:15:36 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 138B4130F3F for ; Thu, 14 Jun 2018 04:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id REvFjYgUwjkY for ; Thu, 14 Jun 2018 04:15:32 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61903130EAC for ; Thu, 14 Jun 2018 04:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w5EBFSHr026602; Thu, 14 Jun 2018 13:15:28 +0200 (CEST) Received: from [192.168.217.114] (p5DC7E3F3.dip0.t-ipconnect.de [93.199.227.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4161Hz5w99zDXPG; Thu, 14 Jun 2018 13:15:27 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Carsten Bormann In-Reply-To: Date: Thu, 14 Jun 2018 13:15:27 +0200 Cc: suit X-Mao-Original-Outgoing-Id: 550667725.518422-b05173fd01fc38f45b12982edc46a2b9 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Brendan Moran X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Suit] New preliminary information model draft X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 11:15:34 -0000 I believe MFT10 and its mitigations still confuse =E2=80=94 is the sender *authorized* to make claims about the firmware = image at hand for device X =E2=80=94 does the sender *intend* to make a claim about this firmware = destined for device X The first one can be supported by ACLs. But the sender may very well be authorized to make a claim, it may just = not want to, pertaining to device X. In general, signed claims may need destination verification. In a CWT, this is often done with the =E2=80=9Caud=E2=80=9D claim field. I have not made up my mind if something like that is enough here as well = or we need something more well structured for destination verification. Gr=C3=BC=C3=9Fe, Carsten > On Jun 13, 2018, at 16:23, Brendan Moran = wrote: >=20 > I have uploaded a new information model draft to the suit-wg repo:=20 > = https://github.com/suit-wg/information-model/blob/v01/draft-ietf-suit-info= rmation-model.md >=20 > You can see the diff using Github=E2=80=99s comparison tool: > https://github.com/suit-wg/information-model/compare/master...v01 >=20 > Best Regards, > Brendan >=20 > IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy = the information in any medium. Thank you. > _______________________________________________ > Suit mailing list > Suit@ietf.org > https://www.ietf.org/mailman/listinfo/suit From nobody Thu Jun 14 04:29:28 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2BFE13112C for ; Thu, 14 Jun 2018 04:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1p60uvMQqwY for ; Thu, 14 Jun 2018 04:29:24 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97E5613112F for ; Thu, 14 Jun 2018 04:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w5EBTHhA006457; Thu, 14 Jun 2018 13:29:18 +0200 (CEST) Received: from [192.168.217.114] (p5DC7E3F3.dip0.t-ipconnect.de [93.199.227.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4161bx1HnFzDXPT; Thu, 14 Jun 2018 13:29:17 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Carsten Bormann In-Reply-To: Date: Thu, 14 Jun 2018 13:29:16 +0200 Cc: suit X-Mao-Original-Outgoing-Id: 550668555.254382-8de144290b2404b54f93c2d11cfe6f0b Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Brendan Moran X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Suit] New preliminary information model draft X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 11:29:26 -0000 A few more items (some editorial): "optional to implement" -- do we need to talk about protocol evolution (extensibility), specifically about ignorable (elective) and mandatory (critical) elements? * referencing RFC 4122: cite in 4.3 * why are we using pre-RFC5378 boilerplate? * The "use UTC as serial" text is a hint for implementers/users, not = part of the information model. * Confidential Information Disclosures (what is confidential?) -> = Disclosures of Confidential Information * "version" (an identifier space implying some form of ordering) vs. = "identifier" (no such implication) * "last application time" -- the time this was last applied? Gr=C3=BC=C3=9Fe, Carsten > On Jun 14, 2018, at 13:15, Carsten Bormann wrote: >=20 > I believe MFT10 and its mitigations still confuse >=20 > =E2=80=94 is the sender *authorized* to make claims about the firmware = image at hand for device X > =E2=80=94 does the sender *intend* to make a claim about this firmware = destined for device X >=20 > The first one can be supported by ACLs. > But the sender may very well be authorized to make a claim, it may = just not want to, pertaining to device X. >=20 > In general, signed claims may need destination verification. >=20 > In a CWT, this is often done with the =E2=80=9Caud=E2=80=9D claim = field. > I have not made up my mind if something like that is enough here as = well or we need something more well structured for destination = verification. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 >=20 >> On Jun 13, 2018, at 16:23, Brendan Moran = wrote: >>=20 >> I have uploaded a new information model draft to the suit-wg repo:=20 >> = https://github.com/suit-wg/information-model/blob/v01/draft-ietf-suit-info= rmation-model.md >>=20 >> You can see the diff using Github=E2=80=99s comparison tool: >> https://github.com/suit-wg/information-model/compare/master...v01 >>=20 >> Best Regards, >> Brendan >>=20 >> IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy = the information in any medium. Thank you. >> _______________________________________________ >> Suit mailing list >> Suit@ietf.org >> https://www.ietf.org/mailman/listinfo/suit >=20 >=20 >=20 From nobody Thu Jun 14 06:12:07 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B634C13114E for ; Thu, 14 Jun 2018 06:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcS_P-LdYvmp for ; Thu, 14 Jun 2018 06:11:56 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0084.outbound.protection.outlook.com [104.47.2.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF55113115D for ; Thu, 14 Jun 2018 06:11:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fjsN+6UXeiwzjQcwxtMYtWSQclWkL1jVoF5MqNVlARY=; b=sQXJNaXiueTPmcltA9ntlkBjyErEbvl20jXqD3N9xcYFbJkHNM1ZCHO1ecOu819QT9zikysppnWprVB2rAqNluzbhXjwyU7h92oInwN88l4bKxrf2nwi4jVN6vRRtjMsr4gk82QP4YiV9SPXJPZ8u3lN5A72dIpXYzCdXsBsQRA= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1358.eurprd08.prod.outlook.com (10.167.198.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.841.16; Thu, 14 Jun 2018 13:11:53 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35%4]) with mapi id 15.20.0841.019; Thu, 14 Jun 2018 13:11:53 +0000 From: Hannes Tschofenig To: "suit@ietf.org" Thread-Topic: SUIT Conference Call Minutes - 14th June 2018 Thread-Index: AdQD4RWFB1sO4QG2QU+xcJ0lVo3uJw== Date: Thu, 14 Jun 2018 13:11:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [156.67.195.102] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1358; 7:vaCLdhuJo8Wyq7Kt30ifC45ZxmiZD2KWog6amZe3LrXWhwI1t8/pJrauy9iB8VUiE2cGKdBYvuUiznHljrwdCKL7BqNBK7oBYLu+2xl0KCeSXWtqt/r0RpZp4wg+2fd9fuCdT9Gex6EecYBA8rVfgPqnqBoy56m+UFqRElJrll+AxuDx+bWt3MN0yB1gEy9kZu3zPYRddHyF4Q3LglTggkZApspni3yVzNmo/AhGBE8aIU6laSCqqMxiQOL4DACU x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 1d7a0b6f-3234-440d-3fd5-08d5d1f865fe x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(711020)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1358; x-ms-traffictypediagnostic: VI1PR0801MB1358: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(192374486261705)(131327999870524)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB1358; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1358; x-forefront-prvs: 0703B549E4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(39860400002)(39380400002)(376002)(346002)(40434004)(57704003)(189003)(199004)(105586002)(106356001)(3660700001)(5660300001)(2900100001)(6116002)(3846002)(66066001)(790700001)(3280700002)(6916009)(8936002)(1730700003)(2906002)(81156014)(8676002)(81166006)(86362001)(5890100001)(102836004)(26005)(59450400001)(2501003)(7696005)(6506007)(5630700001)(186003)(5250100002)(25786009)(74316002)(99286004)(316002)(6436002)(966005)(9686003)(72206003)(5640700003)(33656002)(53936002)(6306002)(7736002)(54896002)(478600001)(97736004)(14454004)(2351001)(55016002)(486006)(68736007)(476003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1358; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 9OrAwBi13QG/X8RtuZQs4OpGLkf2jXXYOkdhTXQUW+u78Wfe1Q4OYhKufnGWXAqEdUQqL9i2Djqs2XN6D82aRk3aTDjnnezj2HCQgCbMcQnTDK0Z/q8STK86yypv2JjTDYNes9IQTPzl6M/8A2DTS2r60HCjbnHITe+RNd0v4bruM6AaPqoBMLJwZK2U8Hec spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB2112781D5D6C6072B0A82D58FA7D0VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1d7a0b6f-3234-440d-3fd5-08d5d1f865fe X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jun 2018 13:11:53.4928 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1358 Archived-At: Subject: [Suit] SUIT Conference Call Minutes - 14th June 2018 X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 13:12:02 -0000 --_000_VI1PR0801MB2112781D5D6C6072B0A82D58FA7D0VI1PR0801MB2112_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Participants: - Frank Audun Kvamtr=F8 (Nordic Semiconductor) - =D8yvind R=F8nningstad (Nordic Semiconductor) - Carsten Bormann (Uni Bremen TZI) - Markus Gueller (Infineon) - Brendan Moran (Arm) - Hannes Tschofenig (Arm) - Henk Birkholz (Fraunhofer) Changes to the informational model have been discussed at the Hackathon and= at the virtual interim meeting. Brendan went through the document. A question about protocol extensibility was raised by Carsten. This is some= thing we need to look into. Brendan states that a new security requirement (MFSR8) has been added about= access control list. Carsten: Are there any hooks that the manifest needs to provide? For exampl= e, do we need to provide names for the fields so that they can be reference= d in the ACLs. The approach of explicit names for elements was discussed an= d also the approach of considering the path into the parse tree of the mani= fest. The latter was seen as a bit brittle. Q: Which elements do you consider to be overrideable? URIs, conditions, and= directives Brendan: The ACL should say whether it is allowed to add or delete from tha= t list. Q about the signed payload descriptor (MFSR4): The idea with the list of el= ements documented in the draft is that they need to be signed. The conclusi= on is that they need to be placed into the manifest. The requirements need = to be formatted so that the correlation between the implementation and the = threat. Suggestion to change the name of MFSR4 to Authenticated Resource Descriptor MFSR5: Cryptographic Authenticity --> Needs to come before MFSR4. MFSR7 (firmware encryption): The manifest information model must support en= cryption of firmware images. Carsten: Is this only for the firmware image or also for other fields? The= expectation is that channel security is sufficient to protect the manifest= content itself against information disclosure. Brendan will document it. The difficulty with encrypted payloads is key distribution. Therefore the m= anifest must convey the information required to allow an intended recipient= to decrypt an encrypted payload. The idea is that every device can receive= an encrypted key that only that device can decrypt. Class keys are obvious= ly possible too. Brendan talked about the key table structure. Not entire s= ure whether the information model is the right document to put this informa= tion in there. Does the group think that the information model document should contain the= key table concept for uniquely distributing content encryption keys to the= device? The group discussed where the best place would be to place the inf= ormation. No conclusion was made. Possible places are: information model, s= erialization document, or separate document. Carsten: What do we sign and in what order (encrypted or unencrypted payloa= d)? Brendan says that it might be best to have the signature cover the installe= d image. The payload description should specify what appears on the payload= after all the processing has happened. The raw payload digest refers to th= e state before any decryption has happened. Frank mentioned that they shared an email about the post condition idea. He= re is the email: https://www.ietf.org/mail-archive/web/suit/current/msg00467.html The pre-conditions need to hold before the update is started and the post-c= onditions need to hold when the update is applied. Discussions didn't not consider the sign after encryption vs. encryption af= ter sign case but rather about what is being signed. Hannes points out that there are security implications of the order. Brendan mentions that there are denial of service. Brendan can see the benefits of the proposed format for post- and pre-condi= tions. How well does this format deals with nested containers isn't clear t= o him though? Does this support "Use Case MFUS7: Prevent Devices from Unpac= king Unknown Formats"? Brendan thinks there should be a list of processing steps the device has to= take. Brendan argues for the ability to determine as quickly as possible w= hat the processing steps are. ... quite a long discussion about the different alternatives ... A tentative conclusion, which needs to be described to the group on the mai= ling list is: We will use out-of-band containers (to put a nil in the cose = structure; when it is nil the meaning is that the protected content is some= where else). The manifest would follow immediately afterwards. If you follo= w this approach for them manifest then the rest is an application specific = decision. The processing steps list will be something that can be transmit= ted separately. The goal is to make the manifest parsing friendly to nested= and non-nested structures. Since we ran out of time we were thinking about having another conference c= all next week. IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_VI1PR0801MB2112781D5D6C6072B0A82D58FA7D0VI1PR0801MB2112_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Participants:

- Frank Audun Kvamtr=F8 (Nordic Semiconductor)<= /o:p>

- =D8yvind R=F8nningstad (Nordic Semiconductor)=

- Carsten Bormann (Uni Bremen TZI)

- Markus Gueller (Infineon)

- Brendan Moran (Arm)

- Hannes Tschofenig (Arm)

- Henk Birkholz (Fraunhofer)

 

Changes to the informational model have been discuss= ed at the Hackathon and at the virtual interim meeting.

 

Brendan went through the document.

 

A question about protocol extensibility was raised b= y Carsten. This is something we need to look into.

 

Brendan states that a new security requirement (MFSR= 8) has been added about access control list.

 

Carsten: Are there any hooks that the manifest needs= to provide? For example, do we need to provide names for the fields so tha= t they can be referenced in the ACLs. The approach of explicit names for el= ements was discussed and also the approach of considering the path into the parse tree of the manifest. The = latter was seen as a bit brittle.

 

Q: Which elements do you consider to be overrideable= ? URIs, conditions, and directives

 

Brendan: The ACL should say whether it is allowed to= add or delete from that list.

 

Q about the signed payload descriptor (MFSR4): The i= dea with the list of elements documented in the draft is that they need to = be signed. The conclusion is that they need to be placed into the manifest.= The requirements need to be formatted so that the correlation between the implementation and the threat.

 

Suggestion to change the name of MFSR4 to Authentica= ted Resource Descriptor

 

MFSR5: Cryptographic Authenticity --> Needs to co= me before MFSR4.

 

MFSR7 (firmware encryption): The manifest informatio= n model must support encryption of firmware images.

 

Carsten: Is this only for the firmware image or also= for other fields?  The expectation is that channel security is suffic= ient to protect the manifest content itself against information disclosure.= Brendan will document it.

 

The difficulty with encrypted payloads is key distri= bution. Therefore the manifest must convey the information required to allo= w an intended recipient to decrypt an encrypted payload. The idea is that e= very device can receive an encrypted key that only that device can decrypt. Class keys are obviously possible t= oo. Brendan talked about the key table structure. Not entire sure whether t= he information model is the right document to put this information in there= .

 

Does the group think that the information model docu= ment should contain the key table concept for uniquely distributing content= encryption keys to the device? The group discussed where the best place wo= uld be to place the information. No conclusion was made. Possible places are: information model, serialization= document, or separate document.

 

Carsten: What do we sign and in what order (encrypte= d or unencrypted payload)?

 

Brendan says that it might be best to have the signa= ture cover the installed image. The payload description should specify what= appears on the payload after all the processing has happened. The raw payl= oad digest refers to the state before any decryption has happened.

 

Frank mentioned that they shared an email about the = post condition idea. Here is the email:

https://www.ietf.org/mail-archive/web/suit/current/m= sg00467.html

 

The pre-conditions need to hold before the update is= started and the post-conditions need to hold when the update is applied.

 

Discussions didn't not consider the sign after encry= ption vs. encryption after sign case but rather about what is being signed.

 

Hannes points out that there are security implicatio= ns of the order.

Brendan mentions that there are denial of service.

 

Brendan can see the benefits of the proposed format = for post- and pre-conditions. How well does this format deals with nested c= ontainers isn't clear to him though? Does this support "Use Case MFUS7= : Prevent Devices from Unpacking Unknown Formats"?

 

Brendan thinks there should be a list of processing = steps the device has to take. Brendan argues for the ability to determine a= s quickly as possible what the processing steps are.

 

... quite a long discussion about the different alte= rnatives ...

 

A tentative conclusion, which needs to be described = to the group on the mailing list is: We will use out-of-band containers (to= put a nil in the cose structure; when it is nil the meaning is that the pr= otected content is somewhere else). The manifest would follow immediately afterwards. If you follow this appro= ach for them manifest then the rest is an application specific decision.&nb= sp; The processing steps list will be something that can be transmitted sep= arately. The goal is to make the manifest parsing friendly to nested and non-nested structures. 

 

Since we ran out of time we were thinking about havi= ng another conference call next week.

 

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_VI1PR0801MB2112781D5D6C6072B0A82D58FA7D0VI1PR0801MB2112_-- From nobody Fri Jun 15 02:10:45 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29AC1120049 for ; Fri, 15 Jun 2018 02:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=linaro.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-VsTRBoN0nZ for ; Fri, 15 Jun 2018 02:10:40 -0700 (PDT) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFF5312F1A2 for ; Fri, 15 Jun 2018 02:10:39 -0700 (PDT) Received: by mail-wr0-x22d.google.com with SMTP id l41-v6so9173662wre.7 for ; Fri, 15 Jun 2018 02:10:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version; bh=hhLoUk0/q2tO5V0gAxGyW3feg0LxFyvzBKxJh9zw7Bg=; b=SfT+xod0FWLZ3if+SfGsKu3sqh++uVpx7XDOMLXcZJeuYTMUefaDnrFKPT07dQnlA3 gW+tQecypPlhoFsJrzTAFOSPCWeEj1E8h0iJGwPJ/SpkDfN+1p9VPIEcJKl/iMPnyFP1 SIBBuMuCzAAolJ8YSzwJsocXuvYPG7miwT8vE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version; bh=hhLoUk0/q2tO5V0gAxGyW3feg0LxFyvzBKxJh9zw7Bg=; b=Uyg4TEEdIc4kTUkSNAC4Cds+/G/aQUB15HNJVoNICDeRJ0NpRzSIauJDH7O1utRXtH ArLW/fGBfLXRyOClOr3UJ6/Lqsun6njUkxcRTjvN5xPaApa6p1jNrK2Q1jgauVZLbz1w gmN49/C7IakI1/iXS6SEXErMW2TBE1edYBDgzPLZMOUKIX5RRxIu+if1tat1X7G11FDd RFWSpLt3qQFN5/CoaTMi0gslAQCBfyuqc0MyGFlyzOEFw5oSU5PFhDKd+pgKM9L4EhmD pjmFv9TWwOrjFcnyti7DFOw9MfOlyVreAqWkFtvQon0gK6MSS2UglnJGBP0OLMM54miu asTA== X-Gm-Message-State: APt69E21W36WN0rR7PFtrZZUnZuMEM9yCMGylSHWB0W/vOPqG2LR1EOj wNAKg7RvS375dFhpLT2LVQ5BZ9EHOyY= X-Google-Smtp-Source: ADUXVKJ6Bp2k/Zz47bxgszpV0fvoXDTkrearuv+QIpvnfgTtCh0lv4qe4m3MH+ixSbCnWMjmQNw5yA== X-Received: by 2002:adf:9acc:: with SMTP id a70-v6mr848147wrc.180.1529053837933; Fri, 15 Jun 2018 02:10:37 -0700 (PDT) Received: from [192.168.0.181] (LPuteaux-656-1-48-212.w82-127.abo.wanadoo.fr. [82.127.83.212]) by smtp.gmail.com with ESMTPSA id v14-v6sm7671036wro.33.2018.06.15.02.10.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Jun 2018 02:10:37 -0700 (PDT) User-Agent: Microsoft-MacOutlook/10.e.1.180613 Date: Fri, 15 Jun 2018 11:10:18 +0200 From: David Brown To: "suit@ietf.org" Message-ID: <2E29EC1C-FAE7-47BE-B48C-F3797C1EC224@linaro.org> Thread-Topic: MCUboot/Zephyr involvement Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3611905831_144895453" Archived-At: Subject: [Suit] MCUboot/Zephyr involvement X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 09:10:43 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3611905831_144895453 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable This week, Linaro held a SPRINT where among other things, we discussed our = future direction for firmware upgrade, especially in regards to two configur= ations: a Secure/Non-secure dual image system on a single CPU, and a similar= dual image running on two separate CPUs. =20 At this point, management of multiple images is not deeply discussed by the= proposed documents, and I=E2=80=99m wondering if this kind of support would best = be left to additional documentation. =20 One thing I=E2=80=99d like to consider is how multiple images could be supported = by a single manifest. There are possibilities, such as concatenating the man= ifests, or just having to track the multiple manifests separately. Most of t= he fields in the manifest allow multiple instances of that field, except for= the payload, where the manifest only describes a single payload. What would= be the ramifications of allowing 1 or more payload blocks in the manifest? =20 Thanks, David --B_3611905831_144895453 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

This week, = Linaro held a SPRINT where among other things, we discussed our future direc= tion for firmware upgrade, especially in regards to two configurations: a Se= cure/Non-secure dual image system on a single CPU, and a similar dual image = running on two separate CPUs.

 

At this point, management of multiple images is n= ot deeply discussed by the proposed documents, and I=E2=80=99m wondering if this k= ind of support would best be left to additional documentation.

 <= /span>

One thing I=E2=80=99d = like to consider is how multiple images could be supported by a single manif= est. There are possibilities, such as concatenating the manifests, or just h= aving to track the multiple manifests separately. Most of the fields in the = manifest allow multiple instances of that field, except for the payload, whe= re the manifest only describes a single payload. What would be the ramificat= ions of allowing 1 or more payload blocks in the manifest?=

 

Thanks,

David

--B_3611905831_144895453-- From nobody Fri Jun 15 02:18:21 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD947126DBF for ; Fri, 15 Jun 2018 02:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mSg_r83vGfTj for ; Fri, 15 Jun 2018 02:18:16 -0700 (PDT) Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40356130DE0 for ; Fri, 15 Jun 2018 02:18:13 -0700 (PDT) Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w5F9IBMu008565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 15 Jun 2018 11:18:12 +0200 Received: from [192.168.16.50] (134.102.43.163) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.399.0; Fri, 15 Jun 2018 11:18:06 +0200 To: David Brown , "suit@ietf.org" References: <2E29EC1C-FAE7-47BE-B48C-F3797C1EC224@linaro.org> From: Henk Birkholz Message-ID: <4aaef410-fe5d-f883-d777-5d8bcb20dbd6@sit.fraunhofer.de> Date: Fri, 15 Jun 2018 11:13:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <2E29EC1C-FAE7-47BE-B48C-F3797C1EC224@linaro.org> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [134.102.43.163] Archived-At: Subject: Re: [Suit] MCUboot/Zephyr involvement X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 09:18:19 -0000 Hello David, thank you for brining that up! Actually, at the last SUIT Hackathon, follow-up Virtual Interim and then Design-Team meeting, there was a strong tendency to allow for more than one "payload" (and corresponding metadata) in one "manifest" (with its own corresponding metadata). The drafts do not reflect that yet, but I am under the impression that on one hand, this will be incorporated soon, and on the other hand, every "user story" that a set of corresponding requirements can be derived from is welcomed in the context of the SUIT information model. Dear WG, please bash my answer, if I am writing anything misleading here :) Viele Grüße, Henk On 06/15/2018 11:10 AM, David Brown wrote: > This week, Linaro held a SPRINT where among other things, we discussed > our future direction for firmware upgrade, especially in regards to two > configurations: a Secure/Non-secure dual image system on a single CPU, > and a similar dual image running on two separate CPUs. > > At this point, management of multiple images is not deeply discussed by > the proposed documents, and I’m wondering if this kind of support would > best be left to additional documentation. > > One thing I’d like to consider is how multiple images could be supported > by a single manifest. There are possibilities, such as concatenating the > manifests, or just having to track the multiple manifests separately. > Most of the fields in the manifest allow multiple instances of that > field, except for the payload, where the manifest only describes a > single payload. What would be the ramifications of allowing 1 or more > payload blocks in the manifest? > > Thanks, > > David__ > > > > _______________________________________________ > Suit mailing list > Suit@ietf.org > https://www.ietf.org/mailman/listinfo/suit > From nobody Fri Jun 15 02:35:37 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AAE012F1A2 for ; Fri, 15 Jun 2018 02:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=linaro.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6rLKufhcBSg for ; Fri, 15 Jun 2018 02:35:34 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30D77126DBF for ; Fri, 15 Jun 2018 02:35:34 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id o13-v6so2466615wmf.4 for ; Fri, 15 Jun 2018 02:35:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version:content-transfer-encoding; bh=b8DUgN9jwD/2fXvNZLkWyCP1I32AoFjPfwP5i6sQugU=; b=eqAdqqXkcx05vJkkYW498XW6vNag9KTGKXTO7jGsgdRYoPWlShjcwyH32kYBmARFmG WofF4exhY44bUJRznKg9q2cv8ZZ+gy2H4h83zXKbIZIQ0XySNm5vb4FITIZmwnzpetL1 ahtwLOmrAHg6dPJlCgPBr4Damo4uSlLRrh/vw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=b8DUgN9jwD/2fXvNZLkWyCP1I32AoFjPfwP5i6sQugU=; b=ICv8ITtn7JReaTsFEatyqAkX5ViBrcwqFDSdRNan+GKY6GpZTZFT0UWrdiWW+ehFi9 HMSEqqzET/Y/8Nku7eYE7/9mo+XlyHNO57+zA9hngpLqQCM0fVBfCdfaGiqXzN4O+ror eNbiVPOEHDRshe5z62DrVMVoZ7FpdkusNpKwT4UGM+lO2n54Kt/nDvj6M0wD0g3N+3mx XyR6OYu+FuvB/4Ruh/GfvxZxPlhzOlGDu1yTEBkx+vfiDxX3ssHUKI25b2xXGgoORDbJ CPXhW5qtY4T8ksHo5ghY9t1DIpRPWtAYwY069NXVLWAChZBG+vqgFCB4XpVKhkj01XzA NynA== X-Gm-Message-State: APt69E10l39Nh+80g4gC43XzyhyabV6Q4varAR5t8i+5IUBFsQxGORwL o2+PBDnFiXcg8xSeM9Z8mDG3YvZeTX0= X-Google-Smtp-Source: ADUXVKKg/aZ2EcSztkVAeUXuXY5tFiW2XFIct61o1oG/JI4UOvi3PkYn6URgb9DgYyZSBaG50tOCcg== X-Received: by 2002:a1c:1588:: with SMTP id 130-v6mr598888wmv.35.1529055332600; Fri, 15 Jun 2018 02:35:32 -0700 (PDT) Received: from [192.168.0.181] (LPuteaux-656-1-48-212.w82-127.abo.wanadoo.fr. [82.127.83.212]) by smtp.gmail.com with ESMTPSA id t14-v6sm9261689wrm.79.2018.06.15.02.35.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Jun 2018 02:35:32 -0700 (PDT) User-Agent: Microsoft-MacOutlook/10.e.1.180613 Date: Fri, 15 Jun 2018 11:35:26 +0200 From: David Brown To: Henk Birkholz , "suit@ietf.org" Message-ID: <35BD193C-BA4B-426A-BCE0-DFB124DBA5AF@linaro.org> Thread-Topic: [Suit] MCUboot/Zephyr involvement References: <2E29EC1C-FAE7-47BE-B48C-F3797C1EC224@linaro.org> <4aaef410-fe5d-f883-d777-5d8bcb20dbd6@sit.fraunhofer.de> In-Reply-To: <4aaef410-fe5d-f883-d777-5d8bcb20dbd6@sit.fraunhofer.de> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Suit] MCUboot/Zephyr involvement X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 09:35:37 -0000 Would it be helpful for me to write up my "user stories" a bit more formall= y? Thanks, David =EF=BB=BFOn 6/15/18, 11:18 AM, "Henk Birkholz" = wrote: Hello David, =20 thank you for brining that up! Actually, at the last SUIT Hackathon,=20 follow-up Virtual Interim and then Design-Team meeting, there was a=20 strong tendency to allow for more than one "payload" (and corresponding= =20 metadata) in one "manifest" (with its own corresponding metadata). The=20 drafts do not reflect that yet, but I am under the impression that on=20 one hand, this will be incorporated soon, and on the other hand, every=20 "user story" that a set of corresponding requirements can be derived=20 from is welcomed in the context of the SUIT information model. =20 Dear WG, please bash my answer, if I am writing anything misleading her= e :) =20 Viele Gr=C3=BC=C3=9Fe, =20 Henk =20 On 06/15/2018 11:10 AM, David Brown wrote: > This week, Linaro held a SPRINT where among other things, we discusse= d=20 > our future direction for firmware upgrade, especially in regards to t= wo=20 > configurations: a Secure/Non-secure dual image system on a single CPU= ,=20 > and a similar dual image running on two separate CPUs. >=20 > At this point, management of multiple images is not deeply discussed = by=20 > the proposed documents, and I=E2=80=99m wondering if this kind of support w= ould=20 > best be left to additional documentation. >=20 > One thing I=E2=80=99d like to consider is how multiple images could be supp= orted=20 > by a single manifest. There are possibilities, such as concatenating = the=20 > manifests, or just having to track the multiple manifests separately.= =20 > Most of the fields in the manifest allow multiple instances of that=20 > field, except for the payload, where the manifest only describes a=20 > single payload. What would be the ramifications of allowing 1 or more= =20 > payload blocks in the manifest? >=20 > Thanks, >=20 > David__ >=20 >=20 >=20 > _______________________________________________ > Suit mailing list > Suit@ietf.org > https://www.ietf.org/mailman/listinfo/suit >=20 =20 From nobody Fri Jun 15 02:36:57 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26D27126DBF for ; Fri, 15 Jun 2018 02:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29wagqAqwWWh for ; Fri, 15 Jun 2018 02:36:52 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50060.outbound.protection.outlook.com [40.107.5.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9091C120049 for ; Fri, 15 Jun 2018 02:36:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=frGJ0eHsYq/FPko9czHmKhOGDaIuRSIrI+7bwQRmAdY=; b=Pb/wq4x96IinxgY4K9lJH6R1kMscAcOvEXATSULb+SRL0sQ2zOz8HYaLi9zQQJnfGERTJ3r4CTCkexAkj5u4LXaMVSUnUKjedlmuIxV4IPJ7DgfebeeySKkGR0i4cAMJNakmHDVf6rbP3OUVgOTELUj81/LVnRt7z+4iregWi2M= Received: from AM4PR0802MB2260.eurprd08.prod.outlook.com (10.172.217.150) by AM4PR0802MB2305.eurprd08.prod.outlook.com (10.172.218.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.14; Fri, 15 Jun 2018 09:36:49 +0000 Received: from AM4PR0802MB2260.eurprd08.prod.outlook.com ([fe80::15ab:db2e:593b:b5e0]) by AM4PR0802MB2260.eurprd08.prod.outlook.com ([fe80::15ab:db2e:593b:b5e0%4]) with mapi id 15.20.0863.016; Fri, 15 Jun 2018 09:36:49 +0000 From: Brendan Moran To: David Brown CC: Henk Birkholz , "suit@ietf.org" Thread-Topic: [Suit] MCUboot/Zephyr involvement Thread-Index: AQHUBIjCPKh9EvkYE0umzwkf/oGEzKRhCTWAgAAGGgCAAABiAA== Date: Fri, 15 Jun 2018 09:36:48 +0000 Message-ID: References: <2E29EC1C-FAE7-47BE-B48C-F3797C1EC224@linaro.org> <4aaef410-fe5d-f883-d777-5d8bcb20dbd6@sit.fraunhofer.de> <35BD193C-BA4B-426A-BCE0-DFB124DBA5AF@linaro.org> In-Reply-To: <35BD193C-BA4B-426A-BCE0-DFB124DBA5AF@linaro.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.8.2) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brendan.Moran@arm.com; x-originating-ip: [217.140.96.140] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0802MB2305; 7:H7nCB5sWSD4FPD6IRwDVIn26pq3Gn335sb5mnHlM/p7NwMCZLYbgdy/rQOpdbrIV7oylpulllFxLw2DJ264Tr0vodaItGZPgcqkByL8nnFvGC8AP62qgJj8P5PBeJJHO56l0rzMR19Upyn8Mn+GM8r2m07HXpHYCnh+pmtKdgwnfGFffHQ9/28kCM2g8h+xZOmjtkyAJ/qP5AQZfNCHsrgrbFAqAvsJvIXKDOs3imPilsLPKf6QzydQYQbOgGGbh x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: f8955834-8895-42f4-e904-08d5d2a384bf x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(711020)(48565401081)(2017052603328)(7153060)(7193020); SRVR:AM4PR0802MB2305; x-ms-traffictypediagnostic: AM4PR0802MB2305: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3231254)(944501410)(52105095)(3002001)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123558120)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:AM4PR0802MB2305; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0802MB2305; x-forefront-prvs: 0704670F76 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(39380400002)(346002)(396003)(376002)(199004)(189003)(40434004)(50226002)(476003)(86362001)(81166006)(8676002)(81156014)(186003)(54906003)(316002)(7736002)(99286004)(102836004)(6506007)(53546011)(3846002)(59450400001)(76176011)(305945005)(26005)(11346002)(486006)(6436002)(14454004)(83716003)(2616005)(446003)(229853002)(6486002)(82746002)(6116002)(2900100001)(8936002)(36756003)(6916009)(105586002)(57306001)(106356001)(5660300001)(3660700001)(4326008)(97736004)(3280700002)(66066001)(53936002)(6306002)(72206003)(345774005)(68736007)(478600001)(6512007)(2906002)(5250100002)(25786009)(966005)(6246003)(33656002)(5890100001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0802MB2305; H:AM4PR0802MB2260.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: hJviy53ac2YQ0/3aBGyfBuckVPKVi3oD9vfO1xnZRTQQoBMkChWwCSbs3eB9ZmErDBofOCgMEEVpcUa6qyAgygeUd19PBZgSHsKcQm7hv6FMh6u9QTfWpOYtCWKgYZYFtoQIbo9lwqcduaKCkSsgV0+fNtXamCmjAJXDwd4/WUgG7LELLpQbBTNf/lLe4tXi spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: f8955834-8895-42f4-e904-08d5d2a384bf X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jun 2018 09:36:49.0193 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0802MB2305 Archived-At: Subject: Re: [Suit] MCUboot/Zephyr involvement X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 09:36:56 -0000 SGkgRGF2aWQsDQpUaGF0IHdvdWxkIGJlIHZlcnkgaGVscGZ1bC4NCg0KVGhhbmtzLA0KQnJlbmRh bg0KDQo+IE9uIDE1IEp1biAyMDE4LCBhdCAxMDozNSwgRGF2aWQgQnJvd24gPGRhdmlkLmJyb3du QGxpbmFyby5vcmc+IHdyb3RlOg0KPg0KPiBXb3VsZCBpdCBiZSBoZWxwZnVsIGZvciBtZSB0byB3 cml0ZSB1cCBteSAidXNlciBzdG9yaWVzIiBhIGJpdCBtb3JlIGZvcm1hbGx5Pw0KPg0KPiBUaGFu a3MsDQo+IERhdmlkDQo+DQo+IO+7v09uIDYvMTUvMTgsIDExOjE4IEFNLCAiSGVuayBCaXJraG9s eiIgPGhlbmsuYmlya2hvbHpAc2l0LmZyYXVuaG9mZXIuZGU+IHdyb3RlOg0KPg0KPiAgICBIZWxs byBEYXZpZCwNCj4NCj4gICAgdGhhbmsgeW91IGZvciBicmluaW5nIHRoYXQgdXAhIEFjdHVhbGx5 LCBhdCB0aGUgbGFzdCBTVUlUIEhhY2thdGhvbiwNCj4gICAgZm9sbG93LXVwIFZpcnR1YWwgSW50 ZXJpbSBhbmQgdGhlbiBEZXNpZ24tVGVhbSBtZWV0aW5nLCB0aGVyZSB3YXMgYQ0KPiAgICBzdHJv bmcgdGVuZGVuY3kgdG8gYWxsb3cgZm9yIG1vcmUgdGhhbiBvbmUgInBheWxvYWQiIChhbmQgY29y cmVzcG9uZGluZw0KPiAgICBtZXRhZGF0YSkgaW4gb25lICJtYW5pZmVzdCIgKHdpdGggaXRzIG93 biBjb3JyZXNwb25kaW5nIG1ldGFkYXRhKS4gVGhlDQo+ICAgIGRyYWZ0cyBkbyBub3QgcmVmbGVj dCB0aGF0IHlldCwgYnV0IEkgYW0gdW5kZXIgdGhlIGltcHJlc3Npb24gdGhhdCBvbg0KPiAgICBv bmUgaGFuZCwgdGhpcyB3aWxsIGJlIGluY29ycG9yYXRlZCBzb29uLCBhbmQgb24gdGhlIG90aGVy IGhhbmQsIGV2ZXJ5DQo+ICAgICJ1c2VyIHN0b3J5IiB0aGF0IGEgc2V0IG9mIGNvcnJlc3BvbmRp bmcgcmVxdWlyZW1lbnRzIGNhbiBiZSBkZXJpdmVkDQo+ICAgIGZyb20gaXMgd2VsY29tZWQgaW4g dGhlIGNvbnRleHQgb2YgdGhlIFNVSVQgaW5mb3JtYXRpb24gbW9kZWwuDQo+DQo+ICAgIERlYXIg V0csIHBsZWFzZSBiYXNoIG15IGFuc3dlciwgaWYgSSBhbSB3cml0aW5nIGFueXRoaW5nIG1pc2xl YWRpbmcgaGVyZSA6KQ0KPg0KPiAgICBWaWVsZSBHcsO8w59lLA0KPg0KPiAgICBIZW5rDQo+DQo+ ICAgIE9uIDA2LzE1LzIwMTggMTE6MTAgQU0sIERhdmlkIEJyb3duIHdyb3RlOg0KPj4gVGhpcyB3 ZWVrLCBMaW5hcm8gaGVsZCBhIFNQUklOVCB3aGVyZSBhbW9uZyBvdGhlciB0aGluZ3MsIHdlIGRp c2N1c3NlZA0KPj4gb3VyIGZ1dHVyZSBkaXJlY3Rpb24gZm9yIGZpcm13YXJlIHVwZ3JhZGUsIGVz cGVjaWFsbHkgaW4gcmVnYXJkcyB0byB0d28NCj4+IGNvbmZpZ3VyYXRpb25zOiBhIFNlY3VyZS9O b24tc2VjdXJlIGR1YWwgaW1hZ2Ugc3lzdGVtIG9uIGEgc2luZ2xlIENQVSwNCj4+IGFuZCBhIHNp bWlsYXIgZHVhbCBpbWFnZSBydW5uaW5nIG9uIHR3byBzZXBhcmF0ZSBDUFVzLg0KPj4NCj4+IEF0 IHRoaXMgcG9pbnQsIG1hbmFnZW1lbnQgb2YgbXVsdGlwbGUgaW1hZ2VzIGlzIG5vdCBkZWVwbHkg ZGlzY3Vzc2VkIGJ5DQo+PiB0aGUgcHJvcG9zZWQgZG9jdW1lbnRzLCBhbmQgSeKAmW0gd29uZGVy aW5nIGlmIHRoaXMga2luZCBvZiBzdXBwb3J0IHdvdWxkDQo+PiBiZXN0IGJlIGxlZnQgdG8gYWRk aXRpb25hbCBkb2N1bWVudGF0aW9uLg0KPj4NCj4+IE9uZSB0aGluZyBJ4oCZZCBsaWtlIHRvIGNv bnNpZGVyIGlzIGhvdyBtdWx0aXBsZSBpbWFnZXMgY291bGQgYmUgc3VwcG9ydGVkDQo+PiBieSBh IHNpbmdsZSBtYW5pZmVzdC4gVGhlcmUgYXJlIHBvc3NpYmlsaXRpZXMsIHN1Y2ggYXMgY29uY2F0 ZW5hdGluZyB0aGUNCj4+IG1hbmlmZXN0cywgb3IganVzdCBoYXZpbmcgdG8gdHJhY2sgdGhlIG11 bHRpcGxlIG1hbmlmZXN0cyBzZXBhcmF0ZWx5Lg0KPj4gTW9zdCBvZiB0aGUgZmllbGRzIGluIHRo ZSBtYW5pZmVzdCBhbGxvdyBtdWx0aXBsZSBpbnN0YW5jZXMgb2YgdGhhdA0KPj4gZmllbGQsIGV4 Y2VwdCBmb3IgdGhlIHBheWxvYWQsIHdoZXJlIHRoZSBtYW5pZmVzdCBvbmx5IGRlc2NyaWJlcyBh DQo+PiBzaW5nbGUgcGF5bG9hZC4gV2hhdCB3b3VsZCBiZSB0aGUgcmFtaWZpY2F0aW9ucyBvZiBh bGxvd2luZyAxIG9yIG1vcmUNCj4+IHBheWxvYWQgYmxvY2tzIGluIHRoZSBtYW5pZmVzdD8NCj4+ DQo+PiBUaGFua3MsDQo+Pg0KPj4gRGF2aWRfXw0KPj4NCj4+DQo+Pg0KPj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IFN1aXQgbWFpbGluZyBsaXN0 DQo+PiBTdWl0QGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3N1aXQNCj4+DQo+DQo+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IFN1aXQgbWFpbGluZyBsaXN0DQo+IFN1aXRAaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdWl0DQoNCklNUE9SVEFOVCBO T1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJl IGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3Qg dGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0 ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24s IHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9u IGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCg== From nobody Fri Jun 15 02:44:57 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56E01130DDD for ; Fri, 15 Jun 2018 02:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMQLOezzcZUU for ; Fri, 15 Jun 2018 02:44:51 -0700 (PDT) Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F52A126DBF for ; Fri, 15 Jun 2018 02:44:51 -0700 (PDT) Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w5F9ikL0011495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 15 Jun 2018 11:44:47 +0200 Received: from [192.168.16.50] (134.102.43.163) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.399.0; Fri, 15 Jun 2018 11:44:41 +0200 To: Brendan Moran , David Brown CC: "suit@ietf.org" References: <2E29EC1C-FAE7-47BE-B48C-F3797C1EC224@linaro.org> <4aaef410-fe5d-f883-d777-5d8bcb20dbd6@sit.fraunhofer.de> <35BD193C-BA4B-426A-BCE0-DFB124DBA5AF@linaro.org> From: Henk Birkholz Message-ID: Date: Fri, 15 Jun 2018 11:40:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [134.102.43.163] Archived-At: Subject: Re: [Suit] MCUboot/Zephyr involvement X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 09:44:55 -0000 A quick addendum. If your require guidance or examples, the current SUIT IM draft already includes a set of user stories and provides a good guideline, I think > https://tools.ietf.org/html/draft-ietf-suit-information-model-00#section-3.4 Viele Grüße, Henk On 06/15/2018 11:36 AM, Brendan Moran wrote: > Hi David, > That would be very helpful. > > Thanks, > Brendan > >> On 15 Jun 2018, at 10:35, David Brown wrote: >> >> Would it be helpful for me to write up my "user stories" a bit more formally? >> >> Thanks, >> David >> >> On 6/15/18, 11:18 AM, "Henk Birkholz" wrote: >> >> Hello David, >> >> thank you for brining that up! Actually, at the last SUIT Hackathon, >> follow-up Virtual Interim and then Design-Team meeting, there was a >> strong tendency to allow for more than one "payload" (and corresponding >> metadata) in one "manifest" (with its own corresponding metadata). The >> drafts do not reflect that yet, but I am under the impression that on >> one hand, this will be incorporated soon, and on the other hand, every >> "user story" that a set of corresponding requirements can be derived >> from is welcomed in the context of the SUIT information model. >> >> Dear WG, please bash my answer, if I am writing anything misleading here :) >> >> Viele Grüße, >> >> Henk >> >> On 06/15/2018 11:10 AM, David Brown wrote: >>> This week, Linaro held a SPRINT where among other things, we discussed >>> our future direction for firmware upgrade, especially in regards to two >>> configurations: a Secure/Non-secure dual image system on a single CPU, >>> and a similar dual image running on two separate CPUs. >>> >>> At this point, management of multiple images is not deeply discussed by >>> the proposed documents, and I’m wondering if this kind of support would >>> best be left to additional documentation. >>> >>> One thing I’d like to consider is how multiple images could be supported >>> by a single manifest. There are possibilities, such as concatenating the >>> manifests, or just having to track the multiple manifests separately. >>> Most of the fields in the manifest allow multiple instances of that >>> field, except for the payload, where the manifest only describes a >>> single payload. What would be the ramifications of allowing 1 or more >>> payload blocks in the manifest? >>> >>> Thanks, >>> >>> David__ >>> >>> >>> >>> _______________________________________________ >>> Suit mailing list >>> Suit@ietf.org >>> https://www.ietf.org/mailman/listinfo/suit >>> >> >> >> >> _______________________________________________ >> Suit mailing list >> Suit@ietf.org >> https://www.ietf.org/mailman/listinfo/suit > > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. > From nobody Fri Jun 15 08:05:12 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 255DC130E4F for ; Fri, 15 Jun 2018 08:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkRezA4r2yh5 for ; Fri, 15 Jun 2018 08:05:08 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBE20130E1F for ; Fri, 15 Jun 2018 08:05:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 30C7AE2050; Fri, 15 Jun 2018 11:05:06 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 18352-09; Fri, 15 Jun 2018 11:05:01 -0400 (EDT) Received: from securerf.ihtfp.org (IHTFP-DHCP-158.IHTFP.ORG [192.168.248.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 41EC7E203F; Fri, 15 Jun 2018 11:05:01 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1529075101; bh=QfsO3jU/EI3UuUlKBYQSw/B1umPAh7i8MPTQoOpCJRk=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=aNKMPzqk2tzBnSw0W+F6BruQ1d7GzQtwyli2nLJ6MLYeRHfZu6fi6nfTPXWrd2l+9 EWRL3Q0hQWEycLzk3Vn0mURaoBwaJXfX8FTSUk2nergB7LLVdUot+H9GdAWYJXqtZ5 bsrCnvZwjiuBfpRLhtKOZVkA6PuWWLoqDOmDHTpg= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.15.2/Submit) id w5FF4gxM024510; Fri, 15 Jun 2018 11:04:42 -0400 From: Derek Atkins To: David Brown Cc: Koen Zandberg , suit@ietf.org References: <238EC1AC-D898-472D-A951-2AD1438C6004@vigilsec.com> <168ED9F9-15CF-457B-850A-77196D423D08@arm.com> <932b5b21-dc56-b316-0c0d-28d43c4cec42@bergzand.net> <20180607160549.GA11744@davidb.org> Date: Fri, 15 Jun 2018 11:04:42 -0400 In-Reply-To: <20180607160549.GA11744@davidb.org> (David Brown's message of "Thu, 7 Jun 2018 10:05:49 -0600") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: Re: [Suit] COSE_Sign vs. COSE_Mac X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 15:05:10 -0000 Hi, David Brown writes: > On Mon, Jun 04, 2018 at 05:59:41PM +0200, Koen Zandberg wrote: > >>My 2 cents for this scenario: the device I'm currently developing for >>(samr21-xplained pro) takes around 8 seconds for ed25519 signature >>verification (TweetNaCl implementation). An HMAC based verification >>would be a lot faster here (saving me battery power). If you like I can >>provide you some numbers on flash requirements for both HMAC and >>public-key implementations. > > I think this more points out that there is a need for a better ed25519 > implementation for this kind of scenario. On my mcu (120Mhz Cortex > M7), TweetNaCl takes 1-2 seconds for a signature verification. It is > nice because it is only about 3kb of code. The other implementation I > have, from NaCl, takes on the order of 20-30ms for the same > verification. However, it is about 130Kb of code, which makes it > unreasonable to use in many situations. For the record, based on our experience on a Cortex M4 and Cortex R5, a WalnutDSA signature verification would take you on the order of 5ms on your M7 using only ~3kB of code. (WalnutDSA is one of the NIST PQC submissions). The downside is that the signature is larger than ECC. > What would be nice to have would be something in between. A little > bit larger code, but that runs faster than TweetNaCl. There is a > https://munacl.cryptojedi.org/faq.shtml microNaCl library that tries > to do this. However, it seems to be largely hand-written assembly, > and targeted to very specific mcus. > > For this MCU, RSA code (using mbed TLS) is about 12Kb of code, and > takes 400-500ms to do the signature verification. Gut feeling is that > Ed25519 could be implemented with similar code size and performance, > or slightly better. > > I don't really have the depth of understanding needed to produce this > implementation, however, but maybe someone does. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Fri Jun 15 13:59:22 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD285130E64 for ; Fri, 15 Jun 2018 13:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzkdLA_1ieXO for ; Fri, 15 Jun 2018 13:59:18 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DFEB126CB6 for ; Fri, 15 Jun 2018 13:59:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 69FB0300A3D for ; Fri, 15 Jun 2018 16:59:16 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id JnG7x6T-OBvK for ; Fri, 15 Jun 2018 16:59:15 -0400 (EDT) Received: from a860b60074bd.home (pool-71-127-50-4.washdc.fios.verizon.net [71.127.50.4]) by mail.smeinc.net (Postfix) with ESMTPSA id 316B730025C for ; Fri, 15 Jun 2018 16:59:15 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <82D68CC7-FFCE-4B99-99C4-9F45388AE4F8@vigilsec.com> Date: Fri, 15 Jun 2018 16:59:16 -0400 To: suit X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Suit] Minutes for the Virtual Interim X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 20:59:21 -0000 The minutes have been posted: = https://datatracker.ietf.org/meeting/interim-2018-suit-03/materials/minute= s-interim-2018-suit-03-201806061600 Please let the chairs know about any errors so that they can be = corrected. Russ= From nobody Sat Jun 16 06:49:36 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D00130E4C; Sat, 16 Jun 2018 06:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDbCBEFlOPl1; Sat, 16 Jun 2018 06:49:23 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D490130E72; Sat, 16 Jun 2018 06:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w5GDfkjT023188; Sat, 16 Jun 2018 15:41:46 +0200 (CEST) Received: from [192.168.217.114] (p5DC7E3F3.dip0.t-ipconnect.de [93.199.227.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 417JRt3Fn4zDXmK; Sat, 16 Jun 2018 15:41:46 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 550849304.347766-37eec474f288a3db954c5b9b0e6f2ce4 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Message-Id: <275F58A0-EDB4-4200-A909-786BCB0C53C2@tzi.org> Date: Sat, 16 Jun 2018 15:41:45 +0200 To: suit , teep@ietf.org, dinrg@ietf.org X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: [Suit] Constrained Node/Network Cluster @ IETF102: DRAFT AGENDA X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2018 13:49:27 -0000 Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF102. Remember that there is still quite some potential for changes. ACE vs. DISPATCH seems to become a common occurrance; at this rate, I'll probably never see a DISPATCH meeting again. CBOR vs. 6LO is maybe just a personal problem for me, throwing in TEEP on top is a bit weird, though. 6TISCH vs. SUIT is probably painful for the few individuals who care about security in both. All times are EDT (UTC-0400). (You can get pure UTC times on https://datatracker.ietf.org/meeting/agenda-utc, for those who want to listen from remote.) Gr=C3=BC=C3=9Fe, Carsten SATURDAY/SUNDAY -- Hackathon (including various interops) (Centre Ville) -- Sun 1800-2000: HotRFC (Viger) MONDAY, July 16, 2018 0930-1200 Morning Session I Duluth ART dispatch Dispatch WG - Joint with ARTAREA Laurier INT 6man IPv6 Maintenance WG Place du Canada RTG detnet Deterministic Networking WG Viger SEC *** ace Authentication and Authorization for = Constrained Environments WG 1330-1530 Afternoon Session I Viger INT ipwave IP Wireless Access in Vehicular = Environments WG Place du Canada SEC tls Transport Layer Security WG 1550-1750 Afternoon Session II Viger ART *** core Constrained RESTful Environments WG Place du Canada INT intarea Internet Area Working Group WG 1810-1940 Afternoon Session III Laurier GEN rfcplusplus The label "RFC" BOF TUESDAY, July 17, 2018 0930-1200 Morning Session I Place du Canada IRTF irtfopen IRTF Open Meeting St-Paul/St-Cath RTG babel Babel routing protocol WG Duluth RTG *** roll Routing Over Low power and Lossy = networks WG 1330-1530 Afternoon Session I Duluth ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Van Horne INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Laurier RTG rtgarea Routing Area Open Meeting Viger SEC *** teep Trusted Execution Environment = Provisioning WG 1550-1820 Afternoon Session II Place du Canada ART httpbis Hypertext Transfer Protocol WG Viger IRTF cfrg Crypto Forum - 1720 - 1820 Centre Ville IRTF icnrg Information-Centric Networking Van Horne SEC acme Automated Certificate Management = Environment WG - 1720 - 1820 Van Horne SEC oauth Web Authorization Protocol WG - 1550 - = 1720 Duluth TSV taps Transport Services WG WEDNESDAY, July 18, 2018 0930-1200 Morning Session I Van Horne OPS anima Autonomic Networking Integrated Model = and Approach WG St-Paul/St-Cath RTG bier Bit Indexed Explicit Replication WG Duluth SEC secdispatch Security Dispatch WG Place du Canada TSV quic QUIC WG 1330-1500 Afternoon Session I Laurier ART httpbis Hypertext Transfer Protocol WG Van Horne INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Centre Ville SEC *** suit Software Updates for Internet of Things = WG 1520-1650 Afternoon Session II Centre Ville INT homenet Home Networking WG Viger TSV tsvarea Transport Area Open Meeting THURSDAY, July 19, 2018 0930-1200 Morning Session I Duluth INT dnssd Extensions for Scalable DNS Service = Discovery WG Centre Ville INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Place du Canada IRTF maprg Measurement and Analysis for Protocols Viger SEC mls Messaging Layer Security WG Van Horne SEC oauth Web Authorization Protocol WG - 0930 - = 1100 1330-1530 Afternoon Session I Centre Ville OPS v6ops IPv6 Operations WG Viger RTG rift Routing In Fat Trees WG Place du Canada SEC saag Security Area Open Meeting 1550-1750 Afternoon Session II Viger IRTF*** t2trg Thing-to-Thing Duluth OPS driu DNS Resolver Identification and Use BOF Centre Ville TSV tsvwg Transport Area Working Group WG 1810-1910 Afternoon Session III Van Horne ART *** core Constrained RESTful Environments WG Place du Canada SEC tls Transport Layer Security WG Centre Ville TSV tsvwg Transport Area Working Group WG FRIDAY, July 20, 2018 0930-1130 Morning Session I Duluth IRTF*** dinrg Decentralized Internet Infrastructure = Proposed RG Place du Canada OPS v6ops IPv6 Operations WG St-Paul/St-Cath TSV rmcat RTP Media Congestion Avoidance = Techniques WG 1150-1320 Afternoon Session I Duluth INT *** lwig Light-Weight Implementation Guidance WG Laurier IRTF panrg Path Aware Networking Proposed RG Centre Ville SEC tokbind Token Binding WG _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace From nobody Tue Jun 19 08:08:44 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29EAE1310B5 for ; Tue, 19 Jun 2018 08:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxpqo4vUrlwr for ; Tue, 19 Jun 2018 08:08:39 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFE62130E9F for ; Tue, 19 Jun 2018 08:08:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C6930300A27 for ; Tue, 19 Jun 2018 11:08:36 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id X3Qr3ouvPXJf for ; Tue, 19 Jun 2018 11:08:31 -0400 (EDT) Received: from a860b60074bd.home (pool-71-127-50-4.washdc.fios.verizon.net [71.127.50.4]) by mail.smeinc.net (Postfix) with ESMTPSA id 9DFF9300A01 for ; Tue, 19 Jun 2018 11:08:31 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_8822CCE3-B07C-4E0C-8D52-EB18348EBCA3" X-Priority: 3 X-Mail-Calendar-Part: Yes Date: Tue, 19 Jun 2018 11:08:32 -0400 To: suit Message-Id: <19C5E4A1-5B82-4C95-9FC1-5E7A5A47C2A8@vigilsec.com> Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Suit] Design team meeting on Thursday, 21 June 2018 at 0800 EDT for 1 hour X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 15:08:42 -0000 --Apple-Mail=_8822CCE3-B07C-4E0C-8D52-EB18348EBCA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii SUIT Working Group invites you to join this WebEx meeting. =20 SUIT Open Design Team Meeting Thursday, June 21, 2018 8:00 am | Eastern Daylight Time (New York, GMT-04:00) | 1 hr Meeting number (access code): 648 754 363 Meeting password: 3C936x32 =20 Add to Calendar = =09 When it's time, join the meeting = . =20 Join by phone 1-650-479-3208 Call-in toll number (US/Canada) =20 Can't join the meeting? = =20 IMPORTANT NOTICE: Please note that this WebEx service allows audio and = other information sent during the session to be recorded, which may be = discoverable in a legal matter. By joining this session, you = automatically consent to such recordings. If you do not consent to being = recorded, discuss your concerns with the host or do not join the = session. --Apple-Mail=_8822CCE3-B07C-4E0C-8D52-EB18348EBCA3 Content-Type: multipart/mixed; boundary="Apple-Mail=_D2D8A7EA-A90E-4558-AD23-76D50D3057D8" --Apple-Mail=_D2D8A7EA-A90E-4558-AD23-76D50D3057D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
SUIT Working Group invites you to join this WebEx = meeting.
 
SUIT Open Design Team = Meeting
Thursday, June 21, 2018
8:00 am  |  Eastern Daylight Time (New = York, GMT-04:00)  |  1 = hr
Meeting number (access code): 648 754 = 363
Meeting password: 3C936x32


 
Add to = Calendar
When it's time, join the = meeting.
 
Join by phone
1-650-479-3208 Call-in toll number = (US/Canada)
 
Can't join the = meeting?
 
IMPORTANT NOTICE: Please note that this WebEx service = allows audio and other information sent during the session to be = recorded, which may be discoverable in a legal matter. By joining this = session, you automatically consent to such recordings. If you do not = consent to being recorded, discuss your concerns with the host or do not = join the = session.
= --Apple-Mail=_D2D8A7EA-A90E-4558-AD23-76D50D3057D8 Content-Disposition: attachment; filename=WebEx_Meeting.ics Content-Type: text/calendar; x-unix-mode=0666; name="WebEx_Meeting.ics" Content-Transfer-Encoding: quoted-printable BEGIN:VCALENDAR=0APRODID:-//Microsoft=20Corporation//Outlook=2010.0=20= MIMEDIR//EN=0AVERSION:2.0=0AMETHOD:REQUEST=0ABEGIN:VTIMEZONE=0A= TZID:Eastern=20Time=0ABEGIN:STANDARD=0ADTSTART:20161101T020000=0A= RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D1SU;BYMONTH=3D11=0A= TZOFFSETFROM:-0400=0ATZOFFSETTO:-0500=0ATZNAME:Standard=20Time=0A= END:STANDARD=0ABEGIN:DAYLIGHT=0ADTSTART:20160301T020000=0A= RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D2SU;BYMONTH=3D3=0A= TZOFFSETFROM:-0500=0ATZOFFSETTO:-0400=0ATZNAME:Daylight=20Savings=20Time=0A= END:DAYLIGHT=0AEND:VTIMEZONE=0ABEGIN:VEVENT=0AATTENDEE;CN=3D"SUIT=20= Working=20= Group";ROLE=3DREQ-PARTICIPANT;RSVP=3DTRUE:MAILTO:suit-chairs@ietf.org=0A= ORGANIZER;CN=3D"SUIT=20Working=20Group":MAILTO:suit-chairs@ietf.org=0A= DTSTART;TZID=3D"Eastern=20Time":20180621T080000=0ADTEND;TZID=3D"Eastern=20= Time":20180621T090000=0ALOCATION:https://ietf.webex.com/ietf=0A= TRANSP:OPAQUE=0ASEQUENCE:1529420594=0A= UID:141d83ec-6321-401e-815d-3f92001092d6=0ADTSTAMP:20180621T120000Z=0A= DESCRIPTION:\n\n\n\nJOIN=20WEBEX=20= MEETING\nhttps://ietf.webex.com/ietf/j.php?MTID=3Dmf041a2aad33cfa3757acaf7= c866aa855\nMeeting=20number=20(access=20code):=20648=20754=20= 363\nMeeting=20password:=203C936x32\n\n\n\nJOIN=20BY=20= PHONE\n1-650-479-3208=20Call-in=20toll=20number=20= (US/Canada)\n\n\n\nCan't=20join=20the=20= meeting?\nhttps://collaborationhelp.cisco.com/article/WBX000029055\n\n\nIM= PORTANT=20NOTICE:=20Please=20note=20that=20this=20WebEx=20service=20= allows=20audio=20and=20other=20information=20sent=20during=20the=20= session=20to=20be=20recorded,=20which=20may=20be=20discoverable=20in=20a=20= legal=20matter.=20By=20joining=20this=20session,=20you=20automatically=20= consent=20to=20such=20recordings.=20If=20you=20do=20not=20consent=20to=20= being=20recorded,=20discuss=20your=20concerns=20with=20the=20host=20or=20= do=20not=20join=20the=20session.\n=0AX-ALT-DESC;FMTTYPE=3Dtext/html:=09=  
 
 
=09=09Join=20= WebEx=20meeting=09=09=09=09=09=09=09=09=09=09=09=09= =09=09=09=09=09=09=09
=09=09=09=09=09=09Meeting=20number=20(access=20code):=20648=20754=20= 363=09=09=09=09=09
=09=09=09= =09=09=09
Meeting=20password:3C936x32
=09=09=

 
 
Join=20by=20phone =20
1-650-479-3208 Call-in=20toll=20= number=20(US/Canada) =20


=09 
=09= =09= Can't=20join=20= the=20meeting?=09 
 
IMPORTANT=20NOTICE:=20Please=20note=20that=20= this=20WebEx=20service=20allows=20audio=20and=20other=20information=20= sent=20during=20the=20session=20to=20be=20recorded,=20which=20may=20be=20= discoverable=20in=20a=20legal=20matter.=20By=20joining=20this=20session,=20= you=20automatically=20consent=20to=20such=20recordings.=20If=20you=20do=20= not=20consent=20to=20being=20recorded,=20discuss=20your=20concerns=20= with=20the=20host=20or=20do=20not=20join=20the=20session.=0A= SUMMARY:SUIT=20Open=20Design=20Team=20Meeting=0APRIORITY:5=0A= CLASS:PUBLIC=0ABEGIN:VALARM=0ATRIGGER:-PT5M=0AACTION:DISPLAY=0A= DESCRIPTION:Reminder=0AEND:VALARM=0AEND:VEVENT=0AEND:VCALENDAR=0A= --Apple-Mail=_D2D8A7EA-A90E-4558-AD23-76D50D3057D8 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii --Apple-Mail=_D2D8A7EA-A90E-4558-AD23-76D50D3057D8-- --Apple-Mail=_8822CCE3-B07C-4E0C-8D52-EB18348EBCA3-- From nobody Tue Jun 19 08:14:55 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A81AF13116C for ; Tue, 19 Jun 2018 08:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQzgO4V9uLNt for ; Tue, 19 Jun 2018 08:14:39 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30055.outbound.protection.outlook.com [40.107.3.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C7C6131167 for ; Tue, 19 Jun 2018 08:14:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sZDzREqTmOKIfgOvQnyhKU/oBJj3QT3quMJoOD5r0wY=; b=C1GiZyNpuKwp0npHV2qEt82V6Kc6YIoT/4XTRa0FELokIOjbckNwlKJzepjFXqG+uVlc77/d7sMjaw1LxkOQ/ZQLIqgp2b3Z7pdh9ibch/sZYKmBNdP+s5eQLP30I5wfXtRsHNzPwrxoclHPr8BW7RTEfu3xACljYpEMRGCrdws= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1631.eurprd08.prod.outlook.com (10.168.66.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.16; Tue, 19 Jun 2018 15:14:36 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35%4]) with mapi id 15.20.0863.016; Tue, 19 Jun 2018 15:14:36 +0000 From: Hannes Tschofenig To: Russ Housley , suit Thread-Topic: [Suit] Design team meeting on Thursday, 21 June 2018 at 0800 EDT for 1 hour Thread-Index: AQHUB99z5Nog3unc+U+Qc67+yer9eKRnsJJQ Date: Tue, 19 Jun 2018 15:14:36 +0000 Message-ID: References: <19C5E4A1-5B82-4C95-9FC1-5E7A5A47C2A8@vigilsec.com> In-Reply-To: <19C5E4A1-5B82-4C95-9FC1-5E7A5A47C2A8@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [217.140.96.140] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1631; 7:f3E+p4uLCWCUPAgO4aYIWFFro8HPH+gLcQz34Y5uoaDQ2iC6u/YKE1KLPZ/7M+buqe40OZK8pJV3+Nyf2WyuhYAzNxirveyeHh/ecf7AGzOQDpGR/OgBjSd9LSsVdVFuMFJVDVhPMhdbqud+HrvN5C/cOuJkjoy8v6Pa1GAYqG1MOXRnKOF8zXUQAo8gc1uMhateFaXMZPy4KxgKHtqwPVtkEyJ3jMTCdoz4Rd/geummmM/R9p2Ezg5gr6MenwrT x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: a906c248-a4ed-4ae2-f353-08d5d5f75e7c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(711020)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1631; x-ms-traffictypediagnostic: VI1PR0801MB1631: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(94707916325470)(95692535739014)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3231254)(944501410)(52105095)(93006095)(93001095)(3002001)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123558120)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB1631; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1631; x-forefront-prvs: 07083FF734 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(346002)(376002)(39380400002)(39860400002)(40434004)(189003)(199004)(16799955002)(14454004)(55016002)(5890100001)(6506007)(229853002)(8676002)(6436002)(8936002)(53546011)(5250100002)(59450400001)(66066001)(102836004)(74316002)(7696005)(7736002)(3280700002)(110136005)(114624004)(68736007)(316002)(26005)(186003)(33656002)(76176011)(99286004)(606006)(6116002)(486006)(25786009)(5660300001)(86362001)(81166006)(2900100001)(476003)(446003)(11346002)(2906002)(97736004)(478600001)(53936002)(9686003)(236005)(6246003)(105586002)(19627405001)(81156014)(72206003)(54896002)(3660700001)(6306002)(551544002)(106356001)(790700001)(3846002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1631; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: cZewUD1L2wUnrVjifxvBq7gSddRV7fWlYjVsaVJPL0qvzDm8hVSVsE8VYDmxx1NjuTQypPy6LBlTtp360z8jGE33sJQbPnneGuUTUpL8cTLag46UIxoCra4Cu3AI0ZjmgoexprtNfEqAkLv+HBIJ2k4mF3VrtuZvNkJtHMtGk/pDArAv2wx1AJjLSi02UMXb1/S9VNvmZu25N4P1mqiCG70ExJT8+p9LWQM5IKRfX6cbrConF2AiLmHO9aL4pXngMN3hd4HUBinFQL3b5W7bexjsXI7lhYzvZc1ipsMffpKhX5BVhSon3Q5DuWtvgLwqD+Dpy0sVys6Pw6JTyosPsw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB21122BA828838DE84F87EF62FA700VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: a906c248-a4ed-4ae2-f353-08d5d5f75e7c X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2018 15:14:36.0557 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1631 Archived-At: Subject: Re: [Suit] Design team meeting on Thursday, 21 June 2018 at 0800 EDT for 1 hour X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 15:14:53 -0000 --_000_VI1PR0801MB21122BA828838DE84F87EF62FA700VI1PR0801MB2112_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks, Russ, for setting up the conference bridge so that we can continue = the discussions from last week. From: Suit [mailto:suit-bounces@ietf.org] On Behalf Of Russ Housley Sent: 19 June 2018 16:09 To: suit Subject: [Suit] Design team meeting on Thursday, 21 June 2018 at 0800 EDT f= or 1 hour SUIT Working Group invites you to join this WebEx meeting. SUIT Open Design Team Meeting Thursday, June 21, 2018 8:00 am | Eastern Daylight Time (New York, GMT-04:00) | 1 hr Meeting number (access code): 648 754 363 Meeting password: 3C936x32 Add to Calendar When it's time, join the meeting. Join by phone 1-650-479-3208 Call-in toll number (US/Canada) Can't join the meeting? IMPORTANT NOTICE: Please note that this WebEx service allows audio and othe= r information sent during the session to be recorded, which may be discover= able in a legal matter. By joining this session, you automatically consent = to such recordings. If you do not consent to being recorded, discuss your c= oncerns with the host or do not join the session. IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_VI1PR0801MB21122BA828838DE84F87EF62FA700VI1PR0801MB2112_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks, Russ, for setting= up the conference bridge so that we can continue the discussions from last= week.

 

From: Suit [mailto:suit-bounces@ietf.org] On Behalf Of Russ Housley
Sent: 19 June 2018 16:09
To: suit
Subject: [Suit] Design team meeting on Thursday, 21 June 2018 at 080= 0 EDT for 1 hour

 

SUIT Working Group invites you to join this WebEx = meeting.

 

 

 

SUIT Open Design Team Meeting

Thursday, June 21, 2018

8:00 am  |  Eastern Daylight T= ime (New York, GMT-04:00)  |  1 hr

 

Meeting number (access code): 648 754 363

 

Meeting password: 3C936x32

 

 

 

Add to Calendar

When it's time, join the meeting.

 

 

 

Join by phone

1-650-479-3208 Call-in toll number (US/Canada)

 

 

 

Can't= join the meeting?

 

 

 

IMPORTANT NOTICE: Please note that this WebEx servi= ce allows audio and other information sent during the session to be recorde= d, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not = consent to being recorded, discuss your concerns with the host or do not jo= in the session.

 

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_VI1PR0801MB21122BA828838DE84F87EF62FA700VI1PR0801MB2112_-- From nobody Tue Jun 19 14:49:08 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE400130F37 for ; Tue, 19 Jun 2018 14:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=linaro.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlANHjX26A5e for ; Tue, 19 Jun 2018 14:49:03 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78F18130E63 for ; Tue, 19 Jun 2018 14:49:03 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id y127-v6so15930877itd.1 for ; Tue, 19 Jun 2018 14:49:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :user-agent; bh=7LbOVIDDj3oOR2VvGxr9XDDYx09g8Q6IJcdf38NO2AY=; b=YMV7+UAgDMKTLFL+LIfIUZ1OAHjk26UVA010oOXWvzlYF12tVzPqqmjAxiaNvImntF fbsOt3Y946ri2eq3EG/TxgDinBjay2t8Ea+I4pPqL4K+iYkFVYYFIuZfVpJ0sC2ZjhmV VUsXomm8i8lJc+G9R0X1Az6EjXqh4srC/A7uY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:user-agent; bh=7LbOVIDDj3oOR2VvGxr9XDDYx09g8Q6IJcdf38NO2AY=; b=GHF0WatmiUEbiH+bp1rla9C2+ocPCXTsS5JODP+brRdVshiDg7XdB+qJ0FSYwfm+cY /hgw4S38kMtjeQJ550OHLCthDRxb89DgBEpGkks/iera5xgwfhZbBI1rxXx27WqkddYZ srRSvEsgSow7oyQxsS+AXRu5REXcbbN8qil4ez/+XgdQKvf3ypQQyCSYfLNuvSVEkMbR +2AusOsvC1ZHxg/PEVJ2Jqbhx8cp3dHRUsEZ73NcZThol0QZ18140aIrAuU1l6Hb6Rvq k7g5vWodGeXsH6Tln6oWTrS+hAyahqMfflwsv3ZW+EsknzDZ5pvJWvm2v1YF/dKb9Fv2 wiOQ== X-Gm-Message-State: APt69E01QIYKIfuQCiAYJRDY1ycwWUeD1NAT3HGSRBNgB3FC0Sct5qU1 8Uy1PhokxyDiJkVh9ya8biNLQUfPvHc= X-Google-Smtp-Source: ADUXVKKV1OpX+DeWWM4teImdqEdFz4U5/pRUTV6ndOHyAxGe+XomnOvBOy290MbRscKR2oqgB8oaqg== X-Received: by 2002:a24:a089:: with SMTP id o131-v6mr14281050ite.149.1529444942444; Tue, 19 Jun 2018 14:49:02 -0700 (PDT) Received: from davidb.org ([2601:283:4300:987c::9]) by smtp.gmail.com with ESMTPSA id p20-v6sm5305210itf.4.2018.06.19.14.49.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jun 2018 14:49:01 -0700 (PDT) Date: Tue, 19 Jun 2018 15:48:59 -0600 From: David Brown To: suit Cc: dev-mcuboot@lists.runtime.co Message-ID: <20180619214859.GA4341@davidb.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: [Suit] Reference implementation of SUIT manifest parsing X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 21:49:06 -0000 At the last hackathon, work was done on implementations of the SUIT manifest format. One way to describe this kind of work would be as a reference implementation: something that could be a starting point for anyone wishing to use SUIT to develop something. However, I had to limit my involvement in this effort, because some of the code being used was covered under the LGPL 2.0. I'm wondering if it would be useful to develop equivalents of this code under a license that would be usable by a larger audience. I'm actually having a pretty hard time understanding how there is any audience for bootloader code covered under the LGPL. A few of the reasons that the LGPL doesn't work for me (and I believe doesn't work for many of the current uses). - The FSF considers the Apache 2.0 license to be incompatible with the GPLv2 (including the LGPL). - The Apache Software Foundation considers GPLv3 to be compatible in only one direction (Apache 2.0 code can be linked into an otherwise GPLv3 application, but GPLv3 code cannot be brought into an Apache 2.0 project). - The Apache Software Foundation considers the GPLv2 (including LGPL) to be incompatible with the Apache 2.0 license. - By Mynewt and Zephyr are licensed under the Apache 2.0 license. Mynewt is an Apache project and would fall under their constraints of forbidding the including of any code under a GPL license. The Zephyr project requires included code to be under the Apache 2.0 license, and occasionally will allow other more liberal licensed code to be included. Regardless of the above, I see a conflict between the LGPLv2 requirement that the user be able to modify the LGPLv2 licensed code, and the general purpose of SUIT to enforce that only authorized images run on the device. One of the purposes of a signed manifest is to restrict the very action that the LGPLv2 requires. My conclusions: - libcose (and any other LGPLv2 code) cannot be used by Zephyr, Mynewt, due to policies by these projects. At best, it would end up being something that end users would have to incorporate, and SUIT support would not be able to become standard support on these platforms. - libcose (and any other LGPLv2 code) cannot be used by Zephyr, Mynewt, mbed OS, and MCUboot, due to incompatibility between the LGPLv2 and the Apache 2.0 license. (Specifically, I do not believe the current mbed OS SUIT work is allowed). - Very few of our end users would want to meet the LGPLv2 requirement allowing end users to replace the firmware. Specifically, those users desiring signed manifests to ensure only authorized images can be run are likely intending to prohibit end users from running their own versions of the code. I've tried to avoid even looking at the libcose code (and making sure to look at licenses carefully) since it seems likely that I, or someone working on Zephyr or MCUboot) will need to implement COSE support in order to support SUIT. David From nobody Wed Jun 20 03:46:18 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15DF11310E1 for ; Wed, 20 Jun 2018 03:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zf4p3vCiMpo6 for ; Wed, 20 Jun 2018 03:46:08 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0046.outbound.protection.outlook.com [104.47.2.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97CED1310A8 for ; Wed, 20 Jun 2018 03:46:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bEQcMjJl6wmMUWJqDVSD9Cyo3P12mMN+Eetgpoxt0ZQ=; b=fLU85Cudy3wl6zhXYp95ldyHzjH/JqKOw/3VolzUXIE2yALkcgic5hLrxoLmBjmTCFozFK0JqqdVbBSrjysSvjUHpqvPjgvWxRQ+zbz9VJSTvWc9tjTjWz+1Y8dh+7qrpI7sHqnecB93lavkKQkpW4yuNXEVX8HCLDMqniU1R4U= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1485.eurprd08.prod.outlook.com (10.167.210.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.19; Wed, 20 Jun 2018 10:46:04 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35%4]) with mapi id 15.20.0863.016; Wed, 20 Jun 2018 10:46:04 +0000 From: Hannes Tschofenig To: Russ Housley , "Waltermire, David A. (Fed)" , Dave Thaler CC: suit Thread-Topic: SUIT Milestone Update Thread-Index: AdQIgwPfHB5PgtE3Q6KZiEYq3TBynA== Date: Wed, 20 Jun 2018 10:46:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [217.140.96.140] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1485; 7:l4zjZa9k5yz5U/ilI1ZP8VudGszYF9gB3eE6v633ED8rRNOXjKHZXSaX0F9adnZQIsrzwRf5I5E74czoAS9kn+U9Fct+S5yseGEOQEAHPeZntx6OvEmBc8wnLaQY5dgUSzkqmctjX0NGisF6IDKxdVH6FMCs1U+ApWkO49Zjjxim4bgz5Ynkb2b9a+WLOW39C/p5kPbzPj4LY/dFlUiuyS21RxfkJQPYd8a2PA7E8p3W7GksHyPa3ajhC+KURrCH x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 0019a19a-9159-446b-1cb5-08d5d69b056a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(711020)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1485; x-ms-traffictypediagnostic: VI1PR0801MB1485: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB1485; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1485; x-forefront-prvs: 070912876F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(39860400002)(376002)(39380400002)(396003)(199004)(189003)(40434004)(4326008)(3280700002)(53936002)(7110500001)(6436002)(8656006)(25786009)(74316002)(2906002)(5250100002)(106356001)(105586002)(1511001)(10710500007)(316002)(6306002)(5890100001)(9686003)(8666007)(7736002)(55016002)(54896002)(3660700001)(97736004)(99286004)(14454004)(33656002)(110136005)(15650500001)(72206003)(5660300001)(2900100001)(102836004)(8936002)(3480700004)(790700001)(478600001)(7116003)(2420400007)(86362001)(186003)(8676002)(6116002)(26005)(7696005)(3846002)(476003)(68736007)(59450400001)(81166006)(486006)(66066001)(81156014)(6506007); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1485; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: fiAFHCTt14wK13SgZHB3O9FSSQRv7cPWqOX97EnjJc1by4yCBdirgF2pVE/elpn+w8RhO03BwjVWF9Mj9tzy/yOWrYq71ysQo9Tp0iO9VyCYe2BbHTPbP7cZ7pMlAS3a/AblMdQONt6Y8yKMZPfW4J12vFVRZ81bbhPAOiEpNt/GNTemB29RDdf564Mk+sCBfbeZNyqYH4+b8Qqovy+dDbaexr87jGIyxnjt+mj062uHZTL0pmP9Z7gSsFYWcC+P5VO3SSKB6P2d+4IHqo13UPtT2WraPWfP7V0ObLg/YbBfGWRkZQ/XExZHgq8P42KLu6MdF7bHvqpWaRb2Wkbujg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB21125833B06FA8A7047057D0FA770VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0019a19a-9159-446b-1cb5-08d5d69b056a X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jun 2018 10:46:03.9936 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1485 Archived-At: Subject: [Suit] SUIT Milestone Update X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 10:46:16 -0000 --_000_VI1PR0801MB21125833B06FA8A7047057D0FA770VI1PR0801MB2112_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Russ, DaveT, DaveW, I looked at the milestones of the SUIT group and I noticed two things: 1) There is no milestone for submitting the architecture documen= t to the IESG. I would suggest some time in the fall. 2) The milestone dates need to be updated. Should the informatio= n model document be put forward to the IESG at the same time as the seriali= zation document? I don't think we will get the manifest serialization done = in November if we also plan to have a reference implementation available at= the same time. Milestones Date Milestone Nov 2018 Submit an initial manifest serialization format to the IESG for publication= as a Proposed Standard. Jul 2018 Submit manifest information model to the IESG for publication as Informatio= nal. Jul 2018 Calendar item: Second interoperability event at IETF 102. Mar 2018 Adopt initial manifest serialization format(s) as WG item(s). Done Calendar item: First interoperability event at IETF 101. Done Adopt a manifest information model as a WG item. Done Adopt "Architecture" document as WG item. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_VI1PR0801MB21125833B06FA8A7047057D0FA770VI1PR0801MB2112_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Russ, DaveT, DaveW,

 

I looked at the milestones of the SUIT g= roup and I noticed two things:

 

1) = ;           There is = no milestone for submitting the architecture document to the IESG. I would = suggest some time in the fall.

2) = ;           The miles= tone dates need to be updated. Should the information model document be put= forward to the IESG at the same time as the serialization document? I don’t think we will get the manifest serialization done = in November if we also plan to have a reference implementation available at= the same time.

 

Milestones

Date

Milestone

Nov 2018

Submit an initial manifest serialization format to the IESG for public= ation as a Proposed Standard.

Jul 2018

Submit manifest information model to the IESG for publication as Infor= mational.

Jul 2018

Calendar item: Second interoperability event at IETF 102.

Mar 2018

Adopt initial manifest serialization format(s) as WG item(s).

Done

Calendar item: First interoperability event at IETF 101.

Done

Adopt a manifest information model as a WG item.

Done

Adopt "Architecture" document as WG item.<= /p>

 

Ciao
Hannes

 =

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_VI1PR0801MB21125833B06FA8A7047057D0FA770VI1PR0801MB2112_-- From nobody Wed Jun 20 03:59:38 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29E94130DC4 for ; Wed, 20 Jun 2018 03:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aolBvcI1_r4a for ; Wed, 20 Jun 2018 03:59:34 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0627.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1e::627]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D3D61277D2 for ; Wed, 20 Jun 2018 03:59:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QMAp8IOVwsnCgiJ4w3A15tckTOypIPj4Lw/5PkBlc/o=; b=Dw7Jeh256VYO4wyoKfGI6ShQxR00NyYZG5J7YLQ3UWwT85vmmnQQpCqN6ytUT0ZoEZkR0MF+PkLQc0zT/zwKWg42af9hldf+2XmHR/WWkaobt6jvRD7nrioT+Kf0B55rKKza0pI83HwONVu6vchd+SQfHl6p2fCkn2FP97irs10= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1613.eurprd08.prod.outlook.com (10.167.211.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.17; Wed, 20 Jun 2018 10:59:30 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35%4]) with mapi id 15.20.0863.016; Wed, 20 Jun 2018 10:59:30 +0000 From: Hannes Tschofenig To: suit Thread-Topic: Hackathon @ Montreal IETF Meeting Thread-Index: AdQIg+04cUh7drkmS760j64dFny90A== Date: Wed, 20 Jun 2018 10:59:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [217.140.96.140] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1613; 7:3NU+rUy89UjfXebn80R9jt6ZEPTbnTo8EWbnatlz91v7/S5R2huk320eS9Wzv1Ehvf3knNJ7UtMC6RnmYYn0irlDfaUsNWl0KB+EegddN1n1E33M3HkDtbXo5wtf6l8qj97ZHOhPI/qRbwE9Qwc2Oh6dQyAcQ+fkyjGiJevCKh6CzjneqtrcI6qzSk1N7tOOOjMfLGERJ2EUr8hFO2fqJKv39VnWGxqcLKfJUKBTJ2JtGe/NFv24hbbZE7Va7p6a x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 285ce2f9-be67-4b2b-ccdd-08d5d69ce5dc x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(711020)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1613; x-ms-traffictypediagnostic: VI1PR0801MB1613: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3231254)(944501410)(52105095)(3002001)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB1613; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1613; x-forefront-prvs: 070912876F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(396003)(376002)(366004)(39860400002)(346002)(53754006)(189003)(199004)(40434004)(7736002)(105586002)(486006)(55016002)(476003)(66066001)(3660700001)(3280700002)(790700001)(3846002)(6116002)(33656002)(5660300001)(6436002)(5890100001)(5250100002)(2906002)(99286004)(14454004)(8936002)(2900100001)(25786009)(7696005)(9686003)(54896002)(6306002)(6506007)(966005)(26005)(102836004)(68736007)(97736004)(74316002)(236005)(59450400001)(86362001)(4743002)(106356001)(478600001)(53936002)(8676002)(316002)(606006)(81166006)(6916009)(72206003)(81156014)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1613; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: zbdd98PrKOcEtDQlHSFVbaf8gQ53G+EAJuC8LUkStda/1d/ZYn5Z6r0grcJYNhWgcAB9A7Y3pzNv8jmSp33AzOLPsP4vn2Ix6FyAkYGAmRw4MWHOVtvioy5uA5uZHmNQTvaRuvDmQ5QGXFC0NPINBZkltrCF9mKQJ+dAFKmFy/aId29FQhAqAoQh2I7pegIGimwd+N3xE8pNXhLbndaJRmpXxkrDX8+xM5zcQ6aRh4MRjXKO6oVhMV/Bs+XBlcWb+PedyyaqXZgjD7b7igbUtreXysUOuFPuA9RCwiCsOsmLlWiA16RaFziTXKgMhOQ5vNtcASwQWQPecqa0P+0fNw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB211265E221FE1AE30AB28AFEFA770VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 285ce2f9-be67-4b2b-ccdd-08d5d69ce5dc X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jun 2018 10:59:30.1027 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1613 Archived-At: Subject: [Suit] Hackathon @ Montreal IETF Meeting X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 10:59:37 -0000 --_000_VI1PR0801MB211265E221FE1AE30AB28AFEFA770VI1PR0801MB2112_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, we are planning to continue our SUIT hackathon at the next IETF meeting and= I added the project to the wiki page at https://trac.ietf.org/trac/ietf/me= eting/wiki/102hackathon. Please register at https://ietf.org/how/runningcode/hackathons/102-hackatho= n/, if you want to participate. Remote participation is also possible. Content-wise we are planning to get the manifest parsing improved. I expect= that we will produce example manifests representing the different features= . Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_VI1PR0801MB211265E221FE1AE30AB28AFEFA770VI1PR0801MB2112_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

we are planning to continue our SUIT hackathon at th= e next IETF meeting and I added the project to the wiki page at https= ://trac.ietf.org/trac/ietf/meeting/wiki/102hackathon.

 

Please register at https://ietf.org/how/runningcode/hackathons/102-hackathon/,  if yo= u want to participate. Remote participation is also possible.

 

Content-wise we are planning to get the manifest par= sing improved. I expect that we will produce example manifests representing= the different features.

 

Ciao

Hannes

 

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_VI1PR0801MB211265E221FE1AE30AB28AFEFA770VI1PR0801MB2112_-- From nobody Thu Jun 21 03:33:43 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A74D8131216 for ; Thu, 21 Jun 2018 03:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXju9a-ZD6xP for ; Thu, 21 Jun 2018 03:33:38 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0622.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1f::622]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8191F130D7A for ; Thu, 21 Jun 2018 03:33:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FQpXt2YyWGwhrU4Er2ucVtfyQgbTaqN1lWVRaFr+8Oo=; b=AFPoJGsuL+Rmi8CHKfVl9SEwGaazqssB0TIa0dAhokHi9cVI29mZP0H2a38NO0PSvymKEx6U+nvYDi+GAKmYLfdGbvMwYZuLoZHLgGFdQL13uw7SUs1qaPlijQ1DIavwRzjDdmEwp63LByhb5XMZJwfQrCMZ3z1GLW7pesh8Dc8= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1632.eurprd08.prod.outlook.com (10.168.66.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.19; Thu, 21 Jun 2018 10:33:34 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35%4]) with mapi id 15.20.0863.016; Thu, 21 Jun 2018 10:33:34 +0000 From: Hannes Tschofenig To: suit Thread-Topic: Blog post about the Berlin Hackathon Thread-Index: AdQJSttQ+6BX13VqQKq7xtaWbt+1ZQ== Importance: low X-Priority: 5 Date: Thu, 21 Jun 2018 10:33:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [217.140.96.140] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1632; 7:wbUn42nymmhyFRjAhJ8FOFVjA4IbaiGFg5Z5A1MmkZb9UfaIe8alv4/VehRYQqe3+teKBUwQfp96PEjR82IGSfj7vdHb5/NYaFWZX9Gk4Mlep5UtK0VMpqJ8Ns4N50uhlAf7klfbE8xK58W0LWqw+hKu156HPTWXQRvtnC6cn3lF+pgAmYGGLq0ai+VNunbMKEizLcLCy9EkmaqjDN7lVcNmNCd2X/8se7FZ77SaeSTWXDtvAqMeQ1+WAa1MVLi2 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 357d5cf0-e20e-4364-639a-08d5d7627120 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(711020)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1632; x-ms-traffictypediagnostic: VI1PR0801MB1632: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231254)(944501410)(52105095)(3002001)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB1632; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1632; x-forefront-prvs: 07106EF9B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(396003)(376002)(39380400002)(346002)(199004)(189003)(40434004)(53754006)(8676002)(9686003)(5890100001)(6306002)(86362001)(54896002)(6506007)(7736002)(102836004)(53936002)(81686011)(25786009)(606006)(2900100001)(33656002)(5250100002)(74316002)(81166006)(81156014)(97736004)(55016002)(476003)(6916009)(8936002)(186003)(59450400001)(486006)(26005)(7696005)(236005)(6436002)(68736007)(5660300001)(790700001)(3846002)(3660700001)(3280700002)(14454004)(6116002)(99286004)(316002)(478600001)(105586002)(72206003)(2906002)(106356001)(966005)(66066001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1632; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: n52L7dhlNiaQuHD7ooAMjIm2ZVPr4L7EzAa4syh1z81+7AjPkJHLkOVBYxUHNPLsMkN6ynWynOi+6c5JYKAVyH8Do+pKPmV1j5xr6cujN5nVNKkIbvG74OZSSjgBEv3QuRtAUBTUxt/xjZCyOF4sC9NQo6SVViFuIkD98VO5ngigZrk9Upa9sLeDCgJv0tTRK1ijnV+hbQ1nQubVbOsLKNVnkdzzAYRRXT438x3mXuHFo49bwZKkk16sZ4tf8rZDn/Tq9YLu9qAODj7s03ZZwT263aix38WXK7HA6ijKW0WdOd8NLXAY9KhC5Khn/7blLjRaGIUzor7hseCLys+hcA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB21121F21DA57FDD2334A1F89FA760VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 357d5cf0-e20e-4364-639a-08d5d7627120 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jun 2018 10:33:34.5856 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1632 Archived-At: Subject: [Suit] Blog post about the Berlin Hackathon X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 10:33:41 -0000 --_000_VI1PR0801MB21121F21DA57FDD2334A1F89FA760VI1PR0801MB2112_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I created a short write-up about the Berlin Hackathon and what we tried to = accomplish: https://os.mbed.com/blog/entry/Firmware-updates-for-IoT-devices/ Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_VI1PR0801MB21121F21DA57FDD2334A1F89FA760VI1PR0801MB2112_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I created a short write-up about the Berlin Hackatho= n and what we tried to accomplish:

https://os.mbed.com/blog/entry/Firmware-updates-fo= r-IoT-devices/

 

Ciao

Hannes

 

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_VI1PR0801MB21121F21DA57FDD2334A1F89FA760VI1PR0801MB2112_-- From nobody Thu Jun 21 04:36:57 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86627130E7E for ; Thu, 21 Jun 2018 04:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id la0yrKvNotGH for ; Thu, 21 Jun 2018 04:36:48 -0700 (PDT) Received: from lepus.uberspace.de (lepus.uberspace.de [95.143.172.195]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D779E131228 for ; Thu, 21 Jun 2018 04:36:47 -0700 (PDT) Received: (qmail 15236 invoked from network); 21 Jun 2018 11:36:45 -0000 Received: from localhost (HELO ?10.188.122.198?) (127.0.0.1) by lepus.uberspace.de with SMTP; 21 Jun 2018 11:36:45 -0000 Date: Thu, 21 Jun 2018 13:36:41 +0200 User-Agent: K-9 Mail for Android In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: Hannes Tschofenig CC: suit@ietf.org From: =?ISO-8859-1?Q?Max_Gr=F6ning?= Message-ID: <9F1602EC-4AFA-4895-B698-D68385300F69@max-g.net> Archived-At: Subject: Re: [Suit] Blog post about the Berlin Hackathon X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 11:36:52 -0000 Hi Hannes, Thank you, you posted a great and informative article! The summary of the = group's work and also mentioning the hackathon in London gives a clear pict= ure also to everyone not involved with SUIT (yet)=2E Thanks, Max >I created a short write-up about the Berlin Hackathon and what we tried >to accomplish: >https://os=2Embed=2Ecom/blog/entry/Firmware-updates-for-IoT-devices/ From nobody Thu Jun 21 04:54:36 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0733713107D for ; Thu, 21 Jun 2018 04:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SlSxFbltnWGr for ; Thu, 21 Jun 2018 04:54:32 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 835A912D7F8 for ; Thu, 21 Jun 2018 04:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w5LBsSYv013515; Thu, 21 Jun 2018 13:54:28 +0200 (CEST) Received: from [192.168.217.114] (p5DC7FF04.dip0.t-ipconnect.de [93.199.255.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41BKqm1Dn0zDXDy; Thu, 21 Jun 2018 13:54:28 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Carsten Bormann In-Reply-To: <20180619214859.GA4341@davidb.org> Date: Thu, 21 Jun 2018 13:54:27 +0200 Cc: suit , dev-mcuboot@lists.runtime.co X-Mao-Original-Outgoing-Id: 551274865.70532-4d8cc69d02767237bd93b87dc79b3735 Content-Transfer-Encoding: quoted-printable Message-Id: <95E49C9F-0332-4925-A212-EBDC23B28738@tzi.org> References: <20180619214859.GA4341@davidb.org> To: David Brown X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Suit] Reference implementation of SUIT manifest parsing X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 11:54:35 -0000 Hi David, Licenses are a difficult area, and I don=E2=80=99t want to go into = details on some of the points that you are making. But we agree in one observation: It would be good to have a liberally = licensed reference implementation of SUIT around. (This statement explicitly does not detract from the merits of having = other implementations, as well.) What are the components we need for that? https://github.com/cose-wg/COSE-C is BSD-3-clause licensed, and is based = on https://github.com/cabo/cn-cbor which is MIT licensed. These make some specific implementation choices that may be right or = wrong for your environments. An alternative CBOR library would be https://github.com/intel/tinycbor = which also is MIT licensed; I haven=E2=80=99t checked COSE-C on how hard = it would be to do the pull-parser approach there as well. (I don=E2=80=99= t see a big problem with sticking to a tree-based implementation on the = generation side.) We=E2=80=99d need liberally licensed implementations of at least SHA-256 = and the ECC algorithms of your choice. A reference implementation of hash-based signatures would be useful, too = (allowing us to relax the reliance on ECC). Finally, it would be useful to have an example implementation of the = actual authorization algorithms that devices are likely to employ =E2=80=94= even if we don=E2=80=99t standardize them, it is useful to shape = expectations here. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jun 21 04:59:09 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA96A1277D2 for ; Thu, 21 Jun 2018 04:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=linaro.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljMNyZYJcXQt for ; Thu, 21 Jun 2018 04:59:02 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38B87130DC3 for ; Thu, 21 Jun 2018 04:59:02 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id q4-v6so2734393iob.2 for ; Thu, 21 Jun 2018 04:59:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=whQ/Rr6t6x64ihEab7X0BNo6ovWqdsJ/2mXMYeGuRDk=; b=FS4Mc90/azWU/NOHUQ6LstYxUBJfudCLvygtKXiizmAldGbSrLyEicmXrjAnlGUrj/ 7GkE4Yij1GtlWMsstBfvAKf4UTBTJmXwHyvuy+jU6c+4Gt0umX0QguzaueyFSIsEQ9sq mGHac0Tk70ffmhr5QV5bHHLFI3bS9GZoX5dTo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=whQ/Rr6t6x64ihEab7X0BNo6ovWqdsJ/2mXMYeGuRDk=; b=mK7HsHcwUMld56BPgNsOQP+bXB6+YbZQjrav2jhluCVXVIVpmsMoAWIcFxLmLPTfsq kvs9BXuj6vHofySpPbUSNKc4rYYkggjYAwBamDYlROZYFJOnAHXffk5UPemW+zZuWE7d 9NzzM7fqudwo6lRFalW7TUG9lMr8qx1hwJM9AJQKeaCbdzzDzIdbfqZMr/AfEZXd2e5w JqMcTLSTFifJw8Sj36TCq4kg3vQD0Dg+r8BRZB19MWoxyLFfKNBDO5b5qHWO4OOzxFtb G68Wj4tDddK1+VCJhDY9/noJuzpPGtmPDqQV6SF1qkp1Pn0EGeXa0j421v9LjszKzPLR yikQ== X-Gm-Message-State: APt69E0THEFxUx1cwfQUIcL/5A1/OtZ4vDMqdr34twp0EySDpLwLomdZ smHuhDsBr4LiMmEZFgbPjil/1w== X-Google-Smtp-Source: ADUXVKKxU6d5Etaf6HsY3UrlMziUWEjsIW8fPZ5np5QovlOjM0qSluadk5cbT/LGiIlICbr1nGhzsA== X-Received: by 2002:a6b:b802:: with SMTP id i2-v6mr19121922iof.41.1529582341289; Thu, 21 Jun 2018 04:59:01 -0700 (PDT) Received: from [10.0.1.3] ([2601:283:4300:987c:fd6e:ffa3:57bb:972e]) by smtp.gmail.com with ESMTPSA id d136-v6sm2324887itd.22.2018.06.21.04.59.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Jun 2018 04:59:00 -0700 (PDT) User-Agent: Microsoft-MacOutlook/10.e.1.180613 Date: Thu, 21 Jun 2018 05:58:59 -0600 From: David Brown To: Tamas Ban , suit CC: "dev-mcuboot@lists.runtime.co" Message-ID: <10617C16-B988-42D2-AFB3-BCAC52AABB15@linaro.org> Thread-Topic: [dev-mcuboot] Reference implementation of SUIT manifest parsing References: <20180619214859.GA4341@davidb.org> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Suit] [dev-mcuboot] Reference implementation of SUIT manifest parsing X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 11:59:05 -0000 I don't really have an idea on the code size change. However, I don't think we should use an existing library for the parsing, b= ut write custom processing code for the things we support, similar to how we= process the TLV data and the signatures now. It will be best to not just a= llow any arbitrary signature type, but specifically require certain specific= signature types. David =EF=BB=BFOn 6/20/18, 9:05 AM, "Tamas Ban" wrote: Hi David, =20 Do you have any rough estimate how much will be the code size increased= due to the libs for the parsing manifest files in CBOR/COSE format? =20 Does it need a separate lib for parsing CBOR(i.e: tinycbor, cn-cbor) an= d a different one to verify COSE signing? =20 Tamas =20 -----Original Message----- From: dev-mcuboot On Behalf Of D= avid Brown Sent: 19 June 2018 23:49 To: suit Cc: dev-mcuboot@lists.runtime.co Subject: [dev-mcuboot] Reference implementation of SUIT manifest parsin= g =20 At the last hackathon, work was done on implementations of the SUIT man= ifest format. One way to describe this kind of work would be as a reference= implementation: something that could be a starting point for anyone wishing= to use SUIT to develop something. =20 However, I had to limit my involvement in this effort, because some of = the code being used was covered under the LGPL 2.0. =20 I'm wondering if it would be useful to develop equivalents of this code= under a license that would be usable by a larger audience. I'm actually ha= ving a pretty hard time understanding how there is any audience for bootload= er code covered under the LGPL. =20 A few of the reasons that the LGPL doesn't work for me (and I believe d= oesn't work for many of the current uses). =20 - The FSF considers the Apache 2.0 license to be incompatible with the GPLv2 (including the LGPL). =20 - The Apache Software Foundation considers GPLv3 to be compatible in only one direction (Apache 2.0 code can be linked into an otherwise GPLv3 application, but GPLv3 code cannot be brought into an Apache 2.0 project). =20 - The Apache Software Foundation considers the GPLv2 (including LGPL) to be incompatible with the Apache 2.0 license. =20 - By Mynewt and Zephyr are licensed under the Apache 2.0 license. Mynewt is an Apache project and would fall under their constraints of forbidding the including of any code under a GPL license. The Zephyr project requires included code to be under the Apache 2.0 license, and occasionally will allow other more liberal licensed code to be included. =20 Regardless of the above, I see a conflict between the LGPLv2 requiremen= t that the user be able to modify the LGPLv2 licensed code, and the general = purpose of SUIT to enforce that only authorized images run on the device. O= ne of the purposes of a signed manifest is to restrict the very action that = the LGPLv2 requires. =20 My conclusions: =20 - libcose (and any other LGPLv2 code) cannot be used by Zephyr, Mynewt, due to policies by these projects. At best, it would end up being something that end users would have to incorporate, and SUIT support would not be able to become standard support on these platforms. =20 - libcose (and any other LGPLv2 code) cannot be used by Zephyr, Mynewt, mbed OS, and MCUboot, due to incompatibility between the LGPLv2 and the Apache 2.0 license. (Specifically, I do not believe the current mbed OS SUIT work is allowed). =20 - Very few of our end users would want to meet the LGPLv2 requirement allowing end users to replace the firmware. Specifically, those users desiring signed manifests to ensure only authorized images can be run are likely intending to prohibit end users from running their own versions of the code. =20 I've tried to avoid even looking at the libcose code (and making sure t= o look at licenses carefully) since it seems likely that I, or someone worki= ng on Zephyr or MCUboot) will need to implement COSE support in order to sup= port SUIT. =20 David =20 _______________________________________________ MCUBoot: a secure, open source bootloader for 32-bit MCUs http://lists.= runtime.co/mailman/listinfo/dev-mcuboot_lists.runtime.co IMPORTANT NOTICE: The contents of this email and any attachments are co= nfidential and may also be privileged. If you are not the intended recipient= , please notify the sender immediately and do not disclose the contents to a= ny other person, use it for any purpose, or store or copy the information in= any medium. Thank you. =20 From nobody Thu Jun 21 06:06:56 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C00FD130E43 for ; Thu, 21 Jun 2018 06:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUJnuUffmYxr for ; Thu, 21 Jun 2018 06:06:51 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0081.outbound.protection.outlook.com [104.47.0.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72F62130DC7 for ; Thu, 21 Jun 2018 06:06:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jAQHBRkjt+U+ULSb1cKxEo77eglKc+QuL0X1LMz7unQ=; b=gGnpTqJVLhxIn31XN4BWy+EzDwTjuKpovrpAz5uXNDjMWyuqtkxRAJ33gOEiKA0vPzUV+BCHNhYlcfjUoFP71E2tqExR3HwEYgneGeaY+W9AWNBt8mwjtipwQje+HAi/RVackaVe7rjFGmLVi42yN5pL210ggE/jnJNuo7jNueg= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1808.eurprd08.prod.outlook.com (10.168.67.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.884.19; Thu, 21 Jun 2018 13:06:47 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35%4]) with mapi id 15.20.0863.016; Thu, 21 Jun 2018 13:06:47 +0000 From: Hannes Tschofenig To: suit Thread-Topic: Meeting Minutes - 21 June 2018 Thread-Index: AdQJYI6AUTg0T7GQTuuSMsS5SYswlg== Date: Thu, 21 Jun 2018 13:06:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [217.140.96.140] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1808; 7:aO5fZwYIVRN8Tl8uhektZS6j3//xKz4tMaQ9PmzIAXhhufGyTBgmqyUTZyDERF44/RbrQijx2/MR7fPfpV5PAF9CkCvZVH6BmsEutNhb4wzR4KyKwsekpWhgYIyVdi2MpPUJk3T7M1EAYFT4TtUVabElLkQ+Wj/KEq9DqoaBlgczATBmUcZFTXkCE7RLkg1xTxOmZfpgj2VIrdOGwp4Ug1HxDBl27PoPxK26iTUiXzswHDvByk41nemuLuw98Hsb x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 26b8bad7-7d76-4bdd-dd2e-08d5d777d85c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:(258095267146985); BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(711020)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1808; x-ms-traffictypediagnostic: VI1PR0801MB1808: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(166708455590820)(192374486261705)(258095267146985)(788757137089)(261952635957900)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123564045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB1808; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1808; x-forefront-prvs: 07106EF9B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(366004)(346002)(39860400002)(376002)(396003)(40434004)(199004)(189003)(186003)(966005)(14454004)(5250100002)(7696005)(99286004)(5890100001)(26005)(97736004)(8936002)(6436002)(106356001)(3280700002)(6916009)(102836004)(72206003)(86362001)(59450400001)(6506007)(476003)(66066001)(486006)(25786009)(9686003)(33656002)(7736002)(74316002)(8676002)(68736007)(81156014)(316002)(3660700001)(478600001)(81166006)(6116002)(790700001)(53936002)(3846002)(2900100001)(6306002)(54896002)(2906002)(5660300001)(105586002)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1808; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 2MDaes3LJI4xNzDccJPm++DMUv7Sm+uEl/NkUyN9t54FDITfyyjLsHzWZUlNOEUErM++AIduVJ3WOC7cGvz+CiJJseIz6JMtZuYoVQ7lCb+RN8+aTQJCtVaJRDihqmgD84jBx02eHRACqbBya2sxzNfM+ZBvWuydZYCVlQtznfTG+CXo7qy5RUS5ddtGRqfgjbSLtQpSjK7eLVtY/hEwXpoYsrYV3lM8J06Qi7IHY77CzS5wndPKYt57nOTNdH35SDAhwm3JUCETxOL/wNkuFw6lesvHiv7h4ZNHjRtYsOxxX6B62ReaBmnPLXxRciWdNb6IXTM2MjbiqPTp5HxhrQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB211215A6C669CFFAE3477D6EFA760VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 26b8bad7-7d76-4bdd-dd2e-08d5d777d85c X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jun 2018 13:06:47.2246 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1808 Archived-At: Subject: [Suit] Meeting Minutes - 21 June 2018 X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 13:06:55 -0000 --_000_VI1PR0801MB211215A6C669CFFAE3477D6EFA760VI1PR0801MB2112_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Participants: * Carsten Bormann * Brendan Moran * David Brown * Markus Gueller * Hannes Tschofenig * Frank Audun Kvamtr=F8 * =D8yvind R=F8nningstad * Michael Richardson Notes: Brendan goes through the current draft: https://github.com/suit-wg/information-model/tree/v01 MFUS7: Brendan explained the use case for preventing devices from unpacking= . Frank & =D8yvind: Anything that can be done prior to starting the process = is super convenient for implementations. We can foresee that some implement= ations will select only a few encoding methods, including some of the encry= ption mechanisms. If we can stop the downloading and the parsing by just pa= rsing the format. The question is only at what stage this should be enforced. Brendan: This can be enforced at various stages. There will be a service co= mponent, a management system. If you go through a management system then th= at system should query the device for capabilities and it should ensure tha= t it communicates that info to the system that provides the update. The dev= ice will have to again make the check. There would be a multi-stage process= . Frank & =D8yvind: In the resource information we have a way to change what= the source is (based on the digest). Hence, you can use a local server rat= her than a cloud server. Could the negotiation be taken over by a third par= ty? Brendan: If you can fully trust a third party then I don't see a reason why= not. Regarding the data structure I haven't thought about how and whether = at all they would be impacted. Has anyone looked at how a third party does the validation check? Nobody in= the group has. Brendan speculates about the possible implications in terms= of a new manifest or a manifest that is counter-signed. This assumes that = public key crypto is used. David: Do you have some examples where this Frank & =D8yvind: It could be an external chip that does the decryption. Brendan: Are we talking about one-device operations? Brendan: One of the discussion that has come up are "primary and secondary"= devices. This is where the storage identifier came from. Hannes: We need to update the architecture document to explain the primary/= secondary verification. David: There are various deployment use cases today, which we could capture= . David brings up an example: http://www.cypress.com/products/32-bit-arm-cortex-m4-psoc-6 In this case Flash and RAM is shared between the two processors. One proces= sor is generic and the second processor is used for security functionality.= For the update the security processor would be involved and it would write= to memory to update the software of the application processor. David agreed to produce a short write-up. Note for MRSR7: Indicate what was done, indicate trust level or provability= . Brendan argues that it would be have a solution that just uses another mani= fest since it keeps the manifest parsing simpler. Frank & =D8yvind: I see the possibility to offload payload processing to o= ther systems so that the manifest does not really know what is being convey= ed. David: We are going to discuss the MCU Boot info Brendan: The manifest contains information that is not necessarily needed b= y a bootloader. David: The installation step is part of the bootloader: 1) Do I replace the old with the new firmware image? 2) Can I boot the new image? Brendan: If it also does installation then it has to have more information Frank & =D8yvind: I hope that the MCU Boot can be parsed in a simpler mann= er. David: We want to mitigate complexity. The bootloader has to make the deter= mination about two images and it has to boot them together then it has to = have more complex logic. Do we extend our manifest or do we make MCU Boot understand the SUIT manife= st? David will post info about the conference call to the SUIT mailing list. Frank & =D8yvind: As long as you can be agnostic about the payload then yo= u can have a way to bridge into a different system. Brendan: I think we will see bootloaders that understand SUIT but also thos= e that do not understand them because the SUIT functionality is handled at = a higher layer. In addition we will also see that bootloaders that will lau= nch second stage bootloaders that are networking capable and understand man= ifests. MFUR8: Frank & =D8yvind: In our email we elaborated on this topic. We would cover= this scenario with storage identifiers. Brendan: This use case came from discussion at the Hackathon. Someone wante= d to be able to replace versions A, B, and D but not version C. They wanted= to target different types of devices but with a single manifest. David: Do we know the bounds on the complexity of the rules (e.g., nested B= oolean evaluation)? Brendan: I am scared of the complexity. I prefer "match all" style comparis= ons only. It appears that this does not address all requirements. The appro= ach that makes most sense is to add special conditions on a case-by-case ba= sis. Brendan: You ship 4 different device versions - A, B, C, and D. Later you discover that there is a flaw on versions A, B, and D. You ship a= n update that applies to these three versions but you skip the update of ve= rsion C. The idea was to provide a "match-any" list (in addition to the cur= rent "match-all" list). Markus: We brought this functionality up. It came from our legacy versions = and we have been trying to map this into SUIT. Previously the manifest didn= 't had a version identification at all. The only other possibility was to i= nclude a list of cryptographic hashes but this takes up some space in the m= anifest (depending on the number of devices). Another option would be a fir= mware version list. As Brendan said it could be a separate condition; alter= natively it would be a proprietary vendor condition. Brendan: The great thing about these conditions is that they don't cost you= something if you don't want to use them. Brendan: The question is whether all conditions are mandatory to implement. Markus: I hope not Brendan: Then, any condition that is not understood leads to an update fail= ure. David: That's also my understanding. Michael: Whether all these conditions will be written by the manufacturer v= s. written by operators. The manufacturer has to provide some description o= f what is being implemented. David: This affects the previous use case. The processing engine needs to k= now what features are available in a later stage. Brendan: This requires a capability negotiation with the bootloader. David: The trust is still determined by the bootloader in our case. We don'= t trust the application. Brendan: The application is trusted that the bootloader is capable of verif= ying the manifest. Hannes: There are different trust models on who verifies the manifest. For = example, one can image a case where an update service verifies the manifest= and then lets the bootloader just jump to the received image vs. having th= e bootloader verify the manifest itself. Carsten: We should be explicit about the threat model we use. Brendan: We need to make this more explicit. (It is essentially a question about where the 'ends' in the end-to-end secu= rity is. ) Frank & =D8yvind: We could have an array of all the versions that are supp= orted then this would fit into the existing design. This would not be diffi= cult to do. There are two different concepts here: First, the version conce= pt. Second, there would be the new matching criteria. I believe you only ne= ed to support one of the two in order to satisfy the use case. Brendan, you= have been looking into the match-any concept rather than the other one. Brendan: I think it makes sense to use the existing conditions and then for= any given condition that already exists then you can provide it with an ar= ray and then you can match any. This would be added to the existing type de= finition. I am concerned about the complexity. Markus: We didn't want to create more manifest. Brendan: I prefer a product of sums than an arbitrary complex Boolean condi= tion. I assume the complexity will be low in most cases. Frank & =D8yvind: How about a separate condition that contains an array of= conditions? (with the exception of not containing itself) Brendan: If we got for a product of sum and all conditions contain lists th= en it would simplify the schema. Frank & =D8yvind: I am fine with that. Carsten: I think we can decide that later. We can for now have it as an arr= ay. IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_VI1PR0801MB211215A6C669CFFAE3477D6EFA760VI1PR0801MB2112_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Participants:

 

* Carsten Bormann

* Brendan Moran

* David Brown

 * Markus Gueller

 * Hannes Tschofenig =

 * Frank Audun Kvamtr=F8

* =D8yvind R=F8nningstad

* Michael Richardson

 

Notes:

 

Brendan goes through the current draft: <= /p>

https://github.com/suit-wg/information-model/tree/v0= 1

 

MFUS7: Brendan explained the use case for preventing= devices from unpacking.

 

Frank & =D8yvind:  Anything that can be don= e prior to starting the process is super convenient for implementations. We= can foresee that some implementations will select only a few encoding meth= ods, including some of the encryption mechanisms. If we can stop the downloading and the parsing by just parsing the format.=

 

The question is only at what stage this should be en= forced.

 

Brendan: This can be enforced at various stages. The= re will be a service component, a management system. If you go through a ma= nagement system then that system should query the device for capabilities a= nd it should ensure that it communicates that info to the system that provides the update. The device will have to = again make the check. There would be a multi-stage process.

 

Frank & =D8yvind:  In the resource informat= ion we have a way to change what the source is (based on the digest). Hence= , you can use a local server rather than a cloud server. Could the negotiat= ion be taken over by a third party?

 

Brendan: If you can fully trust a third party then I= don't see a reason why not. Regarding the data structure I haven't thought= about how and whether at all they would be impacted.

Has anyone looked at how a third party does the vali= dation check? Nobody in the group has. Brendan speculates about the possibl= e implications in terms of a new manifest or a manifest that is counter-sig= ned. This assumes that public key crypto is used.

 

David: Do you have some examples where this

 

Frank & =D8yvind:  It could be an external = chip that does the decryption.

 

Brendan: Are we talking about one-device operations?=

 

Brendan: One of the discussion that has come up are = "primary and secondary" devices. This is where the storage identi= fier came from.

 

Hannes: We need to update the architecture document = to explain the primary/secondary verification.

 

David: There are various deployment use cases today,= which we could capture.

 

David brings up an example:

http://www.cypress.com/products/32-bit-arm-cortex-m4= -psoc-6

 

In this case Flash and RAM is shared between the two= processors. One processor is generic and the second processor is used for = security functionality. For the update the security processor would be invo= lved and it would write to memory to update the software of the application processor. 

 

David agreed to produce a short write-up.

 

Note for MRSR7: Indicate what was done, indicate tru= st level or provability.

 

Brendan argues that it would be have a solution that= just uses another manifest since it keeps the manifest parsing simpler.

 

Frank & =D8yvind:  I see the possibility to= offload payload processing to other systems so that the manifest does not = really know what is being conveyed.

 

David: We are going to discuss the MCU Boot info

 

Brendan: The manifest contains information that is n= ot necessarily needed by a bootloader.

 

David: The installation step is part of the bootload= er:

 

1) Do I replace the old with the new firmware image?=

2) Can I boot the new image?

 

Brendan: If it also does installation then it has to= have more information

 

Frank & =D8yvind:  I hope that the MCU Boot= can be parsed in a simpler manner.

 

David: We want to mitigate complexity. The bootloade= r has to make the determination about  two images and it has to boot t= hem together then it has to have more complex logic.

Do we extend our manifest or do we make MCU Boot und= erstand the SUIT manifest?

 

David will post info about the conference call to th= e SUIT mailing list.

 

Frank & =D8yvind:  As long as you can be ag= nostic about the payload then you can have a way to bridge into a different= system.

 

Brendan: I think we will see bootloaders that unders= tand SUIT but also those that do not understand them because the SUIT funct= ionality is handled at a higher layer. In addition we will also see that bo= otloaders that will launch second stage bootloaders that are networking capable and understand manifests.

 

MFUR8:

 

Frank & =D8yvind:  In our email we elaborat= ed on this topic. We would cover this scenario with storage identifiers.

 

Brendan: This use case came from discussion at the H= ackathon. Someone wanted to be able to replace versions A, B, and D but not= version C. They wanted to target different types of devices but with a sin= gle manifest.

 

David: Do we know the bounds on the complexity of th= e rules (e.g., nested Boolean evaluation)?

 

Brendan: I am scared of the complexity. I prefer &qu= ot;match all" style comparisons only. It appears that this does not ad= dress all requirements. The approach that makes most sense is to add specia= l conditions on a case-by-case basis.

 

Brendan: You ship 4 different device versions - A, B= , C, and D.

Later you discover that there is a flaw on versions = A, B, and D. You ship an update that applies to these three versions but yo= u skip the update of version C. The idea was to provide a "match-any&q= uot; list (in addition to the current "match-all" list).

 

Markus: We brought this functionality up. It came fr= om our legacy versions and we have been trying to map this into SUIT. Previ= ously the manifest didn't had a version identification at all. The only oth= er possibility was to include a list of cryptographic hashes but this takes up some space in the manifest (depe= nding on the number of devices). Another option would be a firmware version= list. As Brendan said it could be a separate condition; alternatively it w= ould be a proprietary vendor condition.

 

Brendan: The great thing about these conditions is t= hat they don't cost you something if you don't want to use them.

 

Brendan: The question is whether all conditions are = mandatory to implement.

 

Markus: I hope not

 

Brendan: Then, any condition that is not understood = leads to an update failure.

 

David: That's also my understanding.

 

Michael: Whether all these conditions will be writte= n by the manufacturer vs. written by operators. The manufacturer has to pro= vide some description of what is being implemented.

 

David: This affects the previous use case. The proce= ssing engine needs to know what features are available in a later stage.

 

Brendan: This requires a capability negotiation with= the bootloader.

 

David: The trust is still determined by the bootload= er in our case. We don't trust the application.

 

Brendan: The application is trusted that the bootloa= der is capable of verifying the manifest.

 

Hannes: There are different trust models on who veri= fies the manifest. For example, one can image a case where an update servic= e verifies the manifest and then lets the bootloader just jump to the recei= ved image vs. having the bootloader verify the manifest itself.

 

Carsten: We should be explicit about the threat mode= l we use.

 

Brendan: We need to make this more explicit.

(It is essentially a question about where the 'ends'= in the end-to-end security is. )

 

Frank & =D8yvind:  We could have an array o= f all the versions that are supported then this would fit into the existing= design. This would not be difficult to do. There are two different concept= s here: First, the version concept. Second, there would be the new matching criteria. I believe you only need to support one= of the two in order to satisfy the use case. Brendan, you have been lookin= g into the match-any concept rather than the other one.

 

Brendan: I think it makes sense to use the existing = conditions and then for any given condition that already exists then you ca= n provide it with an array and then you can match any. This would be added = to the existing type definition. I am concerned about the complexity.

 

Markus: We didn't want to create more manifest.=

 

Brendan: I prefer a product of sums than an arbitrar= y complex Boolean condition.

I assume the complexity will be low in most cases. <= o:p>

 

Frank & =D8yvind:  How about a separate con= dition that contains an array of conditions? (with the exception of not con= taining itself)

 

Brendan: If we got for a product of sum and all cond= itions contain lists then it would simplify the schema.

 

Frank & =D8yvind:  I am fine with that.

 

Carsten: I think we can decide that later. We can fo= r now have it as an array.

 

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_VI1PR0801MB211215A6C669CFFAE3477D6EFA760VI1PR0801MB2112_-- From nobody Thu Jun 21 06:08:54 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2801130E2A for ; Thu, 21 Jun 2018 06:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.008 X-Spam-Level: X-Spam-Status: No, score=-0.008 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, LOTS_OF_MONEY=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=linaro.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bd9GJBm0hT_L for ; Thu, 21 Jun 2018 06:08:50 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50B82130DC7 for ; Thu, 21 Jun 2018 06:08:50 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id m194-v6so4566625itg.2 for ; Thu, 21 Jun 2018 06:08:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version; bh=w8Z+jD3+ZtF0t4/GeS/lXTx62HThrwsN1djpjfp8hfE=; b=KZ0x6sP3M0cHYlGPda48I/wnMIcRc9d0btj4C+s3kjrlsPDBIueQW4BRE7ePxERVSw 7f1qYZbn0G39V2wfGsw1FAnW63Y0Z+N1I27W1pvfBOblJt82o5LD9G5ZaP+Mt5GdOOlm nslZC4zrR+V1IAV2SDNWHn4mtDyALzk6XbhB0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version; bh=w8Z+jD3+ZtF0t4/GeS/lXTx62HThrwsN1djpjfp8hfE=; b=Pfp4LJVDfy8HTBDALTCY3QNKDV8nVVVZ2HI57zqDo7Snb4TEzWyJWmfpZUZfvnKH5A SG2ieMkv8998lmjHtwmzDJfsCTy1WX2nsHkHT1GsmroNQMMq0YgJrpkAFCgfyF4ZL3uO d1Kgwwk/FBBLEl4sQ1Qkwr0mN/9565U9XPrPSuq2RRClet97ipxVTWusrNMFqEK90IaC aH+k/5/qm4LKTf1I+E7jNx9o36pMLQK4S3HO2i/QSdD5HGamXPG3VrzF8gPNp37A3cJY QblGV1qu6aVZV0CN9MRYLsJQv4fBKQD/XsgXqFIGHFajA9V2wB+3+CuOufi1VmYQqG89 u+cg== X-Gm-Message-State: APt69E1ipbHgWXQPn8WPP0MWgc/3xgwOHvizA7stl9StMm/1d8WZdp6C FhQ+FQacDmqrIMC8R+KRhIl1DY7NWuY= X-Google-Smtp-Source: ADUXVKKAGMznMglOBVW+flL4sPe5c4FYKVEmRaDQC8N3jQTZWZEdd/en7nPafqSVMOwmqcSn2hcz1g== X-Received: by 2002:a24:64ce:: with SMTP id t197-v6mr5062393itc.36.1529586529218; Thu, 21 Jun 2018 06:08:49 -0700 (PDT) Received: from [10.0.1.3] ([2601:283:4300:987c:fd6e:ffa3:57bb:972e]) by smtp.gmail.com with ESMTPSA id l13-v6sm1851804iob.82.2018.06.21.06.08.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Jun 2018 06:08:48 -0700 (PDT) User-Agent: Microsoft-MacOutlook/10.e.1.180613 Date: Thu, 21 Jun 2018 07:08:47 -0600 From: David Brown To: suit Message-ID: <4B693B72-461C-4C13-9CF1-07A754A2BA63@linaro.org> Thread-Topic: MCUboot meeting/discussion Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3612409728_618052010" Archived-At: Subject: [Suit] MCUboot meeting/discussion X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 13:08:53 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3612409728_618052010 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit This week, we are meeting today, Thursday, at 1500UTC (11AM US East Coast, 5PM Central European). The regular meeting is on Tuesdays. Let me know if anyone is interested in attending the regular time slot. Today will be discussing the interactions between SUIT and MCUboot, specifically as MCUboot needs to add support for multiple images. David To join the meeting on a computer or mobile phone: https://bluejeans.com/674192919/1410?src=calendarLink Here are the details for the meeting you scheduled: Connecting directly from a room system? 1) Dial: 199.48.152.152 or bjn.vc 2) Enter Meeting ID: 674192919 3) Enter Passcode: 1410 Just want to dial in on your phone? 1) Dial one of the following numbers: +1.408.740.7256 (US) +1.888.240.2560 (US Toll Free) +1.408.317.9253 (Alternate number) (http://bluejeans.com/numbers) 2) Enter Meeting ID: 674192919 3) Press # 4) Enter Passcode: 1410 5) Press # ----------------------------------- Description: This week, we're holding this meeting on Thursday instead of Tuesday due to scheduling. ----------------------------------- Want to test your video connection? https://bluejeans.com/111 --B_3612409728_618052010 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

This week, = we are meeting today, Thursday, at 1500UTC (11AM US East Coast, 5PM Central = European). The regular meeting is on Tuesdays. Let me know if anyone is inte= rested in attending the regular time slot.

 

Today will be discussing the interac= tions between SUIT and MCUboot, specifically as MCUboot needs to add support= for multiple images.

 

David

 

To joi= n the meeting on a computer or mobile phone: https= ://bluejeans.com/674192919/1410?src=3DcalendarLink

Here are the details for the meeting you scheduled:


Connecting directly from a room system?
1) Dial: 199.48.152.152 or <= a href=3D"https://www.google.com/url?q=3Dhttp%3A%2F%2Fbjn.vc&sa=3DD&usd=3D2&= amp;usg=3DAFQjCNEPWy5J881S9k0hmaWFqXuoEXjH4w" target=3D"_blank">bjn.vc
2)= Enter Meeting ID: 674192919
3) Enter Passcode: 1410

Just want to dial in on your phone?
1) Dial one of the following numb= ers:
+1.408.740.7256 (US)
+1.888.240.2560 (US Toll Free)
+1.408.317= .9253 (Alternate number)

(http://bluejeans.com/numbers)
2) Enter= Meeting ID: 674192919
3) Press #
4) Enter Passcode: 1410
5) Press = #


-----------------------------------
Description:
This week, = we're holding this meeting on Thursday instead of Tuesday due to scheduling.=
-----------------------------------
Want to test your video connectio= n?
https://bluejeans.com/111

 =

--B_3612409728_618052010-- From nobody Thu Jun 21 07:42:40 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 194D8130DF0 for ; Thu, 21 Jun 2018 07:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=linaro.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KsVAdA7ol_NF for ; Thu, 21 Jun 2018 07:42:36 -0700 (PDT) Received: from mail-it0-x242.google.com (mail-it0-x242.google.com [IPv6:2607:f8b0:4001:c0b::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72C90130E96 for ; Thu, 21 Jun 2018 07:42:36 -0700 (PDT) Received: by mail-it0-x242.google.com with SMTP id a3-v6so5148560itd.0 for ; Thu, 21 Jun 2018 07:42:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :user-agent; bh=5431D/sLkGfypsiueJ+RMDKjDeaEJVH5k5IX1IhBeyU=; b=PMxEFIQ7gweY8dT/8FeM69+kM57X3K1IjRBWQgMdPobp6TohNER2v3OdI8mk5H4sUI vcHuKM8VeuPPwfFfhlZTMN5GdA3h8zACG2wE8tjWy4HMtHz0O0o0ejZuds/8QTkpaxhB NwAMcUNXGLRNR/Dsk/A0GwLVwO/89dOW7hYRs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:user-agent; bh=5431D/sLkGfypsiueJ+RMDKjDeaEJVH5k5IX1IhBeyU=; b=CqWDd/qDN04Mpm0qhq7dbIDM3aEf/nOTfWsnv6GtCmschWT2UKTrqBBqcPR63CiO3P mJPqeNQCM/hnoKvtTUFKFGUmkBlDSBHUJc0llnLgxiSz7thfRFnz53wQNaonktL8a+m1 jS5Qb2FFIRfHk5ZNQSVn3MBFsRRAw48vEZZ/UMlosnaXQ5oejXp7wR2QwLcVyoSUF6RK Tgh2Hti/KsGAhrICOa3e4N8QOYgUItm0whr7aiIPLlJN0NEnE6YlMGQvk/1dDT0yj9X7 /e34bDPVz9KUFxMSNxvPu4LU6x3fmOo8EiPXKVUfmNh1I0wuaZTGQUo3M5c2I9oLJxx4 sn7w== X-Gm-Message-State: APt69E2bBapIMOe+9xQwMdAFnIqZ9SvlTK41TNlEllcAVrljWU0iTtTb NYKFOPDfrFsM0ccqBLUQOJqaT8Cb32Y= X-Google-Smtp-Source: ADUXVKJxJEW7I2JR3hLJEcCSbSi5bej3WWvQyMx8fxA+SKj7YByo154eDdXjjCYFFGWqUQiWN3o2aQ== X-Received: by 2002:a02:9b39:: with SMTP id o54-v6mr20445395jak.32.1529592155634; Thu, 21 Jun 2018 07:42:35 -0700 (PDT) Received: from davidb.org ([2601:283:4300:987c::9]) by smtp.gmail.com with ESMTPSA id f127-v6sm1530092iof.32.2018.06.21.07.42.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Jun 2018 07:42:35 -0700 (PDT) Date: Thu, 21 Jun 2018 08:42:33 -0600 From: David Brown To: "dev-mcuboot@lists.runtime.co" Cc: suit Message-ID: <20180621144233.GA19590@davidb.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: [Suit] MCUboot SUIT discussions X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 14:42:39 -0000 I've written up the following in preparation for today's discussion of the interaction of the IETF SUIT work, and work to add dual image support to MCUboot. # MCUboot and SUIT - Currently, MCUboot supports a single image. - Last week's LITE, we discussed requirements for multiple-image support: - One possibility is to consider the two images as a single unit, and always update them together. If used with delta compression, this handles the case of only one image changing by encoding just a reference to the unchanged parts. - Another possibility is to have the images separate. - Two possibilities: independent updates, or both together atomically. - We need both of these. Both together would be equivalent to treating them as a single unit. - Image metadata will need to describe the relationship between the images, for example, stating that version A of the first image will require version B of the second image. - The bootloader (and presumably the image download code) will need to determine this relationship, and only perform the upgrade when the conditions have been met. - The IETF SUIT project is working to define a manifest format for embedded device firmware upgrades. - Among other things, they are addressing the same kinds of issues that we have. - This is a working group, and participants can influence the development of the standard. - Possible ways for MCUboot to use SUIT. - "Ignore" SUIT. SUIT is defined in such a way that its manifest could be used for the download part of the process, and the images would still contain the existing TLV information about versions and signature. - This doesn't address the multiple-image issues. - It is likely to be redundant to the metadata contained in the SUIT manifest. - It may require redundant signing of images, if SUIT is used, as the TLV information will also need to contain a signature. - Use SUIT instead of TLV for MCUboot - Pro: This will address the multiple image format issues - Con: There will likely be additional code to parse the manifests. It is unclear how significant this difference will be, given that we would have to extend the TLV format to describe multiple images. - Con: The SUIT manifest format is a work-in-progress, and will likely change over time until the standard is formalized. - Pro: This addresses one security concern with the current TLV format, namely that the TLV data is not covered in the signature. This is fine for now, because the TLV currently only contains information about the signature, but if we add dependency information, that information would be subject to tampering. - My (David Brown) suggestions: - Start by adding support for the "single big image" solution. This shouldn't require manifest changes, and may not require any changes to MCUboot. - Become more involved with the SUIT working group, to make sure MCUboot's needs are considered. - Implement a prototype alternate to TLV that works with the SUIT manifest format. - I recommend a custom parser and signature verification code. The existing libraries for these formats generally use malloc and are larger, more general code than we need. - We should restrict the SUIT manifest to a limited subset of the full format. For examples, a given build may require a specific signature type to be present. - This should be a compile-time decision, and the TLV code should be maintained. - My suggestion would be to keep the existing header, but with a different magic number, and place the manifest at the end of the image, where the current TLV is. - Ideas for things to extend SUIT with: - One of the images to contain the acceptable public keys for the other image. From nobody Thu Jun 21 08:11:34 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A24D6130DE2 for ; Thu, 21 Jun 2018 08:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVsbYBEUvUxq for ; Thu, 21 Jun 2018 08:11:22 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40041.outbound.protection.outlook.com [40.107.4.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F6F412F1A6 for ; Thu, 21 Jun 2018 08:11:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mbhrAq4BY1wb4aXJhxneLWYaL+h2CnFH92CmWQhTRf0=; b=R5kik/iueIRRyq4u9eZObwwAw3MvMrCWB4MMCUcdBRKl3MNyItYynGEYl0T2oduiN5DzG9bTTeiaX9DCKXLubP8ydVl+ubGe8J3TogtoY9wGmL+joTVGydwA9D0DOr/aiPQb8GzrM9lZWTwUAxYWQsYF0yKd6/iiPYE6wFXw9AY= Received: from AM4PR0802MB2260.eurprd08.prod.outlook.com (10.172.217.150) by AM4PR0802MB2289.eurprd08.prod.outlook.com (10.172.218.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.884.20; Thu, 21 Jun 2018 15:11:18 +0000 Received: from AM4PR0802MB2260.eurprd08.prod.outlook.com ([fe80::15ab:db2e:593b:b5e0]) by AM4PR0802MB2260.eurprd08.prod.outlook.com ([fe80::15ab:db2e:593b:b5e0%4]) with mapi id 15.20.0863.016; Thu, 21 Jun 2018 15:11:18 +0000 From: Brendan Moran To: Russ Housley CC: suit Thread-Topic: [Suit] draft-housley-suit-cose-hash-sig Thread-Index: AQHUA0IcLpl64e0Ltk+rjSClOrFaQaRei+EAgAxRz4A= Date: Thu, 21 Jun 2018 15:11:18 +0000 Message-ID: <0CDB8D05-0214-4749-9907-5A1B0B4A2191@arm.com> References: <31676.1528913351@localhost> <04f401d40349$33a58b10$9af0a130$@augustcellars.com> In-Reply-To: <04f401d40349$33a58b10$9af0a130$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.8.2) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brendan.Moran@arm.com; x-originating-ip: [217.140.96.140] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0802MB2289; 7:1NbDkRX+lZGSVMjmVWJ/wxijDBQ34/i0OPu1yBciYN4cmaDzkZ89jXQPMb4wcjuqqLhW/IN8uHIXVpt9ekHgEU4HP1ioRTQwVW9Nc7asOCLP8SLPoTd2NCAUaidHwUf826BJiI208Y2AARR984PhzOHei4GEfP2YBwNky1R6rT1V0BCWnkGmZvennkpDCL6xocNfm92YrKvz409NaPQLNQRtE+Wt0qIQyeKfm5mN+hLySakPikiRo8s2ZMn6E4pq x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 22394dd2-625c-4455-fede-08d5d7893d7c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(711020)(48565401081)(2017052603328)(7153060)(7193020); SRVR:AM4PR0802MB2289; x-ms-traffictypediagnostic: AM4PR0802MB2289: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:AM4PR0802MB2289; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0802MB2289; x-forefront-prvs: 07106EF9B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(396003)(39860400002)(346002)(366004)(376002)(189003)(199004)(40434004)(13464003)(3846002)(6116002)(81166006)(5250100002)(6916009)(7736002)(82746002)(5890100001)(8676002)(2900100001)(5660300001)(81156014)(2906002)(72206003)(68736007)(14454004)(4326008)(966005)(53936002)(25786009)(3660700001)(50226002)(478600001)(3280700002)(6246003)(8936002)(606006)(106356001)(33656002)(57306001)(105586002)(316002)(66066001)(186003)(59450400001)(6512007)(54896002)(6306002)(236005)(86362001)(486006)(99286004)(6506007)(53546011)(97736004)(6436002)(476003)(36756003)(2616005)(229853002)(102836004)(446003)(76176011)(6486002)(11346002)(83716003)(26005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0802MB2289; H:AM4PR0802MB2260.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: RxZtLHOAhwEKSJWXgjNiFn9fcv2cPEfwTVyy62fBUT/pFgZl8a0RtxMyDEfvbHVD1zFnCQ9n/d0txuNJWyIvS7rWoWb1H69Ergi3lh4KcD0HkIQhGzYhy4lFZHy30L9OHihFfAIgBkaIrn8KO4Gl6KY/dYvK+nODCvxW+KS0HoWy+fu5mJrZ02atDB9znoslVgSAkaOjGDldGTbrR7zqRyjfF8MBrYOZ7GqqcB/y2XPx4/SdKq8ln6C9aXxYnWrrUC5UdVcRUK68DyvMS8F91Tm/a+QITcLWHMDt+BYu6j/sG8ZSP6517563JQtsyLhuFk8i2Q1DkaRFxgWEDxgwWg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_0CDB8D050214474999075A1B0B4A2191armcom_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 22394dd2-625c-4455-fede-08d5d7893d7c X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jun 2018 15:11:18.4265 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0802MB2289 Archived-At: Subject: Re: [Suit] draft-housley-suit-cose-hash-sig X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 15:11:26 -0000 --_000_0CDB8D050214474999075A1B0B4A2191armcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I see that there are two current drafts for hash-based signatures: https://tools.ietf.org/html/draft-mcgrew-hash-sigs-11 https://tools.ietf.org/html/draft-irtf-cfrg-xmss-hash-based-signatures-12 I see that you have referenced the mcgrew draft rather than the IRTF/CFRG d= raft. Could you please explain what the difference is between these two dra= fts and why the mcgrew draft was a better choice than XMSS? Thanks, Brendan On 13 Jun 2018, at 20:03, Jim Schaad > wrote: -----Original Message----- From: Suit > On Behalf = Of Michael Richardson Sent: Wednesday, June 13, 2018 11:09 AM To: suit > Subject: [Suit] draft-housley-suit-cose-hash-sig I have read the -01 draft today. I have not read [HASHSIG] yet. I thought I'd try reading this first, to see what questions I had. I have implemented COSE Sign1 with ECDSA in Ruby, so I have a grasp of what we are trying to plug hash-sig *into*. Suggestions: 1) would the structure show in section 3 be easier if it was described by CDDL? I'm rather unclear about this. No - this are not CBOR structures they are pure binary strings 2) I din't understand section 4, where it says: o If the 'key_ops' field is present, it MUST include 'sign' when creating a hash-based signature. o If the 'key_ops' field is present, it MUST include 'verify' when verifying a hash-based signature. Clearly this is not something that travels over the network. Is this somehow indicating how to understand if one is dealing a public (verify) key or a private (sign) key? The key_ops field can be considered to potentially be transported over a network. It is part of the COSE_Key object rather than part of the COSE_Sign1 object. 3) the variations: LMS_SHA256_M32_H20, and LMOTS_SHA256_N32_W2, etc. are listed, but I don't know if they need to be carried in the signature structure somehow. See the [HASHSIG] draft. It is encoded into the signature structure and th= e key type is in the public key structure. 4) I thought that perhaps we'd need CBOR or COSE specific way to transport the signatures. I guess I shall read HASHSIG to find out what the signatures look like. We have that. This is looking at a signature just like ECDSA would produce= . This is a different "ECDSA" replacement. I understand draft-mcgrew-hash-sigs-11 is being advanced by CFRG. I believe that SUIT should adopt this document, and should do so in the current state. I would like to have some examples in CBOR/COSE worked out with private keys available in the appendices. Always a good thing to have. Jim -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ = | ruby on rails [ -- Michael Richardson >, S= andelman Software Works -=3D IPv6 IoT consulting =3D- _______________________________________________ Suit mailing list Suit@ietf.org https://www.ietf.org/mailman/listinfo/suit IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_0CDB8D050214474999075A1B0B4A2191armcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
I see that there are two current drafts for hash-based sign= atures:
https://tools.ietf.org/html/draft-mcgrew-hash-sigs-11=
https://tools.ietf.org/html/draft-irt= f-cfrg-xmss-hash-based-signatures-12

I see that you have referenced the mcgrew draft rather than= the IRTF/CFRG draft. Could you please explain what the difference is betwe= en these two drafts and why the mcgrew draft was a better choice than XMSS?=

Thanks,
Brendan


On 13 Jun 2018, at 20:03, Jim Schaad <ietf@augustcellars.com> wrote:


-----Original Message-----
From: Suit <suit-bou= nces@ietf.org> On Behalf Of Michael Richardson
Sent: Wednesday, June 13, 2018 11:09 AM
To: suit <suit@ietf.org&= gt;
Subject: [Suit] draft-housley-suit-cose-hash-sig


I have read the -01 draft today.
I have not read [HASHSIG] yet.
I thought I'd try reading this first, to see what questions I had.

I have implemented COSE Sign1 with ECDSA in Ruby, so I have a grasp of
what we are trying to plug hash-sig *into*.


Suggestions:
1) would the structure show in section 3 be easier if it was described by   CDDL?  I'm rather unclear about this.

No - this are not CBOR structures they are pure binary strings


2) I din't understand section 4, where it says:
     o  If the 'key_ops' field is present, it= MUST include 'sign' when
            &nb= sp;   creating a hash-based signature.

     o  If the 'key_ops' field is present, it= MUST include 'verify'
            &nb= sp;   when verifying a hash-based signature.

Clearly this is not something that travels over the network.  Is this<= br class=3D"">
somehow
indicating how to understand if one is dealing a public (verify) key or a
private
(sign) key?

The key_ops field can be considered to potentially be transported over a
network.  It is part of the COSE_Key object rather than part of the
COSE_Sign1 object.


3) the variations: LMS_SHA256_M32_H20, and LMOTS_SHA256_N32_W2,
etc. are
  listed, but I don't know if they need to be carried in the sign= ature
  structure somehow.

See the [HASHSIG] draft.  It is encoded into the signature structure and = the
key type is in the public key structure.


4) I thought that perhaps we'd need CBOR or COSE specific way to transport<= br class=3D"">   the signatures.  I guess I shall read HASHSIG to find out = what the
  signatures look like.

We have that.  This is looking at a signature just like ECDSA would prod= uce.
This is a different "ECDSA" replacement.


I understand draft-mcgrew-hash-sigs-11 is being advanced by CFRG.
I believe that SUIT should adopt this document, and should do so in the
current state.

I would like to have some examples in CBOR/COSE worked out with private
keys available in the appendices.

Always a good thing to have.

Jim


--
]             &= nbsp; Never tell me the odds!       &nbs= p;         | ipv6 mesh
networks [
]   Michael Richardson, Sandelman Software Works   &nbs= p;    | network
architect  [
]     mc= r@sandelman.ca  ht= tp://www.sandelman.ca/        | &nbs= p; ruby on rails
[

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
-=3D IPv6 IoT consulting =3D-




_______________________________________________
Suit mailing list
Suit@ietf.org=
ht= tps://www.ietf.org/mailman/listinfo/suit

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_0CDB8D050214474999075A1B0B4A2191armcom_-- From nobody Thu Jun 21 08:43:27 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7065A12F1A5 for ; Thu, 21 Jun 2018 08:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oZaD0Gxa83n for ; Thu, 21 Jun 2018 08:43:21 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90E9F130EEC for ; Thu, 21 Jun 2018 08:43:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 82889300A08 for ; Thu, 21 Jun 2018 11:43:19 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 02sgv_B9Bmd7 for ; Thu, 21 Jun 2018 11:43:17 -0400 (EDT) Received: from new-host-4.home (pool-71-127-50-4.washdc.fios.verizon.net [71.127.50.4]) by mail.smeinc.net (Postfix) with ESMTPSA id 4046F30042A; Thu, 21 Jun 2018 11:43:17 -0400 (EDT) From: Russ Housley Message-Id: <697B1DC9-B1DE-48BA-ADC6-EF936208AFCE@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E7915BCC-9048-4898-8895-20C25B84A823" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Thu, 21 Jun 2018 11:43:17 -0400 In-Reply-To: <0CDB8D05-0214-4749-9907-5A1B0B4A2191@arm.com> Cc: suit To: Brendan Moran References: <31676.1528913351@localhost> <04f401d40349$33a58b10$9af0a130$@augustcellars.com> <0CDB8D05-0214-4749-9907-5A1B0B4A2191@arm.com> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Suit] draft-housley-suit-cose-hash-sig X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 15:43:26 -0000 --Apple-Mail=_E7915BCC-9048-4898-8895-20C25B84A823 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Brendan: Yes, there are two CFRG algorithms for hash-based signatures. I prefer = the one McGrew's document, mostly because it is more straightforward. = There is some speed improvement for the additional complexity in XMSS at = the cost of a larger signature value. To me, the speed improvement is = not big enough to justify the larger signature size. Your mileage may = vary. This paper describes the difference between the two: https://eprint.iacr.org/2017/349.pdf Russ > On Jun 21, 2018, at 11:11 AM, Brendan Moran = wrote: >=20 > I see that there are two current drafts for hash-based signatures: > https://tools.ietf.org/html/draft-mcgrew-hash-sigs-11 = > = https://tools.ietf.org/html/draft-irtf-cfrg-xmss-hash-based-signatures-12 = >=20 > I see that you have referenced the mcgrew draft rather than the = IRTF/CFRG draft. Could you please explain what the difference is between = these two drafts and why the mcgrew draft was a better choice than XMSS? >=20 > Thanks, > Brendan >=20 >=20 >> On 13 Jun 2018, at 20:03, Jim Schaad > wrote: >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: Suit > On = Behalf Of Michael Richardson >>> Sent: Wednesday, June 13, 2018 11:09 AM >>> To: suit > >>> Subject: [Suit] draft-housley-suit-cose-hash-sig >>>=20 >>>=20 >>> I have read the -01 draft today. >>> I have not read [HASHSIG] yet. >>> I thought I'd try reading this first, to see what questions I had. >>>=20 >>> I have implemented COSE Sign1 with ECDSA in Ruby, so I have a grasp = of >>> what we are trying to plug hash-sig *into*. >>>=20 >>>=20 >>> Suggestions: >>> 1) would the structure show in section 3 be easier if it was = described by >>> CDDL? I'm rather unclear about this. >>=20 >> No - this are not CBOR structures they are pure binary strings >>=20 >>>=20 >>> 2) I din't understand section 4, where it says: >>> o If the 'key_ops' field is present, it MUST include 'sign' = when >>> creating a hash-based signature. >>>=20 >>> o If the 'key_ops' field is present, it MUST include 'verify' >>> when verifying a hash-based signature. >>>=20 >>> Clearly this is not something that travels over the network. Is = this >> somehow >>> indicating how to understand if one is dealing a public (verify) key = or a >> private >>> (sign) key? >>=20 >> The key_ops field can be considered to potentially be transported = over a >> network. It is part of the COSE_Key object rather than part of the >> COSE_Sign1 object. >>=20 >>>=20 >>> 3) the variations: LMS_SHA256_M32_H20, and LMOTS_SHA256_N32_W2, >>> etc. are >>> listed, but I don't know if they need to be carried in the = signature >>> structure somehow. >>=20 >> See the [HASHSIG] draft. It is encoded into the signature structure = and the >> key type is in the public key structure. >>=20 >>>=20 >>> 4) I thought that perhaps we'd need CBOR or COSE specific way to = transport >>> the signatures. I guess I shall read HASHSIG to find out what the >>> signatures look like. >>=20 >> We have that. This is looking at a signature just like ECDSA would = produce. >> This is a different "ECDSA" replacement. >>=20 >>>=20 >>> I understand draft-mcgrew-hash-sigs-11 is being advanced by CFRG. >>> I believe that SUIT should adopt this document, and should do so in = the >>> current state. >>>=20 >>> I would like to have some examples in CBOR/COSE worked out with = private >>> keys available in the appendices. >>=20 >> Always a good thing to have. >>=20 >> Jim >>=20 >>>=20 >>> -- >>> ] Never tell me the odds! | ipv6 mesh >> networks [ >>> ] Michael Richardson, Sandelman Software Works | network >> architect [ >>> ] mcr@sandelman.ca = http://www.sandelman.ca/ | ruby on = rails >> [ >>>=20 >>> -- >>> Michael Richardson >, Sandelman Software Works >>> -=3D IPv6 IoT consulting =3D- >>>=20 >>>=20 >>=20 >>=20 >> _______________________________________________ >> Suit mailing list >> Suit@ietf.org >> https://www.ietf.org/mailman/listinfo/suit = > IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy = the information in any medium. Thank you. --Apple-Mail=_E7915BCC-9048-4898-8895-20C25B84A823 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Brendan:

Yes, there are two CFRG algorithms for hash-based signatures. =  I prefer the one McGrew's document, mostly because it is more = straightforward.  There is some speed improvement for the = additional complexity in XMSS at the cost of a larger signature value. =  To me, the speed improvement is not big enough to justify the = larger signature size.  Your mileage may vary.

This paper describes the = difference between the two:

= https://eprint.iacr.org/2017/349.pdf

Russ


On Jun 21, 2018, at 11:11 AM, Brendan Moran = <Brendan.Moran@arm.com> wrote:

I see that there are two current drafts for hash-based = signatures:
https://tools.ietf.org/html/draft-mcgrew-hash-sigs-11
=
https://tools.ietf.org/html/draft-irtf-cfrg-xmss-hash-based-sig= natures-12

I see that you have referenced the mcgrew draft rather = than the IRTF/CFRG draft. Could you please explain what the difference = is between these two drafts and why the mcgrew draft was a better choice = than XMSS?

Thanks,
Brendan


On 13 Jun 2018, at 20:03, Jim Schaad <ietf@augustcellars.com> wrote:



-----Original Message-----
From: Suit <suit-bounces@ietf.org> On Behalf Of Michael = Richardson
Sent: Wednesday, June 13, 2018 11:09 AM
To: suit <suit@ietf.org>
Subject: [Suit] draft-housley-suit-cose-hash-sig


I have read the -01 draft today.
I have not read [HASHSIG] yet.
I thought I'd try reading this first, to see what questions I had.

I have implemented COSE Sign1 with ECDSA in Ruby, so I have a grasp = of
what we are trying to plug hash-sig *into*.


Suggestions:
1) would the structure show in section 3 be easier if it was described = by
  CDDL?  I'm rather unclear about this.

No - this are not CBOR structures they are pure binary strings


2) I din't understand section 4, where it says:
     o  If the 'key_ops' field is present, = it MUST include 'sign' when
=             &n= bsp;   creating a hash-based signature.

     o  If the 'key_ops' field is present, = it MUST include 'verify'
=             &n= bsp;   when verifying a hash-based signature.

Clearly this is not something that travels over the network.  Is = this
somehow
indicating how to understand if one is dealing a public (verify) key or = a
private
(sign) key?

The key_ops field can be considered to potentially be transported over = a
network.  It is part of the COSE_Key object rather than part of = the
COSE_Sign1 object.


3) the variations: LMS_SHA256_M32_H20, and LMOTS_SHA256_N32_W2,
etc. are
  listed, but I don't know if they need to be carried in the = signature
  structure somehow.

See the [HASHSIG] draft.  It is encoded into the signature structure = and the
key type is in the public key structure.


4) I thought that perhaps we'd need CBOR or COSE specific way to = transport
  the signatures.  I guess I shall read HASHSIG to find = out what the
  signatures look like.

We have that.  This is looking at a signature just like ECDSA would = produce.
This is a different "ECDSA" replacement.


I understand draft-mcgrew-hash-sigs-11 is being advanced by CFRG.
I believe that SUIT should adopt this document, and should do so in = the
current state.

I would like to have some examples in CBOR/COSE worked out with = private
keys available in the appendices.

Always a good thing to have.

Jim


--
] =             &n= bsp; Never tell me the odds! =             &n= bsp;   | ipv6 mesh
networks [
]   Michael Richardson, Sandelman Software Works =        | network
architect  [
]     mcr@sandelman.ca  http://www.sandelman.ca/ =        |   ruby on rails
[

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
-=3D IPv6 IoT consulting =3D-




_______________________________________________
Suit mailing list
Suit@ietf.org
https://www.ietf.org/mailman/listinfo/suit

IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

= --Apple-Mail=_E7915BCC-9048-4898-8895-20C25B84A823-- From nobody Thu Jun 21 09:02:50 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C085130F02 for ; Thu, 21 Jun 2018 09:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWtv9nH0iAqG for ; Thu, 21 Jun 2018 09:02:44 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10053.outbound.protection.outlook.com [40.107.1.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D4E5130ED6 for ; Thu, 21 Jun 2018 09:02:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kvv+bzbVjyYdBlT6mlS8M7pinp159+dLtWcKTXQkgVw=; b=n7yN2wJGphsmgOwISUviKh3RdmiXNqu6W/MYBF+OQeVfUz+8nvdjz4qNYpdYNjqTKoR46hKO3BnoQrCxYgFGaKSMpEY4Cj/jDZd8FOQMI3oQGKoKOQukB4KQDKrCVy/YTp+7CetmpidRAk9f/DbhQsZy9FIeIcNgTtlpasNv6D8= Received: from AM4PR0802MB2260.eurprd08.prod.outlook.com (10.172.217.150) by AM4PR0802MB2369.eurprd08.prod.outlook.com (10.172.218.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.17; Thu, 21 Jun 2018 16:02:40 +0000 Received: from AM4PR0802MB2260.eurprd08.prod.outlook.com ([fe80::15ab:db2e:593b:b5e0]) by AM4PR0802MB2260.eurprd08.prod.outlook.com ([fe80::15ab:db2e:593b:b5e0%4]) with mapi id 15.20.0863.016; Thu, 21 Jun 2018 16:02:40 +0000 From: Brendan Moran To: Russ Housley CC: suit Thread-Topic: [Suit] draft-housley-suit-cose-hash-sig Thread-Index: AQHUA0IcLpl64e0Ltk+rjSClOrFaQaRei+EAgAxRz4CAAAjwgIAABWqA Date: Thu, 21 Jun 2018 16:02:40 +0000 Message-ID: <9906B2BC-BFC2-4F83-A0F6-FFCC81912237@arm.com> References: <31676.1528913351@localhost> <04f401d40349$33a58b10$9af0a130$@augustcellars.com> <0CDB8D05-0214-4749-9907-5A1B0B4A2191@arm.com> <697B1DC9-B1DE-48BA-ADC6-EF936208AFCE@vigilsec.com> In-Reply-To: <697B1DC9-B1DE-48BA-ADC6-EF936208AFCE@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.8.2) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brendan.Moran@arm.com; x-originating-ip: [217.140.96.140] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0802MB2369; 7:lmgRoOcuAiq4qflsvFmPSsqyYnlqH8yZi+KPAsVWDzlFrdD0+2NrsDmgENQQdgujK1aFQl/VH0OmOJ5Amcvj0hLSwHrc3Kx+xa0aypX5mbR4GALHY3D6KmOEATH5Xfwrm583lZ7yzBdIoex3ZGSZ2/dHT1W+lAH7KSoRb0ujzCGbmDx2f6vtfZBQtPS/iU7vGADje50Uwb+ynIClwsTf824bpKU/Ey4XBjWZpbLeghiASGWVJo5/+lAbGiGxtotU x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 80ddfd9b-5f96-49be-8e5a-08d5d7906a74 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(711020)(48565401081)(2017052603328)(7153060)(7193020); SRVR:AM4PR0802MB2369; x-ms-traffictypediagnostic: AM4PR0802MB2369: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(180628864354917); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231254)(944501410)(52105095)(3002001)(10201501046)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123558120)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:AM4PR0802MB2369; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0802MB2369; x-forefront-prvs: 07106EF9B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(366004)(396003)(376002)(39380400002)(51914003)(13464003)(199004)(189003)(40434004)(3280700002)(68736007)(76176011)(3846002)(6506007)(53546011)(33656002)(3660700001)(25786009)(606006)(59450400001)(86362001)(82746002)(6116002)(72206003)(97736004)(36756003)(7736002)(83716003)(6436002)(446003)(476003)(478600001)(57306001)(2616005)(486006)(11346002)(316002)(236005)(8676002)(54896002)(105586002)(4326008)(5890100001)(5250100002)(8936002)(106356001)(99286004)(66066001)(102836004)(5660300001)(966005)(186003)(6306002)(26005)(53946003)(93886005)(81156014)(2900100001)(2906002)(229853002)(50226002)(14454004)(6486002)(6246003)(53936002)(81166006)(6512007)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0802MB2369; H:AM4PR0802MB2260.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: ysErg1LP+6IKbL/Dyb3Axn1RFFFDX1i7hgnHd1lna5ngMzRYtKAA8SqDoUnD64JxcsiB4BaFKbX/GZ8ZJ/V/2quV3KT9M55+biQujqKI3zCTDKTqXBrWHNksaWUQzEFYlWt/0rfKFS8gdYzGDH0kDyGAcCougIV0FAWs0qVv8Qu4b9/d3wTYA0r+1kur8bHOSn3RxgNOXqW3Qx59JmFu2oUPv4pOZux3CHzIOmAe85MA2LqwcWldbtCMBQDqJcfONcjaumIwg8hBf4G6TcQW+mMMyWhp2SF4M4kmwJbZu17E0fbt2QyQwRi3Fx+97npgC4eJArPDCtDcyi72zKPbbQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_9906B2BCBFC24F83A0F6FFCC81912237armcom_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 80ddfd9b-5f96-49be-8e5a-08d5d7906a74 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jun 2018 16:02:40.2938 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0802MB2369 Archived-At: Subject: Re: [Suit] draft-housley-suit-cose-hash-sig X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 16:02:48 -0000 --_000_9906B2BCBFC24F83A0F6FFCC81912237armcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUnVzcywNClRoYW5rcyBmb3IgdGhlIGNsYXJpZmljYXRpb24uIEkgYWdyZWUgdGhhdCBhIGxh cmdlciBzaWduYXR1cmUgaXMgbm90IHdoYXQgd2UgbmVlZCBpbiBTVUlULiBIb3dldmVyLCBmb3Ig dGhlIENPU0UgZHJhZnQsIHdvdWxkIGl0IG5vdCBtYWtlIHNlbnNlIHRvIHByb3ZpZGUgZm9yIGJv dGggTE1TIGFuZCBYTVNTPyBJIGRvbuKAmXQgcHJldGVuZCB0byB1bmRlcnN0YW5kIGFsbCBDT1NF IHVzZSBjYXNlcy4NCg0KVGhhbmtzLA0KQnJlbmRhbg0KDQpPbiAyMSBKdW4gMjAxOCwgYXQgMTY6 NDMsIFJ1c3MgSG91c2xleSA8aG91c2xleUB2aWdpbHNlYy5jb208bWFpbHRvOmhvdXNsZXlAdmln aWxzZWMuY29tPj4gd3JvdGU6DQoNCkJyZW5kYW46DQoNClllcywgdGhlcmUgYXJlIHR3byBDRlJH IGFsZ29yaXRobXMgZm9yIGhhc2gtYmFzZWQgc2lnbmF0dXJlcy4gIEkgcHJlZmVyIHRoZSBvbmUg TWNHcmV3J3MgZG9jdW1lbnQsIG1vc3RseSBiZWNhdXNlIGl0IGlzIG1vcmUgc3RyYWlnaHRmb3J3 YXJkLiAgVGhlcmUgaXMgc29tZSBzcGVlZCBpbXByb3ZlbWVudCBmb3IgdGhlIGFkZGl0aW9uYWwg Y29tcGxleGl0eSBpbiBYTVNTIGF0IHRoZSBjb3N0IG9mIGEgbGFyZ2VyIHNpZ25hdHVyZSB2YWx1 ZS4gIFRvIG1lLCB0aGUgc3BlZWQgaW1wcm92ZW1lbnQgaXMgbm90IGJpZyBlbm91Z2ggdG8ganVz dGlmeSB0aGUgbGFyZ2VyIHNpZ25hdHVyZSBzaXplLiAgWW91ciBtaWxlYWdlIG1heSB2YXJ5Lg0K DQpUaGlzIHBhcGVyIGRlc2NyaWJlcyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSB0d286DQoN Cmh0dHBzOi8vZXByaW50LmlhY3Iub3JnLzIwMTcvMzQ5LnBkZg0KDQpSdXNzDQoNCg0KT24gSnVu IDIxLCAyMDE4LCBhdCAxMToxMSBBTSwgQnJlbmRhbiBNb3JhbiA8QnJlbmRhbi5Nb3JhbkBhcm0u Y29tPG1haWx0bzpCcmVuZGFuLk1vcmFuQGFybS5jb20+PiB3cm90ZToNCg0KSSBzZWUgdGhhdCB0 aGVyZSBhcmUgdHdvIGN1cnJlbnQgZHJhZnRzIGZvciBoYXNoLWJhc2VkIHNpZ25hdHVyZXM6DQpo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWNncmV3LWhhc2gtc2lncy0xMQ0KaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlydGYtY2ZyZy14bXNzLWhhc2gtYmFzZWQt c2lnbmF0dXJlcy0xMg0KDQpJIHNlZSB0aGF0IHlvdSBoYXZlIHJlZmVyZW5jZWQgdGhlIG1jZ3Jl dyBkcmFmdCByYXRoZXIgdGhhbiB0aGUgSVJURi9DRlJHIGRyYWZ0LiBDb3VsZCB5b3UgcGxlYXNl IGV4cGxhaW4gd2hhdCB0aGUgZGlmZmVyZW5jZSBpcyBiZXR3ZWVuIHRoZXNlIHR3byBkcmFmdHMg YW5kIHdoeSB0aGUgbWNncmV3IGRyYWZ0IHdhcyBhIGJldHRlciBjaG9pY2UgdGhhbiBYTVNTPw0K DQpUaGFua3MsDQpCcmVuZGFuDQoNCg0KT24gMTMgSnVuIDIwMTgsIGF0IDIwOjAzLCBKaW0gU2No YWFkIDxpZXRmQGF1Z3VzdGNlbGxhcnMuY29tPG1haWx0bzppZXRmQGF1Z3VzdGNlbGxhcnMuY29t Pj4gd3JvdGU6DQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogU3VpdCA8 c3VpdC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzdWl0LWJvdW5jZXNAaWV0Zi5vcmc+PiBPbiBC ZWhhbGYgT2YgTWljaGFlbCBSaWNoYXJkc29uDQpTZW50OiBXZWRuZXNkYXksIEp1bmUgMTMsIDIw MTggMTE6MDkgQU0NClRvOiBzdWl0IDxzdWl0QGlldGYub3JnPG1haWx0bzpzdWl0QGlldGYub3Jn Pj4NClN1YmplY3Q6IFtTdWl0XSBkcmFmdC1ob3VzbGV5LXN1aXQtY29zZS1oYXNoLXNpZw0KDQoN CkkgaGF2ZSByZWFkIHRoZSAtMDEgZHJhZnQgdG9kYXkuDQpJIGhhdmUgbm90IHJlYWQgW0hBU0hT SUddIHlldC4NCkkgdGhvdWdodCBJJ2QgdHJ5IHJlYWRpbmcgdGhpcyBmaXJzdCwgdG8gc2VlIHdo YXQgcXVlc3Rpb25zIEkgaGFkLg0KDQpJIGhhdmUgaW1wbGVtZW50ZWQgQ09TRSBTaWduMSB3aXRo IEVDRFNBIGluIFJ1YnksIHNvIEkgaGF2ZSBhIGdyYXNwIG9mDQp3aGF0IHdlIGFyZSB0cnlpbmcg dG8gcGx1ZyBoYXNoLXNpZyAqaW50byouDQoNCg0KU3VnZ2VzdGlvbnM6DQoxKSB3b3VsZCB0aGUg c3RydWN0dXJlIHNob3cgaW4gc2VjdGlvbiAzIGJlIGVhc2llciBpZiBpdCB3YXMgZGVzY3JpYmVk IGJ5DQogIENEREw/ICBJJ20gcmF0aGVyIHVuY2xlYXIgYWJvdXQgdGhpcy4NCg0KTm8gLSB0aGlz IGFyZSBub3QgQ0JPUiBzdHJ1Y3R1cmVzIHRoZXkgYXJlIHB1cmUgYmluYXJ5IHN0cmluZ3MNCg0K DQoyKSBJIGRpbid0IHVuZGVyc3RhbmQgc2VjdGlvbiA0LCB3aGVyZSBpdCBzYXlzOg0KICAgICBv ICBJZiB0aGUgJ2tleV9vcHMnIGZpZWxkIGlzIHByZXNlbnQsIGl0IE1VU1QgaW5jbHVkZSAnc2ln bicgd2hlbg0KICAgICAgICAgICAgICAgIGNyZWF0aW5nIGEgaGFzaC1iYXNlZCBzaWduYXR1cmUu DQoNCiAgICAgbyAgSWYgdGhlICdrZXlfb3BzJyBmaWVsZCBpcyBwcmVzZW50LCBpdCBNVVNUIGlu Y2x1ZGUgJ3ZlcmlmeScNCiAgICAgICAgICAgICAgICB3aGVuIHZlcmlmeWluZyBhIGhhc2gtYmFz ZWQgc2lnbmF0dXJlLg0KDQpDbGVhcmx5IHRoaXMgaXMgbm90IHNvbWV0aGluZyB0aGF0IHRyYXZl bHMgb3ZlciB0aGUgbmV0d29yay4gIElzIHRoaXMNCnNvbWVob3cNCmluZGljYXRpbmcgaG93IHRv IHVuZGVyc3RhbmQgaWYgb25lIGlzIGRlYWxpbmcgYSBwdWJsaWMgKHZlcmlmeSkga2V5IG9yIGEN CnByaXZhdGUNCihzaWduKSBrZXk/DQoNClRoZSBrZXlfb3BzIGZpZWxkIGNhbiBiZSBjb25zaWRl cmVkIHRvIHBvdGVudGlhbGx5IGJlIHRyYW5zcG9ydGVkIG92ZXIgYQ0KbmV0d29yay4gIEl0IGlz IHBhcnQgb2YgdGhlIENPU0VfS2V5IG9iamVjdCByYXRoZXIgdGhhbiBwYXJ0IG9mIHRoZQ0KQ09T RV9TaWduMSBvYmplY3QuDQoNCg0KMykgdGhlIHZhcmlhdGlvbnM6IExNU19TSEEyNTZfTTMyX0gy MCwgYW5kIExNT1RTX1NIQTI1Nl9OMzJfVzIsDQpldGMuIGFyZQ0KICBsaXN0ZWQsIGJ1dCBJIGRv bid0IGtub3cgaWYgdGhleSBuZWVkIHRvIGJlIGNhcnJpZWQgaW4gdGhlIHNpZ25hdHVyZQ0KICBz dHJ1Y3R1cmUgc29tZWhvdy4NCg0KU2VlIHRoZSBbSEFTSFNJR10gZHJhZnQuICBJdCBpcyBlbmNv ZGVkIGludG8gdGhlIHNpZ25hdHVyZSBzdHJ1Y3R1cmUgYW5kIHRoZQ0Ka2V5IHR5cGUgaXMgaW4g dGhlIHB1YmxpYyBrZXkgc3RydWN0dXJlLg0KDQoNCjQpIEkgdGhvdWdodCB0aGF0IHBlcmhhcHMg d2UnZCBuZWVkIENCT1Igb3IgQ09TRSBzcGVjaWZpYyB3YXkgdG8gdHJhbnNwb3J0DQogIHRoZSBz aWduYXR1cmVzLiAgSSBndWVzcyBJIHNoYWxsIHJlYWQgSEFTSFNJRyB0byBmaW5kIG91dCB3aGF0 IHRoZQ0KICBzaWduYXR1cmVzIGxvb2sgbGlrZS4NCg0KV2UgaGF2ZSB0aGF0LiAgVGhpcyBpcyBs b29raW5nIGF0IGEgc2lnbmF0dXJlIGp1c3QgbGlrZSBFQ0RTQSB3b3VsZCBwcm9kdWNlLg0KVGhp cyBpcyBhIGRpZmZlcmVudCAiRUNEU0EiIHJlcGxhY2VtZW50Lg0KDQoNCkkgdW5kZXJzdGFuZCBk cmFmdC1tY2dyZXctaGFzaC1zaWdzLTExIGlzIGJlaW5nIGFkdmFuY2VkIGJ5IENGUkcuDQpJIGJl bGlldmUgdGhhdCBTVUlUIHNob3VsZCBhZG9wdCB0aGlzIGRvY3VtZW50LCBhbmQgc2hvdWxkIGRv IHNvIGluIHRoZQ0KY3VycmVudCBzdGF0ZS4NCg0KSSB3b3VsZCBsaWtlIHRvIGhhdmUgc29tZSBl eGFtcGxlcyBpbiBDQk9SL0NPU0Ugd29ya2VkIG91dCB3aXRoIHByaXZhdGUNCmtleXMgYXZhaWxh YmxlIGluIHRoZSBhcHBlbmRpY2VzLg0KDQpBbHdheXMgYSBnb29kIHRoaW5nIHRvIGhhdmUuDQoN CkppbQ0KDQoNCi0tDQpdICAgICAgICAgICAgICAgTmV2ZXIgdGVsbCBtZSB0aGUgb2RkcyEgICAg ICAgICAgICAgICAgIHwgaXB2NiBtZXNoDQpuZXR3b3JrcyBbDQpdICAgTWljaGFlbCBSaWNoYXJk c29uLCBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3MgICAgICAgIHwgbmV0d29yaw0KYXJjaGl0ZWN0 ICBbDQpdICAgICBtY3JAc2FuZGVsbWFuLmNhPG1haWx0bzptY3JAc2FuZGVsbWFuLmNhPiAgaHR0 cDovL3d3dy5zYW5kZWxtYW4uY2EvICAgICAgICB8ICAgcnVieSBvbiByYWlscw0KWw0KDQotLQ0K TWljaGFlbCBSaWNoYXJkc29uIDxtY3IrSUVURkBzYW5kZWxtYW4uY2E8bWFpbHRvOm1jcitJRVRG QHNhbmRlbG1hbi5jYT4+LCBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3MNCi09IElQdjYgSW9UIGNv bnN1bHRpbmcgPS0NCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NClN1aXQgbWFpbGluZyBsaXN0DQpTdWl0QGlldGYub3JnPG1haWx0bzpTdWl0 QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdWl0DQoN CklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0 YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYg eW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBv dGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhl IGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCg0KDQpJTVBPUlRBTlQgTk9U SUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBj b25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRo ZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVs eSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1 c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBp biBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo= --_000_9906B2BCBFC24F83A0F6FFCC81912237armcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkhpIFJ1c3MsDQo8ZGl2IGNsYXNzPSIiPlRoYW5r cyBmb3IgdGhlIGNsYXJpZmljYXRpb24uIEkgYWdyZWUgdGhhdCBhIGxhcmdlciBzaWduYXR1cmUg aXMgbm90IHdoYXQgd2UgbmVlZCBpbiBTVUlULiBIb3dldmVyLCBmb3IgdGhlIENPU0UgZHJhZnQs IHdvdWxkIGl0IG5vdCBtYWtlIHNlbnNlIHRvIHByb3ZpZGUgZm9yIGJvdGggTE1TIGFuZCBYTVNT PyBJIGRvbuKAmXQgcHJldGVuZCB0byB1bmRlcnN0YW5kIGFsbCBDT1NFIHVzZSBjYXNlcy48L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRo YW5rcyw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QnJlbmRhbjxiciBjbGFzcz0iIj4NCjxkaXY+PGJy IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPk9uIDIxIEp1biAyMDE4LCBhdCAxNjo0MywgUnVzcyBIb3VzbGV5ICZsdDs8YSBocmVmPSJt YWlsdG86aG91c2xleUB2aWdpbHNlYy5jb20iIGNsYXNzPSIiPmhvdXNsZXlAdmlnaWxzZWMuY29t PC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xp bmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsg LXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyBsaW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsi IGNsYXNzPSIiPg0KQnJlbmRhbjoNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPlllcywgdGhlcmUgYXJlIHR3byBDRlJHIGFsZ29yaXRobXMgZm9yIGhh c2gtYmFzZWQgc2lnbmF0dXJlcy4gJm5ic3A7SSBwcmVmZXIgdGhlIG9uZSBNY0dyZXcncyBkb2N1 bWVudCwgbW9zdGx5IGJlY2F1c2UgaXQgaXMgbW9yZSBzdHJhaWdodGZvcndhcmQuICZuYnNwO1Ro ZXJlIGlzIHNvbWUgc3BlZWQgaW1wcm92ZW1lbnQgZm9yIHRoZSBhZGRpdGlvbmFsIGNvbXBsZXhp dHkgaW4gWE1TUyBhdCB0aGUgY29zdCBvZiBhIGxhcmdlciBzaWduYXR1cmUNCiB2YWx1ZS4gJm5i c3A7VG8gbWUsIHRoZSBzcGVlZCBpbXByb3ZlbWVudCBpcyBub3QgYmlnIGVub3VnaCB0byBqdXN0 aWZ5IHRoZSBsYXJnZXIgc2lnbmF0dXJlIHNpemUuICZuYnNwO1lvdXIgbWlsZWFnZSBtYXkgdmFy eS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPlRoaXMgcGFwZXIgZGVzY3JpYmVzIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIHR3bzo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9z cGFuPjxhIGhyZWY9Imh0dHBzOi8vZXByaW50LmlhY3Iub3JnLzIwMTcvMzQ5LnBkZiIgY2xhc3M9 IiI+aHR0cHM6Ly9lcHJpbnQuaWFjci5vcmcvMjAxNy8zNDkucGRmPC9hPjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+UnVzczwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBKdW4g MjEsIDIwMTgsIGF0IDExOjExIEFNLCBCcmVuZGFuIE1vcmFuICZsdDs8YSBocmVmPSJtYWlsdG86 QnJlbmRhbi5Nb3JhbkBhcm0uY29tIiBjbGFzcz0iIj5CcmVuZGFuLk1vcmFuQGFybS5jb208L2E+ Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Vi a2l0LW5ic3AtbW9kZTogc3BhY2U7IGxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPkkgc2VlIHRoYXQgdGhlcmUgYXJlIHR3byBjdXJyZW50IGRy YWZ0cyBmb3IgaGFzaC1iYXNlZCBzaWduYXR1cmVzOjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YSBo cmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWNncmV3LWhhc2gtc2lncy0x MSIgY2xhc3M9IiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1jZ3Jldy1oYXNo LXNpZ3MtMTE8L2E+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pcnRmLWNmcmcteG1zcy1oYXNoLWJhc2VkLXNpZ25hdHVyZXMt MTIiIGNsYXNzPSIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pcnRmLWNmcmct eG1zcy1oYXNoLWJhc2VkLXNpZ25hdHVyZXMtMTI8L2E+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIHNlZSB0aGF0IHlvdSBoYXZlIHJl ZmVyZW5jZWQgdGhlIG1jZ3JldyBkcmFmdCByYXRoZXIgdGhhbiB0aGUgSVJURi9DRlJHIGRyYWZ0 LiBDb3VsZCB5b3UgcGxlYXNlIGV4cGxhaW4gd2hhdCB0aGUgZGlmZmVyZW5jZSBpcyBiZXR3ZWVu IHRoZXNlIHR3byBkcmFmdHMgYW5kIHdoeSB0aGUgbWNncmV3IGRyYWZ0IHdhcyBhIGJldHRlciBj aG9pY2UgdGhhbiBYTVNTPzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+VGhhbmtzLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5CcmVuZGFuPGJy IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gMTMgSnVuIDIw MTgsIGF0IDIwOjAzLCBKaW0gU2NoYWFkICZsdDs8YSBocmVmPSJtYWlsdG86aWV0ZkBhdWd1c3Rj ZWxsYXJzLmNvbSIgY2xhc3M9IiI+aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbTwvYT4mZ3Q7IHdyb3Rl OjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xh c3M9IiI+PGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTog SGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJp YW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5v cm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt OiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4N CjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZl dGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1j YXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7 IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z aXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7 IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1 dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS08YnIgY2xhc3M9IiI+DQpGcm9tOiBTdWl0ICZsdDs8YSBocmVmPSJtYWls dG86c3VpdC1ib3VuY2VzQGlldGYub3JnIiBjbGFzcz0iIj5zdWl0LWJvdW5jZXNAaWV0Zi5vcmc8 L2E+Jmd0OyBPbiBCZWhhbGYgT2YgTWljaGFlbCBSaWNoYXJkc29uPGJyIGNsYXNzPSIiPg0KU2Vu dDogV2VkbmVzZGF5LCBKdW5lIDEzLCAyMDE4IDExOjA5IEFNPGJyIGNsYXNzPSIiPg0KVG86IHN1 aXQgJmx0OzxhIGhyZWY9Im1haWx0bzpzdWl0QGlldGYub3JnIiBjbGFzcz0iIj5zdWl0QGlldGYu b3JnPC9hPiZndDs8YnIgY2xhc3M9IiI+DQpTdWJqZWN0OiBbU3VpdF0gZHJhZnQtaG91c2xleS1z dWl0LWNvc2UtaGFzaC1zaWc8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQpJIGhhdmUgcmVhZCB0aGUgLTAxIGRyYWZ0IHRvZGF5LjxiciBjbGFzcz0iIj4NCkkgaGF2 ZSBub3QgcmVhZCBbSEFTSFNJR10geWV0LjxiciBjbGFzcz0iIj4NCkkgdGhvdWdodCBJJ2QgdHJ5 IHJlYWRpbmcgdGhpcyBmaXJzdCwgdG8gc2VlIHdoYXQgcXVlc3Rpb25zIEkgaGFkLjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCkkgaGF2ZSBpbXBsZW1lbnRlZCBDT1NFIFNpZ24xIHdpdGgg RUNEU0EgaW4gUnVieSwgc28gSSBoYXZlIGEgZ3Jhc3Agb2Y8YnIgY2xhc3M9IiI+DQp3aGF0IHdl IGFyZSB0cnlpbmcgdG8gcGx1ZyBoYXNoLXNpZyAqaW50byouPGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KU3VnZ2VzdGlvbnM6PGJyIGNsYXNzPSIiPg0KMSkgd291 bGQgdGhlIHN0cnVjdHVyZSBzaG93IGluIHNlY3Rpb24gMyBiZSBlYXNpZXIgaWYgaXQgd2FzIGRl c2NyaWJlZCBieTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO0NEREw/ICZuYnNwO0knbSByYXRo ZXIgdW5jbGVhciBhYm91dCB0aGlzLjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBz dHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsg Zm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBu b3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHls ZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9u dC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3Jt YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxp Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt c3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5s aW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5Obw0KIC0gdGhpcyBhcmUgbm90IENCT1Igc3RydWN0 dXJlcyB0aGV5IGFyZSBwdXJlIGJpbmFyeSBzdHJpbmdzPC9zcGFuPjxiciBzdHlsZT0iY2FyZXQt Y29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAx MnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQt d2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0 OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsg dGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8YnIgc3R5bGU9ImNhcmV0LWNvbG9y OiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsg Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdo dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4 dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7 IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQt ZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgc3R5 bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTog bm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsg dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt YWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFk anVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRp b246IG5vbmU7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjIpIEkgZGluJ3QgdW5kZXJzdGFu ZCBzZWN0aW9uIDQsIHdoZXJlIGl0IHNheXM6PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7byAmbmJzcDtJZiB0aGUgJ2tleV9vcHMnIGZpZWxkIGlzIHByZXNlbnQs IGl0IE1VU1QgaW5jbHVkZSAnc2lnbicgd2hlbjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2NyZWF0aW5nIGEgaGFzaC1iYXNlZCBzaWduYXR1cmUu PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7byAmbmJzcDtJZiB0aGUgJ2tleV9vcHMnIGZpZWxkIGlzIHByZXNlbnQsIGl0IE1VU1QgaW5j bHVkZSAndmVyaWZ5JzxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwO3doZW4gdmVyaWZ5aW5nIGEgaGFzaC1iYXNlZCBzaWduYXR1cmUuPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KQ2xlYXJseSB0aGlzIGlzIG5vdCBzb21ldGhpbmcgdGhhdCB0 cmF2ZWxzIG92ZXIgdGhlIG5ldHdvcmsuICZuYnNwO0lzIHRoaXM8YnIgY2xhc3M9IiI+DQo8L2Js b2NrcXVvdGU+DQo8c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1m YW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZv bnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFj aW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRy YW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBmbG9h dDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5zb21laG93PC9z cGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhl bHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu dC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9u dC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3Jt YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6 IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9y bTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6 IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KaW5kaWNhdGlu ZyBob3cgdG8gdW5kZXJzdGFuZCBpZiBvbmUgaXMgZGVhbGluZyBhIHB1YmxpYyAodmVyaWZ5KSBr ZXkgb3IgYTxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxzcGFuIHN0eWxlPSJjYXJldC1j b2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEy cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13 ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7 IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0 ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9y dGFudDsiIGNsYXNzPSIiPnByaXZhdGU8L3NwYW4+PGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdi KDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3Jk LXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29y YXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIHN0eWxlPSJm b250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1h bDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3 aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6 IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBu b25lOyIgY2xhc3M9IiI+DQooc2lnbikga2V5PzxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4N CjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZl dGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1j YXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7 IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8c3Bh biBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGlj YTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBz OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBmbG9hdDogbm9uZTsgZGlzcGxh eTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5UaGUNCiBrZXlfb3BzIGZpZWxkIGNhbiBi ZSBjb25zaWRlcmVkIHRvIHBvdGVudGlhbGx5IGJlIHRyYW5zcG9ydGVkIG92ZXIgYTwvc3Bhbj48 YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRp Y2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fw czogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPHNwYW4g c3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6 IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+bmV0d29yay4NCiAmbmJzcDtJdCBpcyBwYXJ0 IG9mIHRoZSBDT1NFX0tleSBvYmplY3QgcmF0aGVyIHRoYW4gcGFydCBvZiB0aGU8L3NwYW4+PGJy IHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNh OyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxzcGFuIHN0 eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBm b250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBp bmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPkNPU0VfU2lnbjENCiBvYmplY3QuPC9zcGFuPjxi ciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGlj YTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBz OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8YnIgc3R5 bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZv bnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9y bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFs aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRl LXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJw eDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdl aWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjMpIHRo ZSB2YXJpYXRpb25zOiBMTVNfU0hBMjU2X00zMl9IMjAsIGFuZCBMTU9UU19TSEEyNTZfTjMyX1cy LDxiciBjbGFzcz0iIj4NCmV0Yy4gYXJlPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7bGlzdGVk LCBidXQgSSBkb24ndCBrbm93IGlmIHRoZXkgbmVlZCB0byBiZSBjYXJyaWVkIGluIHRoZSBzaWdu YXR1cmU8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtzdHJ1Y3R1cmUgc29tZWhvdy48YnIgY2xh c3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwg MCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTog bm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBw eDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjog bm9uZTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7 IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9y bWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzog MHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9u ZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+U2Vl DQogdGhlIFtIQVNIU0lHXSBkcmFmdC4gJm5ic3A7SXQgaXMgZW5jb2RlZCBpbnRvIHRoZSBzaWdu YXR1cmUgc3RydWN0dXJlIGFuZCB0aGU8L3NwYW4+PGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdi KDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3Jk LXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29y YXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAs IDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5 bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50 OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNw YWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRp b246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNz PSIiPmtleQ0KIHR5cGUgaXMgaW4gdGhlIHB1YmxpYyBrZXkgc3RydWN0dXJlLjwvc3Bhbj48YnIg c3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPGJyIHN0eWxl PSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250 LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1h bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGln bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7 IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0 LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsg dGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo0KSBJIHRo b3VnaHQgdGhhdCBwZXJoYXBzIHdlJ2QgbmVlZCBDQk9SIG9yIENPU0Ugc3BlY2lmaWMgd2F5IHRv IHRyYW5zcG9ydDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO3RoZSBzaWduYXR1cmVzLiAmbmJz cDtJIGd1ZXNzIEkgc2hhbGwgcmVhZCBIQVNIU0lHIHRvIGZpbmQgb3V0IHdoYXQgdGhlPGJyIGNs YXNzPSIiPg0KJm5ic3A7Jm5ic3A7c2lnbmF0dXJlcyBsb29rIGxpa2UuPGJyIGNsYXNzPSIiPg0K PC9ibG9ja3F1b3RlPg0KPGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250 LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBj bGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZh bWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9u dC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0 OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPldlDQogaGF2ZSB0 aGF0LiAmbmJzcDtUaGlzIGlzIGxvb2tpbmcgYXQgYSBzaWduYXR1cmUganVzdCBsaWtlIEVDRFNB IHdvdWxkIHByb2R1Y2UuPC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl dHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBu b25lOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsg Zm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3Jt YWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRl ci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0 ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25l OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5UaGlz DQogaXMgYSBkaWZmZXJlbnQgJnF1b3Q7RUNEU0EmcXVvdDsgcmVwbGFjZW1lbnQuPC9zcGFuPjxi ciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGlj YTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBz OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8YnIgc3R5 bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZv bnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9y bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFs aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRl LXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJw eDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdl aWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkkgdW5k ZXJzdGFuZCBkcmFmdC1tY2dyZXctaGFzaC1zaWdzLTExIGlzIGJlaW5nIGFkdmFuY2VkIGJ5IENG UkcuPGJyIGNsYXNzPSIiPg0KSSBiZWxpZXZlIHRoYXQgU1VJVCBzaG91bGQgYWRvcHQgdGhpcyBk b2N1bWVudCwgYW5kIHNob3VsZCBkbyBzbyBpbiB0aGU8YnIgY2xhc3M9IiI+DQpjdXJyZW50IHN0 YXRlLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkkgd291bGQgbGlrZSB0byBoYXZlIHNv bWUgZXhhbXBsZXMgaW4gQ0JPUi9DT1NFIHdvcmtlZCBvdXQgd2l0aCBwcml2YXRlPGJyIGNsYXNz PSIiPg0Ka2V5cyBhdmFpbGFibGUgaW4gdGhlIGFwcGVuZGljZXMuPGJyIGNsYXNzPSIiPg0KPC9i bG9ja3F1b3RlPg0KPGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZh bWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9u dC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFz cz0iIj4NCjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWls eTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12 YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6 IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0OiBu b25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPkFsd2F5cw0KIGEgZ29v ZCB0aGluZyB0byBoYXZlLjwvc3Bhbj48YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwg MCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTog bm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBw eDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjog bm9uZTsiIGNsYXNzPSIiPg0KPGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBm b250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1h bDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRl eHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7 IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250 LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZs b2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPkppbTwvc3Bh bj48YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2 ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQt Y2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPGJy IHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNh OyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6 IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9u dC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsg dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAt d2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQot LTxiciBjbGFzcz0iIj4NCl0gJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7TmV2ZXIgdGVsbCBt ZSB0aGUgb2RkcyEgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCBpcHY2 IG1lc2g8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8c3BhbiBzdHlsZT0iY2FyZXQtY29s b3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4 OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2Vp Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0 ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h bDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4 dC1kZWNvcmF0aW9uOiBub25lOyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRh bnQ7IiBjbGFzcz0iIj5uZXR3b3Jrcw0KIFs8L3NwYW4+PGJyIHN0eWxlPSJjYXJldC1jb2xvcjog cmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZv bnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6 IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3 b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRl Y29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIHN0eWxl PSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs OyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1 c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9u OiBub25lOyIgY2xhc3M9IiI+DQpdICZuYnNwOyZuYnNwO01pY2hhZWwgUmljaGFyZHNvbiwgU2Fu ZGVsbWFuIFNvZnR3YXJlIFdvcmtzICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwO3wgbmV0d29yazxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxzcGFuIHN0eWxl PSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250 LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1h bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGln bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxp bmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPmFyY2hpdGVjdA0KICZuYnNwO1s8L3NwYW4+PGJyIHN0 eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBm b250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEy cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13 ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi a2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw eDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQpdICZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOzxhIGhyZWY9Im1haWx0bzptY3JAc2FuZGVsbWFuLmNhIiBjbGFzcz0iIj5tY3JAc2Fu ZGVsbWFuLmNhPC9hPiAmbmJzcDs8YSBocmVmPSJodHRwOi8vd3d3LnNhbmRlbG1hbi5jYS8iIGNs YXNzPSIiPmh0dHA6Ly93d3cuc2FuZGVsbWFuLmNhLzwvYT4gJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCAmbmJzcDsmbmJzcDtydWJ5IG9uIHJhaWxzPGJyIGNsYXNz PSIiPg0KPC9ibG9ja3F1b3RlPg0KPHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwg MCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTog bm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBw eDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjog bm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+ Wzwvc3Bhbj48YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5 OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh cmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIi Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBo YW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCi0tPGJyIGNsYXNzPSIiPg0KTWljaGFlbCBSaWNoYXJkc29uICZsdDs8YSBocmVm PSJtYWlsdG86bWNyJiM0MztJRVRGQHNhbmRlbG1hbi5jYSIgY2xhc3M9IiI+bWNyJiM0MztJRVRG QHNhbmRlbG1hbi5jYTwvYT4mZ3Q7LCBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3M8YnIgY2xhc3M9 IiI+DQotPSBJUHY2IElvVCBjb25zdWx0aW5nID0tPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIHN0eWxlPSJjYXJldC1jb2xvcjog cmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZv bnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6 IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3 b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRl Y29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigw LCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0 eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3Jt YWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu dDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1z cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0 aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAw LCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxl OiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7 IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDog MHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9u OiBub25lOyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0i Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48 YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRp Y2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fw czogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPHNwYW4g c3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6 IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+U3VpdA0KIG1haWxpbmcgbGlzdDwvc3Bhbj48 YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRp Y2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fw czogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPHNwYW4g c3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6 IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+PGEgaHJlZj0ibWFpbHRvOlN1aXRAaWV0Zi5v cmciIGNsYXNzPSIiPlN1aXRAaWV0Zi5vcmc8L2E+PC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29s b3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4 OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2Vp Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0 ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h bDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4 dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6 IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBm b250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0 OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0 LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsg d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1k ZWNvcmF0aW9uOiBub25lOyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7 IiBjbGFzcz0iIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3N1aXQiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3Vp dDwvYT48L3NwYW4+PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBv ZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5 IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVu dCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xv c2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBv c2UsDQogb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhh bmsgeW91LiA8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMg ZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBi ZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVh c2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUg Y29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwNCiBv ciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3Uu DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_9906B2BCBFC24F83A0F6FFCC81912237armcom_-- From nobody Thu Jun 21 09:08:18 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26C62130F08 for ; Thu, 21 Jun 2018 09:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCHnQnemsI1C for ; Thu, 21 Jun 2018 09:08:13 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0102.outbound.protection.outlook.com [104.47.36.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B02C130ED6 for ; Thu, 21 Jun 2018 09:08:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HBT2YzNGHgdqbsYB/spLrQ3y8PBoMgtlPlWvs2MJpxQ=; b=UFjjdmEOqXp1ztLpoRNHKJgAqRoiM3dHoP66+Y9/JhPJRQfFRhDJCrTaAb7u7fv17BoSc4Brp35DhR+q9CKIWQACN3n4EAZ/fVegVJe5WF6kuZLSmHM8eb6V/AEMb5oQnyU6Ps3KWpeL7/EP7i3WgDmQ+qHKjp4N5I5ZOOysdOg= Received: from DM5PR2101MB0805.namprd21.prod.outlook.com (10.167.105.149) by DM5PR2101MB1064.namprd21.prod.outlook.com (52.132.130.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.906.3; Thu, 21 Jun 2018 16:08:11 +0000 Received: from DM5PR2101MB0805.namprd21.prod.outlook.com ([fe80::30ec:e30c:8f5c:b685]) by DM5PR2101MB0805.namprd21.prod.outlook.com ([fe80::30ec:e30c:8f5c:b685%2]) with mapi id 15.20.0906.013; Thu, 21 Jun 2018 16:08:11 +0000 From: Dave Thaler To: Brendan Moran , Russ Housley CC: suit Thread-Topic: [Suit] draft-housley-suit-cose-hash-sig Thread-Index: AQHUA0IRLifED7szcUiGqpElu04r7qRei+EAgAxR0ACAAAjvgIAABWsAgAABKWA= Date: Thu, 21 Jun 2018 16:08:10 +0000 Message-ID: References: <31676.1528913351@localhost> <04f401d40349$33a58b10$9af0a130$@augustcellars.com> <0CDB8D05-0214-4749-9907-5A1B0B4A2191@arm.com> <697B1DC9-B1DE-48BA-ADC6-EF936208AFCE@vigilsec.com> <9906B2BC-BFC2-4F83-A0F6-FFCC81912237@arm.com> In-Reply-To: <9906B2BC-BFC2-4F83-A0F6-FFCC81912237@arm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=dthaler@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-06-21T16:08:10.3570651Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [73.59.106.235] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR2101MB1064; 7:f2lHBp2SnW6JMrcb+SWDS6QcK2x6oRvt5+7FiHsBZ2V63sHAHkrGpjkpR0uRJjimhrWtsfDgkQBYjK3kgF7vv/evC2aZ7DhlAR8u3UdD7BxqHprQhT/VKepG0IWaIq9vvslB2dA0ivPxYvZnX4vGfX957ee78bAmk+s/VXVSvtlBagMO6HaJVME9Lp3biY+rV6uBXzNHeBK6KkVCvlAmpnACNSsgovJCXbJhaExW3rV8TZEdwPVkl7yIlW51UvjS x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: b950eb35-a5d7-4d25-52b8-08d5d7912f9a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989088)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(711020)(48565401081)(2017052603328)(7193020); SRVR:DM5PR2101MB1064; x-ms-traffictypediagnostic: DM5PR2101MB1064: authentication-results: spf=none (sender IP is ) smtp.mailfrom=dthaler@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(180628864354917)(189930954265078)(219752817060721)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231254)(2018427008)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:DM5PR2101MB1064; BCL:0; PCL:0; RULEID:; SRVR:DM5PR2101MB1064; x-forefront-prvs: 07106EF9B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(39380400002)(366004)(346002)(39860400002)(51914003)(199004)(189003)(13464003)(40434004)(316002)(478600001)(7736002)(966005)(105586002)(229853002)(106356001)(110136005)(790700001)(6116002)(3846002)(33656002)(74316002)(19609705001)(10290500003)(476003)(14454004)(68736007)(8936002)(606006)(11346002)(446003)(486006)(81166006)(81156014)(86362001)(86612001)(8676002)(53936002)(3660700001)(25786009)(26005)(186003)(59450400001)(2906002)(236005)(3280700002)(76176011)(7696005)(99286004)(5660300001)(5250100002)(5890100001)(2900100001)(22452003)(97736004)(55016002)(6436002)(93886005)(53546011)(6246003)(4326008)(102836004)(66066001)(6506007)(10090500001)(54896002)(6306002)(9686003)(8990500004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR2101MB1064; H:DM5PR2101MB0805.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: L9yA+NAX4ZMNk82S3tx096DaOKvKR121T2kT+tNWYxD9kdRM/s9KFbOIcv+68Fe1TRc5m0vOSCHyRltWfbDDJ3nmxMwxhVpQMuQIEEXHWxuUsjM7EoHV1ARaqiMP2aPjX4oybDf7DPNSYqWHWUIqSLZ7DFbstmXh5rbPpMEmACbBBeS1NPsgK24u+aiAkSQnoQCCn7ShKKF2VoWRPZ5u+5S6Jgjk/GYcS/fd6AgqSF51V20lbpcyo0HbuUkxO+9Rm0tIXBeN9mEOA5cJhDkCrXmNL/nU/iJXlzJLzCeDZUyYMW/8SOaD7py0Re+FZrtQTyAncImI1xTJfUeCSa/TCg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR2101MB0805F9D2D2372C4AEE2C7E5BA3760DM5PR2101MB0805_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: b950eb35-a5d7-4d25-52b8-08d5d7912f9a X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jun 2018 16:08:11.0655 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR2101MB1064 Archived-At: Subject: Re: [Suit] draft-housley-suit-cose-hash-sig X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 16:08:18 -0000 --_000_DM5PR2101MB0805F9D2D2372C4AEE2C7E5BA3760DM5PR2101MB0805_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBpcyBzaW1pbGFyIHRvIGEgcXVlc3Rpb24gSSBhc2tlZCBhcyB3ZWxsLCB3aGV0aGVyIHRo ZSBJRVRGIG9ubHkgbmVlZHMgTE1TIG9yIHdoZXRoZXIgTE1TIGlzIGp1c3QgYW4gaW5zdGFuY2Ug aW4gYSBsYXJnZXIgY2xhc3MgdGhhdCBtaWdodCBiZSBuZWVkZWQsIGFuZCB3aGF0IHRoZSBzY29w ZSBvZiB0aGUgZHJhZnQgc2hvdWxkIGJlLg0KDQpJZiB0aGUgZHJhZnQgaXMgbm90IFNVSVQtb25s eSAoZS5nLiwgYWxsb3dpbmcgdXNlIGluIE9TQ09SRSwgZXRjLikgdGhlbiBpdCBzb3VuZHMgbGlr ZSB3ZSBtaWdodCBuZWVkIHRoZSBhYmlsaXR5IHRvIHN1cHBvcnQgbW9yZSB0aGFuIExNUyBmb3Ig c29tZSB1c2UgY2FzZXMuDQoNCkRhdmUNCg0KRnJvbTogU3VpdCA8c3VpdC1ib3VuY2VzQGlldGYu b3JnPiBPbiBCZWhhbGYgT2YgQnJlbmRhbiBNb3Jhbg0KU2VudDogVGh1cnNkYXksIEp1bmUgMjEs IDIwMTggOTowMyBBTQ0KVG86IFJ1c3MgSG91c2xleSA8aG91c2xleUB2aWdpbHNlYy5jb20+DQpD Yzogc3VpdCA8c3VpdEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbU3VpdF0gZHJhZnQtaG91c2xl eS1zdWl0LWNvc2UtaGFzaC1zaWcNCg0KSGkgUnVzcywNClRoYW5rcyBmb3IgdGhlIGNsYXJpZmlj YXRpb24uIEkgYWdyZWUgdGhhdCBhIGxhcmdlciBzaWduYXR1cmUgaXMgbm90IHdoYXQgd2UgbmVl ZCBpbiBTVUlULiBIb3dldmVyLCBmb3IgdGhlIENPU0UgZHJhZnQsIHdvdWxkIGl0IG5vdCBtYWtl IHNlbnNlIHRvIHByb3ZpZGUgZm9yIGJvdGggTE1TIGFuZCBYTVNTPyBJIGRvbuKAmXQgcHJldGVu ZCB0byB1bmRlcnN0YW5kIGFsbCBDT1NFIHVzZSBjYXNlcy4NCg0KVGhhbmtzLA0KQnJlbmRhbg0K DQoNCk9uIDIxIEp1biAyMDE4LCBhdCAxNjo0MywgUnVzcyBIb3VzbGV5IDxob3VzbGV5QHZpZ2ls c2VjLmNvbTxtYWlsdG86aG91c2xleUB2aWdpbHNlYy5jb20+PiB3cm90ZToNCg0KQnJlbmRhbjoN Cg0KWWVzLCB0aGVyZSBhcmUgdHdvIENGUkcgYWxnb3JpdGhtcyBmb3IgaGFzaC1iYXNlZCBzaWdu YXR1cmVzLiAgSSBwcmVmZXIgdGhlIG9uZSBNY0dyZXcncyBkb2N1bWVudCwgbW9zdGx5IGJlY2F1 c2UgaXQgaXMgbW9yZSBzdHJhaWdodGZvcndhcmQuICBUaGVyZSBpcyBzb21lIHNwZWVkIGltcHJv dmVtZW50IGZvciB0aGUgYWRkaXRpb25hbCBjb21wbGV4aXR5IGluIFhNU1MgYXQgdGhlIGNvc3Qg b2YgYSBsYXJnZXIgc2lnbmF0dXJlIHZhbHVlLiAgVG8gbWUsIHRoZSBzcGVlZCBpbXByb3ZlbWVu dCBpcyBub3QgYmlnIGVub3VnaCB0byBqdXN0aWZ5IHRoZSBsYXJnZXIgc2lnbmF0dXJlIHNpemUu ICBZb3VyIG1pbGVhZ2UgbWF5IHZhcnkuDQoNClRoaXMgcGFwZXIgZGVzY3JpYmVzIHRoZSBkaWZm ZXJlbmNlIGJldHdlZW4gdGhlIHR3bzoNCg0KaHR0cHM6Ly9lcHJpbnQuaWFjci5vcmcvMjAxNy8z NDkucGRmPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJs PWh0dHBzJTNBJTJGJTJGZXByaW50LmlhY3Iub3JnJTJGMjAxNyUyRjM0OS5wZGYmZGF0YT0wMiU3 QzAxJTdDZHRoYWxlciU0MG1pY3Jvc29mdC5jb20lN0MzMDJkMGYxMDYyNmI0NTRhNzMyMzA4ZDVk NzkwNzM1OSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY2 NTE5Mzc3NzEzODMwOTImc2RhdGE9ekRHcVIyTnNrakp6eVZWY0NFZzhzdVBvM0x0OWI2eExJMWx4 YVlsV3JiUSUzRCZyZXNlcnZlZD0wPg0KDQpSdXNzDQoNCg0KDQpPbiBKdW4gMjEsIDIwMTgsIGF0 IDExOjExIEFNLCBCcmVuZGFuIE1vcmFuIDxCcmVuZGFuLk1vcmFuQGFybS5jb208bWFpbHRvOkJy ZW5kYW4uTW9yYW5AYXJtLmNvbT4+IHdyb3RlOg0KDQpJIHNlZSB0aGF0IHRoZXJlIGFyZSB0d28g Y3VycmVudCBkcmFmdHMgZm9yIGhhc2gtYmFzZWQgc2lnbmF0dXJlczoNCmh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1tY2dyZXctaGFzaC1zaWdzLTExPGh0dHBzOi8vbmEwMS5zYWZl bGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdG9vbHMuaWV0 Zi5vcmclMkZodG1sJTJGZHJhZnQtbWNncmV3LWhhc2gtc2lncy0xMSZkYXRhPTAyJTdDMDElN0Nk dGhhbGVyJTQwbWljcm9zb2Z0LmNvbSU3QzMwMmQwZjEwNjI2YjQ1NGE3MzIzMDhkNWQ3OTA3MzU5 JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjY1MTkzNzc3 MTM5MzA5NyZzZGF0YT1DVFJ4M0JXM2R1WElSRVl4UDRDeVIlMkJRWTYzcVlnaTJ2cWpuVU05dUtx UU0lM0QmcmVzZXJ2ZWQ9MD4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pcnRm LWNmcmcteG1zcy1oYXNoLWJhc2VkLXNpZ25hdHVyZXMtMTI8aHR0cHM6Ly9uYTAxLnNhZmVsaW5r cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9y ZyUyRmh0bWwlMkZkcmFmdC1pcnRmLWNmcmcteG1zcy1oYXNoLWJhc2VkLXNpZ25hdHVyZXMtMTIm ZGF0YT0wMiU3QzAxJTdDZHRoYWxlciU0MG1pY3Jvc29mdC5jb20lN0MzMDJkMGYxMDYyNmI0NTRh NzMyMzA4ZDVkNzkwNzM1OSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3 QzAlN0M2MzY2NTE5Mzc3NzEzOTMwOTcmc2RhdGE9cGlpJTJCb2E4U2tUdDdQTGFycTBQJTJGS1hM NFdCVnBOd0x6R1NJeEVnWkc1WVUlM0QmcmVzZXJ2ZWQ9MD4NCg0KSSBzZWUgdGhhdCB5b3UgaGF2 ZSByZWZlcmVuY2VkIHRoZSBtY2dyZXcgZHJhZnQgcmF0aGVyIHRoYW4gdGhlIElSVEYvQ0ZSRyBk cmFmdC4gQ291bGQgeW91IHBsZWFzZSBleHBsYWluIHdoYXQgdGhlIGRpZmZlcmVuY2UgaXMgYmV0 d2VlbiB0aGVzZSB0d28gZHJhZnRzIGFuZCB3aHkgdGhlIG1jZ3JldyBkcmFmdCB3YXMgYSBiZXR0 ZXIgY2hvaWNlIHRoYW4gWE1TUz8NCg0KVGhhbmtzLA0KQnJlbmRhbg0KDQoNCg0KT24gMTMgSnVu IDIwMTgsIGF0IDIwOjAzLCBKaW0gU2NoYWFkIDxpZXRmQGF1Z3VzdGNlbGxhcnMuY29tPG1haWx0 bzppZXRmQGF1Z3VzdGNlbGxhcnMuY29tPj4gd3JvdGU6DQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBTdWl0IDxzdWl0LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnN1 aXQtYm91bmNlc0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBNaWNoYWVsIFJpY2hhcmRzb24NClNl bnQ6IFdlZG5lc2RheSwgSnVuZSAxMywgMjAxOCAxMTowOSBBTQ0KVG86IHN1aXQgPHN1aXRAaWV0 Zi5vcmc8bWFpbHRvOnN1aXRAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW1N1aXRdIGRyYWZ0LWhvdXNs ZXktc3VpdC1jb3NlLWhhc2gtc2lnDQoNCg0KSSBoYXZlIHJlYWQgdGhlIC0wMSBkcmFmdCB0b2Rh eS4NCkkgaGF2ZSBub3QgcmVhZCBbSEFTSFNJR10geWV0Lg0KSSB0aG91Z2h0IEknZCB0cnkgcmVh ZGluZyB0aGlzIGZpcnN0LCB0byBzZWUgd2hhdCBxdWVzdGlvbnMgSSBoYWQuDQoNCkkgaGF2ZSBp bXBsZW1lbnRlZCBDT1NFIFNpZ24xIHdpdGggRUNEU0EgaW4gUnVieSwgc28gSSBoYXZlIGEgZ3Jh c3Agb2YNCndoYXQgd2UgYXJlIHRyeWluZyB0byBwbHVnIGhhc2gtc2lnICppbnRvKi4NCg0KDQpT dWdnZXN0aW9uczoNCjEpIHdvdWxkIHRoZSBzdHJ1Y3R1cmUgc2hvdyBpbiBzZWN0aW9uIDMgYmUg ZWFzaWVyIGlmIGl0IHdhcyBkZXNjcmliZWQgYnkNCiAgQ0RETD8gIEknbSByYXRoZXIgdW5jbGVh ciBhYm91dCB0aGlzLg0KDQpObyAtIHRoaXMgYXJlIG5vdCBDQk9SIHN0cnVjdHVyZXMgdGhleSBh cmUgcHVyZSBiaW5hcnkgc3RyaW5ncw0KDQoNCg0KMikgSSBkaW4ndCB1bmRlcnN0YW5kIHNlY3Rp b24gNCwgd2hlcmUgaXQgc2F5czoNCiAgICAgbyAgSWYgdGhlICdrZXlfb3BzJyBmaWVsZCBpcyBw cmVzZW50LCBpdCBNVVNUIGluY2x1ZGUgJ3NpZ24nIHdoZW4NCiAgICAgICAgICAgICAgICBjcmVh dGluZyBhIGhhc2gtYmFzZWQgc2lnbmF0dXJlLg0KDQogICAgIG8gIElmIHRoZSAna2V5X29wcycg ZmllbGQgaXMgcHJlc2VudCwgaXQgTVVTVCBpbmNsdWRlICd2ZXJpZnknDQogICAgICAgICAgICAg ICAgd2hlbiB2ZXJpZnlpbmcgYSBoYXNoLWJhc2VkIHNpZ25hdHVyZS4NCg0KQ2xlYXJseSB0aGlz IGlzIG5vdCBzb21ldGhpbmcgdGhhdCB0cmF2ZWxzIG92ZXIgdGhlIG5ldHdvcmsuICBJcyB0aGlz DQpzb21laG93DQoNCmluZGljYXRpbmcgaG93IHRvIHVuZGVyc3RhbmQgaWYgb25lIGlzIGRlYWxp bmcgYSBwdWJsaWMgKHZlcmlmeSkga2V5IG9yIGENCnByaXZhdGUNCg0KKHNpZ24pIGtleT8NCg0K VGhlIGtleV9vcHMgZmllbGQgY2FuIGJlIGNvbnNpZGVyZWQgdG8gcG90ZW50aWFsbHkgYmUgdHJh bnNwb3J0ZWQgb3ZlciBhDQpuZXR3b3JrLiAgSXQgaXMgcGFydCBvZiB0aGUgQ09TRV9LZXkgb2Jq ZWN0IHJhdGhlciB0aGFuIHBhcnQgb2YgdGhlDQpDT1NFX1NpZ24xIG9iamVjdC4NCg0KDQoNCjMp IHRoZSB2YXJpYXRpb25zOiBMTVNfU0hBMjU2X00zMl9IMjAsIGFuZCBMTU9UU19TSEEyNTZfTjMy X1cyLA0KZXRjLiBhcmUNCiAgbGlzdGVkLCBidXQgSSBkb24ndCBrbm93IGlmIHRoZXkgbmVlZCB0 byBiZSBjYXJyaWVkIGluIHRoZSBzaWduYXR1cmUNCiAgc3RydWN0dXJlIHNvbWVob3cuDQoNClNl ZSB0aGUgW0hBU0hTSUddIGRyYWZ0LiAgSXQgaXMgZW5jb2RlZCBpbnRvIHRoZSBzaWduYXR1cmUg c3RydWN0dXJlIGFuZCB0aGUNCmtleSB0eXBlIGlzIGluIHRoZSBwdWJsaWMga2V5IHN0cnVjdHVy ZS4NCg0KDQoNCjQpIEkgdGhvdWdodCB0aGF0IHBlcmhhcHMgd2UnZCBuZWVkIENCT1Igb3IgQ09T RSBzcGVjaWZpYyB3YXkgdG8gdHJhbnNwb3J0DQogIHRoZSBzaWduYXR1cmVzLiAgSSBndWVzcyBJ IHNoYWxsIHJlYWQgSEFTSFNJRyB0byBmaW5kIG91dCB3aGF0IHRoZQ0KICBzaWduYXR1cmVzIGxv b2sgbGlrZS4NCg0KV2UgaGF2ZSB0aGF0LiAgVGhpcyBpcyBsb29raW5nIGF0IGEgc2lnbmF0dXJl IGp1c3QgbGlrZSBFQ0RTQSB3b3VsZCBwcm9kdWNlLg0KVGhpcyBpcyBhIGRpZmZlcmVudCAiRUNE U0EiIHJlcGxhY2VtZW50Lg0KDQoNCg0KSSB1bmRlcnN0YW5kIGRyYWZ0LW1jZ3Jldy1oYXNoLXNp Z3MtMTEgaXMgYmVpbmcgYWR2YW5jZWQgYnkgQ0ZSRy4NCkkgYmVsaWV2ZSB0aGF0IFNVSVQgc2hv dWxkIGFkb3B0IHRoaXMgZG9jdW1lbnQsIGFuZCBzaG91bGQgZG8gc28gaW4gdGhlDQpjdXJyZW50 IHN0YXRlLg0KDQpJIHdvdWxkIGxpa2UgdG8gaGF2ZSBzb21lIGV4YW1wbGVzIGluIENCT1IvQ09T RSB3b3JrZWQgb3V0IHdpdGggcHJpdmF0ZQ0Ka2V5cyBhdmFpbGFibGUgaW4gdGhlIGFwcGVuZGlj ZXMuDQoNCkFsd2F5cyBhIGdvb2QgdGhpbmcgdG8gaGF2ZS4NCg0KSmltDQoNCg0KDQotLQ0KXSAg ICAgICAgICAgICAgIE5ldmVyIHRlbGwgbWUgdGhlIG9kZHMhICAgICAgICAgICAgICAgICB8IGlw djYgbWVzaA0KbmV0d29ya3MgWw0KDQpdICAgTWljaGFlbCBSaWNoYXJkc29uLCBTYW5kZWxtYW4g U29mdHdhcmUgV29ya3MgICAgICAgIHwgbmV0d29yaw0KYXJjaGl0ZWN0ICBbDQoNCl0gICAgIG1j ckBzYW5kZWxtYW4uY2E8bWFpbHRvOm1jckBzYW5kZWxtYW4uY2E+ICBodHRwOi8vd3d3LnNhbmRl bG1hbi5jYS88aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91 cmw9aHR0cCUzQSUyRiUyRnd3dy5zYW5kZWxtYW4uY2ElMkYmZGF0YT0wMiU3QzAxJTdDZHRoYWxl ciU0MG1pY3Jvc29mdC5jb20lN0MzMDJkMGYxMDYyNmI0NTRhNzMyMzA4ZDVkNzkwNzM1OSU3Qzcy Zjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY2NTE5Mzc3NzE0MDMx MDImc2RhdGE9TTdUbmttOVN6RnkwSW1KVGlIUlRCVkRHZmkzcFIxdkZpeE1DV3NrV21PbyUzRCZy ZXNlcnZlZD0wPiAgICAgICAgfCAgIHJ1Ynkgb24gcmFpbHMNClsNCg0KDQotLQ0KTWljaGFlbCBS aWNoYXJkc29uIDxtY3IrSUVURkBzYW5kZWxtYW4uY2E8bWFpbHRvOm1jcitJRVRGQHNhbmRlbG1h bi5jYT4+LCBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3MNCi09IElQdjYgSW9UIGNvbnN1bHRpbmcg PS0NCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpTdWl0IG1haWxpbmcgbGlzdA0KU3VpdEBpZXRmLm9yZzxtYWlsdG86U3VpdEBpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3VpdDxodHRwczovL25hMDEu c2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5p ZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnN1aXQmZGF0YT0wMiU3QzAxJTdDZHRoYWxl ciU0MG1pY3Jvc29mdC5jb20lN0MzMDJkMGYxMDYyNmI0NTRhNzMyMzA4ZDVkNzkwNzM1OSU3Qzcy Zjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY2NTE5Mzc3NzE0MDMx MDImc2RhdGE9QUtFempPWHRFJTJGUFNjJTJGYndLVVAwY3RDbVlOTDRDTFdOdUY5aGg3SXpPeEUl M0QmcmVzZXJ2ZWQ9MD4NCg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMg ZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBi ZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVh c2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUg Y29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Ig c3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K DQoNCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkg YXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4g SWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUg c2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFu eSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkg dGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCg== --_000_DM5PR2101MB0805F9D2D2372C4AEE2C7E5BA3760DM5PR2101MB0805_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEt LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpIZWx2 ZXRpY2E7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAyIDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxp Lk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9y bWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNv bm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5h cHBsZS10YWItc3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS10YWItc3Bhbjt9DQpzcGFuLkVt YWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhpcyBpcyBzaW1pbGFyIHRvIGEgcXVlc3Rpb24g SSBhc2tlZCBhcyB3ZWxsLCB3aGV0aGVyIHRoZSBJRVRGIG9ubHkgbmVlZHMgTE1TIG9yIHdoZXRo ZXIgTE1TIGlzIGp1c3QgYW4gaW5zdGFuY2UgaW4gYSBsYXJnZXIgY2xhc3MgdGhhdCBtaWdodCBi ZSBuZWVkZWQsIGFuZA0KIHdoYXQgdGhlIHNjb3BlIG9mIHRoZSBkcmFmdCBzaG91bGQgYmUuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JZiB0aGUgZHJhZnQgaXMg bm90IFNVSVQtb25seSAoZS5nLiwgYWxsb3dpbmcgdXNlIGluIE9TQ09SRSwgZXRjLikgdGhlbiBp dCBzb3VuZHMgbGlrZSB3ZSBtaWdodCBuZWVkIHRoZSBhYmlsaXR5IHRvIHN1cHBvcnQgbW9yZSB0 aGFuIExNUyBmb3Igc29tZSB1c2UgY2FzZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5EYXZlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiBTdWl0ICZsdDtzdWl0LWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7DQo8Yj5PbiBCZWhhbGYgT2Yg PC9iPkJyZW5kYW4gTW9yYW48YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEp1bmUgMjEsIDIw MTggOTowMyBBTTxicj4NCjxiPlRvOjwvYj4gUnVzcyBIb3VzbGV5ICZsdDtob3VzbGV5QHZpZ2ls c2VjLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IHN1aXQgJmx0O3N1aXRAaWV0Zi5vcmcmZ3Q7PGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbU3VpdF0gZHJhZnQtaG91c2xleS1zdWl0LWNvc2UtaGFz aC1zaWc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBS dXNzLCA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3Mg Zm9yIHRoZSBjbGFyaWZpY2F0aW9uLiBJIGFncmVlIHRoYXQgYSBsYXJnZXIgc2lnbmF0dXJlIGlz IG5vdCB3aGF0IHdlIG5lZWQgaW4gU1VJVC4gSG93ZXZlciwgZm9yIHRoZSBDT1NFIGRyYWZ0LCB3 b3VsZCBpdCBub3QgbWFrZSBzZW5zZSB0byBwcm92aWRlIGZvciBib3RoIExNUyBhbmQgWE1TUz8g SSBkb27igJl0IHByZXRlbmQgdG8gdW5kZXJzdGFuZCBhbGwgQ09TRSB1c2UgY2FzZXMuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJyZW5k YW48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+ DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDIxIEp1 biAyMDE4LCBhdCAxNjo0MywgUnVzcyBIb3VzbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86aG91c2xl eUB2aWdpbHNlYy5jb20iPmhvdXNsZXlAdmlnaWxzZWMuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CcmVuZGFuOiA8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcywgdGhlcmUgYXJlIHR3 byBDRlJHIGFsZ29yaXRobXMgZm9yIGhhc2gtYmFzZWQgc2lnbmF0dXJlcy4gJm5ic3A7SSBwcmVm ZXIgdGhlIG9uZSBNY0dyZXcncyBkb2N1bWVudCwgbW9zdGx5IGJlY2F1c2UgaXQgaXMgbW9yZSBz dHJhaWdodGZvcndhcmQuICZuYnNwO1RoZXJlIGlzIHNvbWUgc3BlZWQgaW1wcm92ZW1lbnQgZm9y IHRoZSBhZGRpdGlvbmFsIGNvbXBsZXhpdHkgaW4gWE1TUyBhdCB0aGUgY29zdCBvZiBhIGxhcmdl cg0KIHNpZ25hdHVyZSB2YWx1ZS4gJm5ic3A7VG8gbWUsIHRoZSBzcGVlZCBpbXByb3ZlbWVudCBp cyBub3QgYmlnIGVub3VnaCB0byBqdXN0aWZ5IHRoZSBsYXJnZXIgc2lnbmF0dXJlIHNpemUuICZu YnNwO1lvdXIgbWlsZWFnZSBtYXkgdmFyeS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBwYXBlciBkZXNjcmliZXMgdGhlIGRpZmZlcmVu Y2UgYmV0d2VlbiB0aGUgdHdvOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rp b24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmVwcmludC5pYWNyLm9yZyUyRjIwMTcl MkYzNDkucGRmJmFtcDtkYXRhPTAyJTdDMDElN0NkdGhhbGVyJTQwbWljcm9zb2Z0LmNvbSU3QzMw MmQwZjEwNjI2YjQ1NGE3MzIzMDhkNWQ3OTA3MzU5JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdj ZDAxMWRiNDclN0MxJTdDMCU3QzYzNjY1MTkzNzc3MTM4MzA5MiZhbXA7c2RhdGE9ekRHcVIyTnNr akp6eVZWY0NFZzhzdVBvM0x0OWI2eExJMWx4YVlsV3JiUSUzRCZhbXA7cmVzZXJ2ZWQ9MCI+aHR0 cHM6Ly9lcHJpbnQuaWFjci5vcmcvMjAxNy8zNDkucGRmPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SdXNzPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEp1biAyMSwgMjAxOCwgYXQgMTE6MTEg QU0sIEJyZW5kYW4gTW9yYW4gJmx0OzxhIGhyZWY9Im1haWx0bzpCcmVuZGFuLk1vcmFuQGFybS5j b20iPkJyZW5kYW4uTW9yYW5AYXJtLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgc2VlIHRoYXQgdGhlcmUgYXJl IHR3byBjdXJyZW50IGRyYWZ0cyBmb3IgaGFzaC1iYXNlZCBzaWduYXR1cmVzOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6 Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYl MkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZkcmFmdC1tY2dyZXctaGFzaC1zaWdzLTExJmFtcDtk YXRhPTAyJTdDMDElN0NkdGhhbGVyJTQwbWljcm9zb2Z0LmNvbSU3QzMwMmQwZjEwNjI2YjQ1NGE3 MzIzMDhkNWQ3OTA3MzU5JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdD MCU3QzYzNjY1MTkzNzc3MTM5MzA5NyZhbXA7c2RhdGE9Q1RSeDNCVzNkdVhJUkVZeFA0Q3lSJTJC UVk2M3FZZ2kydnFqblVNOXVLcVFNJTNEJmFtcDtyZXNlcnZlZD0wIj5odHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtbWNncmV3LWhhc2gtc2lncy0xMTwvYT48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vbmEw MS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdG9v bHMuaWV0Zi5vcmclMkZodG1sJTJGZHJhZnQtaXJ0Zi1jZnJnLXhtc3MtaGFzaC1iYXNlZC1zaWdu YXR1cmVzLTEyJmFtcDtkYXRhPTAyJTdDMDElN0NkdGhhbGVyJTQwbWljcm9zb2Z0LmNvbSU3QzMw MmQwZjEwNjI2YjQ1NGE3MzIzMDhkNWQ3OTA3MzU5JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdj ZDAxMWRiNDclN0MxJTdDMCU3QzYzNjY1MTkzNzc3MTM5MzA5NyZhbXA7c2RhdGE9cGlpJTJCb2E4 U2tUdDdQTGFycTBQJTJGS1hMNFdCVnBOd0x6R1NJeEVnWkc1WVUlM0QmYW1wO3Jlc2VydmVkPTAi Pmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pcnRmLWNmcmcteG1zcy1oYXNoLWJh c2VkLXNpZ25hdHVyZXMtMTI8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkkgc2VlIHRoYXQgeW91IGhhdmUgcmVmZXJlbmNlZCB0aGUgbWNn cmV3IGRyYWZ0IHJhdGhlciB0aGFuIHRoZSBJUlRGL0NGUkcgZHJhZnQuIENvdWxkIHlvdSBwbGVh c2UgZXhwbGFpbiB3aGF0IHRoZSBkaWZmZXJlbmNlIGlzIGJldHdlZW4gdGhlc2UgdHdvIGRyYWZ0 cyBhbmQgd2h5IHRoZSBtY2dyZXcgZHJhZnQgd2FzIGEgYmV0dGVyIGNob2ljZSB0aGFuIFhNU1M/ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo YW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkJyZW5kYW48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiAxMyBKdW4gMjAxOCwgYXQgMjA6MDMsIEppbSBTY2hhYWQgJmx0Ozxh IGhyZWY9Im1haWx0bzppZXRmQGF1Z3VzdGNlbGxhcnMuY29tIj5pZXRmQGF1Z3VzdGNlbGxhcnMu Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAw LCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7LXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPGJyPg0KPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4t LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IFN1aXQgJmx0OzxhIGhyZWY9Im1h aWx0bzpzdWl0LWJvdW5jZXNAaWV0Zi5vcmciPnN1aXQtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7 IE9uIEJlaGFsZiBPZiBNaWNoYWVsIFJpY2hhcmRzb248YnI+DQpTZW50OiBXZWRuZXNkYXksIEp1 bmUgMTMsIDIwMTggMTE6MDkgQU08YnI+DQpUbzogc3VpdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN1 aXRAaWV0Zi5vcmciPnN1aXRAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NClN1YmplY3Q6IFtTdWl0XSBk cmFmdC1ob3VzbGV5LXN1aXQtY29zZS1oYXNoLXNpZzxicj4NCjxicj4NCjxicj4NCkkgaGF2ZSBy ZWFkIHRoZSAtMDEgZHJhZnQgdG9kYXkuPGJyPg0KSSBoYXZlIG5vdCByZWFkIFtIQVNIU0lHXSB5 ZXQuPGJyPg0KSSB0aG91Z2h0IEknZCB0cnkgcmVhZGluZyB0aGlzIGZpcnN0LCB0byBzZWUgd2hh dCBxdWVzdGlvbnMgSSBoYWQuPGJyPg0KPGJyPg0KSSBoYXZlIGltcGxlbWVudGVkIENPU0UgU2ln bjEgd2l0aCBFQ0RTQSBpbiBSdWJ5LCBzbyBJIGhhdmUgYSBncmFzcCBvZjxicj4NCndoYXQgd2Ug YXJlIHRyeWluZyB0byBwbHVnIGhhc2gtc2lnICppbnRvKi48YnI+DQo8YnI+DQo8YnI+DQpTdWdn ZXN0aW9uczo8YnI+DQoxKSB3b3VsZCB0aGUgc3RydWN0dXJlIHNob3cgaW4gc2VjdGlvbiAzIGJl IGVhc2llciBpZiBpdCB3YXMgZGVzY3JpYmVkIGJ5PGJyPg0KJm5ic3A7Jm5ic3A7Q0RETD8gJm5i c3A7SSdtIHJhdGhlciB1bmNsZWFyIGFib3V0IHRoaXMuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJy Pg0KTm8gLSB0aGlzIGFyZSBub3QgQ0JPUiBzdHJ1Y3R1cmVzIHRoZXkgYXJlIHB1cmUgYmluYXJ5 IHN0cmluZ3M8YnI+DQo8YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12 YXJpYW50LWNhcHM6IG5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0Oy13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxicj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KMikgSSBk aW4ndCB1bmRlcnN0YW5kIHNlY3Rpb24gNCwgd2hlcmUgaXQgc2F5czo8YnI+DQombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDtvICZuYnNwO0lmIHRoZSAna2V5X29wcycgZmllbGQgaXMgcHJl c2VudCwgaXQgTVVTVCBpbmNsdWRlICdzaWduJyB3aGVuPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Y3JlYXRpbmcgYSBoYXNoLWJhc2VkIHNpZ25hdHVyZS48YnI+ DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtvICZuYnNwO0lmIHRoZSAna2V5 X29wcycgZmllbGQgaXMgcHJlc2VudCwgaXQgTVVTVCBpbmNsdWRlICd2ZXJpZnknPGJyPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7d2hlbiB2ZXJpZnlpbmcgYSBoYXNo LWJhc2VkIHNpZ25hdHVyZS48YnI+DQo8YnI+DQpDbGVhcmx5IHRoaXMgaXMgbm90IHNvbWV0aGlu ZyB0aGF0IHRyYXZlbHMgb3ZlciB0aGUgbmV0d29yay4gJm5ic3A7SXMgdGhpczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPnNvbWVob3c8YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9u dC12YXJpYW50LWNhcHM6IG5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0Oy13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxicj4NCjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+aW5kaWNhdGlu ZyBob3cgdG8gdW5kZXJzdGFuZCBpZiBvbmUgaXMgZGVhbGluZyBhIHB1YmxpYyAodmVyaWZ5KSBr ZXkgb3IgYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPnByaXZhdGU8YnIgc3R5bGU9ImNhcmV0LWNvbG9y OiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0 Oy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxicj4N Cjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+KHNpZ24pIGtleT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQpUaGUga2V5X29w cyBmaWVsZCBjYW4gYmUgY29uc2lkZXJlZCB0byBwb3RlbnRpYWxseSBiZSB0cmFuc3BvcnRlZCBv dmVyIGE8YnI+DQpuZXR3b3JrLiAmbmJzcDtJdCBpcyBwYXJ0IG9mIHRoZSBDT1NFX0tleSBvYmpl Y3QgcmF0aGVyIHRoYW4gcGFydCBvZiB0aGU8YnI+DQpDT1NFX1NpZ24xIG9iamVjdC48YnI+DQo8 YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDt0ZXh0LWFsaWduOnN0YXJ0Oy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3Jk LXNwYWNpbmc6MHB4Ij4NCjxicj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KMykgdGhlIHZhcmlhdGlvbnM6IExN U19TSEEyNTZfTTMyX0gyMCwgYW5kIExNT1RTX1NIQTI1Nl9OMzJfVzIsPGJyPg0KZXRjLiBhcmU8 YnI+DQombmJzcDsmbmJzcDtsaXN0ZWQsIGJ1dCBJIGRvbid0IGtub3cgaWYgdGhleSBuZWVkIHRv IGJlIGNhcnJpZWQgaW4gdGhlIHNpZ25hdHVyZTxicj4NCiZuYnNwOyZuYnNwO3N0cnVjdHVyZSBz b21laG93LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NClNlZSB0aGUgW0hBU0hTSUddIGRyYWZ0 LiAmbmJzcDtJdCBpcyBlbmNvZGVkIGludG8gdGhlIHNpZ25hdHVyZSBzdHJ1Y3R1cmUgYW5kIHRo ZTxicj4NCmtleSB0eXBlIGlzIGluIHRoZSBwdWJsaWMga2V5IHN0cnVjdHVyZS48YnI+DQo8YnIg c3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1h bDt0ZXh0LWFsaWduOnN0YXJ0Oy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNw YWNpbmc6MHB4Ij4NCjxicj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KNCkgSSB0aG91Z2h0IHRoYXQgcGVyaGFw cyB3ZSdkIG5lZWQgQ0JPUiBvciBDT1NFIHNwZWNpZmljIHdheSB0byB0cmFuc3BvcnQ8YnI+DQom bmJzcDsmbmJzcDt0aGUgc2lnbmF0dXJlcy4gJm5ic3A7SSBndWVzcyBJIHNoYWxsIHJlYWQgSEFT SFNJRyB0byBmaW5kIG91dCB3aGF0IHRoZTxicj4NCiZuYnNwOyZuYnNwO3NpZ25hdHVyZXMgbG9v ayBsaWtlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCldlIGhhdmUgdGhhdC4gJm5ic3A7VGhp cyBpcyBsb29raW5nIGF0IGEgc2lnbmF0dXJlIGp1c3QgbGlrZSBFQ0RTQSB3b3VsZCBwcm9kdWNl Ljxicj4NClRoaXMgaXMgYSBkaWZmZXJlbnQgJnF1b3Q7RUNEU0EmcXVvdDsgcmVwbGFjZW1lbnQu PGJyPg0KPGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1j YXBzOiBub3JtYWw7dGV4dC1hbGlnbjpzdGFydDstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7d29yZC1zcGFjaW5nOjBweCI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCkkgdW5kZXJzdGFuZCBk cmFmdC1tY2dyZXctaGFzaC1zaWdzLTExIGlzIGJlaW5nIGFkdmFuY2VkIGJ5IENGUkcuPGJyPg0K SSBiZWxpZXZlIHRoYXQgU1VJVCBzaG91bGQgYWRvcHQgdGhpcyBkb2N1bWVudCwgYW5kIHNob3Vs ZCBkbyBzbyBpbiB0aGU8YnI+DQpjdXJyZW50IHN0YXRlLjxicj4NCjxicj4NCkkgd291bGQgbGlr ZSB0byBoYXZlIHNvbWUgZXhhbXBsZXMgaW4gQ0JPUi9DT1NFIHdvcmtlZCBvdXQgd2l0aCBwcml2 YXRlPGJyPg0Ka2V5cyBhdmFpbGFibGUgaW4gdGhlIGFwcGVuZGljZXMuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+PGJyPg0KQWx3YXlzIGEgZ29vZCB0aGluZyB0byBoYXZlLjxicj4NCjxicj4NCkppbTxi cj4NCjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fw czogbm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 O3dvcmQtc3BhY2luZzowcHgiPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQotLTxicj4NCl0gJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7TmV2ZXIgdGVsbCBtZSB0aGUgb2RkcyEgJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCBpcHY2IG1lc2g8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij5uZXR3b3JrcyBbPGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFy aWFudC1jYXBzOiBub3JtYWw7dGV4dC1hbGlnbjpzdGFydDstd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPl0gJm5ic3A7Jm5ic3A7 TWljaGFlbCBSaWNoYXJkc29uLCBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3MgJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCBuZXR3b3JrPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+YXJjaGl0ZWN0ICZuYnNwO1s8YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7 Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0Oy13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxicj4NCjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+XSAmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSJtYWlsdG86bWNyQHNhbmRlbG1hbi5jYSI+bWNy QHNhbmRlbG1hbi5jYTwvYT4gJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5w cm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzQSUyRiUyRnd3dy5zYW5kZWxtYW4uY2El MkYmYW1wO2RhdGE9MDIlN0MwMSU3Q2R0aGFsZXIlNDBtaWNyb3NvZnQuY29tJTdDMzAyZDBmMTA2 MjZiNDU0YTczMjMwOGQ1ZDc5MDczNTklN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0 NyU3QzElN0MwJTdDNjM2NjUxOTM3NzcxNDAzMTAyJmFtcDtzZGF0YT1NN1Rua205U3pGeTBJbUpU aUhSVEJWREdmaTNwUjF2Rml4TUNXc2tXbU9vJTNEJmFtcDtyZXNlcnZlZD0wIj5odHRwOi8vd3d3 LnNhbmRlbG1hbi5jYS88L2E+DQogJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7fCAmbmJzcDsmbmJzcDtydWJ5IG9uIHJhaWxzPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Wzxi ciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9y bWFsO3RleHQtYWxpZ246c3RhcnQ7LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQt c3BhY2luZzowcHgiPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi Pjxicj4NCi0tPGJyPg0KTWljaGFlbCBSaWNoYXJkc29uICZsdDs8YSBocmVmPSJtYWlsdG86bWNy JiM0MztJRVRGQHNhbmRlbG1hbi5jYSI+bWNyJiM0MztJRVRGQHNhbmRlbG1hbi5jYTwvYT4mZ3Q7 LCBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3M8YnI+DQotPSBJUHY2IElvVCBjb25zdWx0aW5nID0t PGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpTdWl0IG1haWxpbmcgbGlz dDxicj4NCjxhIGhyZWY9Im1haWx0bzpTdWl0QGlldGYub3JnIj5TdWl0QGlldGYub3JnPC9hPjxi cj4NCjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNv bS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJG c3VpdCZhbXA7ZGF0YT0wMiU3QzAxJTdDZHRoYWxlciU0MG1pY3Jvc29mdC5jb20lN0MzMDJkMGYx MDYyNmI0NTRhNzMyMzA4ZDVkNzkwNzM1OSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFk YjQ3JTdDMSU3QzAlN0M2MzY2NTE5Mzc3NzE0MDMxMDImYW1wO3NkYXRhPUFLRXpqT1h0RSUyRlBT YyUyRmJ3S1VQMGN0Q21ZTkw0Q0xXTnVGOWhoN0l6T3hFJTNEJmFtcDtyZXNlcnZlZD0wIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N1aXQ8L2E+PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1h aWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBw cml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ug bm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29u dGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwNCiB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBz dG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SU1QT1JUQU5U IE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBh cmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5v dCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRp YXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNv biwNCiB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1h dGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_DM5PR2101MB0805F9D2D2372C4AEE2C7E5BA3760DM5PR2101MB0805_-- From nobody Thu Jun 21 10:20:53 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F697130EA8 for ; Thu, 21 Jun 2018 10:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=linaro.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuslMgrIqoTJ for ; Thu, 21 Jun 2018 10:20:45 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1988B130E9F for ; Thu, 21 Jun 2018 10:20:44 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id l6-v6so5867374iti.2 for ; Thu, 21 Jun 2018 10:20:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:subject:message-id:mime-version:content-disposition :user-agent; bh=UU16dTP6sYgZSPPWYnNvzPFIT7e/AaRidr/XyZxydV8=; b=SAzKP8xfnifj581uEq+czX7d2cejQFNkSilImckndS6MXBFQiSg+fuyUlfr4xQqcwq DhsUwGOSAwJYnbCzijxBYDcm4dCfC+nEU5RnYBUo/lVq1Gg1mp2llus2bVaYy6oLvdbz 8AHJHU0ZyCVVYKSLSaAfMNe2nrJw3zUu9fhqg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition:user-agent; bh=UU16dTP6sYgZSPPWYnNvzPFIT7e/AaRidr/XyZxydV8=; b=iPld7KXa6/JZCU7HMYVnTSbXlrgle6AGEoEMO2UDRYdp+Ps4Wy7Y6uQaB58OrAtC+m mqr9l4qOX167A8IjT9s4leF7BZLPReuiG9GlFBA8+pvKhF/NCvu5OHw7aF/V0uSIwwf5 7HffrpBcII5ioA3pCx85b5xtwaT9GYwPCSdZIHUNeiG/jYUpb8FsBndubdqJ/aM5M2WL ehmHnm/DAotLzrFXHpZXPjiXDvFq0reqnk3orC2QFwa0bSQXjijpJhijKOnmxcThaqtd c3eTjWxXKhufUecOzvVzMDTEWdxDrM5KLMcMED+AZ5mWGiBBiSAMZb/v1NPGddu7rG7Y uwJg== X-Gm-Message-State: APt69E3akHlU/tj7E5Oxn8GpLgwozPHwlrJRvwxFYlqGRfO9ADdpfQXh sDDKjr9XL3wHZGqrgtUvDVGw3LAtLfA= X-Google-Smtp-Source: ADUXVKL4K/Zi4RAktcYLaesuaZVlQ6omGhLsyGG1rTgCgixStA9B4NBYkdoIQGZa8CJY8Hpr/Qeysw== X-Received: by 2002:a02:2341:: with SMTP id u62-v6mr21761858jau.62.1529601643086; Thu, 21 Jun 2018 10:20:43 -0700 (PDT) Received: from davidb.org ([2601:283:4300:987c::9]) by smtp.gmail.com with ESMTPSA id m76-v6sm2732296ioi.68.2018.06.21.10.20.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Jun 2018 10:20:42 -0700 (PDT) Date: Thu, 21 Jun 2018 11:20:40 -0600 From: David Brown To: suit Message-ID: <20180621172040.GA24927@davidb.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: [Suit] SUIT architecture examples X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 17:20:51 -0000 During today's SUIT meeting, we discussed writing up some known example architectures of systems requiring firmware updates. Attached below is a draft of this writeup. ## Architectural examples Although these documents attempt to define a firmware update architecture that is applicable to both existing systems, as well as yet-to-be-conceived systems; it is still helpful to consider existing architectures. ### Single CPU SoC The simplest, and currently most common, architecture consists of a single MCU along with its own peripherals. These SoCs generally contain some amount of flash memory for code and fixed data, as well as RAM for working storage. These systems either have a single firmware image, or an immutable bootloader that runs a single image. A notable characteristic of these SoCs is that the primary code is generally execute in place (XIP). Combined with the non-relocatable nature of the code, firmware updates need to be done in place. ### Single CPU with secure mode Another configuration consists of a similar architecture to the previous, with a single CPU. However, this CPU supports a security partitioning scheme that allows memory (in addition to other things) to be divided into secure and non-secure. There will generally be two images, one for secure mode, and one for non-secure. In this configuration, firmware upgrades will generally be done by the CPU in secure mode, which is able to write to both areas of the flash device. In addition, there are requirements to be able to update either image independently, as well as to update them together atomically, as specified in the associated manifests. ### Dual CPU, shared memory This configuration has two or more CPUs in a single SoC that share memory (flash and RAM). Generally, they will be a protection mechanism to prevent one CPU from accessing the other's memory. Upgrades in this case will typically be done by one of the CPUs, and is similar to the single CPU with secure mode. ### Dual CPU, other bus This configuration has two or more CPUs, each having their own memory. There will be a communication channel between them, but it will be used as a peripheral, not via shared memory. In this case, each CPU will have to be responsible for its own firmware upgrade. It is likely that one of the CPUs will be considered a master, and will direct the other CPU to do the upgrade. This configuration is commonly used to offload specific work to other CPUs. Firmware dependencies are similar to the other solutions above, sometimes allowing only one image to be upgraded, other times requiring several to be upgraded atomically. Because the updates are happening on multiple CPUs, upgrading the two images atomically is challenging. From nobody Thu Jun 21 12:44:01 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDD6A130EC5 for ; Thu, 21 Jun 2018 12:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.091 X-Spam-Level: X-Spam-Status: No, score=0.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjZ4F8qJxHZh for ; Thu, 21 Jun 2018 12:43:55 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8A2A130DFA for ; Thu, 21 Jun 2018 12:43:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id AC738300557 for ; Thu, 21 Jun 2018 15:43:52 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id bmxiegFBnnKi for ; Thu, 21 Jun 2018 15:43:49 -0400 (EDT) Received: from new-host-4.home (pool-71-127-50-4.washdc.fios.verizon.net [71.127.50.4]) by mail.smeinc.net (Postfix) with ESMTPSA id B1998300433; Thu, 21 Jun 2018 15:43:49 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A848FCD0-E45D-4BCE-B424-852D2958D8E5" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Thu, 21 Jun 2018 15:43:50 -0400 In-Reply-To: Cc: suit To: Dave Thaler , Brendan Moran References: <31676.1528913351@localhost> <04f401d40349$33a58b10$9af0a130$@augustcellars.com> <0CDB8D05-0214-4749-9907-5A1B0B4A2191@arm.com> <697B1DC9-B1DE-48BA-ADC6-EF936208AFCE@vigilsec.com> <9906B2BC-BFC2-4F83-A0F6-FFCC81912237@arm.com> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Suit] draft-housley-suit-cose-hash-sig X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 19:43:59 -0000 --Apple-Mail=_A848FCD0-E45D-4BCE-B424-852D2958D8E5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I am advocating LMS. I think it would be appropriate for an advocate for = XMSS to write a similar draft for that algorithm. Russ > On Jun 21, 2018, at 12:08 PM, Dave Thaler = wrote: >=20 > This is similar to a question I asked as well, whether the IETF only = needs LMS or whether LMS is just an instance in a larger class that = might be needed, and what the scope of the draft should be. > =20 > If the draft is not SUIT-only (e.g., allowing use in OSCORE, etc.) = then it sounds like we might need the ability to support more than LMS = for some use cases. > =20 > Dave > =20 > From: Suit > On = Behalf Of Brendan Moran > Sent: Thursday, June 21, 2018 9:03 AM > To: Russ Housley > > Cc: suit > > Subject: Re: [Suit] draft-housley-suit-cose-hash-sig > =20 > Hi Russ,=20 > Thanks for the clarification. I agree that a larger signature is not = what we need in SUIT. However, for the COSE draft, would it not make = sense to provide for both LMS and XMSS? I don=E2=80=99t pretend to = understand all COSE use cases. > =20 > Thanks, > Brendan >=20 >=20 > On 21 Jun 2018, at 16:43, Russ Housley > wrote: > =20 > Brendan:=20 > =20 > Yes, there are two CFRG algorithms for hash-based signatures. I = prefer the one McGrew's document, mostly because it is more = straightforward. There is some speed improvement for the additional = complexity in XMSS at the cost of a larger signature value. To me, the = speed improvement is not big enough to justify the larger signature = size. Your mileage may vary. > =20 > This paper describes the difference between the two: > =20 > https://eprint.iacr.org/2017/349.pdf = > =20 > Russ > =20 >=20 >=20 > On Jun 21, 2018, at 11:11 AM, Brendan Moran > wrote: > =20 > I see that there are two current drafts for hash-based signatures: > https://tools.ietf.org/html/draft-mcgrew-hash-sigs-11 = > = https://tools.ietf.org/html/draft-irtf-cfrg-xmss-hash-based-signatures-12 = > =20 > I see that you have referenced the mcgrew draft rather than the = IRTF/CFRG draft. Could you please explain what the difference is between = these two drafts and why the mcgrew draft was a better choice than XMSS? > =20 > Thanks, > Brendan > =20 >=20 >=20 > On 13 Jun 2018, at 20:03, Jim Schaad > wrote: > =20 >=20 >=20 >=20 > -----Original Message----- > From: Suit > On = Behalf Of Michael Richardson > Sent: Wednesday, June 13, 2018 11:09 AM > To: suit > > Subject: [Suit] draft-housley-suit-cose-hash-sig >=20 >=20 > I have read the -01 draft today. > I have not read [HASHSIG] yet. > I thought I'd try reading this first, to see what questions I had. >=20 > I have implemented COSE Sign1 with ECDSA in Ruby, so I have a grasp of > what we are trying to plug hash-sig *into*. >=20 >=20 > Suggestions: > 1) would the structure show in section 3 be easier if it was described = by > CDDL? I'm rather unclear about this. >=20 > No - this are not CBOR structures they are pure binary strings >=20 >=20 >=20 > 2) I din't understand section 4, where it says: > o If the 'key_ops' field is present, it MUST include 'sign' when > creating a hash-based signature. >=20 > o If the 'key_ops' field is present, it MUST include 'verify' > when verifying a hash-based signature. >=20 > Clearly this is not something that travels over the network. Is this > somehow >=20 > indicating how to understand if one is dealing a public (verify) key = or a > private >=20 > (sign) key? >=20 > The key_ops field can be considered to potentially be transported over = a > network. It is part of the COSE_Key object rather than part of the > COSE_Sign1 object. >=20 >=20 >=20 > 3) the variations: LMS_SHA256_M32_H20, and LMOTS_SHA256_N32_W2, > etc. are > listed, but I don't know if they need to be carried in the signature > structure somehow. >=20 > See the [HASHSIG] draft. It is encoded into the signature structure = and the > key type is in the public key structure. >=20 >=20 >=20 > 4) I thought that perhaps we'd need CBOR or COSE specific way to = transport > the signatures. I guess I shall read HASHSIG to find out what the > signatures look like. >=20 > We have that. This is looking at a signature just like ECDSA would = produce. > This is a different "ECDSA" replacement. >=20 >=20 >=20 > I understand draft-mcgrew-hash-sigs-11 is being advanced by CFRG. > I believe that SUIT should adopt this document, and should do so in = the > current state. >=20 > I would like to have some examples in CBOR/COSE worked out with = private > keys available in the appendices. >=20 > Always a good thing to have. >=20 > Jim >=20 >=20 >=20 > -- > ] Never tell me the odds! | ipv6 mesh > networks [ >=20 > ] Michael Richardson, Sandelman Software Works | network > architect [ >=20 > ] mcr@sandelman.ca = http://www.sandelman.ca/ = = | ruby on rails > [ >=20 >=20 > -- > Michael Richardson >, Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 >=20 > _______________________________________________ > Suit mailing list > Suit@ietf.org > https://www.ietf.org/mailman/listinfo/suit = > =20 > IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy = the information in any medium. Thank you. > =20 > =20 > IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy = the information in any medium. Thank you. --Apple-Mail=_A848FCD0-E45D-4BCE-B424-852D2958D8E5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = am advocating LMS. I think it would be appropriate for an advocate for = XMSS to write a similar draft for that algorithm.

Russ


On Jun 21, 2018, at 12:08 PM, Dave Thaler <dthaler@microsoft.com> wrote:

This is similar to a = question I asked as well, whether the IETF only needs LMS or whether LMS = is just an instance in a larger class that might be needed, and what the = scope of the draft should be.
 
If = the draft is not SUIT-only (e.g., allowing use in OSCORE, etc.) then it = sounds like we might need the ability to support more than LMS for some = use cases.
 
Dave
 
From: Suit <suit-bounces@ietf.org> On Behalf = Of Brendan = Moran
Sent: Thursday, June 21, 2018 = 9:03 AM
To: Russ Housley <housley@vigilsec.com>
Cc: suit <suit@ietf.org>
Subject: Re: [Suit] = draft-housley-suit-cose-hash-sig
 
Hi Russ, 
Thanks for the clarification. I agree that a larger = signature is not what we need in SUIT. However, for the COSE draft, = would it not make sense to provide for both LMS and XMSS? I don=E2=80=99t = pretend to understand all COSE use cases.
 
Thanks,
Brendan


On 21 Jun 2018, at 16:43, Russ Housley = <housley@vigilsec.com> = wrote:
 
Brendan: 
 
Yes, there = are two CFRG algorithms for hash-based signatures.  I prefer the = one McGrew's document, mostly because it is more straightforward. =  There is some speed improvement for the additional complexity in = XMSS at the cost of a larger signature value.  To me, the speed = improvement is not big enough to justify the larger signature size. =  Your mileage may vary.
 
This paper describes the difference = between the two:
 
https://eprint.iacr.org/2017/349.pdf
 
Russ
 


On Jun 21, 2018, at 11:11 AM, Brendan = Moran <Brendan.Moran@arm.com> wrote:
 
I see that there are two current drafts for hash-based = signatures:
https://tools.ietf.org/html/draft-mcgrew-hash-sigs-11
https://tools.ietf.org/html/draft-irtf-cfrg-xmss-hash-based-sig= natures-12
 
I see that you have referenced the = mcgrew draft rather than the IRTF/CFRG draft. Could you please explain = what the difference is between these two drafts and why the mcgrew draft = was a better choice than XMSS?
 
Thanks,
Brendan
 


On 13 Jun = 2018, at 20:03, Jim Schaad <ietf@augustcellars.com> wrote:
 



-----Original = Message-----
From: Suit <suit-bounces@ietf.org> On = Behalf Of Michael Richardson
Sent: Wednesday, June 13, = 2018 11:09 AM
To: suit <suit@ietf.org>
Subject: [Suit] = draft-housley-suit-cose-hash-sig


I have read the -01 draft today.
I have not = read [HASHSIG] yet.
I thought I'd try reading this first, = to see what questions I had.

I have = implemented COSE Sign1 with ECDSA in Ruby, so I have a grasp of
what we are trying to plug hash-sig *into*.


Suggestions:
1) would the = structure show in section 3 be easier if it was described by
  CDDL?  I'm rather unclear about this.

No - this are not CBOR = structures they are pure binary strings



2) I = din't understand section 4, where it says:
     o  If the 'key_ops' field = is present, it MUST include 'sign' when
          &nb= sp;     creating a hash-based signature.

     o  If the = 'key_ops' field is present, it MUST include 'verify'
          &nb= sp;     when verifying a hash-based = signature.

Clearly this is not something = that travels over the network.  Is this
somehow

indicating how to = understand if one is dealing a public (verify) key or a
private

(sign) key?

The key_ops field can = be considered to potentially be transported over a
network. =  It is part of the COSE_Key object rather than part of the
COSE_Sign1 object.



3) = the variations: LMS_SHA256_M32_H20, and LMOTS_SHA256_N32_W2,
etc. are
  listed, but I don't know = if they need to be carried in the signature
  structure somehow.

See the [HASHSIG] = draft.  It is encoded into the signature structure and the
key type is in the public key structure.



4) I = thought that perhaps we'd need CBOR or COSE specific way to transport
  the signatures.  I guess I shall read = HASHSIG to find out what the
  signatures look = like.

We have = that.  This is looking at a signature just like ECDSA would = produce.
This is a different "ECDSA" replacement.



I understand = draft-mcgrew-hash-sigs-11 is being advanced by CFRG.
I = believe that SUIT should adopt this document, and should do so in the
current state.

I would like to = have some examples in CBOR/COSE worked out with private
keys= available in the appendices.

Always a good thing to = have.

Jim



--
] =             &n= bsp; Never tell me the odds! =             &n= bsp;   | ipv6 mesh
networks [

] =   Michael Richardson, Sandelman Software Works =        | network
architect  [

] =     mcr@sandelman.ca  http://www.sandelman.ca/      = ;  |   ruby on rails
[


--
Michael Richardson <mcr+IETF@sandelman.ca>, = Sandelman Software Works
-=3D IPv6 IoT consulting =3D-



_______________________________________________
Suit mailing list
Suit@ietf.org
https://www.ietf.org/mailman/listinfo/suit
 
IMPORTANT NOTICE: The contents of this email and any = attachments are confidential and may also be privileged. If you are not = the intended recipient, please notify the sender immediately and do not = disclose the contents to any other person, use it for any purpose, or = store or copy the information in any medium. Thank you.
 
 
IMPORTANT NOTICE: The contents of this email and any = attachments are confidential and may also be privileged. If you are not = the intended recipient, please notify the sender immediately and do not = disclose the contents to any other person, use it for any purpose, or = store or copy the information in any medium. Thank = you.

= --Apple-Mail=_A848FCD0-E45D-4BCE-B424-852D2958D8E5-- From nobody Thu Jun 21 13:15:04 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4F47130E0F for ; Thu, 21 Jun 2018 13:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lm7sZIh8zFXe for ; Thu, 21 Jun 2018 13:14:59 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A133130E14 for ; Thu, 21 Jun 2018 13:14:58 -0700 (PDT) Received: from Jude (50.252.25.182) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 21 Jun 2018 13:11:51 -0700 From: Jim Schaad To: 'Russ Housley' , 'Dave Thaler' , 'Brendan Moran' CC: 'suit' References: <31676.1528913351@localhost> <04f401d40349$33a58b10$9af0a130$@augustcellars.com> <0CDB8D05-0214-4749-9907-5A1B0B4A2191@arm.com> <697B1DC9-B1DE-48BA-ADC6-EF936208AFCE@vigilsec.com> <9906B2BC-BFC2-4F83-A0F6-FFCC81912237@arm.com> In-Reply-To: Date: Thu, 21 Jun 2018 13:14:47 -0700 Message-ID: <014901d4099c$82be6150$883b23f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_014A_01D40961.D6688A00" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHwZWPvfC0oH/KJpPKzh2KFlMHiSQFvEQHtAbrOmkYA7bECGAHMf9bXAeyn/S8A68Uj4qPsiX3w Content-Language: en-us X-Originating-IP: [50.252.25.182] Archived-At: Subject: Re: [Suit] draft-housley-suit-cose-hash-sig X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 20:15:03 -0000 ------=_NextPart_000_014A_01D40961.D6688A00 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I have not looked in detail at the XMSS signature structure and key = structure and would want to do so before making any type of definitive = statement. However different drafts defining the different signature = structures is what I would generally expect unless there is a huge = overlap between them. I would guess that the key structures are also = different and thus would probably need to be identified differently. = This is based on the fact that a algorithm variant byte is placed at the = start of both the key and signatures. =20 Doing this separately when we know they are going to be used (or = potentially used) makes more sense to me. =20 Jim =20 =20 From: Suit On Behalf Of Russ Housley Sent: Thursday, June 21, 2018 12:44 PM To: Dave Thaler ; Brendan Moran = Cc: suit Subject: Re: [Suit] draft-housley-suit-cose-hash-sig =20 I am advocating LMS. I think it would be appropriate for an advocate for = XMSS to write a similar draft for that algorithm. =20 Russ =20 On Jun 21, 2018, at 12:08 PM, Dave Thaler > wrote: =20 This is similar to a question I asked as well, whether the IETF only = needs LMS or whether LMS is just an instance in a larger class that = might be needed, and what the scope of the draft should be. =20 If the draft is not SUIT-only (e.g., allowing use in OSCORE, etc.) then = it sounds like we might need the ability to support more than LMS for = some use cases. =20 Dave =20 From: Suit < suit-bounces@ietf.org> On = Behalf Of Brendan Moran Sent: Thursday, June 21, 2018 9:03 AM To: Russ Housley < housley@vigilsec.com> Cc: suit < suit@ietf.org> Subject: Re: [Suit] draft-housley-suit-cose-hash-sig =20 Hi Russ,=20 Thanks for the clarification. I agree that a larger signature is not = what we need in SUIT. However, for the COSE draft, would it not make = sense to provide for both LMS and XMSS? I don=E2=80=99t pretend to = understand all COSE use cases. =20 Thanks, Brendan On 21 Jun 2018, at 16:43, Russ Housley < = housley@vigilsec.com> wrote: =20 Brendan:=20 =20 Yes, there are two CFRG algorithms for hash-based signatures. I prefer = the one McGrew's document, mostly because it is more straightforward. = There is some speed improvement for the additional complexity in XMSS at = the cost of a larger signature value. To me, the speed improvement is = not big enough to justify the larger signature size. Your mileage may = vary. =20 This paper describes the difference between the two: =20 = https://eprint.iacr.org/2017/349.pdf =20 Russ =20 On Jun 21, 2018, at 11:11 AM, Brendan Moran < = Brendan.Moran@arm.com> wrote: =20 I see that there are two current drafts for hash-based signatures: = = https://tools.ietf.org/html/draft-mcgrew-hash-sigs-11 = = https://tools.ietf.org/html/draft-irtf-cfrg-xmss-hash-based-signatures-12= =20 I see that you have referenced the mcgrew draft rather than the = IRTF/CFRG draft. Could you please explain what the difference is between = these two drafts and why the mcgrew draft was a better choice than XMSS? =20 Thanks, Brendan =20 On 13 Jun 2018, at 20:03, Jim Schaad < = ietf@augustcellars.com> wrote: =20 -----Original Message----- From: Suit < suit-bounces@ietf.org> On = Behalf Of Michael Richardson Sent: Wednesday, June 13, 2018 11:09 AM To: suit < suit@ietf.org> Subject: [Suit] draft-housley-suit-cose-hash-sig I have read the -01 draft today. I have not read [HASHSIG] yet. I thought I'd try reading this first, to see what questions I had. I have implemented COSE Sign1 with ECDSA in Ruby, so I have a grasp of what we are trying to plug hash-sig *into*. Suggestions: 1) would the structure show in section 3 be easier if it was described = by CDDL? I'm rather unclear about this. No - this are not CBOR structures they are pure binary strings 2) I din't understand section 4, where it says: o If the 'key_ops' field is present, it MUST include 'sign' when creating a hash-based signature. o If the 'key_ops' field is present, it MUST include 'verify' when verifying a hash-based signature. Clearly this is not something that travels over the network. Is this somehow indicating how to understand if one is dealing a public (verify) key or = a private (sign) key? The key_ops field can be considered to potentially be transported over a network. It is part of the COSE_Key object rather than part of the COSE_Sign1 object. 3) the variations: LMS_SHA256_M32_H20, and LMOTS_SHA256_N32_W2, etc. are listed, but I don't know if they need to be carried in the signature structure somehow. See the [HASHSIG] draft. It is encoded into the signature structure and = the key type is in the public key structure. 4) I thought that perhaps we'd need CBOR or COSE specific way to = transport the signatures. I guess I shall read HASHSIG to find out what the signatures look like. We have that. This is looking at a signature just like ECDSA would = produce. This is a different "ECDSA" replacement. I understand draft-mcgrew-hash-sigs-11 is being advanced by CFRG. I believe that SUIT should adopt this document, and should do so in the current state. I would like to have some examples in CBOR/COSE worked out with private keys available in the appendices. Always a good thing to have. Jim -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca = http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson < = mcr+IETF@sandelman.ca>, Sandelman Software Works -=3D IPv6 IoT consulting =3D- _______________________________________________ Suit mailing list Suit@ietf.org = https://www.ietf.org/mailman/listinfo/suit =20 IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy = the information in any medium. Thank you. =20 =20 IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy = the information in any medium. Thank you. =20 ------=_NextPart_000_014A_01D40961.D6688A00 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I have not = looked in detail at the XMSS signature structure =C2=A0and key structure = and would want to do so before making any type of definitive = statement.=C2=A0 However different drafts defining the different = signature structures is what I would generally expect unless there is a = huge overlap between them.=C2=A0 I would guess that the key structures = are also different and thus would probably need to be identified = differently.=C2=A0 This is based on the fact that a algorithm variant = byte is placed at the start of both the key and = signatures.

 

Doing this separately when we know they are going to = be used (or potentially used) makes more sense to me.

 

Jim

 

 

From: Suit = <suit-bounces@ietf.org> On Behalf Of Russ = Housley
Sent: Thursday, June 21, 2018 12:44 PM
To: = Dave Thaler <dthaler@microsoft.com>; Brendan Moran = <Brendan.Moran@arm.com>
Cc: suit = <suit@ietf.org>
Subject: Re: [Suit] = draft-housley-suit-cose-hash-sig

 

I am = advocating LMS. I think it would be appropriate for an advocate for XMSS = to write a similar draft for that algorithm.

 

Russ

 



On Jun 21, 2018, at 12:08 PM, Dave Thaler <dthaler@microsoft.com> = wrote:

 

This is similar to a = question I asked as well, whether the IETF only needs LMS or whether LMS = is just an instance in a larger class that might be needed, and what the = scope of the draft should be.

 

If the draft is not = SUIT-only (e.g., allowing use in OSCORE, etc.) then it sounds like we = might need the ability to support more than LMS for some use = cases.

 

Dave

 

From: Suit <suit-bounces@ietf.org> On Behalf Of Brendan = Moran
Sent: Thursday, June 21, 2018 9:03 = AM
To: Russ = Housley <housley@vigilsec.com>
Cc:<= span class=3Dapple-converted-space> suit <suit@ietf.org>
Subject: Re: [Suit] = draft-housley-suit-cose-hash-sig

 

Hi Russ, 

Thanks = for the clarification. I agree that a larger signature is not what we = need in SUIT. However, for the COSE draft, would it not make sense to = provide for both LMS and XMSS? I don=E2=80=99t pretend to understand all = COSE use cases.

 

Thanks,

Brendan




On 21 Jun 2018, at 16:43, Russ Housley <housley@vigilsec.com> = wrote:

 

Brendan: 

 

Yes, there are two CFRG algorithms for hash-based = signatures.  I prefer the one McGrew's document, mostly because it = is more straightforward.  There is some speed improvement for the = additional complexity in XMSS at the cost of a larger signature value. =  To me, the speed improvement is not big enough to justify the = larger signature size.  Your mileage may = vary.

 

This paper describes the difference between the = two:

 

 

Russ

 




On Jun 21, 2018, at 11:11 AM, Brendan Moran <Brendan.Moran@arm.com> = wrote:

 

I see that there are two current drafts for hash-based = signatures:

=

 

I see that you have referenced the mcgrew draft rather = than the IRTF/CFRG draft. Could you please explain what the difference = is between these two drafts and why the mcgrew draft was a better choice = than XMSS?

 

Thanks,

Brendan

 




On 13 Jun 2018, at 20:03, Jim Schaad <ietf@augustcellars.com> = wrote:

 




=

-----Origina= l Message-----
From: Suit <suit-bounces@ietf.org> On Behalf Of = Michael Richardson
Sent: Wednesday, June 13, 2018 11:09 AM
To: = suit <suit@ietf.org>
Subject: [Suit] = draft-housley-suit-cose-hash-sig


I have read the -01 draft = today.
I have not read [HASHSIG] yet.
I thought I'd try reading = this first, to see what questions I had.

I have implemented COSE = Sign1 with ECDSA in Ruby, so I have a grasp of
what we are trying to = plug hash-sig *into*.


Suggestions:
1) would the structure = show in section 3 be easier if it was described by
  CDDL? =  I'm rather unclear about this.


No - = this are not CBOR structures they are pure binary = strings




2) I = din't understand section 4, where it = says:
     o  If the 'key_ops' field is = present, it MUST include 'sign' = when
           = ;     creating a hash-based = signature.

     o  If the 'key_ops' = field is present, it MUST include = 'verify'
          &= nbsp;     when verifying a hash-based = signature.

Clearly this is not something that travels over the = network.  Is this

somehow
<= br>

indicating = how to understand if one is dealing a public (verify) key or = a

private
<= br>

(sign) = key?


The = key_ops field can be considered to potentially be transported over = a
network.  It is part of the COSE_Key object rather than part = of the
COSE_Sign1 object.




3) the = variations: LMS_SHA256_M32_H20, and LMOTS_SHA256_N32_W2,
etc. = are
  listed, but I don't know if they need to be carried = in the signature
  structure somehow.


See the = [HASHSIG] draft.  It is encoded into the signature structure and = the
key type is in the public key = structure.




4) I = thought that perhaps we'd need CBOR or COSE specific way to = transport
  the signatures.  I guess I shall read = HASHSIG to find out what the
  signatures look = like.


We have = that.  This is looking at a signature just like ECDSA would = produce.
This is a different "ECDSA" = replacement.




I = understand draft-mcgrew-hash-sigs-11 is being advanced by CFRG.
I = believe that SUIT should adopt this document, and should do so in = the
current state.

I would like to have some examples in = CBOR/COSE worked out with private
keys available in the = appendices.


Always = a good thing to have.

Jim




--
] =             &= nbsp; Never tell me the odds! =             &= nbsp;   | ipv6 mesh

networks = [


] =   Michael Richardson, Sandelman Software Works =        | network

architect =  [


] =     mcr@sandelman.ca  http://www.sandelman.ca/      =   |   ruby on rails

[


--
Mi= chael Richardson <mcr+IETF@sandelman.ca>, Sandelman = Software Works
-=3D IPv6 IoT consulting =3D-




____= ___________________________________________
Suit mailing list
Suit@ietf.org
https://www.ietf.org/mailman/listinfo/suit<= /a>

 

------=_NextPart_000_014A_01D40961.D6688A00-- From nobody Thu Jun 21 14:02:40 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3051294D0 for ; Thu, 21 Jun 2018 14:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gr2pX1MhCtgy for ; Thu, 21 Jun 2018 14:02:36 -0700 (PDT) Received: from NAM05-DM3-obe.outbound.protection.outlook.com (mail-eopbgr730110.outbound.protection.outlook.com [40.107.73.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C10B12785F for ; Thu, 21 Jun 2018 14:02:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/T10cY8od2BvsHcWKfarlhe4JNR9bDtGE1EHkD9wSAg=; b=X1QBhSMs1A1IX0ENbE0mjOqh7FV3PKz6My4ablSUjThIBLbrinYJ39xGBqLFtZa8eMEjvqI1EFsxtYM9y+K0zOwUXbpJgrpgdItELz5bb2PoWs1o6vFa+H2oHMu2X//3JGHYpDILyOYRuFyk+oYyI5bHUrKcGnsnccmPfAqZqI4= Received: from DM5PR2101MB0805.namprd21.prod.outlook.com (10.167.105.149) by DM5PR2101MB1064.namprd21.prod.outlook.com (52.132.130.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.906.3; Thu, 21 Jun 2018 21:02:34 +0000 Received: from DM5PR2101MB0805.namprd21.prod.outlook.com ([fe80::30ec:e30c:8f5c:b685]) by DM5PR2101MB0805.namprd21.prod.outlook.com ([fe80::30ec:e30c:8f5c:b685%2]) with mapi id 15.20.0906.013; Thu, 21 Jun 2018 21:02:34 +0000 From: Dave Thaler To: suit Thread-Topic: Doodle poll for next design team meeting Thread-Index: AdQJorEZfSTUEtzXSiCxBH9Hc5NAog== Date: Thu, 21 Jun 2018 21:02:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=dthaler@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-06-21T21:02:33.1422144Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:1:c664:6de4:c8cb:9cd2] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR2101MB1064; 7:F4v1CqtqgvzSgaoLOYJETvcofv8WWYpy0Sp2Jot1PEIZJOQIyopzslMCGt0V+E0Fm/y6ye3bavT/nGoI4/tstn7N8W5kLr71haFhJu6dQ8eOqyLohK61LJ9zBDKC08yYMkxSDUCcjiAdjXCvuXozkyFbkja4lGFQbqiLMqiA/0UV7w1ciXgHBmjbaWSgoXj2iYU/r6JlTMoW9O9xHsceyd8njaFBq5UkKhAjrZnaNW5rumOekWmdyAMaAdl9ZoHl x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: bd7e3694-4844-45e6-fba1-08d5d7ba4fea x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989088)(4534165)(4627221)(201703031133081)(201702281549075)(8990095)(5600026)(711020)(48565401081)(2017052603328)(7193020); SRVR:DM5PR2101MB1064; x-ms-traffictypediagnostic: DM5PR2101MB1064: authentication-results: spf=none (sender IP is ) smtp.mailfrom=dthaler@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(60409825278598)(100405760836317)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231254)(2018427008)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:DM5PR2101MB1064; BCL:0; PCL:0; RULEID:; SRVR:DM5PR2101MB1064; x-forefront-prvs: 07106EF9B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(366004)(39380400002)(396003)(39860400002)(199004)(189003)(316002)(7736002)(478600001)(46003)(966005)(105586002)(106356001)(6916009)(6116002)(790700001)(33656002)(68736007)(476003)(10290500003)(14454004)(74316002)(606006)(8936002)(486006)(86612001)(81166006)(81156014)(86362001)(21615005)(8676002)(99286004)(53936002)(3660700001)(25786009)(186003)(2906002)(236005)(3280700002)(7696005)(5660300001)(2900100001)(22452003)(97736004)(5250100002)(55016002)(6436002)(102836004)(6506007)(9686003)(8990500004)(6306002)(10090500001)(54896002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR2101MB1064; H:DM5PR2101MB0805.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: syY3Hsvr9/4efhu+AN5vKaZ/O2zM1IB4S3z1psI/NymfceXIeg598FptTy1VWxMNwcJSzt7JoPcohyO6z/kJkdwEJB/EkwG8S9I3E+B3e2nRPhmshovZ0aCLuAN8VWvpJB3hatRO/Pi4BTBoBvoztuCLdfHZg3stU/Yep1Fh4l21fmqGNXmLe+u11L+Vr0XkrsxZV78oqmwvNjPrNQXItdiyN3wPctYfnpgft9IZyU8fatHoyWx+fkqTDCjMu4AJpqrn+RgNOo/Ya7wos8bilX3fj5LNU8kCfQMerBqNoAa/Fqab1RYV3Qov1HmDKkOlMSBXJNxLBkdqubhmLcLurg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR2101MB08057B5D7B4153D99C78ACA8A3760DM5PR2101MB0805_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: bd7e3694-4844-45e6-fba1-08d5d7ba4fea X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jun 2018 21:02:34.6451 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR2101MB1064 Archived-At: Subject: [Suit] Doodle poll for next design team meeting X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 21:02:39 -0000 --_000_DM5PR2101MB08057B5D7B4153D99C78ACA8A3760DM5PR2101MB0805_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There will be another open design team meeting on Thursday June 28th, time = TBD. We've created a doodle poll to see what time of day will work best for folk= s who want to attend: https://doodle.com/poll/i2qesun9p35i5tbc Dave P.S.: Note that design team meetings are not official WG meetings and thus = are not about getting WG consensus, they're about developing proposals that can be brought to the WG for review= , and hence have the same status as any other individual submission to a WG. For more info, see https://www= .ietf.org/iesg/statement/design-team.html --_000_DM5PR2101MB08057B5D7B4153D99C78ACA8A3760DM5PR2101MB0805_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There will be another open design team = meeting on Thursday June 28th, time TBD.

We’ve created a doodle poll to se= e what time of day will work best for folks who want to attend:<= /span>

https://doodle.com/poll/i2qesun9p35i5tbc

 

Dave

 

P.S.: Note that design team meetings are not offici= al WG meetings and thus are not about getting WG consensus,

they’re about developing proposals that can b= e brought to the WG for review, and hence have the same status

as any other individual submission to a WG.  F= or more info, see https://ww= w.ietf.org/iesg/statement/design-team.html

 

 

--_000_DM5PR2101MB08057B5D7B4153D99C78ACA8A3760DM5PR2101MB0805_-- From nobody Fri Jun 22 01:13:33 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87070130DFC for ; Fri, 22 Jun 2018 01:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.611 X-Spam-Level: X-Spam-Status: No, score=-0.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7IQWcoIC8aY for ; Fri, 22 Jun 2018 01:13:29 -0700 (PDT) Received: from esa1.dyson.c3s2.iphmx.com (esa1.dyson.c3s2.iphmx.com [68.232.133.31]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C276D130DC6 for ; Fri, 22 Jun 2018 01:13:28 -0700 (PDT) X-IronPort-SPF: SKIP X-IronPort-AV: E=McAfee;i="5900,7806,8931"; a="40321826" X-IronPort-AV: E=Sophos; i="5.51,256,1526338800"; d="scan'208,217"; a="40321826" Received: from unknown (HELO uk-dlp-smtp-02.dyson.global.corp) ([62.189.202.16]) by esa1.dyson.c3s2.iphmx.com with ESMTP; 22 Jun 2018 09:24:39 +0100 Received: from uk-dlp-smtp-02.dyson.global.corp (uk-dlp-smtp-02.dyson.global.corp [127.0.0.1]) by uk-dlp-smtp-02.dyson.global.corp (Service) with ESMTP id 6E4F594702; Fri, 22 Jun 2018 06:52:12 +0000 (GMT) Received: from UK-MAL-CAS-01.dyson.global.corp (unknown [10.1.108.2]) by uk-dlp-smtp-02.dyson.global.corp (Service) with ESMTP id 4A22294711; Fri, 22 Jun 2018 06:52:12 +0000 (GMT) Received: from UK-MAL-MBOX-01.dyson.global.corp ([fe80::3975:cbc9:490b:523a]) by UK-MAL-CAS-01.dyson.global.corp ([fe80::e820:2e99:cbf:405b%16]) with mapi id 14.03.0319.002; Fri, 22 Jun 2018 09:13:22 +0100 From: Tony Putman To: Russ Housley CC: suit , Dave Thaler , Brendan Moran Thread-Topic: [Suit] draft-housley-suit-cose-hash-sig Thread-Index: AQHUA0IpmCMrPXwNBEGZJN1O4yNrXaReex0AgAxR0ACAAAjwgIAABWoAgAABigCAADxBAIAA4PKg Date: Fri, 22 Jun 2018 08:13:22 +0000 Message-ID: <140080C241BAA1419B58F093108F9EDC1E0D1690@UK-MAL-MBOX-01.dyson.global.corp> References: <31676.1528913351@localhost> <04f401d40349$33a58b10$9af0a130$@augustcellars.com> <0CDB8D05-0214-4749-9907-5A1B0B4A2191@arm.com> <697B1DC9-B1DE-48BA-ADC6-EF936208AFCE@vigilsec.com> <9906B2BC-BFC2-4F83-A0F6-FFCC81912237@arm.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.108.27] Content-Type: multipart/alternative; boundary="_000_140080C241BAA1419B58F093108F9EDC1E0D1690UKMALMBOX01dyso_" MIME-Version: 1.0 Archived-At: Subject: Re: [Suit] draft-housley-suit-cose-hash-sig X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 08:13:33 -0000 --_000_140080C241BAA1419B58F093108F9EDC1E0D1690UKMALMBOX01dyso_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 QXMgZmFyIGFzIEkgY2FuIHRlbGwsIGl0IGlzIG5vdCBwb3NzaWJsZSB0byB0ZWxsIGZyb20gdGhl IHNpZ25hdHVyZSB3aGV0aGVyIGl0IGlzIExNUyBvciBYTVNTIChvciBpbmRlZWQgYW55IG90aGVy IGhhc2gtYmFzZWQgc2lnbmF0dXJlIHNjaGVtZSkuIElmIHRoaXMgaXMgdGhlIGNhc2UsIHRoZW4g SSBzdWdnZXN0IHRoYXQgdGhlIGFsZ29yaXRobSBpZGVudGlmaWVycyBpbiBzZWN0aW9uIDQgc2hv dWxkIGJlIG1vcmUgc3BlY2lmaWMgKGUuZy4gJ0hTSUctTE1TJyksIGFzIHNob3VsZCB0aGUgQ09T RSByZWdpc3RyeSBlbnRyaWVzIGluIHNlY3Rpb24gNyAoZS5nLiBOYW1lOiBIQVNIU0lHLUxNUywg d2l0aCBjb3JyZXNwb25kaW5nIGV4cGFuZGVkIGRlc2NyaXB0aW9uKS4NCi0tIFRvbnkNCg0KRnJv bTogU3VpdCBbbWFpbHRvOnN1aXQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJ1c3Mg SG91c2xleQ0KU2VudDogMjEgSnVuZSAyMDE4IDIwOjQ0DQpUbzogRGF2ZSBUaGFsZXI7IEJyZW5k YW4gTW9yYW4NCkNjOiBzdWl0DQpTdWJqZWN0OiBSZTogW1N1aXRdIGRyYWZ0LWhvdXNsZXktc3Vp dC1jb3NlLWhhc2gtc2lnDQoNCkkgYW0gYWR2b2NhdGluZyBMTVMuIEkgdGhpbmsgaXQgd291bGQg YmUgYXBwcm9wcmlhdGUgZm9yIGFuIGFkdm9jYXRlIGZvciBYTVNTIHRvIHdyaXRlIGEgc2ltaWxh ciBkcmFmdCBmb3IgdGhhdCBhbGdvcml0aG0uDQoNClJ1c3MNCg0KDQoNCk9uIEp1biAyMSwgMjAx OCwgYXQgMTI6MDggUE0sIERhdmUgVGhhbGVyIDxkdGhhbGVyQG1pY3Jvc29mdC5jb208bWFpbHRv OmR0aGFsZXJAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KDQpUaGlzIGlzIHNpbWlsYXIgdG8gYSBx dWVzdGlvbiBJIGFza2VkIGFzIHdlbGwsIHdoZXRoZXIgdGhlIElFVEYgb25seSBuZWVkcyBMTVMg b3Igd2hldGhlciBMTVMgaXMganVzdCBhbiBpbnN0YW5jZSBpbiBhIGxhcmdlciBjbGFzcyB0aGF0 IG1pZ2h0IGJlIG5lZWRlZCwgYW5kIHdoYXQgdGhlIHNjb3BlIG9mIHRoZSBkcmFmdCBzaG91bGQg YmUuDQoNCklmIHRoZSBkcmFmdCBpcyBub3QgU1VJVC1vbmx5IChlLmcuLCBhbGxvd2luZyB1c2Ug aW4gT1NDT1JFLCBldGMuKSB0aGVuIGl0IHNvdW5kcyBsaWtlIHdlIG1pZ2h0IG5lZWQgdGhlIGFi aWxpdHkgdG8gc3VwcG9ydCBtb3JlIHRoYW4gTE1TIGZvciBzb21lIHVzZSBjYXNlcy4NCg0KRGF2 ZQ0KDQpGcm9tOiBTdWl0IDxzdWl0LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnN1aXQtYm91bmNl c0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBCcmVuZGFuIE1vcmFuDQpTZW50OiBUaHVyc2RheSwg SnVuZSAyMSwgMjAxOCA5OjAzIEFNDQpUbzogUnVzcyBIb3VzbGV5IDxob3VzbGV5QHZpZ2lsc2Vj LmNvbTxtYWlsdG86aG91c2xleUB2aWdpbHNlYy5jb20+Pg0KQ2M6IHN1aXQgPHN1aXRAaWV0Zi5v cmc8bWFpbHRvOnN1aXRAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtTdWl0XSBkcmFmdC1ob3Vz bGV5LXN1aXQtY29zZS1oYXNoLXNpZw0KDQpIaSBSdXNzLA0KVGhhbmtzIGZvciB0aGUgY2xhcmlm aWNhdGlvbi4gSSBhZ3JlZSB0aGF0IGEgbGFyZ2VyIHNpZ25hdHVyZSBpcyBub3Qgd2hhdCB3ZSBu ZWVkIGluIFNVSVQuIEhvd2V2ZXIsIGZvciB0aGUgQ09TRSBkcmFmdCwgd291bGQgaXQgbm90IG1h a2Ugc2Vuc2UgdG8gcHJvdmlkZSBmb3IgYm90aCBMTVMgYW5kIFhNU1M/IEkgZG9u4oCZdCBwcmV0 ZW5kIHRvIHVuZGVyc3RhbmQgYWxsIENPU0UgdXNlIGNhc2VzLg0KDQpUaGFua3MsDQpCcmVuZGFu DQoNCg0KDQpPbiAyMSBKdW4gMjAxOCwgYXQgMTY6NDMsIFJ1c3MgSG91c2xleSA8aG91c2xleUB2 aWdpbHNlYy5jb208bWFpbHRvOmhvdXNsZXlAdmlnaWxzZWMuY29tPj4gd3JvdGU6DQoNCkJyZW5k YW46DQoNClllcywgdGhlcmUgYXJlIHR3byBDRlJHIGFsZ29yaXRobXMgZm9yIGhhc2gtYmFzZWQg c2lnbmF0dXJlcy4gIEkgcHJlZmVyIHRoZSBvbmUgTWNHcmV3J3MgZG9jdW1lbnQsIG1vc3RseSBi ZWNhdXNlIGl0IGlzIG1vcmUgc3RyYWlnaHRmb3J3YXJkLiAgVGhlcmUgaXMgc29tZSBzcGVlZCBp bXByb3ZlbWVudCBmb3IgdGhlIGFkZGl0aW9uYWwgY29tcGxleGl0eSBpbiBYTVNTIGF0IHRoZSBj b3N0IG9mIGEgbGFyZ2VyIHNpZ25hdHVyZSB2YWx1ZS4gIFRvIG1lLCB0aGUgc3BlZWQgaW1wcm92 ZW1lbnQgaXMgbm90IGJpZyBlbm91Z2ggdG8ganVzdGlmeSB0aGUgbGFyZ2VyIHNpZ25hdHVyZSBz aXplLiAgWW91ciBtaWxlYWdlIG1heSB2YXJ5Lg0KDQpUaGlzIHBhcGVyIGRlc2NyaWJlcyB0aGUg ZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSB0d286DQoNCmh0dHBzOi8vZXByaW50LmlhY3Iub3JnLzIw MTcvMzQ5LnBkZjxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20v P3VybD1odHRwcyUzQSUyRiUyRmVwcmludC5pYWNyLm9yZyUyRjIwMTclMkYzNDkucGRmJmRhdGE9 MDIlN0MwMSU3Q2R0aGFsZXIlNDBtaWNyb3NvZnQuLmNvbSU3QzMwMmQwZjEwNjI2YjQ1NGE3MzIz MDhkNWQ3OTA3MzU5JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3 QzYzNjY1MTkzNzc3MTM4MzA5MiZzZGF0YT16REdxUjJOc2tqSnp5VlZjQ0VnOHN1UG8zTHQ5YjZ4 TEkxbHhhWWxXcmJRJTNEJnJlc2VydmVkPTA+DQoNClJ1c3MNCg0KDQoNCg0KT24gSnVuIDIxLCAy MDE4LCBhdCAxMToxMSBBTSwgQnJlbmRhbiBNb3JhbiA8QnJlbmRhbi5Nb3JhbkBhcm0uY29tPG1h aWx0bzpCcmVuZGFuLk1vcmFuQGFybS5jb20+PiB3cm90ZToNCg0KSSBzZWUgdGhhdCB0aGVyZSBh cmUgdHdvIGN1cnJlbnQgZHJhZnRzIGZvciBoYXNoLWJhc2VkIHNpZ25hdHVyZXM6DQpodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWNncmV3LWhhc2gtc2lncy0xMTxodHRwczovL25h MDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnRv b2xzLmlldGYub3JnJTJGaHRtbCUyRmRyYWZ0LW1jZ3Jldy1oYXNoLXNpZ3MtMTEmZGF0YT0wMiU3 QzAxJTdDZHRoYWxlciU0MG1pY3Jvc29mdC5jb20lN0MzMDJkMGYxMDYyNmI0NTRhNzMyMzA4ZDVk NzkwNzM1OSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY2 NTE5Mzc3NzEzOTMwOTcmc2RhdGE9Q1RSeDNCVzNkdVhJUkVZeFA0Q3lSJTJCUVk2M3FZZ2kydnFq blVNOXVLcVFNJTNEJnJlc2VydmVkPTA+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaXJ0Zi1jZnJnLXhtc3MtaGFzaC1iYXNlZC1zaWduYXR1cmVzLTEyPGh0dHBzOi8vbmEwMS5z YWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdG9vbHMu aWV0Zi5vcmclMkZodG1sJTJGZHJhZnQtaXJ0Zi1jZnJnLXhtc3MtaGFzaC1iYXNlZC1zaWduYXR1 cmVzLTEyJmRhdGE9MDIlN0MwMSU3Q2R0aGFsZXIlNDBtaWNyb3NvZnQuY29tJTdDMzAyZDBmMTA2 MjZiNDU0YTczMjMwOGQ1ZDc5MDczNTklN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0 NyU3QzElN0MwJTdDNjM2NjUxOTM3NzcxMzkzMDk3JnNkYXRhPXBpaSUyQm9hOFNrVHQ3UExhcnEw UCUyRktYTDRXQlZwTndMekdTSXhFZ1pHNVlVJTNEJnJlc2VydmVkPTA+DQoNCkkgc2VlIHRoYXQg eW91IGhhdmUgcmVmZXJlbmNlZCB0aGUgbWNncmV3IGRyYWZ0IHJhdGhlciB0aGFuIHRoZSBJUlRG L0NGUkcgZHJhZnQuIENvdWxkIHlvdSBwbGVhc2UgZXhwbGFpbiB3aGF0IHRoZSBkaWZmZXJlbmNl IGlzIGJldHdlZW4gdGhlc2UgdHdvIGRyYWZ0cyBhbmQgd2h5IHRoZSBtY2dyZXcgZHJhZnQgd2Fz IGEgYmV0dGVyIGNob2ljZSB0aGFuIFhNU1M/DQoNClRoYW5rcywNCkJyZW5kYW4NCg0KDQoNCg0K T24gMTMgSnVuIDIwMTgsIGF0IDIwOjAzLCBKaW0gU2NoYWFkIDxpZXRmQGF1Z3VzdGNlbGxhcnMu Y29tPG1haWx0bzppZXRmQGF1Z3VzdGNlbGxhcnMuY29tPj4gd3JvdGU6DQoNCg0KDQoNCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFN1aXQgPHN1aXQtYm91bmNlc0BpZXRmLm9y ZzxtYWlsdG86c3VpdC1ib3VuY2VzQGlldGYub3JnPj4gT24gQmVoYWxmIE9mIE1pY2hhZWwgUmlj aGFyZHNvbg0KU2VudDogV2VkbmVzZGF5LCBKdW5lIDEzLCAyMDE4IDExOjA5IEFNDQpUbzogc3Vp dCA8c3VpdEBpZXRmLm9yZzxtYWlsdG86c3VpdEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBbU3VpdF0g ZHJhZnQtaG91c2xleS1zdWl0LWNvc2UtaGFzaC1zaWcNCg0KDQpJIGhhdmUgcmVhZCB0aGUgLTAx IGRyYWZ0IHRvZGF5Lg0KSSBoYXZlIG5vdCByZWFkIFtIQVNIU0lHXSB5ZXQuDQpJIHRob3VnaHQg SSdkIHRyeSByZWFkaW5nIHRoaXMgZmlyc3QsIHRvIHNlZSB3aGF0IHF1ZXN0aW9ucyBJIGhhZC4N Cg0KSSBoYXZlIGltcGxlbWVudGVkIENPU0UgU2lnbjEgd2l0aCBFQ0RTQSBpbiBSdWJ5LCBzbyBJ IGhhdmUgYSBncmFzcCBvZg0Kd2hhdCB3ZSBhcmUgdHJ5aW5nIHRvIHBsdWcgaGFzaC1zaWcgKmlu dG8qLg0KDQoNClN1Z2dlc3Rpb25zOg0KMSkgd291bGQgdGhlIHN0cnVjdHVyZSBzaG93IGluIHNl Y3Rpb24gMyBiZSBlYXNpZXIgaWYgaXQgd2FzIGRlc2NyaWJlZCBieQ0KICBDRERMPyAgSSdtIHJh dGhlciB1bmNsZWFyIGFib3V0IHRoaXMuDQoNCk5vIC0gdGhpcyBhcmUgbm90IENCT1Igc3RydWN0 dXJlcyB0aGV5IGFyZSBwdXJlIGJpbmFyeSBzdHJpbmdzDQoNCg0KDQoNCjIpIEkgZGluJ3QgdW5k ZXJzdGFuZCBzZWN0aW9uIDQsIHdoZXJlIGl0IHNheXM6DQogICAgIG8gIElmIHRoZSAna2V5X29w cycgZmllbGQgaXMgcHJlc2VudCwgaXQgTVVTVCBpbmNsdWRlICdzaWduJyB3aGVuDQogICAgICAg ICAgICAgICAgY3JlYXRpbmcgYSBoYXNoLWJhc2VkIHNpZ25hdHVyZS4NCg0KICAgICBvICBJZiB0 aGUgJ2tleV9vcHMnIGZpZWxkIGlzIHByZXNlbnQsIGl0IE1VU1QgaW5jbHVkZSAndmVyaWZ5Jw0K ICAgICAgICAgICAgICAgIHdoZW4gdmVyaWZ5aW5nIGEgaGFzaC1iYXNlZCBzaWduYXR1cmUuDQoN CkNsZWFybHkgdGhpcyBpcyBub3Qgc29tZXRoaW5nIHRoYXQgdHJhdmVscyBvdmVyIHRoZSBuZXR3 b3JrLiAgSXMgdGhpcw0Kc29tZWhvdw0KDQoNCmluZGljYXRpbmcgaG93IHRvIHVuZGVyc3RhbmQg aWYgb25lIGlzIGRlYWxpbmcgYSBwdWJsaWMgKHZlcmlmeSkga2V5IG9yIGENCnByaXZhdGUNCg0K DQooc2lnbikga2V5Pw0KDQpUaGUga2V5X29wcyBmaWVsZCBjYW4gYmUgY29uc2lkZXJlZCB0byBw b3RlbnRpYWxseSBiZSB0cmFuc3BvcnRlZCBvdmVyIGENCm5ldHdvcmsuICBJdCBpcyBwYXJ0IG9m IHRoZSBDT1NFX0tleSBvYmplY3QgcmF0aGVyIHRoYW4gcGFydCBvZiB0aGUNCkNPU0VfU2lnbjEg b2JqZWN0Lg0KDQoNCg0KDQozKSB0aGUgdmFyaWF0aW9uczogTE1TX1NIQTI1Nl9NMzJfSDIwLCBh bmQgTE1PVFNfU0hBMjU2X04zMl9XMiwNCmV0Yy4gYXJlDQogIGxpc3RlZCwgYnV0IEkgZG9uJ3Qg a25vdyBpZiB0aGV5IG5lZWQgdG8gYmUgY2FycmllZCBpbiB0aGUgc2lnbmF0dXJlDQogIHN0cnVj dHVyZSBzb21laG93Lg0KDQpTZWUgdGhlIFtIQVNIU0lHXSBkcmFmdC4gIEl0IGlzIGVuY29kZWQg aW50byB0aGUgc2lnbmF0dXJlIHN0cnVjdHVyZSBhbmQgdGhlDQprZXkgdHlwZSBpcyBpbiB0aGUg cHVibGljIGtleSBzdHJ1Y3R1cmUuDQoNCg0KDQoNCjQpIEkgdGhvdWdodCB0aGF0IHBlcmhhcHMg d2UnZCBuZWVkIENCT1Igb3IgQ09TRSBzcGVjaWZpYyB3YXkgdG8gdHJhbnNwb3J0DQogIHRoZSBz aWduYXR1cmVzLiAgSSBndWVzcyBJIHNoYWxsIHJlYWQgSEFTSFNJRyB0byBmaW5kIG91dCB3aGF0 IHRoZQ0KICBzaWduYXR1cmVzIGxvb2sgbGlrZS4NCg0KV2UgaGF2ZSB0aGF0LiAgVGhpcyBpcyBs b29raW5nIGF0IGEgc2lnbmF0dXJlIGp1c3QgbGlrZSBFQ0RTQSB3b3VsZCBwcm9kdWNlLg0KVGhp cyBpcyBhIGRpZmZlcmVudCAiRUNEU0EiIHJlcGxhY2VtZW50Lg0KDQoNCg0KDQpJIHVuZGVyc3Rh bmQgZHJhZnQtbWNncmV3LWhhc2gtc2lncy0xMSBpcyBiZWluZyBhZHZhbmNlZCBieSBDRlJHLg0K SSBiZWxpZXZlIHRoYXQgU1VJVCBzaG91bGQgYWRvcHQgdGhpcyBkb2N1bWVudCwgYW5kIHNob3Vs ZCBkbyBzbyBpbiB0aGUNCmN1cnJlbnQgc3RhdGUuDQoNCkkgd291bGQgbGlrZSB0byBoYXZlIHNv bWUgZXhhbXBsZXMgaW4gQ0JPUi9DT1NFIHdvcmtlZCBvdXQgd2l0aCBwcml2YXRlDQprZXlzIGF2 YWlsYWJsZSBpbiB0aGUgYXBwZW5kaWNlcy4NCg0KQWx3YXlzIGEgZ29vZCB0aGluZyB0byBoYXZl Lg0KDQpKaW0NCg0KDQoNCg0KLS0NCl0gICAgICAgICAgICAgICBOZXZlciB0ZWxsIG1lIHRoZSBv ZGRzISAgICAgICAgICAgICAgICAgfCBpcHY2IG1lc2gNCm5ldHdvcmtzIFsNCg0KDQpdICAgTWlj aGFlbCBSaWNoYXJkc29uLCBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3MgICAgICAgIHwgbmV0d29y aw0KYXJjaGl0ZWN0ICBbDQoNCg0KXSAgICAgbWNyQHNhbmRlbG1hbi5jYTxtYWlsdG86bWNyQHNh bmRlbG1hbi5jYT4gIGh0dHA6Ly93d3cuc2FuZGVsbWFuLmNhLzxodHRwczovL25hMDEuc2FmZWxp bmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJGd3d3LnNhbmRlbG1h bi5jYSUyRiZkYXRhPTAyJTdDMDElN0NkdGhhbGVyJTQwbWljcm9zb2Z0LmNvbSU3QzMwMmQwZjEw NjI2YjQ1NGE3MzIzMDhkNWQ3OTA3MzU5JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRi NDclN0MxJTdDMCU3QzYzNjY1MTkzNzc3MTQwMzEwMiZzZGF0YT1NN1Rua205U3pGeTBJbUpUaUhS VEJWREdmaTNwUjF2Rml4TUNXc2tXbU9vJTNEJnJlc2VydmVkPTA+ICAgICAgICB8ICAgcnVieSBv biByYWlscw0KWw0KDQoNCg0KLS0NCk1pY2hhZWwgUmljaGFyZHNvbiA8bWNyK0lFVEZAc2FuZGVs bWFuLmNhPG1haWx0bzptY3IrSUVURkBzYW5kZWxtYW4uY2E+PiwgU2FuZGVsbWFuIFNvZnR3YXJl IFdvcmtzDQotPSBJUHY2IElvVCBjb25zdWx0aW5nID0tDQoNCg0KDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpTdWl0IG1haWxpbmcgbGlzdA0KU3Vp dEBpZXRmLm9yZzxtYWlsdG86U3VpdEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc3VpdDxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0 bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0 aW5mbyUyRnN1aXQmZGF0YT0wMiU3QzAxJTdDZHRoYWxlciU0MG1pY3Jvc29mdC5jb20lN0MzMDJk MGYxMDYyNmI0NTRhNzMyMzA4ZDVkNzkwNzM1OSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2Qw MTFkYjQ3JTdDMSU3QzAlN0M2MzY2NTE5Mzc3NzE0MDMxMDImc2RhdGE9QUtFempPWHRFJTJGUFNj JTJGYndLVVAwY3RDbVlOTDRDTFdOdUY5aGg3SXpPeEUlM0QmcmVzZXJ2ZWQ9MD4NCg0KSU1QT1JU QU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50 cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJl IG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1t ZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBl cnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3Jt YXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KDQoNCklNUE9SVEFOVCBOT1RJQ0U6IFRo ZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVu dGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVu ZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBk byBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBm b3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBt ZWRpdW0uIFRoYW5rIHlvdS4NCg0KCkR5c29uIFRlY2hub2xvZ3kgTGltaXRlZCwgY29tcGFueSBu dW1iZXIgMDE5NTkwOTAsIFRldGJ1cnkgSGlsbCwgTWFsbWVzYnVyeSwgU04xNiAwUlAsIFVLLgpU aGlzIG1lc3NhZ2UgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgYWRkcmVzc2VlIGFuZCBtYXkg Y29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24uIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgbWVzc2FnZSBpbiBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBk ZWxldGUgaXQsIGFuZCBkbyBub3QgdXNlLCBjb3B5IG9yIGRpc2Nsb3NlIHRoZSBpbmZvcm1hdGlv biBjb250YWluZWQgaW4gdGhpcyBtZXNzYWdlIG9yIGluIGFueSBhdHRhY2htZW50LgpEeXNvbiBt YXkgbW9uaXRvciBlbWFpbCB0cmFmZmljIGRhdGEgYW5kIGNvbnRlbnQgZm9yIHNlY3VyaXR5ICYg dHJhaW5pbmcuCg== --_000_140080C241BAA1419B58F093108F9EDC1E0D1690UKMALMBOX01dyso_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6dGF4PSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL3NoYXJlcG9pbnQvdGF4b25vbXkvc29hcC8iIHhtbG5zOnRucz0iaHR0cDovL3NjaGVt YXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvcmVjb3Jkc3JlcG9zaXRvcnkvIiB4bWxu czpzcHN1cD0iaHR0cDovL21pY3Jvc29mdC5jb20vd2Vic2VydmljZXMvU2hhcmVQb2ludFBvcnRh bFNlcnZlci9Vc2VyUHJvZmlsZVNlcnZpY2UiIHhtbG5zOm1tbD0iaHR0cDovL3d3dy53My5vcmcv MTk5OC9NYXRoL01hdGhNTCIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9y Zy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBl IiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJh dG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5 bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAyIDIgMiAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAyIDIgMiAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBh bm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpw Lk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBs ZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3Jh cDogYnJlYWstd29yZDstd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7bGluZS1icmVhazphZnRlci13 aGl0ZS1zcGFjZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5BcyBmYXIgYXMgSSBjYW4gdGVsbCwg aXQgaXMgbm90IHBvc3NpYmxlIHRvIHRlbGwgZnJvbSB0aGUgc2lnbmF0dXJlIHdoZXRoZXIgaXQg aXMgTE1TIG9yIFhNU1MgKG9yIGluZGVlZCBhbnkgb3RoZXIgaGFzaC1iYXNlZCBzaWduYXR1cmUg c2NoZW1lKS4gSWYgdGhpcyBpcyB0aGUgY2FzZSwgdGhlbg0KIEkgc3VnZ2VzdCB0aGF0IHRoZSBh bGdvcml0aG0gaWRlbnRpZmllcnMgaW4gc2VjdGlvbiA0IHNob3VsZCBiZSBtb3JlIHNwZWNpZmlj IChlLmcuICdIU0lHLUxNUycpLCBhcyBzaG91bGQgdGhlIENPU0UgcmVnaXN0cnkgZW50cmllcyBp biBzZWN0aW9uIDcgKGUuZy4gTmFtZTogSEFTSFNJRy1MTVMsIHdpdGggY29ycmVzcG9uZGluZyBl eHBhbmRlZCBkZXNjcmlwdGlvbikuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4tLSBUb255PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNt IDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4gU3VpdCBbbWFpbHRvOnN1aXQtYm91bmNlc0BpZXRmLm9yZ10N CjxiPk9uIEJlaGFsZiBPZiA8L2I+UnVzcyBIb3VzbGV5PGJyPg0KPGI+U2VudDo8L2I+IDIxIEp1 bmUgMjAxOCAyMDo0NDxicj4NCjxiPlRvOjwvYj4gRGF2ZSBUaGFsZXI7IEJyZW5kYW4gTW9yYW48 YnI+DQo8Yj5DYzo8L2I+IHN1aXQ8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtTdWl0XSBkcmFm dC1ob3VzbGV5LXN1aXQtY29zZS1oYXNoLXNpZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkkgYW0gYWR2b2NhdGluZyBMTVMuIEkgdGhpbmsgaXQgd291bGQg YmUgYXBwcm9wcmlhdGUgZm9yIGFuIGFkdm9jYXRlIGZvciBYTVNTIHRvIHdyaXRlIGEgc2ltaWxh ciBkcmFmdCBmb3IgdGhhdCBhbGdvcml0aG0uPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5SdXNzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBKdW4gMjEsIDIwMTgsIGF0IDEyOjA4IFBNLCBEYXZlIFRoYWxlciAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmR0aGFsZXJAbWljcm9zb2Z0LmNvbSI+ZHRoYWxlckBtaWNyb3NvZnQu Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhpcyBp cyBzaW1pbGFyIHRvIGEgcXVlc3Rpb24gSSBhc2tlZCBhcyB3ZWxsLCB3aGV0aGVyIHRoZSBJRVRG IG9ubHkgbmVlZHMgTE1TIG9yIHdoZXRoZXIgTE1TIGlzIGp1c3QgYW4gaW5zdGFuY2UgaW4gYSBs YXJnZXIgY2xhc3MgdGhhdCBtaWdodCBiZSBuZWVkZWQsIGFuZA0KIHdoYXQgdGhlIHNjb3BlIG9m IHRoZSBkcmFmdCBzaG91bGQgYmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5JZiB0aGUgZHJhZnQgaXMgbm90IFNVSVQtb25seSAoZS5nLiwgYWxsb3dpbmcgdXNlIGlu IE9TQ09SRSwgZXRjLikgdGhlbiBpdCBzb3VuZHMgbGlrZSB3ZSBtaWdodCBuZWVkIHRoZSBhYmls aXR5IHRvIHN1cHBvcnQgbW9yZSB0aGFuIExNUyBmb3Igc29tZSB1c2UgY2FzZXMuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5EYXZlPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0Ux RTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5TdWl0DQogJmx0OzxhIGhyZWY9Im1haWx0bzpzdWl0LWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFu IHN0eWxlPSJjb2xvcjpwdXJwbGUiPnN1aXQtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+Jmd0 OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48Yj5PbiBC ZWhhbGYgT2Y8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PC9iPkJyZW5kYW4gTW9yYW48YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+VGh1cnNkYXksIEp1bmUgMjEsIDIwMTggOTowMyBB TTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+UnVzcyBIb3VzbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86aG91c2xleUB2aWdpbHNl Yy5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmhvdXNsZXlAdmlnaWxzZWMuY29tPC9z cGFuPjwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj5zdWl0ICZsdDs8YSBocmVmPSJtYWlsdG86c3VpdEBpZXRmLm9y ZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+c3VpdEBpZXRmLm9yZzwvc3Bhbj48L2E+Jmd0 Ozxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj5SZTogW1N1aXRdIGRyYWZ0LWhvdXNsZXktc3VpdC1jb3NlLWhhc2gtc2ln PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgUnVzcyw8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIGZvciB0aGUgY2xhcmlmaWNhdGlvbi4gSSBh Z3JlZSB0aGF0IGEgbGFyZ2VyIHNpZ25hdHVyZSBpcyBub3Qgd2hhdCB3ZSBuZWVkIGluIFNVSVQu IEhvd2V2ZXIsIGZvciB0aGUgQ09TRSBkcmFmdCwgd291bGQgaXQgbm90IG1ha2Ugc2Vuc2UgdG8g cHJvdmlkZSBmb3IgYm90aCBMTVMgYW5kIFhNU1M/IEkgZG9u4oCZdCBwcmV0ZW5kIHRvIHVuZGVy c3RhbmQgYWxsIENPU0UgdXNlIGNhc2VzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFu a3MsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5CcmVuZGFuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAyMSBKdW4g MjAxOCwgYXQgMTY6NDMsIFJ1c3MgSG91c2xleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhvdXNsZXlA dmlnaWxzZWMuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5ob3VzbGV5QHZpZ2lsc2Vj LmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJyZW5kYW46PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+WWVzLCB0aGVyZSBhcmUgdHdvIENGUkcgYWxnb3JpdGhtcyBmb3IgaGFzaC1iYXNl ZCBzaWduYXR1cmVzLiAmbmJzcDtJIHByZWZlciB0aGUgb25lIE1jR3JldydzIGRvY3VtZW50LCBt b3N0bHkgYmVjYXVzZSBpdCBpcyBtb3JlIHN0cmFpZ2h0Zm9yd2FyZC4gJm5ic3A7VGhlcmUgaXMg c29tZSBzcGVlZCBpbXByb3ZlbWVudCBmb3IgdGhlIGFkZGl0aW9uYWwgY29tcGxleGl0eSBpbiBY TVNTIGF0IHRoZSBjb3N0IG9mIGEgbGFyZ2VyDQogc2lnbmF0dXJlIHZhbHVlLiAmbmJzcDtUbyBt ZSwgdGhlIHNwZWVkIGltcHJvdmVtZW50IGlzIG5vdCBiaWcgZW5vdWdoIHRvIGp1c3RpZnkgdGhl IGxhcmdlciBzaWduYXR1cmUgc2l6ZS4gJm5ic3A7WW91ciBtaWxlYWdlIG1heSB2YXJ5LjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIHBhcGVyIGRlc2NyaWJlcyB0aGUgZGlmZmVyZW5j ZSBiZXR3ZWVuIHRoZSB0d286PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0 dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNB JTJGJTJGZXByaW50LmlhY3Iub3JnJTJGMjAxNyUyRjM0OS5wZGYmYW1wO2RhdGE9MDIlN0MwMSU3 Q2R0aGFsZXIlNDBtaWNyb3NvZnQuLmNvbSU3QzMwMmQwZjEwNjI2YjQ1NGE3MzIzMDhkNWQ3OTA3 MzU5JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjY1MTkz Nzc3MTM4MzA5MiZhbXA7c2RhdGE9ekRHcVIyTnNrakp6eVZWY0NFZzhzdVBvM0x0OWI2eExJMWx4 YVlsV3JiUSUzRCZhbXA7cmVzZXJ2ZWQ9MCI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0 cHM6Ly9lcHJpbnQuaWFjci5vcmcvMjAxNy8zNDkucGRmPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+UnVzczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0K PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBKdW4gMjEsIDIwMTgsIGF0IDExOjExIEFNLCBCcmVuZGFuIE1vcmFuICZsdDs8YSBo cmVmPSJtYWlsdG86QnJlbmRhbi5Nb3JhbkBhcm0uY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVy cGxlIj5CcmVuZGFuLk1vcmFuQGFybS5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SSBzZWUgdGhhdCB0aGVyZSBhcmUgdHdvIGN1cnJlbnQgZHJhZnRz IGZvciBoYXNoLWJhc2VkIHNpZ25hdHVyZXM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL25h MDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnRv b2xzLmlldGYub3JnJTJGaHRtbCUyRmRyYWZ0LW1jZ3Jldy1oYXNoLXNpZ3MtMTEmYW1wO2RhdGE9 MDIlN0MwMSU3Q2R0aGFsZXIlNDBtaWNyb3NvZnQuY29tJTdDMzAyZDBmMTA2MjZiNDU0YTczMjMw OGQ1ZDc5MDczNTklN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdD NjM2NjUxOTM3NzcxMzkzMDk3JmFtcDtzZGF0YT1DVFJ4M0JXM2R1WElSRVl4UDRDeVIlMkJRWTYz cVlnaTJ2cWpuVU05dUtxUU0lM0QmYW1wO3Jlc2VydmVkPTAiPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tY2dyZXctaGFzaC1zaWdz LTExPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3Mu cHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdG9vbHMuaWV0Zi5vcmcl MkZodG1sJTJGZHJhZnQtaXJ0Zi1jZnJnLXhtc3MtaGFzaC1iYXNlZC1zaWduYXR1cmVzLTEyJmFt cDtkYXRhPTAyJTdDMDElN0NkdGhhbGVyJTQwbWljcm9zb2Z0LmNvbSU3QzMwMmQwZjEwNjI2YjQ1 NGE3MzIzMDhkNWQ3OTA3MzU5JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0Mx JTdDMCU3QzYzNjY1MTkzNzc3MTM5MzA5NyZhbXA7c2RhdGE9cGlpJTJCb2E4U2tUdDdQTGFycTBQ JTJGS1hMNFdCVnBOd0x6R1NJeEVnWkc1WVUlM0QmYW1wO3Jlc2VydmVkPTAiPjxzcGFuIHN0eWxl PSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pcnRmLWNm cmcteG1zcy1oYXNoLWJhc2VkLXNpZ25hdHVyZXMtMTI8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIHNlZSB0aGF0IHlvdSBoYXZlIHJlZmVyZW5jZWQgdGhlIG1jZ3JldyBk cmFmdCByYXRoZXIgdGhhbiB0aGUgSVJURi9DRlJHIGRyYWZ0LiBDb3VsZCB5b3UgcGxlYXNlIGV4 cGxhaW4gd2hhdCB0aGUgZGlmZmVyZW5jZSBpcyBiZXR3ZWVuIHRoZXNlIHR3byBkcmFmdHMgYW5k IHdoeSB0aGUgbWNncmV3IGRyYWZ0IHdhcyBhIGJldHRlciBjaG9pY2UgdGhhbiBYTVNTPzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CcmVuZGFuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMTMgSnVu IDIwMTgsIGF0IDIwOjAzLCBKaW0gU2NoYWFkICZsdDs8YSBocmVmPSJtYWlsdG86aWV0ZkBhdWd1 c3RjZWxsYXJzLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aWV0ZkBhdWd1c3RjZWxs YXJzLmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IFN1 aXQgJmx0OzxhIGhyZWY9Im1haWx0bzpzdWl0LWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxl PSJjb2xvcjpwdXJwbGUiPnN1aXQtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+Jmd0OyBPbiBC ZWhhbGYgT2YgTWljaGFlbCBSaWNoYXJkc29uPGJyPg0KU2VudDogV2VkbmVzZGF5LCBKdW5lIDEz LCAyMDE4IDExOjA5IEFNPGJyPg0KVG86IHN1aXQgJmx0OzxhIGhyZWY9Im1haWx0bzpzdWl0QGll dGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5zdWl0QGlldGYub3JnPC9zcGFuPjwv YT4mZ3Q7PGJyPg0KU3ViamVjdDogW1N1aXRdIGRyYWZ0LWhvdXNsZXktc3VpdC1jb3NlLWhhc2gt c2lnPGJyPg0KPGJyPg0KPGJyPg0KSSBoYXZlIHJlYWQgdGhlIC0wMSBkcmFmdCB0b2RheS48YnI+ DQpJIGhhdmUgbm90IHJlYWQgW0hBU0hTSUddIHlldC48YnI+DQpJIHRob3VnaHQgSSdkIHRyeSBy ZWFkaW5nIHRoaXMgZmlyc3QsIHRvIHNlZSB3aGF0IHF1ZXN0aW9ucyBJIGhhZC48YnI+DQo8YnI+ DQpJIGhhdmUgaW1wbGVtZW50ZWQgQ09TRSBTaWduMSB3aXRoIEVDRFNBIGluIFJ1YnksIHNvIEkg aGF2ZSBhIGdyYXNwIG9mPGJyPg0Kd2hhdCB3ZSBhcmUgdHJ5aW5nIHRvIHBsdWcgaGFzaC1zaWcg KmludG8qLjxicj4NCjxicj4NCjxicj4NClN1Z2dlc3Rpb25zOjxicj4NCjEpIHdvdWxkIHRoZSBz dHJ1Y3R1cmUgc2hvdyBpbiBzZWN0aW9uIDMgYmUgZWFzaWVyIGlmIGl0IHdhcyBkZXNjcmliZWQg Ynk8YnI+DQombmJzcDsmbmJzcDtDRERMPyAmbmJzcDtJJ20gcmF0aGVyIHVuY2xlYXIgYWJvdXQg dGhpcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+ DQpObyAtIHRoaXMgYXJlIG5vdCBDQk9SIHN0cnVjdHVyZXMgdGhleSBhcmUgcHVyZSBiaW5hcnkg c3RyaW5nczxicj4NCjxicj4NCjxicj4NCjxicj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+PGJyPg0KMikgSSBkaW4ndCB1bmRlcnN0YW5kIHNlY3Rpb24gNCwgd2hlcmUgaXQg c2F5czo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtvICZuYnNwO0lmIHRoZSAn a2V5X29wcycgZmllbGQgaXMgcHJlc2VudCwgaXQgTVVTVCBpbmNsdWRlICdzaWduJyB3aGVuPGJy Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Y3JlYXRpbmcgYSBoYXNo LWJhc2VkIHNpZ25hdHVyZS48YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDtvICZuYnNwO0lmIHRoZSAna2V5X29wcycgZmllbGQgaXMgcHJlc2VudCwgaXQgTVVTVCBpbmNs dWRlICd2ZXJpZnknPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 d2hlbiB2ZXJpZnlpbmcgYSBoYXNoLWJhc2VkIHNpZ25hdHVyZS48YnI+DQo8YnI+DQpDbGVhcmx5 IHRoaXMgaXMgbm90IHNvbWV0aGluZyB0aGF0IHRyYXZlbHMgb3ZlciB0aGUgbmV0d29yay4gJm5i c3A7SXMgdGhpczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PnNvbWVob3c8YnI+DQo8YnI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPmluZGljYXRpbmcgaG93IHRvIHVuZGVyc3RhbmQgaWYgb25lIGlzIGRlYWxpbmcgYSBwdWJs aWMgKHZlcmlmeSkga2V5IG9yIGE8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5wcml2YXRlPGJyPg0KPGJyPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4oc2lnbikga2V5Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPjxicj4NClRoZSBrZXlfb3BzIGZpZWxkIGNhbiBiZSBjb25zaWRlcmVk IHRvIHBvdGVudGlhbGx5IGJlIHRyYW5zcG9ydGVkIG92ZXIgYTxicj4NCm5ldHdvcmsuICZuYnNw O0l0IGlzIHBhcnQgb2YgdGhlIENPU0VfS2V5IG9iamVjdCByYXRoZXIgdGhhbiBwYXJ0IG9mIHRo ZTxicj4NCkNPU0VfU2lnbjEgb2JqZWN0Ljxicj4NCjxicj4NCjxicj4NCjxicj4NCjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KMykgdGhlIHZhcmlhdGlvbnM6IExNU19T SEEyNTZfTTMyX0gyMCwgYW5kIExNT1RTX1NIQTI1Nl9OMzJfVzIsPGJyPg0KZXRjLiBhcmU8YnI+ DQombmJzcDsmbmJzcDtsaXN0ZWQsIGJ1dCBJIGRvbid0IGtub3cgaWYgdGhleSBuZWVkIHRvIGJl IGNhcnJpZWQgaW4gdGhlIHNpZ25hdHVyZTxicj4NCiZuYnNwOyZuYnNwO3N0cnVjdHVyZSBzb21l aG93Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4N ClNlZSB0aGUgW0hBU0hTSUddIGRyYWZ0LiAmbmJzcDtJdCBpcyBlbmNvZGVkIGludG8gdGhlIHNp Z25hdHVyZSBzdHJ1Y3R1cmUgYW5kIHRoZTxicj4NCmtleSB0eXBlIGlzIGluIHRoZSBwdWJsaWMg a2V5IHN0cnVjdHVyZS48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPjxicj4NCjQpIEkgdGhvdWdodCB0aGF0IHBlcmhhcHMgd2UnZCBuZWVk IENCT1Igb3IgQ09TRSBzcGVjaWZpYyB3YXkgdG8gdHJhbnNwb3J0PGJyPg0KJm5ic3A7Jm5ic3A7 dGhlIHNpZ25hdHVyZXMuICZuYnNwO0kgZ3Vlc3MgSSBzaGFsbCByZWFkIEhBU0hTSUcgdG8gZmlu ZCBvdXQgd2hhdCB0aGU8YnI+DQombmJzcDsmbmJzcDtzaWduYXR1cmVzIGxvb2sgbGlrZS48L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQpXZSBoYXZl IHRoYXQuICZuYnNwO1RoaXMgaXMgbG9va2luZyBhdCBhIHNpZ25hdHVyZSBqdXN0IGxpa2UgRUNE U0Egd291bGQgcHJvZHVjZS48YnI+DQpUaGlzIGlzIGEgZGlmZmVyZW50ICZxdW90O0VDRFNBJnF1 b3Q7IHJlcGxhY2VtZW50Ljxicj4NCjxicj4NCjxicj4NCjxicj4NCjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KSSB1bmRlcnN0YW5kIGRyYWZ0LW1jZ3Jldy1oYXNoLXNp Z3MtMTEgaXMgYmVpbmcgYWR2YW5jZWQgYnkgQ0ZSRy48YnI+DQpJIGJlbGlldmUgdGhhdCBTVUlU IHNob3VsZCBhZG9wdCB0aGlzIGRvY3VtZW50LCBhbmQgc2hvdWxkIGRvIHNvIGluIHRoZTxicj4N CmN1cnJlbnQgc3RhdGUuPGJyPg0KPGJyPg0KSSB3b3VsZCBsaWtlIHRvIGhhdmUgc29tZSBleGFt cGxlcyBpbiBDQk9SL0NPU0Ugd29ya2VkIG91dCB3aXRoIHByaXZhdGU8YnI+DQprZXlzIGF2YWls YWJsZSBpbiB0aGUgYXBwZW5kaWNlcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij48YnI+DQpBbHdheXMgYSBnb29kIHRoaW5nIHRvIGhhdmUuPGJyPg0KPGJy Pg0KSmltPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij48YnI+DQotLTxicj4NCl0gJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7TmV2ZXIg dGVsbCBtZSB0aGUgb2RkcyEgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 fCBpcHY2IG1lc2g8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5uZXR3b3JrcyBbPGJyPg0KPGJyPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5dICZuYnNwOyZuYnNwO01pY2hhZWwgUmljaGFyZHNvbiwgU2FuZGVsbWFuIFNvZnR3 YXJlIFdvcmtzICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wgbmV0 d29yazwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmFyY2hp dGVjdCAmbmJzcDtbPGJyPg0KPGJyPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5dICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9Im1haWx0bzptY3JAc2Fu ZGVsbWFuLmNhIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tY3JAc2FuZGVsbWFuLmNhPC9z cGFuPjwvYT48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2su Y29tLz91cmw9aHR0cCUzQSUyRiUyRnd3dy5zYW5kZWxtYW4uY2ElMkYmYW1wO2RhdGE9MDIlN0Mw MSU3Q2R0aGFsZXIlNDBtaWNyb3NvZnQuY29tJTdDMzAyZDBmMTA2MjZiNDU0YTczMjMwOGQ1ZDc5 MDczNTklN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2NjUx OTM3NzcxNDAzMTAyJmFtcDtzZGF0YT1NN1Rua205U3pGeTBJbUpUaUhSVEJWREdmaTNwUjF2Rml4 TUNXc2tXbU9vJTNEJmFtcDtyZXNlcnZlZD0wIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5o dHRwOi8vd3d3LnNhbmRlbG1hbi5jYS88L3NwYW4+PC9hPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDt8DQogJm5ic3A7Jm5ic3A7cnVieSBvbiByYWlsczwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPls8YnI+DQo8YnI+DQo8YnI+DQo8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQot LTxicj4NCk1pY2hhZWwgUmljaGFyZHNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1jciYjNDM7SUVU RkBzYW5kZWxtYW4uY2EiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1jciYjNDM7SUVURkBz YW5kZWxtYW4uY2E8L3NwYW4+PC9hPiZndDssIFNhbmRlbG1hbiBTb2Z0d2FyZSBXb3Jrczxicj4N Ci09IElQdjYgSW9UIGNvbnN1bHRpbmcgPS08YnI+DQo8YnI+DQo8YnI+DQo8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpTdWl0IG1haWxpbmcgbGlzdDxicj4N CjxhIGhyZWY9Im1haWx0bzpTdWl0QGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl Ij5TdWl0QGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL25hMDEuc2Fm ZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRm Lm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnN1aXQmYW1wO2RhdGE9MDIlN0MwMSU3Q2R0aGFs ZXIlNDBtaWNyb3NvZnQuY29tJTdDMzAyZDBmMTA2MjZiNDU0YTczMjMwOGQ1ZDc5MDczNTklN0M3 MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2NjUxOTM3NzcxNDAz MTAyJmFtcDtzZGF0YT1BS0V6ak9YdEUlMkZQU2MlMkZid0tVUDBjdENtWU5MNENMV051RjloaDdJ ek94RSUzRCZhbXA7cmVzZXJ2ZWQ9MCI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdWl0PC9zcGFuPjwvYT48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JTVBPUlRB TlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRz IGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUg bm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1l ZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVy c29uLA0KIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9y bWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwg YW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2 aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90 aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVu dHMgdG8gYW55IG90aGVyIHBlcnNvbiwNCiB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9y ZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YnI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxM3B4OyI+DQpEeXNvbiBUZWNobm9sb2d5IExpbWl0ZWQsIGNvbXBhbnkgbnVt YmVyIDAxOTU5MDkwLCBUZXRidXJ5IEhpbGwsIE1hbG1lc2J1cnksIFNOMTYgMFJQLCBVSy4NCjxi cj4NClRoaXMgbWVzc2FnZSBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRyZXNzZWUgYW5k IG1heSBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbi4gSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBtZXNzYWdlIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVu dGx5IGRlbGV0ZSBpdCwgYW5kIGRvIG5vdCB1c2UsIGNvcHkgb3IgZGlzY2xvc2UgdGhlIGluZm9y bWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1lc3NhZ2Ugb3IgaW4gYW55IGF0dGFjaG1lbnQuDQo8 YnI+DQpEeXNvbiBtYXkgbW9uaXRvciBlbWFpbCB0cmFmZmljIGRhdGEgYW5kIGNvbnRlbnQgZm9y IHNlY3VyaXR5ICZhbXA7IHRyYWluaW5nLg0KPC9zcGFuPjwvYm9keT4NCjwvaHRtbD4NCg== --_000_140080C241BAA1419B58F093108F9EDC1E0D1690UKMALMBOX01dyso_-- From nobody Fri Jun 22 02:17:44 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FAC1130E15 for ; Fri, 22 Jun 2018 02:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhh5lu2H_x6M for ; Fri, 22 Jun 2018 02:17:39 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50C5F130E0E for ; Fri, 22 Jun 2018 02:17:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id F152E300A01 for ; Fri, 22 Jun 2018 05:17:36 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id mrAdOFRsy4fp for ; Fri, 22 Jun 2018 05:17:34 -0400 (EDT) Received: from [5.5.33.206] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id AF23F3004B7; Fri, 22 Jun 2018 05:17:33 -0400 (EDT) From: Russ Housley Message-Id: <18F16995-D6BF-4C68-9E93-B1CF93D4369D@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_2E7F704E-9956-4A96-940F-EB2A3CD8AFC7" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Fri, 22 Jun 2018 05:17:33 -0400 In-Reply-To: <140080C241BAA1419B58F093108F9EDC1E0D1690@UK-MAL-MBOX-01.dyson.global.corp> Cc: suit To: Tony Putman References: <31676.1528913351@localhost> <04f401d40349$33a58b10$9af0a130$@augustcellars.com> <0CDB8D05-0214-4749-9907-5A1B0B4A2191@arm.com> <697B1DC9-B1DE-48BA-ADC6-EF936208AFCE@vigilsec.com> <9906B2BC-BFC2-4F83-A0F6-FFCC81912237@arm.com> <140080C241BAA1419B58F093108F9EDC1E0D1690@UK-MAL-MBOX-01.dyson.global.corp> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Suit] draft-housley-suit-cose-hash-sig X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 09:17:43 -0000 --Apple-Mail=_2E7F704E-9956-4A96-940F-EB2A3CD8AFC7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I was assuming that LMS would use "HASHSIG", and XMSS would use "XMSS". = These labels align with the Internet-Draft file names. In the long run, = your suggestion is probably better. Russ > On Jun 22, 2018, at 4:13 AM, Tony Putman = wrote: >=20 > As far as I can tell, it is not possible to tell from the signature = whether it is LMS or XMSS (or indeed any other hash-based signature = scheme). If this is the case, then I suggest that the algorithm = identifiers in section 4 should be more specific (e.g. 'HSIG-LMS'), as = should the COSE registry entries in section 7 (e.g. Name: HASHSIG-LMS, = with corresponding expanded description). > -- Tony > =20 > From: Suit [mailto:suit-bounces@ietf.org = ] On Behalf Of Russ Housley > Sent: 21 June 2018 20:44 > To: Dave Thaler; Brendan Moran > Cc: suit > Subject: Re: [Suit] draft-housley-suit-cose-hash-sig > =20 > I am advocating LMS. I think it would be appropriate for an advocate = for XMSS to write a similar draft for that algorithm. > =20 > Russ > =20 >=20 >=20 > On Jun 21, 2018, at 12:08 PM, Dave Thaler > wrote: > =20 > This is similar to a question I asked as well, whether the IETF only = needs LMS or whether LMS is just an instance in a larger class that = might be needed, and what the scope of the draft should be. > =20 > If the draft is not SUIT-only (e.g., allowing use in OSCORE, etc.) = then it sounds like we might need the ability to support more than LMS = for some use cases. > =20 > Dave > =20 > From: Suit > On = Behalf Of Brendan Moran > Sent: Thursday, June 21, 2018 9:03 AM > To: Russ Housley > > Cc: suit > > Subject: Re: [Suit] draft-housley-suit-cose-hash-sig > =20 > Hi Russ,=20 > Thanks for the clarification. I agree that a larger signature is not = what we need in SUIT. However, for the COSE draft, would it not make = sense to provide for both LMS and XMSS? I don=E2=80=99t pretend to = understand all COSE use cases. > =20 > Thanks, > Brendan >=20 >=20 >=20 > On 21 Jun 2018, at 16:43, Russ Housley > wrote: > =20 > Brendan:=20 > =20 > Yes, there are two CFRG algorithms for hash-based signatures. I = prefer the one McGrew's document, mostly because it is more = straightforward. There is some speed improvement for the additional = complexity in XMSS at the cost of a larger signature value. To me, the = speed improvement is not big enough to justify the larger signature = size. Your mileage may vary. > =20 > This paper describes the difference between the two: > =20 > https://eprint.iacr.org/2017/349.pdf = > =20 > Russ > =20 >=20 >=20 >=20 > On Jun 21, 2018, at 11:11 AM, Brendan Moran > wrote: > =20 > I see that there are two current drafts for hash-based signatures: > https://tools.ietf.org/html/draft-mcgrew-hash-sigs-11 = > = https://tools.ietf.org/html/draft-irtf-cfrg-xmss-hash-based-signatures-12 = > =20 > I see that you have referenced the mcgrew draft rather than the = IRTF/CFRG draft. Could you please explain what the difference is between = these two drafts and why the mcgrew draft was a better choice than XMSS? > =20 > Thanks, > Brendan > =20 >=20 >=20 >=20 > On 13 Jun 2018, at 20:03, Jim Schaad > wrote: > =20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Suit > On = Behalf Of Michael Richardson > Sent: Wednesday, June 13, 2018 11:09 AM > To: suit > > Subject: [Suit] draft-housley-suit-cose-hash-sig >=20 >=20 > I have read the -01 draft today. > I have not read [HASHSIG] yet. > I thought I'd try reading this first, to see what questions I had. >=20 > I have implemented COSE Sign1 with ECDSA in Ruby, so I have a grasp of > what we are trying to plug hash-sig *into*. >=20 >=20 > Suggestions: > 1) would the structure show in section 3 be easier if it was described = by > CDDL? I'm rather unclear about this. >=20 > No - this are not CBOR structures they are pure binary strings >=20 >=20 >=20 >=20 > 2) I din't understand section 4, where it says: > o If the 'key_ops' field is present, it MUST include 'sign' when > creating a hash-based signature. >=20 > o If the 'key_ops' field is present, it MUST include 'verify' > when verifying a hash-based signature. >=20 > Clearly this is not something that travels over the network. Is this > somehow >=20 >=20 > indicating how to understand if one is dealing a public (verify) key = or a > private >=20 >=20 > (sign) key? >=20 > The key_ops field can be considered to potentially be transported over = a > network. It is part of the COSE_Key object rather than part of the > COSE_Sign1 object. >=20 >=20 >=20 >=20 > 3) the variations: LMS_SHA256_M32_H20, and LMOTS_SHA256_N32_W2, > etc. are > listed, but I don't know if they need to be carried in the signature > structure somehow. >=20 > See the [HASHSIG] draft. It is encoded into the signature structure = and the > key type is in the public key structure. >=20 >=20 >=20 >=20 > 4) I thought that perhaps we'd need CBOR or COSE specific way to = transport > the signatures. I guess I shall read HASHSIG to find out what the > signatures look like. >=20 > We have that. This is looking at a signature just like ECDSA would = produce. > This is a different "ECDSA" replacement. >=20 >=20 >=20 >=20 > I understand draft-mcgrew-hash-sigs-11 is being advanced by CFRG. > I believe that SUIT should adopt this document, and should do so in = the > current state. >=20 > I would like to have some examples in CBOR/COSE worked out with = private > keys available in the appendices. >=20 > Always a good thing to have. >=20 > Jim >=20 >=20 >=20 >=20 > -- > ] Never tell me the odds! | ipv6 mesh > networks [ >=20 >=20 > ] Michael Richardson, Sandelman Software Works | network > architect [ >=20 >=20 > ] mcr@sandelman.ca = http://www.sandelman.ca/ = = | ruby on rails > [ >=20 >=20 >=20 > -- > Michael Richardson >, Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Suit mailing list > Suit@ietf.org > https://www.ietf.org/mailman/listinfo/suit = > =20 > IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy = the information in any medium. Thank you. > =20 > =20 > IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy = the information in any medium. Thank you. > =20 >=20 > Dyson Technology Limited, company number 01959090, Tetbury Hill, = Malmesbury, SN16 0RP, UK.=20 > This message is intended solely for the addressee and may contain = confidential information. If you have received this message in error, = please immediately and permanently delete it, and do not use, copy or = disclose the information contained in this message or in any attachment.=20= > Dyson may monitor email traffic data and content for security & = training. --Apple-Mail=_2E7F704E-9956-4A96-940F-EB2A3CD8AFC7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = was assuming that LMS would use "HASHSIG", and XMSS would use "XMSS". =  These labels align with the Internet-Draft file names.  In = the long run, your suggestion is probably better.

Russ


On Jun 22, 2018, at 4:13 AM, Tony Putman <Tony.Putman@dyson.com> wrote:

As far as I can tell, it is not possible to tell = from the signature whether it is LMS or XMSS (or indeed any other = hash-based signature scheme). If this is the case, then I suggest that = the algorithm identifiers in section 4 should be more specific (e.g. = 'HSIG-LMS'), as should the COSE registry entries in section 7 (e.g. = Name: HASHSIG-LMS, with corresponding expanded description).
-- Tony
 
From: Suit [mailto:suit-bounces@ietf.org] On Behalf = Of Russ Housley
Sent: 21 June 2018 20:44
To: Dave Thaler; Brendan = Moran
Cc: suit
Subject: Re: [Suit] = draft-housley-suit-cose-hash-sig
 
I am advocating LMS. I think it would be = appropriate for an advocate for XMSS to write a similar draft for that = algorithm.
 
Russ
 


On Jun 21, 2018, at 12:08 PM, Dave Thaler <dthaler@microsoft.com> = wrote:
 
This is similar to a question I asked as = well, whether the IETF only needs LMS or whether LMS is just an instance = in a larger class that might be needed, and what the scope of the draft = should be.
 
If the draft is not SUIT-only (e.g., = allowing use in OSCORE, etc.) then it sounds like we might need the = ability to support more than LMS for some use cases.
 
Dave
 
From: Suit <suit-bounces@ietf.org> On Behalf = Of Brendan = Moran
Sent: Thursday, June 21, 2018 = 9:03 AM
To: Russ Housley <housley@vigilsec.com>
Cc: suit = <suit@ietf.org>
Subject: Re: [Suit] = draft-housley-suit-cose-hash-sig
 
Hi Russ, 
Thanks for the = clarification. I agree that a larger signature is not what we need in = SUIT. However, for the COSE draft, would it not make sense to provide = for both LMS and XMSS? I don=E2=80=99t pretend to understand all COSE = use cases.
 
Thanks,
Brendan



On 21 Jun 2018, at 16:43, Russ Housley <housley@vigilsec.com> wrote:
 
Brendan: 
 
Yes, there are two CFRG = algorithms for hash-based signatures.  I prefer the one McGrew's = document, mostly because it is more straightforward.  There is some = speed improvement for the additional complexity in XMSS at the cost of a = larger signature value.  To me, the speed improvement is not big = enough to justify the larger signature size.  Your mileage may = vary.
 
This paper describes the = difference between the two:
 
 
Russ
 



On Jun 21, 2018, at 11:11 AM, Brendan Moran <Brendan.Moran@arm.com> wrote:
 
I see that there are two current drafts for hash-based = signatures:
https://tools.ietf.org/html/draft-mcgrew-hash-sigs-11
https://tools.ietf.org/html/draft-irtf-cfrg-xmss-hash-based-sig= natures-12
 
I see that you have referenced the mcgrew draft rather than = the IRTF/CFRG draft. Could you please explain what the difference is = between these two drafts and why the mcgrew draft was a better choice = than XMSS?
 
Thanks,
Brendan
 



On 13 Jun 2018, at = 20:03, Jim Schaad <ietf@augustcellars.com> = wrote:
 




-----Original = Message-----
From: Suit <suit-bounces@ietf.org> On Behalf Of Michael = Richardson
Sent: Wednesday, June 13, 2018 11:09 AM
To: suit <suit@ietf.org>
Subject: = [Suit] draft-housley-suit-cose-hash-sig


I have read the -01 draft today.
I have not = read [HASHSIG] yet.
I thought I'd try reading this first, = to see what questions I had.

I have = implemented COSE Sign1 with ECDSA in Ruby, so I have a grasp of
what we are trying to plug hash-sig *into*.


Suggestions:
1) would the = structure show in section 3 be easier if it was described by
  CDDL?  I'm rather unclear about = this.

No - this are not CBOR structures they are = pure binary strings




2) I din't understand section 4, where it = says:
     o  If the = 'key_ops' field is present, it MUST include 'sign' when
          &nb= sp;     creating a hash-based signature.

     o  If the = 'key_ops' field is present, it MUST include 'verify'
          &nb= sp;     when verifying a hash-based = signature.

Clearly this is not something = that travels over the network.  Is this
somehow


indicating how to = understand if one is dealing a public (verify) key or a
private


(sign) key?

The = key_ops field can be considered to potentially be transported over a
network.  It is part of the COSE_Key object rather than = part of the
COSE_Sign1 object.




3) the = variations: LMS_SHA256_M32_H20, and LMOTS_SHA256_N32_W2,
etc. are
  listed, but I don't know = if they need to be carried in the signature
  structure somehow.

See = the [HASHSIG] draft.  It is encoded into the signature structure = and the
key type is in the public key structure.




4) I = thought that perhaps we'd need CBOR or COSE specific way to transport
  the signatures.  I guess I shall read = HASHSIG to find out what the
  signatures look = like.

We have that.  This is looking at a = signature just like ECDSA would produce.
This is a = different "ECDSA" replacement.




I = understand draft-mcgrew-hash-sigs-11 is being advanced by CFRG.
I believe that SUIT should adopt this document, and should do = so in the
current state.

I = would like to have some examples in CBOR/COSE worked out with private
keys available in the appendices.

Always= a good thing to have.

Jim




--
] =             &n= bsp; Never tell me the odds! =             &n= bsp;   | ipv6 mesh
networks [


]   Michael = Richardson, Sandelman Software Works =        | network
architect =  [


] =     mcr@sandelman.ca  http://www.sandelman.ca/      = ;  |   ruby on rails
[



--
Michael = Richardson <mcr+IETF@sandelman.ca>, Sandelman = Software Works
-=3D IPv6 IoT consulting =3D-




_______________________________________________
Suit mailing list
Suit@ietf.org
https://www.ietf.org/mailman/listinfo/suit
 
IMPORTANT NOTICE: The = contents of this email and any attachments are confidential and may also = be privileged. If you are not the intended recipient, please notify the = sender immediately and do not disclose the contents to any other person, = use it for any purpose, or store or copy the information in any medium. = Thank you.
 
 
IMPORTANT NOTICE: The contents of this = email and any attachments are confidential and may also be privileged. = If you are not the intended recipient, please notify the sender = immediately and do not disclose the contents to any other person, use it = for any purpose, or store or copy the information in any medium. Thank = you.
 

Dyson Technology Limited, company = number 01959090, Tetbury Hill, Malmesbury, SN16 0RP, UK. 
This message = is intended solely for the addressee and may contain confidential = information. If you have received this message in error, please = immediately and permanently delete it, and do not use, copy or disclose = the information contained in this message or in any attachment. 
Dyson may = monitor email traffic data and content for security & = training.

= --Apple-Mail=_2E7F704E-9956-4A96-940F-EB2A3CD8AFC7-- From nobody Fri Jun 22 02:41:18 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C672D130DC1 for ; Fri, 22 Jun 2018 02:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHi1igeDNj3q for ; Fri, 22 Jun 2018 02:41:12 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B9DC1274D0 for ; Fri, 22 Jun 2018 02:41:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E3C49300A08 for ; Fri, 22 Jun 2018 05:41:09 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ddrLsCyLS_B4 for ; Fri, 22 Jun 2018 05:41:07 -0400 (EDT) Received: from [5.5.33.206] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 73E173004B7; Fri, 22 Jun 2018 05:41:06 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_029582B2-A66D-4545-8200-91C1645FBC49" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Fri, 22 Jun 2018 05:41:06 -0400 In-Reply-To: <18F16995-D6BF-4C68-9E93-B1CF93D4369D@vigilsec.com> Cc: suit To: Tony Putman References: <31676.1528913351@localhost> <04f401d40349$33a58b10$9af0a130$@augustcellars.com> <0CDB8D05-0214-4749-9907-5A1B0B4A2191@arm.com> <697B1DC9-B1DE-48BA-ADC6-EF936208AFCE@vigilsec.com> <9906B2BC-BFC2-4F83-A0F6-FFCC81912237@arm.com> <140080C241BAA1419B58F093108F9EDC1E0D1690@UK-MAL-MBOX-01.dyson.global.corp> <18F16995-D6BF-4C68-9E93-B1CF93D4369D@vigilsec.com> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Suit] draft-housley-suit-cose-hash-sig X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 09:41:15 -0000 --Apple-Mail=_029582B2-A66D-4545-8200-91C1645FBC49 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I uses 'HSS-LMS' for the algorithm identifier. The the updates in = Sections 4 and 7... Name: draft-housley-suit-cose-hash-sig Revision: 02 Title: Use of the Hash-based Signature Algorithm with CBOR = Object Signing and Encryption (COSE) Document date: 2018-06-22 Group: Individual Submission Pages: 10 URL: = https://www.ietf.org/internet-drafts/draft-housley-suit-cose-hash-sig-02.t= xt = Status: = https://datatracker.ietf.org/doc/draft-housley-suit-cose-hash-sig/ = Htmlized: = https://tools.ietf.org/html/draft-housley-suit-cose-hash-sig-02 = Htmlized: = https://datatracker.ietf.org/doc/html/draft-housley-suit-cose-hash-sig = Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-housley-suit-cose-hash-sig-02 = Abstract: This document specifies the conventions for using the Leighton-Micali Signature (LMS) algorithm for digital signatures with the CBOR Object Signing and Encryption (COSE) syntax. > On Jun 22, 2018, at 5:17 AM, Russ Housley = wrote: >=20 > I was assuming that LMS would use "HASHSIG", and XMSS would use = "XMSS". These labels align with the Internet-Draft file names. In the = long run, your suggestion is probably better. >=20 > Russ >=20 >=20 >> On Jun 22, 2018, at 4:13 AM, Tony Putman > wrote: >>=20 >> As far as I can tell, it is not possible to tell from the signature = whether it is LMS or XMSS (or indeed any other hash-based signature = scheme). If this is the case, then I suggest that the algorithm = identifiers in section 4 should be more specific (e.g. 'HSIG-LMS'), as = should the COSE registry entries in section 7 (e.g. Name: HASHSIG-LMS, = with corresponding expanded description). >> -- Tony >> =20 >> From: Suit [mailto:suit-bounces@ietf.org = ] On Behalf Of Russ Housley >> Sent: 21 June 2018 20:44 >> To: Dave Thaler; Brendan Moran >> Cc: suit >> Subject: Re: [Suit] draft-housley-suit-cose-hash-sig >> =20 >> I am advocating LMS. I think it would be appropriate for an advocate = for XMSS to write a similar draft for that algorithm. >> =20 >> Russ >> =20 >>=20 >>=20 >> On Jun 21, 2018, at 12:08 PM, Dave Thaler > wrote: >> =20 >> This is similar to a question I asked as well, whether the IETF only = needs LMS or whether LMS is just an instance in a larger class that = might be needed, and what the scope of the draft should be. >> =20 >> If the draft is not SUIT-only (e.g., allowing use in OSCORE, etc.) = then it sounds like we might need the ability to support more than LMS = for some use cases. >> =20 >> Dave >> =20 >> From: Suit > On = Behalf Of Brendan Moran >> Sent: Thursday, June 21, 2018 9:03 AM >> To: Russ Housley > >> Cc: suit > >> Subject: Re: [Suit] draft-housley-suit-cose-hash-sig >> =20 >> Hi Russ,=20 >> Thanks for the clarification. I agree that a larger signature is not = what we need in SUIT. However, for the COSE draft, would it not make = sense to provide for both LMS and XMSS? I don=E2=80=99t pretend to = understand all COSE use cases. >> =20 >> Thanks, >> Brendan >>=20 >>=20 >>=20 >> On 21 Jun 2018, at 16:43, Russ Housley > wrote: >> =20 >> Brendan:=20 >> =20 >> Yes, there are two CFRG algorithms for hash-based signatures. I = prefer the one McGrew's document, mostly because it is more = straightforward. There is some speed improvement for the additional = complexity in XMSS at the cost of a larger signature value. To me, the = speed improvement is not big enough to justify the larger signature = size. Your mileage may vary. >> =20 >> This paper describes the difference between the two: >> =20 >> https://eprint.iacr.org/2017/349.pdf = >> =20 >> Russ >> =20 >>=20 >>=20 >>=20 >> On Jun 21, 2018, at 11:11 AM, Brendan Moran > wrote: >> =20 >> I see that there are two current drafts for hash-based signatures: >> https://tools.ietf.org/html/draft-mcgrew-hash-sigs-11 = >> = https://tools.ietf.org/html/draft-irtf-cfrg-xmss-hash-based-signatures-12 = >> =20 >> I see that you have referenced the mcgrew draft rather than the = IRTF/CFRG draft. Could you please explain what the difference is between = these two drafts and why the mcgrew draft was a better choice than XMSS? >> =20 >> Thanks, >> Brendan >> =20 >>=20 >>=20 >>=20 >> On 13 Jun 2018, at 20:03, Jim Schaad > wrote: >> =20 >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Suit > On = Behalf Of Michael Richardson >> Sent: Wednesday, June 13, 2018 11:09 AM >> To: suit > >> Subject: [Suit] draft-housley-suit-cose-hash-sig >>=20 >>=20 >> I have read the -01 draft today. >> I have not read [HASHSIG] yet. >> I thought I'd try reading this first, to see what questions I had. >>=20 >> I have implemented COSE Sign1 with ECDSA in Ruby, so I have a grasp = of >> what we are trying to plug hash-sig *into*. >>=20 >>=20 >> Suggestions: >> 1) would the structure show in section 3 be easier if it was = described by >> CDDL? I'm rather unclear about this. >>=20 >> No - this are not CBOR structures they are pure binary strings >>=20 >>=20 >>=20 >>=20 >> 2) I din't understand section 4, where it says: >> o If the 'key_ops' field is present, it MUST include 'sign' = when >> creating a hash-based signature. >>=20 >> o If the 'key_ops' field is present, it MUST include 'verify' >> when verifying a hash-based signature. >>=20 >> Clearly this is not something that travels over the network. Is this >> somehow >>=20 >>=20 >> indicating how to understand if one is dealing a public (verify) key = or a >> private >>=20 >>=20 >> (sign) key? >>=20 >> The key_ops field can be considered to potentially be transported = over a >> network. It is part of the COSE_Key object rather than part of the >> COSE_Sign1 object. >>=20 >>=20 >>=20 >>=20 >> 3) the variations: LMS_SHA256_M32_H20, and LMOTS_SHA256_N32_W2, >> etc. are >> listed, but I don't know if they need to be carried in the = signature >> structure somehow. >>=20 >> See the [HASHSIG] draft. It is encoded into the signature structure = and the >> key type is in the public key structure. >>=20 >>=20 >>=20 >>=20 >> 4) I thought that perhaps we'd need CBOR or COSE specific way to = transport >> the signatures. I guess I shall read HASHSIG to find out what the >> signatures look like. >>=20 >> We have that. This is looking at a signature just like ECDSA would = produce. >> This is a different "ECDSA" replacement. >>=20 >>=20 >>=20 >>=20 >> I understand draft-mcgrew-hash-sigs-11 is being advanced by CFRG. >> I believe that SUIT should adopt this document, and should do so in = the >> current state. >>=20 >> I would like to have some examples in CBOR/COSE worked out with = private >> keys available in the appendices. >>=20 >> Always a good thing to have. >>=20 >> Jim >>=20 >>=20 >>=20 >>=20 >> -- >> ] Never tell me the odds! | ipv6 mesh >> networks [ >>=20 >>=20 >> ] Michael Richardson, Sandelman Software Works | network >> architect [ >>=20 >>=20 >> ] mcr@sandelman.ca = http://www.sandelman.ca/ = = | ruby on rails >> [ >>=20 >>=20 >>=20 >> -- >> Michael Richardson >, Sandelman Software Works >> -=3D IPv6 IoT consulting =3D- >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Suit mailing list >> Suit@ietf.org >> https://www.ietf.org/mailman/listinfo/suit = >> =20 >> IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy = the information in any medium. Thank you. >> =20 >> =20 >> IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy = the information in any medium. Thank you. >> =20 >>=20 >> Dyson Technology Limited, company number 01959090, Tetbury Hill, = Malmesbury, SN16 0RP, UK.=20 >> This message is intended solely for the addressee and may contain = confidential information. If you have received this message in error, = please immediately and permanently delete it, and do not use, copy or = disclose the information contained in this message or in any attachment.=20= >> Dyson may monitor email traffic data and content for security & = training. >=20 > _______________________________________________ > Suit mailing list > Suit@ietf.org > https://www.ietf.org/mailman/listinfo/suit --Apple-Mail=_029582B2-A66D-4545-8200-91C1645FBC49 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I uses 'HSS-LMS' for the algorithm identifier.  The the = updates in Sections 4 and 7...

Name: draft-housley-suit-cose-hash-sig
Revision: 02
Title: Use of the Hash-based Signature = Algorithm with CBOR Object Signing and Encryption (COSE)
Document date: 2018-06-22
Group: Individual Submission
Pages: 10
URL: =            https://www.ietf.org/internet-drafts/draft-housley-suit-cose-ha= sh-sig-02.txt
Status: =         https://datatracker.ietf.org/doc/draft-housley-suit-cose-hash-s= ig/
Htmlized:       https://tools.ietf.org/html/draft-housley-suit-cose-hash-sig-02=
Htmlized:       https://datatracker.ietf.org/doc/html/draft-housley-suit-cose-h= ash-sig
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-housley-suit-cose-has= h-sig-02

Abstract:
  This document specifies the conventions for using = the Leighton-Micali
  Signature (LMS) algorithm = for digital signatures with the CBOR Object
  Signing and Encryption (COSE) syntax.

On Jun 22, 2018, at 5:17 AM, Russ Housley <housley@vigilsec.com> wrote:

I was assuming that = LMS would use "HASHSIG", and XMSS would use "XMSS".  These labels = align with the Internet-Draft file names.  In the long run, your = suggestion is probably better.

Russ


On Jun = 22, 2018, at 4:13 AM, Tony Putman <Tony.Putman@dyson.com> wrote:

As far as I can tell, it is not possible to tell = from the signature whether it is LMS or XMSS (or indeed any other = hash-based signature scheme). If this is the case, then I suggest that = the algorithm identifiers in section 4 should be more specific (e.g. = 'HSIG-LMS'), as should the COSE registry entries in section 7 (e.g. = Name: HASHSIG-LMS, with corresponding expanded description).
-- Tony
 
From: Suit [mailto:suit-bounces@ietf.org] On Behalf = Of Russ Housley
Sent: 21 June 2018 20:44
To: Dave Thaler; Brendan = Moran
Cc: suit
Subject: Re: [Suit] = draft-housley-suit-cose-hash-sig
 
I am advocating LMS. I think it would be = appropriate for an advocate for XMSS to write a similar draft for that = algorithm.
 
Russ
 


On Jun 21, 2018, at 12:08 PM, Dave Thaler <dthaler@microsoft.com> = wrote:
 
This is similar to a question I asked as = well, whether the IETF only needs LMS or whether LMS is just an instance = in a larger class that might be needed, and what the scope of the draft = should be.
 
If the draft is not SUIT-only (e.g., = allowing use in OSCORE, etc.) then it sounds like we might need the = ability to support more than LMS for some use cases.
 
Dave
 
From: Suit <suit-bounces@ietf.org> On Behalf = Of Brendan = Moran
Sent: Thursday, June 21, 2018 = 9:03 AM
To: Russ Housley <housley@vigilsec.com>
Cc: suit = <suit@ietf.org>
Subject: Re: [Suit] = draft-housley-suit-cose-hash-sig
 
Hi Russ, 
Thanks for the = clarification. I agree that a larger signature is not what we need in = SUIT. However, for the COSE draft, would it not make sense to provide = for both LMS and XMSS? I don=E2=80=99t pretend to understand all COSE = use cases.
 
Thanks,
Brendan



On 21 Jun 2018, at 16:43, Russ Housley <housley@vigilsec.com> wrote:
 
Brendan: 
 
Yes, there are two CFRG = algorithms for hash-based signatures.  I prefer the one McGrew's = document, mostly because it is more straightforward.  There is some = speed improvement for the additional complexity in XMSS at the cost of a = larger signature value.  To me, the speed improvement is not big = enough to justify the larger signature size.  Your mileage may = vary.
 
This paper describes the = difference between the two:
 
 
Russ
 



On Jun 21, 2018, at 11:11 AM, Brendan Moran <Brendan.Moran@arm.com> wrote:
 
I see that there are two current drafts for hash-based = signatures:
https://tools.ietf.org/html/draft-mcgrew-hash-sigs-11
https://tools.ietf.org/html/draft-irtf-cfrg-xmss-hash-based-sig= natures-12
 
I see that you have referenced the mcgrew draft rather than = the IRTF/CFRG draft. Could you please explain what the difference is = between these two drafts and why the mcgrew draft was a better choice = than XMSS?
 
Thanks,
Brendan
 



On 13 Jun 2018, at = 20:03, Jim Schaad <ietf@augustcellars.com> = wrote:
 




-----Original = Message-----
From: Suit <suit-bounces@ietf.org> On Behalf Of Michael = Richardson
Sent: Wednesday, June 13, 2018 11:09 AM
To: suit <suit@ietf.org>
Subject: = [Suit] draft-housley-suit-cose-hash-sig


I have read the -01 draft today.
I have not = read [HASHSIG] yet.
I thought I'd try reading this first, = to see what questions I had.

I have = implemented COSE Sign1 with ECDSA in Ruby, so I have a grasp of
what we are trying to plug hash-sig *into*.


Suggestions:
1) would the = structure show in section 3 be easier if it was described by
  CDDL?  I'm rather unclear about = this.

No - this are not CBOR structures they are = pure binary strings




2) I din't understand section 4, where it = says:
     o  If the = 'key_ops' field is present, it MUST include 'sign' when
          &nb= sp;     creating a hash-based signature.

     o  If the = 'key_ops' field is present, it MUST include 'verify'
          &nb= sp;     when verifying a hash-based = signature.

Clearly this is not something = that travels over the network.  Is this
somehow


indicating how to = understand if one is dealing a public (verify) key or a
private


(sign) key?

The = key_ops field can be considered to potentially be transported over a
network.  It is part of the COSE_Key object rather than = part of the
COSE_Sign1 object.




3) the = variations: LMS_SHA256_M32_H20, and LMOTS_SHA256_N32_W2,
etc. are
  listed, but I don't know = if they need to be carried in the signature
  structure somehow.

See = the [HASHSIG] draft.  It is encoded into the signature structure = and the
key type is in the public key structure.




4) I = thought that perhaps we'd need CBOR or COSE specific way to transport
  the signatures.  I guess I shall read = HASHSIG to find out what the
  signatures look = like.

We have that.  This is looking at a = signature just like ECDSA would produce.
This is a = different "ECDSA" replacement.




I = understand draft-mcgrew-hash-sigs-11 is being advanced by CFRG.
I believe that SUIT should adopt this document, and should do = so in the
current state.

I = would like to have some examples in CBOR/COSE worked out with private
keys available in the appendices.

Always= a good thing to have.

Jim




--
] =             &n= bsp; Never tell me the odds! =             &n= bsp;   | ipv6 mesh
networks [


]   Michael = Richardson, Sandelman Software Works =        | network
architect =  [


] =     mcr@sandelman.ca  http://www.sandelman.ca/      = ;  |   ruby on rails
[



--
Michael = Richardson <mcr+IETF@sandelman.ca>, Sandelman = Software Works
-=3D IPv6 IoT consulting =3D-




_______________________________________________
Suit mailing list
Suit@ietf.org
https://www.ietf.org/mailman/listinfo/suit
 
IMPORTANT NOTICE: The = contents of this email and any attachments are confidential and may also = be privileged. If you are not the intended recipient, please notify the = sender immediately and do not disclose the contents to any other person, = use it for any purpose, or store or copy the information in any medium. = Thank you.
 
 
IMPORTANT NOTICE: The contents of this = email and any attachments are confidential and may also be privileged. = If you are not the intended recipient, please notify the sender = immediately and do not disclose the contents to any other person, use it = for any purpose, or store or copy the information in any medium. Thank = you.
 

Dyson Technology Limited, company = number 01959090, Tetbury Hill, Malmesbury, SN16 0RP, UK. 
This message = is intended solely for the addressee and may contain confidential = information. If you have received this message in error, please = immediately and permanently delete it, and do not use, copy or disclose = the information contained in this message or in any attachment. 
Dyson may = monitor email traffic data and content for security & = training.

_______________________________________________
Suit mailing list
Suit@ietf.org
https://www.ietf.org/mailman/listinfo/suit

= --Apple-Mail=_029582B2-A66D-4545-8200-91C1645FBC49-- From nobody Fri Jun 22 09:47:11 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D3A130EB0 for ; Fri, 22 Jun 2018 09:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XmUG9aBLgRY for ; Fri, 22 Jun 2018 09:47:07 -0700 (PDT) Received: from esa2.dyson.c3s2.iphmx.com (esa2.dyson.c3s2.iphmx.com [68.232.133.94]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CFBA130EAC for ; Fri, 22 Jun 2018 09:47:06 -0700 (PDT) X-IronPort-SPF: SKIP X-IronPort-AV: E=McAfee;i="5900,7806,8932"; a="35145484" X-IronPort-AV: E=Sophos; i="5.51,257,1526338800"; d="scan'208,217"; a="35145484" Received: from unknown (HELO uk-dlp-smtp-01.dyson.global.corp) ([62.189.202.16]) by esa2.dyson.c3s2.iphmx.com with ESMTP; 22 Jun 2018 17:57:57 +0100 Received: from uk-dlp-smtp-01.dyson.global.corp (uk-dlp-smtp-01.dyson.global.corp [127.0.0.1]) by uk-dlp-smtp-01.dyson.global.corp (Service) with ESMTP id 1853BFA10; Fri, 22 Jun 2018 14:55:02 +0000 (GMT) Received: from UK-MAL-CAS-01.dyson.global.corp (unknown [10.1.108.2]) by uk-dlp-smtp-01.dyson.global.corp (Service) with ESMTP id F3884FA02; Fri, 22 Jun 2018 14:55:01 +0000 (GMT) Received: from UK-MAL-CAS-04.dyson.global.corp (10.1.108.112) by UK-MAL-CAS-01.dyson.global.corp (10.1.108.2) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 22 Jun 2018 17:47:03 +0100 Received: from UK-MAL-MBOX-01.dyson.global.corp ([fe80::3975:cbc9:490b:523a]) by UK-MAL-CAS-04.dyson.global.corp ([10.1.108.112]) with mapi id 14.03.0319.002; Fri, 22 Jun 2018 17:47:03 +0100 From: Tony Putman To: Russ Housley CC: suit Thread-Topic: [Suit] draft-housley-suit-cose-hash-sig Thread-Index: AQHUA0IpmCMrPXwNBEGZJN1O4yNrXaReex0AgAxR0ACAAAjwgIAABWoAgAABigCAADxBAIAA4PKggAACaICAAAaUAIAAhXjQ Date: Fri, 22 Jun 2018 16:47:03 +0000 Message-ID: <140080C241BAA1419B58F093108F9EDC1E0D18AA@UK-MAL-MBOX-01.dyson.global.corp> References: <31676.1528913351@localhost> <04f401d40349$33a58b10$9af0a130$@augustcellars.com> <0CDB8D05-0214-4749-9907-5A1B0B4A2191@arm.com> <697B1DC9-B1DE-48BA-ADC6-EF936208AFCE@vigilsec.com> <9906B2BC-BFC2-4F83-A0F6-FFCC81912237@arm.com> <140080C241BAA1419B58F093108F9EDC1E0D1690@UK-MAL-MBOX-01.dyson.global.corp> <18F16995-D6BF-4C68-9E93-B1CF93D4369D@vigilsec.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.108.27] Content-Type: multipart/alternative; boundary="_000_140080C241BAA1419B58F093108F9EDC1E0D18AAUKMALMBOX01dyso_" MIME-Version: 1.0 Archived-At: Subject: Re: [Suit] draft-housley-suit-cose-hash-sig X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 16:47:10 -0000 --_000_140080C241BAA1419B58F093108F9EDC1E0D18AAUKMALMBOX01dyso_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 SGkgUnVzcywNCg0KU29tZSBmdXJ0aGVyIGNvbW1lbnRzIG9uIHlvdXIgZHJhZnQgc3VpdC1jb3Nl LWhhc2gtc2lnOg0KDQpJbiBhIG51bWJlciBvZiBwbGFjZXMsIHN0YXJ0aW5nIGluIHNlY3Rpb24g MywgeW91IGxpbWl0IHRoaXMgc3BlY2lmaWNhdGlvbg0KdG8gdXNpbmcgU0hBLTI1Ni4gQXMgZmFy IGFzIEkgY2FuIHNlZSwgaWYgYSBuZXcgUkZDIHdlcmUgaXNzdWVkIHVwZGF0aW5nDQpbSEFTSFNJ R30gYW5kIHVzaW5nIGEgZGlmZmVyZW50IGhhc2ggZnVuY3Rpb24sIHRoaXMgc3BlY2lmaWNhdGlv biB3b3VsZA0Kbm90IGNoYW5nZSBkdWUgdG8gdGhlIHNlbGYtZGVzY3JpYmluZyBuYXR1cmUgb2Yg dGhlIHNpZ25hdHVyZS4gU28gd2hpbGUNCnRoZSByZXN0cmljdGlvbiBhcHBsaWVzIHRvIFtIQVNI U0lHfSwgd2hpY2ggaXMgZGVmaW5pbmcgYWN0dWFsIHNpZ25hdHVyZXMsDQpJIGJlbGlldmUgaXQg ZG9lcyBub3QgYXBwbHkgdG8gdGhpcyBkcmFmdCwgd2hpY2ggaXMgZGVmaW5pbmcgYSB3YXkgdG8N CnRyYW5zcG9ydCBzaWduYXR1cmVzLg0KDQpTZWN0aW9uIDMuMTogIkVhY2ggc2lnbmVkIHB1Ymxp YyBrZXkgaXMgcmVwcmVzZW50ZWQgYnkgdGhlIGhhc2ggdmFsdWUgYXQNCnRoZSByb290IG9mIHRo ZSB0cmVlIjogaXQgYWxzbyBjb250YWlucyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgdHJlZQ0Kc3Ry dWN0dXJlICh0eXBlIGFuZCBvdHN0eXBlKSBhbmQgdGhlIGlkZW50aXR5IEk7IGJ1dCBwZXJoYXBz IHRoaXMgZGV0YWlsDQppcyBub3QgbmVlZGVkLg0KDQpFbmQgb2Ygc2VjdGlvbiAzLjE6IEkgZmlu ZCB0aGUgdGV4dCAibG1zX3NpZ25hdHVyZV9vbl9wdWJsaWNfa2V5WzBdIg0KKGFuZCBzbyBvbikg bWlzbGVhZGluZyBiZWNhdXNlIHRoZSBzaWduYXR1cmUgaXMgYWN0dWFsbHkgb24gcHVibGljX2tl eVsxXS4NCkkgZmVlbCBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gYmUgYSBiaXQgbW9yZSB2ZXJib3Nl LCBhbmQgZGVmaW5lOg0KICBzaWduYXR1cmVbay0xXSA9IGxtc19zaWduYXR1cmVfb25fcHVibGlj X2tleV9rX3VzaW5nX3ByaXZhdGVfa2V5W2stMV0NCiAgc2lnbmVkX3B1YmxpY19rZXlba10gPSBz aWduYXR1cmVbay0xXSB8fCBwdWJsaWNfa2V5W2tdDQpUaGVuIHRoZSBvdmVyYWxsIHRyZWUgaXMg anVzdA0KICB1MzJzdHIoTnNwaykgfHwNCiAgc2lnbmVkX3B1YmxpY19rZXlbMV0gfHwNCiAgc2ln bmVkX3B1YmxpY19rZXlbMl0gfHwNCiAgICAgLi4uDQogIHNpZ25lZF9wdWJsaWNfa2V5W05zcGst MV0gfHwNCiAgc2lnbmVkX3B1YmxpY19rZXlbTnNwa10gfHwNCiAgbG1zX3NpZ25hdHVyZV9vbl9t ZXNzYWdlX3VzaW5nX3ByaXZhdGVfa2V5W05zcGtdDQoNClNlY3Rpb24gMy4yLCB0aGlyZCBwYXJh Z3JhcGg6IEkgc3VnZ2VzdCBwdXR0aW5nIHRoZSBlbGVtZW50cyBpbiB0aGUgc2FtZQ0Kb3JkZXIg dGhhdCB0aGV5IGFwcGVhciBpbiB0aGUgc2lnbmF0dXJlLCBuYW1lbHk6DQogICJBbiBMTVMgc2ln bmF0dXJlIGNvbnNpc3RzIG9mIGZvdXIgZWxlbWVudHM6IHRoZSBudW1iZXIgb2YgdGhlIGxlYWYN CiAgIGFzc29jaWF0ZWQgd2l0aCB0aGUgTE0tT1RTIHNpZ25hdHVyZSwgYW4gTE0tT1RTIHNpZ25h dHVyZSBhcyBkZXNjcmliZWQNCiAgIGluIFNlY3Rpb24gMy4zLCBhIHR5cGVjb2RlIGluZGljYXRp bmcgdGhlIHBhcnRpY3VsYXIgTE1TIGFsZ29yaXRobSwNCiAgIGFuZCBhbiBhcnJheSBvZiB2YWx1 ZXMgdGhhdCBpcyBhc3NvY2lhdGVkIHdpdGggdGhlIHBhdGggdGhyb3VnaCB0aGUNCiAgIHRyZWUg ZnJvbSB0aGUgbGVhZiBhc3NvY2lhdGVkIHdpdGggdGhlIExNLU9UUyBzaWduYXR1cmUgdG8gdGhl IHJvb3QuIg0KSXQgaXMgcHJvYmFibHkgd29ydGggbm90aW5nIGhlcmUgdGhhdCB0aGUgTE0tT1RT IHNpZ25hdHVyZSBzdGFydHMgd2l0aA0KYW4gb3RzLXR5cGVjb2RlLCBzbyB0aGF0IHRoZSBzaWdu YXR1cmUgY2FuIGJlIGVhc2lseSBwYXJzZWQuDQoNClNlY3Rpb24gMy4zLCBsYXN0IGxpbmU6IEkg c3VnZ2VzdCByZXBsYWNpbmcgdGhlIGZpcnN0IGVsZW1lbnQgd2l0aA0KdTMyc3RyKG90c3R5cGUp IGZvciBjbGFyaXR5LiBJdCBzaG91bGQgYmUgY2xlYXIgZnJvbSBjb250ZXh0LCBidXQgSSB0aGlu aw0KaXQncyB3b3J0aCBlbXBoYXNpc2luZy4NCg0KU2VjdGlvbiA0LCBzZWNvbmQgcGFyYWdyYXBo OiAiVGhlIGZpcnN0IGZvdXIgYnl0ZXMgb2YgZWFjaCBMTVMgc2lnbmF0dXJlDQp2YWx1ZSBjb250 YWlucyB0eXBlIGNvZGUiIGlzIG5vdCBjb3JyZWN0LiBJIHN1Z2dlc3QgYmVpbmcgbGVzcyBzcGVj aWZpYw0KYW5kIHNheSBzb21ldGhpbmcgbGlrZSAidGhlIExNUyBzaWduYXR1cmUgdmFsdWUgaXMg c2VsZi1kZXNjcmliaW5nIiwgYXMNCnBhcnNpbmcgaXMgYSBsaXR0bGUgbW9yZSBkaWZmaWN1bHQg dG8gZXhwbGFpbi4gQWx0ZXJuYXRpdmVseSwgcmV2ZXJzZSB0aGUNCm9yZGVyIG9mIGRlc2NyaWJp bmcgdGhlIHBhcnRzLCB0byB0aGF0IHRoZSBzZWxmLXBhcnNpbmcgb2YgdGhlIE9UUw0Kc2lnbmF0 dXJlIGhhcyBhbHJlYWR5IGJlZW4gZXhwbGFpbmVkIGJlZm9yZSBjb21pbmcgdG8gdGhlIExNUyBz aWduYXR1cmUuDQoNClNlY3Rpb24gNDogVGhlcmUgaXMgbm8gbWVudGlvbiBvZiB3aGljaCBraWQg dG8gdXNlLiBUaGlzIG1heSBiZSBhIG1hdHRlcg0Kb2YgY29udmVudGlvbiBiZXR3ZWVuIHNlbmRl ciBhbmQgcmVjZWl2ZXIsIGJ1dCBpZiBwdWJsaWMga2V5cyBhcmUgdXNlZA0KYXMgdHJ1c3QgYW5j aG9ycyB0aGVuIHRoZSBpZGVudGl0eSBJIG9mIHRoZSBwdWJsaWMga2V5IGNvdWxkIGJlIHNlbnQg aW4NCnRoZSBraWQgZmllbGQuIEkgdGhpbmsgdGhpcyBzaG91bGQgYmUgbWVudGlvbmVkIGF0IGxl YXN0IGFzIGEgTUFZLCB0bw0KZmFjaWxpdGF0ZSBpbnRlcm9wZXJhYmlsaXR5Lg0KDQpTZWN0aW9u IDUuMSwgbGFzdCBwYXJhZ3JhcGg6IFRoZSBnZW5lcmF0aW9uIG9mIHNpZ25hdHVyZXMgYWxzbyBy ZWxpZXMgb24NCnJhbmRvbSBudW1iZXJzLiBUaGVpciBnZW5lcmF0aW9uIGlzIG11Y2ggbGVzcyBz ZW5zaXRpdmUgdGhhbiB0aGUgZ2VuZXJhdGlvbg0Kb2YgcHJpdmF0ZSBrZXlzLCBzbyBkb24ndCBs dW1wIHRoZW0gdG9nZXRoZXIgaW4gdGhlIHNhbWUgcGFyYWdyYXBoLCBidXQNCml0IGlzIHdvcnRo IGEgbWVudGlvbi4gQXMgYW4gYXNpZGUsIGlzIHRoZXJlIGFueSBpbnZlc3RpZ2F0aW9uIGludG8g YQ0KZGV0ZXJtaW5pc3RpYyBzaWduYXR1cmUsIGUuZy4gYnkgc2V0dGluZyBDIHRvIGEgaGFzaCBv ZiBhbGwgdGhlIHByaXZhdGUNCmtleXM/DQoNClNlY3Rpb24gNjogU29tZSBtb3JlIGlkbGUgc3Bl Y3VsYXRpb24gb24gbXkgcGFydC4gSW4gc29mdHdhcmUgdXBkYXRlLA0KdGhlIHNpZ25lZCBidW5k bGUgKnNob3VsZCogaGF2ZSBhIHVuaXF1ZSB2ZXJzaW9uIG51bWJlci4gSWYgdGhlcmUgd2VyZQ0K YSB3YXkgdG8gbWFwIHZlcnNpb24gbnVtYmVyIHRvIExNUyBub2RlLCB0aGlzIHdvdWxkIHByb3Zp ZGUgYSBkaWZmZXJlbnQNCndheSB0byBlbnN1cmUgdGhhdCB0aGUgc2FtZSBrZXkgd2FzIG5ldmVy IHJldXNlZC4gQnV0IEkgYWdyZWUgdGhhdCBzdWNoDQphIGRpc2N1c3Npb24gZG9lc24ndCBiZWxv bmcgaW4gdGhpcyBkb2N1bWVudC4NCg0KU2VjdGlvbiA3LjEvNy4yOiBQbGVhc2UgdXBkYXRlIHRo ZSAiRGVzY3JpcHRpb24iIHRvIGJlIG1vcmUgc3BlY2lmaWMsDQpzdWNoIGFzOg0KICAiRGVzY3Jp cHRpb246ICBIYXNoLWJhc2VkIGRpZ2l0YWwgc2lnbmF0dXJlcyB1c2luZyBIU1MvTE1TIiBhbmQN CiAgIkRlc2NyaXB0aW9uOiBQdWJsaWMga2V5IG9mIEhTUy9MTVMgaGFzaC1iYXNlZCBkaWdpdGFs IHNpZ25hdHVyZSINCg0KQmVzdCByZWdhcmRzLA0KVG9ueQ0KDQoKRHlzb24gVGVjaG5vbG9neSBM aW1pdGVkLCBjb21wYW55IG51bWJlciAwMTk1OTA5MCwgVGV0YnVyeSBIaWxsLCBNYWxtZXNidXJ5 LCBTTjE2IDBSUCwgVUsuClRoaXMgbWVzc2FnZSBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBh ZGRyZXNzZWUgYW5kIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbi4gSWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkg YW5kIHBlcm1hbmVudGx5IGRlbGV0ZSBpdCwgYW5kIGRvIG5vdCB1c2UsIGNvcHkgb3IgZGlzY2xv c2UgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1lc3NhZ2Ugb3IgaW4gYW55IGF0 dGFjaG1lbnQuCkR5c29uIG1heSBtb25pdG9yIGVtYWlsIHRyYWZmaWMgZGF0YSBhbmQgY29udGVu dCBmb3Igc2VjdXJpdHkgJiB0cmFpbmluZy4K --_000_140080C241BAA1419B58F093108F9EDC1E0D18AAUKMALMBOX01dyso_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5hcHBsZS10YWItc3Bhbg0KCXttc28tc3R5bGUtbmFt ZTphcHBsZS10YWItc3Bhbjt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5 bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBw dCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5 bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDstd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7bGluZS1i cmVhazphZnRlci13aGl0ZS1zcGFjZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5IaSBSdXNzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Tb21lIGZ1cnRoZXIgY29tbWVu dHMgb24geW91ciBkcmFmdCBzdWl0LWNvc2UtaGFzaC1zaWc6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkluIGEgbnVtYmVyIG9mIHBsYWNlcywgc3RhcnRpbmcgaW4gc2Vj dGlvbiAzLCB5b3UgbGltaXQgdGhpcyBzcGVjaWZpY2F0aW9uDQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnRv IHVzaW5nIFNIQS0yNTYuIEFzIGZhciBhcyBJIGNhbiBzZWUsIGlmIGEgbmV3IFJGQyB3ZXJlIGlz c3VlZCB1cGRhdGluZw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5bSEFTSFNJR30gYW5kIHVzaW5nIGEgZGlm ZmVyZW50IGhhc2ggZnVuY3Rpb24sIHRoaXMgc3BlY2lmaWNhdGlvbiB3b3VsZA0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5ub3QgY2hhbmdlIGR1ZSB0byB0aGUgc2VsZi1kZXNjcmliaW5nIG5hdHVyZSBvZiB0 aGUgc2lnbmF0dXJlLiBTbyB3aGlsZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+dGhlIHJlc3RyaWN0aW9uIGFw cGxpZXMgdG8gW0hBU0hTSUd9LCB3aGljaCBpcyBkZWZpbmluZyBhY3R1YWwgc2lnbmF0dXJlcyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkkgYmVsaWV2ZSBpdCBkb2VzIG5vdCBhcHBseSB0byB0aGlzIGRyYWZ0 LCB3aGljaCBpcyBkZWZpbmluZyBhIHdheSB0bw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij50cmFuc3BvcnQg c2lnbmF0dXJlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+U2VjdGlv biAzLjE6ICZxdW90O0VhY2ggc2lnbmVkIHB1YmxpYyBrZXkgaXMgcmVwcmVzZW50ZWQgYnkgdGhl IGhhc2ggdmFsdWUgYXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnRoZSByb290IG9mIHRoZSB0cmVlJnF1b3Q7 OiBpdCBhbHNvIGNvbnRhaW5zIGluZm9ybWF0aW9uIGFib3V0IHRoZSB0cmVlDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPnN0cnVjdHVyZSAodHlwZSBhbmQgb3RzdHlwZSkgYW5kIHRoZSBpZGVudGl0eSBJOyBi dXQgcGVyaGFwcyB0aGlzIGRldGFpbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+aXMgbm90IG5lZWRlZC4NCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5FbmQgb2Ygc2VjdGlvbiAzLjE6 IEkgZmluZCB0aGUgdGV4dCAmcXVvdDtsbXNfc2lnbmF0dXJlX29uX3B1YmxpY19rZXlbMF0mcXVv dDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+KGFuZCBzbyBvbikgbWlzbGVhZGluZyBiZWNhdXNlIHRoZSBz aWduYXR1cmUgaXMgYWN0dWFsbHkgb24gcHVibGljX2tleVsxXS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkkg ZmVlbCBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gYmUgYSBiaXQgbW9yZSB2ZXJib3NlLCBhbmQgZGVm aW5lOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7IHNpZ25hdHVyZVtrLTFdID0gbG1zX3NpZ25hdHVy ZV9vbl9wdWJsaWNfa2V5X2tfdXNpbmdfcHJpdmF0ZV9rZXlbay0xXTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Jm5ic3A7IHNpZ25lZF9wdWJsaWNfa2V5W2tdID0gc2lnbmF0dXJlW2stMV0gfHwgcHVibGljX2tl eVtrXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhlbiB0aGUgb3ZlcmFsbCB0cmVlIGlzIGp1c3Q8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiZuYnNwOyB1MzJzdHIoTnNwaykgfHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyBz aWduZWRfcHVibGljX2tleVsxXSB8fDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7IHNpZ25lZF9wdWJs aWNfa2V5WzJdIHx8PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLi4u PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsgc2lnbmVkX3B1YmxpY19rZXlbTnNway0xXSB8fDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+Jm5ic3A7IHNpZ25lZF9wdWJsaWNfa2V5W05zcGtdIHx8PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4mbmJzcDsgbG1zX3NpZ25hdHVyZV9vbl9tZXNzYWdlX3VzaW5nX3ByaXZhdGVfa2V5W05z cGtdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlNlY3Rpb24gMy4yLCB0 aGlyZCBwYXJhZ3JhcGg6IEkgc3VnZ2VzdCBwdXR0aW5nIHRoZSBlbGVtZW50cyBpbiB0aGUgc2Ft ZQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5vcmRlciB0aGF0IHRoZXkgYXBwZWFyIGluIHRoZSBzaWduYXR1 cmUsIG5hbWVseTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyAmcXVvdDtBbiBMTVMgc2lnbmF0dXJl IGNvbnNpc3RzIG9mIGZvdXIgZWxlbWVudHM6IHRoZSBudW1iZXIgb2YgdGhlIGxlYWYNCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7YXNzb2NpYXRlZCB3aXRoIHRoZSBMTS1PVFMg c2lnbmF0dXJlLCBhbiBMTS1PVFMgc2lnbmF0dXJlIGFzIGRlc2NyaWJlZA0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDtpbiBTZWN0aW9uIDMuMywgYSB0eXBlY29kZSBpbmRpY2F0 aW5nIHRoZSBwYXJ0aWN1bGFyIExNUyBhbGdvcml0aG0sDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwO2FuZCBhbiBhcnJheSBvZiB2YWx1ZXMgdGhhdCBpcyBhc3NvY2lhdGVkIHdp dGggdGhlIHBhdGggdGhyb3VnaCB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyB0cmVl IGZyb20gdGhlIGxlYWYgYXNzb2NpYXRlZCB3aXRoIHRoZSBMTS1PVFMgc2lnbmF0dXJlIHRvIHRo ZSByb290LiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SXQgaXMgcHJvYmFibHkgd29ydGggbm90aW5n IGhlcmUgdGhhdCB0aGUgTE0tT1RTIHNpZ25hdHVyZSBzdGFydHMgd2l0aA0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5hbiBvdHMtdHlwZWNvZGUsIHNvIHRoYXQgdGhlIHNpZ25hdHVyZSBjYW4gYmUgZWFzaWx5 IHBhcnNlZC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TZWN0aW9u IDMuMywgbGFzdCBsaW5lOiBJIHN1Z2dlc3QgcmVwbGFjaW5nIHRoZSBmaXJzdCBlbGVtZW50IHdp dGgNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+dTMyc3RyKG90c3R5cGUpIGZvciBjbGFyaXR5LiBJdCBzaG91 bGQgYmUgY2xlYXIgZnJvbSBjb250ZXh0LCBidXQgSSB0aGluazxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+aXQn cyB3b3J0aCBlbXBoYXNpc2luZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+U2VjdGlvbiA0LCBzZWNvbmQgcGFyYWdyYXBoOiAmcXVvdDtUaGUgZmlyc3QgZm91ciBieXRl cyBvZiBlYWNoIExNUyBzaWduYXR1cmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnZhbHVlIGNvbnRhaW5zIHR5 cGUgY29kZSZxdW90OyBpcyBub3QgY29ycmVjdC4gSSBzdWdnZXN0IGJlaW5nIGxlc3Mgc3BlY2lm aWMNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+YW5kIHNheSBzb21ldGhpbmcgbGlrZSAmcXVvdDt0aGUgTE1T IHNpZ25hdHVyZSB2YWx1ZSBpcyBzZWxmLWRlc2NyaWJpbmcmcXVvdDssIGFzPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5wYXJzaW5nIGlzIGEgbGl0dGxlIG1vcmUgZGlmZmljdWx0IHRvIGV4cGxhaW4uIEFsdGVy bmF0aXZlbHksIHJldmVyc2UgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5vcmRlciBvZiBkZXNjcmliaW5n IHRoZSBwYXJ0cywgdG8gdGhhdCB0aGUgc2VsZi1wYXJzaW5nIG9mIHRoZSBPVFMNCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+c2lnbmF0dXJlIGhhcyBhbHJlYWR5IGJlZW4gZXhwbGFpbmVkIGJlZm9yZSBjb21p bmcgdG8gdGhlIExNUyBzaWduYXR1cmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPlNlY3Rpb24gNDogVGhlcmUgaXMgbm8gbWVudGlvbiBvZiB3aGljaCBraWQgdG8gdXNl LiBUaGlzIG1heSBiZSBhIG1hdHRlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+b2YgY29udmVudGlvbiBiZXR3 ZWVuIHNlbmRlciBhbmQgcmVjZWl2ZXIsIGJ1dCBpZiBwdWJsaWMga2V5cyBhcmUgdXNlZA0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5hcyB0cnVzdCBhbmNob3JzIHRoZW4gdGhlIGlkZW50aXR5IEkgb2YgdGhl IHB1YmxpYyBrZXkgY291bGQgYmUgc2VudCBpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+dGhlIGtpZCBmaWVs ZC4gSSB0aGluayB0aGlzIHNob3VsZCBiZSBtZW50aW9uZWQgYXQgbGVhc3QgYXMgYSBNQVksIHRv PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5mYWNpbGl0YXRlIGludGVyb3BlcmFiaWxpdHkuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlNlY3Rpb24gNS4xLCBsYXN0IHBhcmFncmFwaDog VGhlIGdlbmVyYXRpb24gb2Ygc2lnbmF0dXJlcyBhbHNvIHJlbGllcyBvbjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+cmFuZG9tIG51bWJlcnMuIFRoZWlyIGdlbmVyYXRpb24gaXMgbXVjaCBsZXNzIHNlbnNpdGl2 ZSB0aGFuIHRoZSBnZW5lcmF0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5vZiBwcml2YXRlIGtleXMsIHNv IGRvbid0IGx1bXAgdGhlbSB0b2dldGhlciBpbiB0aGUgc2FtZSBwYXJhZ3JhcGgsIGJ1dA0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5pdCBpcyB3b3J0aCBhIG1lbnRpb24uIEFzIGFuIGFzaWRlLCBpcyB0aGVy ZSBhbnkgaW52ZXN0aWdhdGlvbiBpbnRvIGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmRldGVybWluaXN0aWMg c2lnbmF0dXJlLCBlLmcuIGJ5IHNldHRpbmcgQyB0byBhIGhhc2ggb2YgYWxsIHRoZSBwcml2YXRl PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5rZXlzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5TZWN0aW9uIDY6IFNvbWUgbW9yZSBpZGxlIHNwZWN1bGF0aW9uIG9uIG15IHBhcnQuIElu IHNvZnR3YXJlIHVwZGF0ZSwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+dGhlIHNpZ25lZCBidW5kbGUgKnNo b3VsZCogaGF2ZSBhIHVuaXF1ZSB2ZXJzaW9uIG51bWJlci4gSWYgdGhlcmUgd2VyZTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+YSB3YXkgdG8gbWFwIHZlcnNpb24gbnVtYmVyIHRvIExNUyBub2RlLCB0aGlzIHdv dWxkIHByb3ZpZGUgYSBkaWZmZXJlbnQNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+d2F5IHRvIGVuc3VyZSB0 aGF0IHRoZSBzYW1lIGtleSB3YXMgbmV2ZXIgcmV1c2VkLiBCdXQgSSBhZ3JlZSB0aGF0IHN1Y2g8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPmEgZGlzY3Vzc2lvbiBkb2Vzbid0IGJlbG9uZyBpbiB0aGlzIGRvY3Vt ZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TZWN0aW9uIDcuMS83 LjI6IFBsZWFzZSB1cGRhdGUgdGhlICZxdW90O0Rlc2NyaXB0aW9uJnF1b3Q7IHRvIGJlIG1vcmUg c3BlY2lmaWMsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnN1Y2ggYXM6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJz cDsgJnF1b3Q7RGVzY3JpcHRpb246Jm5ic3A7IEhhc2gtYmFzZWQgZGlnaXRhbCBzaWduYXR1cmVz IHVzaW5nIEhTUy9MTVMmcXVvdDsgYW5kPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsgJnF1b3Q7RGVz Y3JpcHRpb246IFB1YmxpYyBrZXkgb2YgSFNTL0xNUyBoYXNoLWJhc2VkIGRpZ2l0YWwgc2lnbmF0 dXJlJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkJlc3QgcmVn YXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPlRvbnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTNw eDsiPg0KRHlzb24gVGVjaG5vbG9neSBMaW1pdGVkLCBjb21wYW55IG51bWJlciAwMTk1OTA5MCwg VGV0YnVyeSBIaWxsLCBNYWxtZXNidXJ5LCBTTjE2IDBSUCwgVUsuDQo8YnI+DQpUaGlzIG1lc3Nh Z2UgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgYWRkcmVzc2VlIGFuZCBtYXkgY29udGFpbiBj b25maWRlbnRpYWwgaW5mb3JtYXRpb24uIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWVzc2Fn ZSBpbiBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgaXQs IGFuZCBkbyBub3QgdXNlLCBjb3B5IG9yIGRpc2Nsb3NlIHRoZSBpbmZvcm1hdGlvbiBjb250YWlu ZWQgaW4gdGhpcyBtZXNzYWdlIG9yIGluIGFueSBhdHRhY2htZW50Lg0KPGJyPg0KRHlzb24gbWF5 IG1vbml0b3IgZW1haWwgdHJhZmZpYyBkYXRhIGFuZCBjb250ZW50IGZvciBzZWN1cml0eSAmYW1w OyB0cmFpbmluZy4NCjwvc3Bhbj48L2JvZHk+DQo8L2h0bWw+DQo= --_000_140080C241BAA1419B58F093108F9EDC1E0D18AAUKMALMBOX01dyso_-- From nobody Fri Jun 22 18:10:46 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 336E312D949 for ; Fri, 22 Jun 2018 18:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1vdXMojx2zi for ; Fri, 22 Jun 2018 18:10:42 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFE71127AC2 for ; Fri, 22 Jun 2018 18:10:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 6507B300A08 for ; Fri, 22 Jun 2018 21:10:40 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id aSVhCYb8k-st for ; Fri, 22 Jun 2018 21:10:39 -0400 (EDT) Received: from a860b60074bd.home (pool-71-127-50-4.washdc.fios.verizon.net [71.127.50.4]) by mail.smeinc.net (Postfix) with ESMTPSA id 8B32330025C for ; Fri, 22 Jun 2018 21:10:39 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Message-Id: <3269DD94-D0EF-44A4-8032-6DE38048F179@vigilsec.com> Date: Fri, 22 Jun 2018 21:10:40 -0400 To: suit X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: [Suit] DRAFT SUIT Agenda for IETF 102 X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2018 01:10:45 -0000 Here is the draft agenda. Please review and post comments to the list. Russ = = = = = = = = IETF 101 SUIT Working Group in Montreal Wednesday, 18 July 2018 at 13:30 Agenda ------ 1) Agenda bashing, Logistics -- Chairs 2) Hackathon Report -- Hannes 3) Suit Architecture -- Authors - draft-ietf-suit-architecture 4) Suit Information Model -- Authors - draft-ietf-suit-information-model 5) Suit Manifest Format -- Authors - draft-moran-suit-manifest 6) Next Steps -- Chairs Jabber: xmpp:suit@jabber.ietf.org?join MeetEcho: https://www.meetecho.com/ietf102/suit Etherpad: https://etherpad.tools.ietf.org/p/notes-ietf-102-suit From nobody Sat Jun 23 07:26:16 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581C3130E5B for ; Sat, 23 Jun 2018 07:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64RwfeLjsSI0 for ; Sat, 23 Jun 2018 07:26:13 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77BC5130E58 for ; Sat, 23 Jun 2018 07:26:13 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1536420090; Sat, 23 Jun 2018 10:40:37 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 633F817DD; Sat, 23 Jun 2018 10:23:09 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 6131E17DB; Sat, 23 Jun 2018 10:23:09 -0400 (EDT) From: Michael Richardson To: David Brown cc: suit In-Reply-To: <20180621172040.GA24927@davidb.org> References: <20180621172040.GA24927@davidb.org> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Suit] SUIT architecture examples X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2018 14:26:15 -0000 --=-=-= Content-Type: text/plain David Brown wrote: > ### Dual CPU, other bus > This configuration has two or more CPUs, each having their own memory. > There will be a communication channel between them, but it will be used > as a peripheral, not via shared memory. In this case, each CPU will > have to be responsible for its own firmware upgrade. It is likely that > one of the CPUs will be considered a master, and will direct the other > CPU to do the upgrade. This configuration is commonly used to offload > specific work to other CPUs. Firmware dependencies are similar to the > other solutions above, sometimes allowing only one image to be > upgraded, other times requiring several to be upgraded atomically. > Because the updates are happening on multiple CPUs, upgrading the two > images atomically is challenging. Is there sometimes an ordering constrained between images? I.e. upgrade CPU-A to version X, before you upgrade CPU-B to version X? Does the Manifest need to specify this constraint, or would it be implied? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWy5XxoCLcPvd0N1lAQIFfAf/chKEt2X5kgmzEL3xMm8aypvc9sDAcIxW PltIVCka2bdffYJP/LFxTo12Tcx4cDMMayO8mhESU/ViD/kWWNJeN8Ur5Syb4e+1 wDxng5N47cqyFT4QGkICpc39SSNpWxUa938R8+Tih531mK7NFqJpIPvJkxMJ3lde 5nwbnkk2//toJ3Fz+hfp7r5oX3wi7vpv2vACRhUqtgf+Tx2a8NeqGvqtmtTA/KCv VSUCdY6XSmZbCipfdE/3Bq+vrAQSS69VmmyraZ/t0xXrDHGq6ZdMTDgp5Q2pEVdh Zy35K/axbP73vG7FRY2drn3R261TJ7yNsJgozXaiZqeN8vn8zelXUA== =0nY5 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 25 14:13:04 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58FEA130E58 for ; Mon, 25 Jun 2018 14:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=linaro.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HB0CgyWrTPvc for ; Mon, 25 Jun 2018 14:12:54 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C15F130E5A for ; Mon, 25 Jun 2018 14:12:54 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id i23-v6so10998072iog.10 for ; Mon, 25 Jun 2018 14:12:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=EzNRcuvQ3d1KUCPBWhKUhIW28P2Y9SC7D26v1nakvmc=; b=KdDI4s8f/xu572Zya04w58UfQtHCKHffUaDo/tzY+Rbc0ZKenPqLH5QjKeelqtxMEl rKPTCQM2odStXU+gJNx0RBJBkQaK/LV4VMXpzCzsaiMCIhufC6be5+mC8GKyI0jNmH/G cevkabYHYPkQYGBFF5aaI27phPLofFPkcYEM8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=EzNRcuvQ3d1KUCPBWhKUhIW28P2Y9SC7D26v1nakvmc=; b=EMiGAmKnqJAFWLwJPOan7P7F0D5NOpre3sdV3acgaYl1EhbqGf/1VqjI2JagnJyMkP j9OC2J3jV58mlHuIdiBUL5SPxWR7iAk0cq5r/hSQD5tGFews7ypC8Xs2+8ka/1glLAP6 WqoxdSkBjgn/UGzTge6j7xgYQKbb3ci+1G+NybdYTqZv2MKQ66B9Bl8aD5OooTJHLqs0 HulW8jfROfMXv1RkWx0YFNyrvi/QRyI/yyCKTIC2Ina6FIJW3G20A+P8PQiIdLklK/me Gi+wtwY7nP+A0aWfUQcUhuLsTj24K0va+TWNrvOp4njN9N89W0PFAOd8yZxfVfN8/Lj6 2b+Q== X-Gm-Message-State: APt69E20PogNm6SODnrYKpT/yNavRYdfNmZZAbOu6h+af2YEwX0QucbV pJjw8dSf61D1NiLAOrvfOA8yMw== X-Google-Smtp-Source: AAOMgpckGm+/WZJOSI75p+SvUEexFmQO92gTQt8gtVYVqQt0a2JsuuHrVAMspdBiawhGJzzh12dSdw== X-Received: by 2002:a6b:910a:: with SMTP id t10-v6mr6364759iod.59.1529961173727; Mon, 25 Jun 2018 14:12:53 -0700 (PDT) Received: from davidb.org ([2601:283:4300:987c::9]) by smtp.gmail.com with ESMTPSA id o18-v6sm6633045iod.19.2018.06.25.14.12.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Jun 2018 14:12:52 -0700 (PDT) Date: Mon, 25 Jun 2018 15:12:51 -0600 From: David Brown To: Michael Richardson Cc: suit Message-ID: <20180625211251.GA6063@davidb.org> References: <20180621172040.GA24927@davidb.org> <31986.1529763789@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <31986.1529763789@localhost> User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: Re: [Suit] SUIT architecture examples X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2018 21:12:57 -0000 On Sat, Jun 23, 2018 at 10:23:09AM -0400, Michael Richardson wrote: > >David Brown wrote: > > ### Dual CPU, other bus > > > This configuration has two or more CPUs, each having their own memory. > > There will be a communication channel between them, but it will be used > > as a peripheral, not via shared memory. In this case, each CPU will > > have to be responsible for its own firmware upgrade. It is likely that > > one of the CPUs will be considered a master, and will direct the other > > CPU to do the upgrade. This configuration is commonly used to offload > > specific work to other CPUs. Firmware dependencies are similar to the > > other solutions above, sometimes allowing only one image to be > > upgraded, other times requiring several to be upgraded atomically. > > Because the updates are happening on multiple CPUs, upgrading the two > > images atomically is challenging. > >Is there sometimes an ordering constrained between images? >I.e. upgrade CPU-A to version X, before you upgrade CPU-B to version X? > >Does the Manifest need to specify this constraint, or would it be implied? The current requirements as I am aware of them, only require the two images either be updated independently, or both be updated atomically. But, maybe it is worth being able to specify a one-directional ordering. In fact, a one-directional ordering could be used for the atomic case by just having each image specify a dependency on the other image at that version. David From nobody Mon Jun 25 16:18:16 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F354130F01 for ; Mon, 25 Jun 2018 16:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MU2B0xhAwIYQ for ; Mon, 25 Jun 2018 16:18:11 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCA3E130EF2 for ; Mon, 25 Jun 2018 16:18:11 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 92B5120090; Mon, 25 Jun 2018 19:32:43 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id E6AEA1778; Mon, 25 Jun 2018 19:15:05 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id E4A6871; Mon, 25 Jun 2018 19:15:05 -0400 (EDT) From: Michael Richardson To: David Brown cc: suit In-Reply-To: <20180625211251.GA6063@davidb.org> References: <20180621172040.GA24927@davidb.org> <31986.1529763789@localhost> <20180625211251.GA6063@davidb.org> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Suit] SUIT architecture examples X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2018 23:18:15 -0000 --=-=-= Content-Type: text/plain David Brown wrote: >> David Brown wrote: >> > ### Dual CPU, other bus >> >> > This configuration has two or more CPUs, each having their own memory. >> > There will be a communication channel between them, but it will be used >> > as a peripheral, not via shared memory. In this case, each CPU will >> > have to be responsible for its own firmware upgrade. It is likely that >> > one of the CPUs will be considered a master, and will direct the other >> > CPU to do the upgrade. This configuration is commonly used to offload >> > specific work to other CPUs. Firmware dependencies are similar to the >> > other solutions above, sometimes allowing only one image to be >> > upgraded, other times requiring several to be upgraded atomically. >> > Because the updates are happening on multiple CPUs, upgrading the two >> > images atomically is challenging. >> >> Is there sometimes an ordering constrained between images? >> I.e. upgrade CPU-A to version X, before you upgrade CPU-B to version X? >> >> Does the Manifest need to specify this constraint, or would it be implied? > The current requirements as I am aware of them, only require the two > images either be updated independently, or both be updated atomically. > But, maybe it is worth being able to specify a one-directional > ordering. In fact, a one-directional ordering could be used for the > atomic case by just having each image specify a dependency on the > other image at that version. The specific case I am painfully familiar with is on many Qualcomm based Android devices, where a particular main-CPU ROM images requires an baseband RADIO image at least as new as X, or stuff seriously fails. And sometimes a ROM image of Y, must have a RADIO image <= Z. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWzF3doCLcPvd0N1lAQJYlQgAhAGJsLjDFrewOkj01Jfchzv+J2tz1WY/ DHgvFVP+oZ7uB3fZExEvJ38waj4mYVAfC5JlgLzmKFgVvpPqKzyva63ZlHpdz4+S zkARiJKdCPJ/leVhZohwcoDVsdGgsM+oRvah7/sPxN6UJZDW4c4wRwG3wx3d4Nj9 /OFcjgjrioWSv0HWY1uxhLOfv2TT+7YAbgr4q+2896roL0/FqSpzatgZpyGIUxSE WEvKoNLYMmyzrOHWbWhZjuNniqPS+xrDSWuxG+3TQWpUbOleWK+JBR/YUsSHeiKD Rk6zFge0a6YrV0tzV8V23lSS5Y60mdmQBjWdsY0SKwbbGpv2AIpqHw== =ZI0+ -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jun 26 11:21:03 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D82891310EB for ; Tue, 26 Jun 2018 11:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7yRkM8EzSdU for ; Tue, 26 Jun 2018 11:20:58 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-am5eur03on070a.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe08::70a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE6061310CA for ; Tue, 26 Jun 2018 11:20:57 -0700 (PDT) Received: from HE1PR05MB1628.eurprd05.prod.outlook.com (10.169.119.142) by HE1PR05MB3178.eurprd05.prod.outlook.com (10.170.242.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.884.23; Tue, 26 Jun 2018 18:20:53 +0000 Received: from HE1PR05MB1628.eurprd05.prod.outlook.com ([fe80::f103:ad70:6100:223c]) by HE1PR05MB1628.eurprd05.prod.outlook.com ([fe80::f103:ad70:6100:223c%4]) with mapi id 15.20.0884.024; Tue, 26 Jun 2018 18:20:53 +0000 From: Paul Lambert To: suit Thread-Topic: CBOR and Firmware Word Alignment Thread-Index: AQHUDXpqlZOfRiTqM06CKoHAYhbheA== Date: Tue, 26 Jun 2018 18:20:53 +0000 Message-ID: <5DF0B5F0-85E2-4681-9581-E28A3F0A5446@intrinsic-id.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=paul.lambert@intrinsic-id.com; x-originating-ip: [96.86.174.246] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR05MB3178; 7:CrX7XzQ4w6I+HvE+P4kV8bfu/p9cqzEXKp44vbEND1+S9rjbgWaN8+Mm9InmsdoJC2Dg3vSBy/5O/Rg9jWhCqCFSlLNNkH5G9v0nhGVSTfUOniS7xh6ptxSB6RIqzpR8daeUrdmgF6zmwP/bP9rp8wvIvnPLOQBYYXPOmPIv5mD1fXoUzbIvBE8NrZFObmmzZqTXi1ql7AXl+C7eA3fH9tMgep9+DBcqFKYSn8vb6EayEzS3693MlbG1zNkPMaaa x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: d8abf185-3e67-4bdb-389d-08d5db918d62 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(8989117)(4534165)(7022125)(4603075)(4627221)(201702281549075)(8990107)(7048125)(7024125)(7027125)(7028125)(7023125)(5600026)(711020)(2017052603328)(7153060)(7193020); SRVR:HE1PR05MB3178; x-ms-traffictypediagnostic: HE1PR05MB3178: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231254)(944501410)(52105095)(10201501046)(3002001)(149027)(150027)(6041310)(20161123560045)(20161123562045)(20161123564045)(2016111802025)(20161123558120)(6072148)(6043046)(201708071742011)(7699016); SRVR:HE1PR05MB3178; BCL:0; PCL:0; RULEID:; SRVR:HE1PR05MB3178; x-forefront-prvs: 071518EF63 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(346002)(376002)(366004)(39830400003)(396003)(199004)(189003)(36756003)(7736002)(106356001)(2900100001)(14454004)(33656002)(6512007)(2906002)(305945005)(66066001)(82746002)(476003)(486006)(53936002)(105586002)(25786009)(68736007)(44832011)(256004)(6486002)(97736004)(6436002)(2616005)(102836004)(83716003)(86362001)(26005)(186003)(6506007)(5250100002)(6916009)(5660300001)(6116002)(8676002)(81166006)(81156014)(99286004)(3846002)(478600001)(8936002)(316002); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR05MB3178; H:HE1PR05MB1628.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: intrinsic-id.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: oIdeqUMoA6VRgbaGsdUuKtDyfCj0OxErf87RCDM55Ep6/CAGDN9pFTfrZEFhO+s9wCmpGKHfIYLe6c5mDCqZ4jbpkiFPs/T5AtVLjBTcghF8JIXN7vnFmNdYMEovISfhvdDRvywZX8CuyRNekGqFo1EN60mcKihvHok+fTk+WWaovpJhLt+a1DL1oeFsPkciC7I2Z77go9Zb8yEQl2JgBafeqmTxNssDr2UpkF8DPZcxlSuxFtJT0EkH8ive6EaEQFcxlgnm7DocfebHu7Why2wDh2JkJ9FCe0vB5t4QT+MM6vPbEyGoFRSpUf8kn+me2pOm1vAX3f1M/+lAe6uLqk/1NN8TPp4vPwNscJyCqjg= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <5A883DD22BE42546B8C30F76C17C7485@eurprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: intrinsic-id.com X-MS-Exchange-CrossTenant-Network-Message-Id: d8abf185-3e67-4bdb-389d-08d5db918d62 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2018 18:20:53.0777 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ba1ffe94-beb8-45fb-8407-ee2e3510fc68 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR05MB3178 Archived-At: Subject: [Suit] CBOR and Firmware Word Alignment X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 18:21:01 -0000 SGFzIGFueSB0aG91Z2h0IGdvbmUgaW50byB3b3JkIGFsaWdubWVudCBpc3N1ZXM/DQoNCk1hbnkg cGxhdGZvcm1zIHJlcXVpcmUgZmlybXdhcmUgb3Igb3RoZXIgZGF0YSBvYmplY3RzIHRvIGJlIHdv cmQgYWxpZ25lZC4gSXQgd2FvdWxkIGJlIGVzcGVjaWFsbHkgZGVzaXJhYmxlIHRvIGhhdmUgbGFy Z2Ugb2JqZWN0cyAobGlrZSB0aGUgZmlybXdhcmUpIGJlIHBhY2thZ2VkIHN1Y2ggdGhhdCB0aGUg ZGF0YSBkb2VzIG5vdCBoYXZlIHRvIGJlIGNvcGllZCB0byBhIG5ldyBsb2NhdGlvbiBqdXN0IHRv IGVuc3VyZSB3b3JkIGFsaWdubWVudC4gV29yZCBhbGlnbm1lbnQgd291bGQgYWxzbyBmYWNpbGl0 YXRlIGluLXBsYWNlIGRlY3J5cHRpb24gb2YgdGhlIGZpcm1lYXJlLg0KDQoNClBhdWwNCiAgICAN Cg0K From nobody Tue Jun 26 15:01:30 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3301F131134 for ; Tue, 26 Jun 2018 15:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZlXQO_1ziZ41 for ; Tue, 26 Jun 2018 15:01:10 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F6E1130F16 for ; Tue, 26 Jun 2018 15:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w5QM162G014532; Wed, 27 Jun 2018 00:01:06 +0200 (CEST) Received: from client-0193.vpn.uni-bremen.de (client-0193.vpn.uni-bremen.de [134.102.107.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41Fg3Q3q99zDWm0; Wed, 27 Jun 2018 00:01:06 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Carsten Bormann In-Reply-To: <5DF0B5F0-85E2-4681-9581-E28A3F0A5446@intrinsic-id.com> Date: Wed, 27 Jun 2018 00:01:06 +0200 Cc: suit X-Mao-Original-Outgoing-Id: 551743264.4023761-980305aae29c1aef0f4b5a648454093c Content-Transfer-Encoding: quoted-printable Message-Id: <97F2AD49-B1E8-44DC-9805-BFD6228301E0@tzi.org> References: <5DF0B5F0-85E2-4681-9581-E28A3F0A5446@intrinsic-id.com> To: Paul Lambert X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Suit] CBOR and Firmware Word Alignment X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 22:01:13 -0000 Hi Paul, CBOR does not have a padding feature (although it would be easy to add = one). Of course you can fake one by including a byte string in front of the = to-be-aligned data and dimensioning this just right. I am not aware of CBOR implementations that support this today, but it = should not be too hard to add this. Alternatively, the word-aligned firmware image could be kept separate = from the manifest itself. Gr=C3=BC=C3=9Fe, Carsten > On Jun 26, 2018, at 20:20, Paul Lambert = wrote: >=20 > Has any thought gone into word alignment issues? >=20 > Many platforms require firmware or other data objects to be word = aligned. It waould be especially desirable to have large objects (like = the firmware) be packaged such that the data does not have to be copied = to a new location just to ensure word alignment. Word alignment would = also facilitate in-place decryption of the firmeare. >=20 >=20 > Paul >=20 >=20 > _______________________________________________ > Suit mailing list > Suit@ietf.org > https://www.ietf.org/mailman/listinfo/suit >=20 From nobody Tue Jun 26 16:35:52 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF9C130E6B for ; Tue, 26 Jun 2018 16:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROxHbb5KOnpV for ; Tue, 26 Jun 2018 16:35:48 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88562130E61 for ; Tue, 26 Jun 2018 16:35:48 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6725F20090 for ; Tue, 26 Jun 2018 19:50:23 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 683511C1F; Tue, 26 Jun 2018 19:32:41 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 653FC1C1E for ; Tue, 26 Jun 2018 19:32:41 -0400 (EDT) From: Michael Richardson To: suit In-Reply-To: <5DF0B5F0-85E2-4681-9581-E28A3F0A5446@intrinsic-id.com> References: <5DF0B5F0-85E2-4681-9581-E28A3F0A5446@intrinsic-id.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Suit] CBOR and Firmware Word Alignment X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 23:35:51 -0000 --=-=-= Content-Type: text/plain Paul Lambert wrote: > Has any thought gone into word alignment issues? > Many platforms require firmware or other data objects to be word > aligned. It waould be especially desirable to have large objects (like > the firmware) be packaged such that the data does not have to be copied > to a new location just to ensure word alignment. Word alignment would > also facilitate in-place decryption of the firmeare. AFAIK, the firmware image is not *in* the manifest, so the actual firmware alignment does not depend upon any feature of the manifest. The firmware image can be put anywhere one likes. I find it unlikely that the manifest contents will need any specific alignment for a bulk operation. If so, it's small enough to copy around the place. Over on the mcuboot list, it seems that they currently putting their image TLV at the end of the firmware image, and they will place the manifest there. That would seem to align the firmware image nicely. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWzLNFoCLcPvd0N1lAQL82QgAoeR+u96v9j4Ga1rTg+CRz7/979Lhg8Ld qABQt6nO5FwwlFYaSm/fDrAzw1r2dsOlcf4mVo0MQ8gi94UZHOgtV8ZGabkVn2/U sETtyWTstNH01TjYA8xHcXZDz40Um8QIU9b63gyglzmJKQT4UOX5xMZFE/R+hnmc kDnwJy+wQlgAwqCYTscvCIOruzZVSixTxl7zWbiV5wLyVasoITO4mUElQbFYaZb3 nHVQjRw+indszE1Ek8TansJv8QTxReIHgo61YTK2UCZeNBrmB0B961oVB2Qt4ifq Ze43SZskwLNWke1Pv/l5Lyv4VlY5qaBLxf3dXQI6j2wuFb/3G8sfDg== =1mKN -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jun 26 23:47:06 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BEA0129385 for ; Tue, 26 Jun 2018 23:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nordicsemi.no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJPLOJij4eZ0 for ; Tue, 26 Jun 2018 23:47:02 -0700 (PDT) Received: from ironport01.nordicsemi.no (mx01.nordicsemi.no [194.19.86.146]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D068A130F30 for ; Tue, 26 Jun 2018 23:47:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nordicsemi.no; l=1584; s=default; t=1530082022; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=4gJRWAye8qzbYiNNHIMhvNOvPnMZBGJ+gYTBe4HLPUc=; b=wScNn3cSrJ2R4Wmb6n5bfcLmgK1A2k9MezNnWNCpTy2pg5TLquOp5hFs g++mBqBc+mJqTmdkCB+5s1IFeNCBUJG+p8iAxx3Yl+mfFGbeSP8fjknHg AOztVllIe8xkVSFrWNMmall0e6A8uYqCYp6n8boto0TRs+cU2Arx6PfXN Q=; X-IronPort-AV: E=Sophos;i="5.51,278,1526335200"; d="scan'208";a="11120650" From: =?iso-8859-1?Q?R=F8nningstad=2C_=D8yvind?= To: Michael Richardson , suit Thread-Topic: [Suit] CBOR and Firmware Word Alignment Thread-Index: AQHUDXpqlZOfRiTqM06CKoHAYhbheKRzD3eAgACY7TA= Date: Wed, 27 Jun 2018 06:46:58 +0000 Message-ID: References: <5DF0B5F0-85E2-4681-9581-E28A3F0A5446@intrinsic-id.com> <19378.1530055961@localhost> In-Reply-To: <19378.1530055961@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.9.200.83] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Suit] CBOR and Firmware Word Alignment X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 06:47:05 -0000 > -----Original Message----- > From: Suit [mailto:suit-bounces@ietf.org] On Behalf Of Michael > Richardson > Sent: 27. juni 2018 01:33 > To: suit > Subject: Re: [Suit] CBOR and Firmware Word Alignment >=20 >=20 > Paul Lambert wrote: > > Has any thought gone into word alignment issues? >=20 > > Many platforms require firmware or other data objects to be word > > aligned. It waould be especially desirable to have large objects (l= ike > > the firmware) be packaged such that the data does not have to be > copied > > to a new location just to ensure word alignment. Word alignment > would > > also facilitate in-place decryption of the firmeare. >=20 > AFAIK, the firmware image is not *in* the manifest, so the actual > firmware alignment does not depend upon any feature of the manifest. > The firmware image can be put anywhere one likes. > I find it unlikely that the manifest contents will need any specific > alignment for a bulk operation. If so, it's small enough to copy around > the place. >=20 > Over on the mcuboot list, it seems that they currently putting their imag= e > TLV at the end of the firmware image, and they will place the manifest > there. That would seem to align the firmware image nicely. >=20 In some cases it makes sense to concatenate the payload after the manifest = to simplify delivery, In which case I think it would be useful to have the = option of padding. There could be a bstr padding entry at the end of the ma= nifest, or maybe a padding extension. From nobody Wed Jun 27 01:27:31 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D3912872C for ; Wed, 27 Jun 2018 01:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5BK0IettESuA for ; Wed, 27 Jun 2018 01:27:27 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BA0C1277D2 for ; Wed, 27 Jun 2018 01:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w5R8RNiu020001; Wed, 27 Jun 2018 10:27:23 +0200 (CEST) Received: from [100.76.202.113] (ip-109-41-67-209.web.vodafone.de [109.41.67.209]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41Fwy26jRCzDWqt; Wed, 27 Jun 2018 10:27:22 +0200 (CEST) Content-Type: multipart/alternative; boundary=Apple-Mail-12CB2B3B-C445-4460-9CEE-726CD52260F5 Mime-Version: 1.0 (1.0) From: Carsten Bormann X-Mailer: iPhone Mail (15F79) In-Reply-To: Date: Wed, 27 Jun 2018 10:27:21 +0200 Cc: Michael Richardson , suit Content-Transfer-Encoding: 7bit Message-Id: <45FFC315-6D5A-4E08-BE4C-0DE2DEBA3C19@tzi.org> References: <5DF0B5F0-85E2-4681-9581-E28A3F0A5446@intrinsic-id.com> <19378.1530055961@localhost> To: =?utf-8?Q?"R=C3=B8nningstad, _=C3=98yvind"?= Archived-At: Subject: Re: [Suit] CBOR and Firmware Word Alignment X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 08:27:30 -0000 --Apple-Mail-12CB2B3B-C445-4460-9CEE-726CD52260F5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable So what is the container format for delivering manifest and image? You coul= d solve the problem there. (eg, round up before spending the next thing.) Sent from mobile > On 27. Jun 2018, at 08:46, R=C3=B8nningstad, =C3=98yvind wrote: >=20 >=20 >=20 >> -----Original Message----- >> From: Suit [mailto:suit-bounces@ietf.org] On Behalf Of Michael >> Richardson >> Sent: 27. juni 2018 01:33 >> To: suit >> Subject: Re: [Suit] CBOR and Firmware Word Alignment >>=20 >>=20 >> Paul Lambert wrote: >>> Has any thought gone into word alignment issues? >>=20 >>> Many platforms require firmware or other data objects to be word >>> aligned. It waould be especially desirable to have large objects (like >>> the firmware) be packaged such that the data does not have to be >> copied >>> to a new location just to ensure word alignment. Word alignment >> would >>> also facilitate in-place decryption of the firmeare. >>=20 >> AFAIK, the firmware image is not *in* the manifest, so the actual >> firmware alignment does not depend upon any feature of the manifest. >> The firmware image can be put anywhere one likes. >> I find it unlikely that the manifest contents will need any specific >> alignment for a bulk operation. If so, it's small enough to copy around >> the place. >>=20 >> Over on the mcuboot list, it seems that they currently putting their imag= e >> TLV at the end of the firmware image, and they will place the manifest >> there. That would seem to align the firmware image nicely. >>=20 >=20 > In some cases it makes sense to concatenate the payload after the manifest= to simplify delivery, In which case I think it would be useful to have the o= ption of padding. There could be a bstr padding entry at the end of the mani= fest, or maybe a padding extension. >=20 > _______________________________________________ > Suit mailing list > Suit@ietf.org > https://www.ietf.org/mailman/listinfo/suit >=20 --Apple-Mail-12CB2B3B-C445-4460-9CEE-726CD52260F5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable So what is the container format for deliver= ing manifest and image?  You could solve the problem there. (eg, round u= p before spending the next thing.)

Sen= t from mobile

On 2= 7. Jun 2018, at 08:46, R=C3=B8nningstad, =C3=98yvind <Oyvind.Ronningstad@nordicsemi.no> wr= ote:



-----Original Message-----
=
From: Suit [mailto:suit-bounces@ietf.org] On Behalf Of Michael=
Richardson
Sent: 27. juni 2018 01:33
To: suit <suit@ietf.org>
Subject: Re: [Suit] CBOR and Firmware Word Alignment


Paul Lambert <paul.lambert@intrinsic-id.com> wrote:
Has any thought gone in= to word alignment issues?

Many platforms require firmware or other data object= s to be word
<= blockquote type=3D"cite">aligned. It waould be especially desirable to= have large objects (like
the firmware) be packaged such t= hat the data does not have to be
copied
to a new location just to ensure word a= lignment. Word alignment
would
also facilitate in-place decryption of the firme= are.

AFAIK, the firmware ima= ge is not *in* the manifest, so the actual
firmware alignment does not depend upon any feature of= the manifest.
The fi= rmware image can be put anywhere one likes.
I find it unlikely that the manifest contents will ne= ed any specific
align= ment for a bulk operation.  If so, it's small enough to copy around
the place.

Over on the mcuboot list, it seems that they currently= putting their image
= TLV at the end of the firmware image, and they will place the manifest
there.  That would se= em to align the firmware image nicely.


In some cas= es it makes sense to concatenate the payload after the manifest to simplify d= elivery, In which case I think it would be useful to have the option of padd= ing. There could be a bstr padding entry at the end of the manifest, or mayb= e a padding extension.

____________________= ___________________________
Suit mailing list
Suit@ietf.org
https://www.ietf.org/mailman= /listinfo/suit

= --Apple-Mail-12CB2B3B-C445-4460-9CEE-726CD52260F5-- From nobody Wed Jun 27 11:33:02 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E60F8130E93 for ; Wed, 27 Jun 2018 11:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=linaro.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZB_awBNhZlP for ; Wed, 27 Jun 2018 11:32:59 -0700 (PDT) Received: from mail-it0-x243.google.com (mail-it0-x243.google.com [IPv6:2607:f8b0:4001:c0b::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57E32130E74 for ; Wed, 27 Jun 2018 11:32:59 -0700 (PDT) Received: by mail-it0-x243.google.com with SMTP id 188-v6so8827345ita.5 for ; Wed, 27 Jun 2018 11:32:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=j1TNW/mOyHnrUaijeiuyg2kZH15eRG0af1ehth+tp9M=; b=V0LJIgkuO1/K1IM2gMSgXKe8/dawXf1nWOB8RqXbtkkJ/WEeBt7ANj3s/JssLTDXPV eTYa94cV0SyDGPtB7tmstKzkDQm+V8gST36aAoq4spPk6tGbZoYZgxyLa1DP/tM1o1Bo 2iUOCjUx5UUGliaYsycbTThNPJUcRLD6nDvlA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=j1TNW/mOyHnrUaijeiuyg2kZH15eRG0af1ehth+tp9M=; b=qPB1HdUw4GllMKIDCVyeak6qrXvGqgxd8aTt2ogh/IR7wjnbyh2o0+r1FWD1CJUA2P voISJo1AnKuPbTcgHLBNdtuhtMRNmsNrvEh+bm3sHt7HwVuy3FLzGOS47G7KmqShtZWb RKGFNP2MwDNXpLsa/6wp2jZyN/rXuKZMh8slJOel4j2p66XGwMnAjFdKXQm5vGraHjag Y5u7a52ww22tnZuzlnECF1U+Uwr1MryXlKBkrthnr2U41xjC004ilmdnbghgd3EUyvze JmwJ2k/79XgY0H2RULZ3bukAlMNj4QwKrSNkNDz7zC231wIiLL3XDTmU2PaDVC71RE4y 5FSQ== X-Gm-Message-State: APt69E0GbvkwgGiokiLrI0SRvNl33xbouQuYY998qHZ366x/4rMrn71Z Cixp0RSiQSpTZd/u83W9sN1e0vDgx2Y= X-Google-Smtp-Source: AAOMgpccyFhE4llIuvZHJ5k60chmEHLR5Y0EmHYQMv8MkhJa9baWafx6ObRlINKxFr1q4GouKOtb6Q== X-Received: by 2002:a24:dec5:: with SMTP id d188-v6mr3334603itg.123.1530124378521; Wed, 27 Jun 2018 11:32:58 -0700 (PDT) Received: from davidb.org ([2601:283:4300:987c::9]) by smtp.gmail.com with ESMTPSA id o20-v6sm2073507ioa.83.2018.06.27.11.32.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Jun 2018 11:32:57 -0700 (PDT) Date: Wed, 27 Jun 2018 12:32:55 -0600 From: David Brown To: Paul Lambert Cc: suit Message-ID: <20180627183255.GA30443@davidb.org> References: <5DF0B5F0-85E2-4681-9581-E28A3F0A5446@intrinsic-id.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <5DF0B5F0-85E2-4681-9581-E28A3F0A5446@intrinsic-id.com> User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: Re: [Suit] CBOR and Firmware Word Alignment X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 18:33:01 -0000 On Tue, Jun 26, 2018 at 06:20:53PM +0000, Paul Lambert wrote: >Has any thought gone into word alignment issues? >Many platforms require firmware or other data objects to be word >aligned. It waould be especially desirable to have large objects >(like the firmware) be packaged such that the data does not have to >be copied to a new location just to ensure word alignment. Word >alignment would also facilitate in-place decryption of the firmeare. What we do today in MCUboot is something like: +--------------------+ | Header | +--------------------+ | Padding | +--------------------+ | XIP firmware image | +--------------------+ | Manifest | +--------------------+ where the header contains a length field to make finding the manifest easy. Because the images are execute in place (XIP), they have to be compiled and linked at a specific address. This precludes placing them after the manifest, since the information there is variable (even some signature encodings aren't deterministic in length). The constraints on this image are fairly specific: - It is XIP, and therefore must be placed at an address known at compile/link time. - The start address must be aligned to a particular alignment, depending on the particular hardware (for Cortex M, it is a power of two greater or equal to the size of the interrupt vector table, typically 256 or 512 bytes). It would be possible to insert 1 or more tags of some type into a CBOR stream in order to pad data, and this could possibly be standardized to one of the small values, so that this tag is only a single byte. We haven't determine how the image and manifest will be delivered, currently it seems like the manifest will be a separate file, but the image file that is then downloaded, will also already have the manifest appended to it. David From nobody Wed Jun 27 23:59:17 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71B60130DC2 for ; Wed, 27 Jun 2018 23:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.02 X-Spam-Level: X-Spam-Status: No, score=-1.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nordicsemi.no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7MQPzDA2unD for ; Wed, 27 Jun 2018 23:59:12 -0700 (PDT) Received: from ironport01.nordicsemi.no (mx01.nordicsemi.no [194.19.86.146]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EF3F12F295 for ; Wed, 27 Jun 2018 23:59:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nordicsemi.no; l=16467; s=default; t=1530169151; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=HoJVZfc/yKYZXv4cIGQQ5jJbms16FtHmZxuWy4dG7Q4=; b=VLG1A57zcW+Xh6A9AyVCKqOlQTnWvzRX0jyIz5wdHE77OtXiqgai+YID cqJ8L92Kvbf6HXx/eTZfxnIMFs+XAaRzF6vyCkD8slr9k5AW7OJfZpvMT S5mlx232XbUPX0qKPnZzqK93h2CQVHTqB9oPVKjpiYLO6dXqatzWhgWYf E=; X-IronPort-AV: E=Sophos; i="5.51,282,1526335200"; d="scan'208,217"; a="11133113" From: =?utf-8?B?UsO4bm5pbmdzdGFkLCDDmHl2aW5k?= To: Carsten Bormann CC: Michael Richardson , suit Thread-Topic: [Suit] CBOR and Firmware Word Alignment Thread-Index: AQHUDXpqlZOfRiTqM06CKoHAYhbheKRzD3eAgACY7TD///x1gIABmbHQ Date: Thu, 28 Jun 2018 06:59:06 +0000 Message-ID: <88b73191a7344beab90cf6e6aa831db1@nordicsemi.no> References: <5DF0B5F0-85E2-4681-9581-E28A3F0A5446@intrinsic-id.com> <19378.1530055961@localhost> <45FFC315-6D5A-4E08-BE4C-0DE2DEBA3C19@tzi.org> In-Reply-To: <45FFC315-6D5A-4E08-BE4C-0DE2DEBA3C19@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.9.200.83] Content-Type: multipart/alternative; boundary="_000_88b73191a7344beab90cf6e6aa831db1nordicsemino_" MIME-Version: 1.0 Archived-At: Subject: Re: [Suit] CBOR and Firmware Word Alignment X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 06:59:16 -0000 --_000_88b73191a7344beab90cf6e6aa831db1nordicsemino_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVmaW5pdGVseS4gSeKAmW0gbm90IGVudGlyZWx5IGNvbnZpbmNlZCB3ZSBuZWVkIGEgY29udGFp bmVyIGZvcm1hdCB0aG91Z2guIFRoZSBvcmRlciBvZiBibG9icyBpbiB0aGUgc3RyZWFtIGNvdWxk IGJlIGltcGxpY2l0LCBhbmQgc2l6ZSBpbmZvcm1hdGlvbiBpcyBhbHJlYWR5IHByZXNlbnQgaW4g dGhlIG1hbmlmZXN0cy4NCg0KRnJvbTogQ2Fyc3RlbiBCb3JtYW5uIFttYWlsdG86Y2Fib0B0emku b3JnXQ0KU2VudDogMjcuIGp1bmkgMjAxOCAxMDoyNw0KVG86IFLDuG5uaW5nc3RhZCwgw5h5dmlu ZCA8T3l2aW5kLlJvbm5pbmdzdGFkQG5vcmRpY3NlbWkubm8+DQpDYzogTWljaGFlbCBSaWNoYXJk c29uIDxtY3IraWV0ZkBzYW5kZWxtYW4uY2E+OyBzdWl0IDxzdWl0QGlldGYub3JnPg0KU3ViamVj dDogUmU6IFtTdWl0XSBDQk9SIGFuZCBGaXJtd2FyZSBXb3JkIEFsaWdubWVudA0KDQpTbyB3aGF0 IGlzIHRoZSBjb250YWluZXIgZm9ybWF0IGZvciBkZWxpdmVyaW5nIG1hbmlmZXN0IGFuZCBpbWFn ZT8gIFlvdSBjb3VsZCBzb2x2ZSB0aGUgcHJvYmxlbSB0aGVyZS4gKGVnLCByb3VuZCB1cCBiZWZv cmUgc3BlbmRpbmcgdGhlIG5leHQgdGhpbmcuKQ0KU2VudCBmcm9tIG1vYmlsZQ0KDQpPbiAyNy4g SnVuIDIwMTgsIGF0IDA4OjQ2LCBSw7hubmluZ3N0YWQsIMOYeXZpbmQgPE95dmluZC5Sb25uaW5n c3RhZEBub3JkaWNzZW1pLm5vPG1haWx0bzpPeXZpbmQuUm9ubmluZ3N0YWRAbm9yZGljc2VtaS5u bz4+IHdyb3RlOg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFN1aXQg W21haWx0bzpzdWl0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNaWNoYWVsDQpSaWNo YXJkc29uDQpTZW50OiAyNy4ganVuaSAyMDE4IDAxOjMzDQpUbzogc3VpdCA8c3VpdEBpZXRmLm9y ZzxtYWlsdG86c3VpdEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW1N1aXRdIENCT1IgYW5kIEZp cm13YXJlIFdvcmQgQWxpZ25tZW50DQoNCg0KUGF1bCBMYW1iZXJ0IDxwYXVsLmxhbWJlcnRAaW50 cmluc2ljLWlkLmNvbTxtYWlsdG86cGF1bC5sYW1iZXJ0QGludHJpbnNpYy1pZC5jb20+PiB3cm90 ZToNCkhhcyBhbnkgdGhvdWdodCBnb25lIGludG8gd29yZCBhbGlnbm1lbnQgaXNzdWVzPw0KDQpN YW55IHBsYXRmb3JtcyByZXF1aXJlIGZpcm13YXJlIG9yIG90aGVyIGRhdGEgb2JqZWN0cyB0byBi ZSB3b3JkDQphbGlnbmVkLiBJdCB3YW91bGQgYmUgZXNwZWNpYWxseSBkZXNpcmFibGUgdG8gaGF2 ZSBsYXJnZSBvYmplY3RzIChsaWtlDQp0aGUgZmlybXdhcmUpIGJlIHBhY2thZ2VkIHN1Y2ggdGhh dCB0aGUgZGF0YSBkb2VzIG5vdCBoYXZlIHRvIGJlDQpjb3BpZWQNCnRvIGEgbmV3IGxvY2F0aW9u IGp1c3QgdG8gZW5zdXJlIHdvcmQgYWxpZ25tZW50LiBXb3JkIGFsaWdubWVudA0Kd291bGQNCmFs c28gZmFjaWxpdGF0ZSBpbi1wbGFjZSBkZWNyeXB0aW9uIG9mIHRoZSBmaXJtZWFyZS4NCg0KQUZB SUssIHRoZSBmaXJtd2FyZSBpbWFnZSBpcyBub3QgKmluKiB0aGUgbWFuaWZlc3QsIHNvIHRoZSBh Y3R1YWwNCmZpcm13YXJlIGFsaWdubWVudCBkb2VzIG5vdCBkZXBlbmQgdXBvbiBhbnkgZmVhdHVy ZSBvZiB0aGUgbWFuaWZlc3QuDQpUaGUgZmlybXdhcmUgaW1hZ2UgY2FuIGJlIHB1dCBhbnl3aGVy ZSBvbmUgbGlrZXMuDQpJIGZpbmQgaXQgdW5saWtlbHkgdGhhdCB0aGUgbWFuaWZlc3QgY29udGVu dHMgd2lsbCBuZWVkIGFueSBzcGVjaWZpYw0KYWxpZ25tZW50IGZvciBhIGJ1bGsgb3BlcmF0aW9u LiAgSWYgc28sIGl0J3Mgc21hbGwgZW5vdWdoIHRvIGNvcHkgYXJvdW5kDQp0aGUgcGxhY2UuDQoN Ck92ZXIgb24gdGhlIG1jdWJvb3QgbGlzdCwgaXQgc2VlbXMgdGhhdCB0aGV5IGN1cnJlbnRseSBw dXR0aW5nIHRoZWlyIGltYWdlDQpUTFYgYXQgdGhlIGVuZCBvZiB0aGUgZmlybXdhcmUgaW1hZ2Us IGFuZCB0aGV5IHdpbGwgcGxhY2UgdGhlIG1hbmlmZXN0DQp0aGVyZS4gIFRoYXQgd291bGQgc2Vl bSB0byBhbGlnbiB0aGUgZmlybXdhcmUgaW1hZ2UgbmljZWx5Lg0KDQoNCkluIHNvbWUgY2FzZXMg aXQgbWFrZXMgc2Vuc2UgdG8gY29uY2F0ZW5hdGUgdGhlIHBheWxvYWQgYWZ0ZXIgdGhlIG1hbmlm ZXN0IHRvIHNpbXBsaWZ5IGRlbGl2ZXJ5LCBJbiB3aGljaCBjYXNlIEkgdGhpbmsgaXQgd291bGQg YmUgdXNlZnVsIHRvIGhhdmUgdGhlIG9wdGlvbiBvZiBwYWRkaW5nLiBUaGVyZSBjb3VsZCBiZSBh IGJzdHIgcGFkZGluZyBlbnRyeSBhdCB0aGUgZW5kIG9mIHRoZSBtYW5pZmVzdCwgb3IgbWF5YmUg YSBwYWRkaW5nIGV4dGVuc2lvbi4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NClN1aXQgbWFpbGluZyBsaXN0DQpTdWl0QGlldGYub3JnPG1haWx0bzpT dWl0QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdWl0 DQo= --_000_88b73191a7344beab90cf6e6aa831db1nordicsemino_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44 NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJOTy1CT0siIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkRlZmluaXRl bHkuIEnigJltIG5vdCBlbnRpcmVseSBjb252aW5jZWQgd2UgbmVlZCBhIGNvbnRhaW5lciBmb3Jt YXQgdGhvdWdoLiBUaGUgb3JkZXIgb2YgYmxvYnMgaW4gdGhlIHN0cmVhbSBjb3VsZCBiZSBpbXBs aWNpdCwgYW5kIHNpemUgaW5mb3JtYXRpb24gaXMgYWxyZWFkeSBwcmVzZW50IGluIHRoZSBtYW5p ZmVzdHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5n PSJFTi1VUyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gQ2Fyc3RlbiBCb3Jt YW5uIFttYWlsdG86Y2Fib0B0emkub3JnXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDI3LiBqdW5pIDIw MTggMTA6Mjc8YnI+DQo8Yj5Ubzo8L2I+IFLDuG5uaW5nc3RhZCwgw5h5dmluZCAmbHQ7T3l2aW5k LlJvbm5pbmdzdGFkQG5vcmRpY3NlbWkubm8mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBNaWNoYWVsIFJp Y2hhcmRzb24gJmx0O21jciYjNDM7aWV0ZkBzYW5kZWxtYW4uY2EmZ3Q7OyBzdWl0ICZsdDtzdWl0 QGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1N1aXRdIENCT1IgYW5kIEZp cm13YXJlIFdvcmQgQWxpZ25tZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5TbyB3aGF0IGlzIHRoZSBj b250YWluZXIgZm9ybWF0IGZvciBkZWxpdmVyaW5nIG1hbmlmZXN0IGFuZCBpbWFnZT8gJm5ic3A7 WW91IGNvdWxkIHNvbHZlIHRoZSBwcm9ibGVtIHRoZXJlLiAoZWcsIHJvdW5kIHVwIGJlZm9yZSBz cGVuZGluZyB0aGUgbmV4dCB0aGluZy4pPG86cD48L286cD48L3A+DQo8ZGl2IGlkPSJBcHBsZU1h aWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VudCBmcm9tJm5ic3A7PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMy4wcHQiPm1vYmlsZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PGJyPg0KT24gMjcuIEp1biAyMDE4LCBhdCAwODo0NiwgUsO4bm5pbmdzdGFkLCDDmHl2 aW5kICZsdDs8YSBocmVmPSJtYWlsdG86T3l2aW5kLlJvbm5pbmdzdGFkQG5vcmRpY3NlbWkubm8i Pk95dmluZC5Sb25uaW5nc3RhZEBub3JkaWNzZW1pLm5vPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4N Cjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Gcm9tOiBTdWl0IFs8YSBocmVmPSJtYWlsdG86c3VpdC1ib3VuY2VzQGll dGYub3JnIj5tYWlsdG86c3VpdC1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIE1p Y2hhZWw8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+UmljaGFyZHNvbjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5TZW50OiAyNy4ganVuaSAyMDE4IDAxOjMzPG86cD48L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRvOiBzdWl0ICZsdDs8YSBocmVmPSJt YWlsdG86c3VpdEBpZXRmLm9yZyI+c3VpdEBpZXRmLm9yZzwvYT4mZ3Q7PG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN1YmplY3Q6IFJlOiBbU3Vp dF0gQ0JPUiBhbmQgRmlybXdhcmUgV29yZCBBbGlnbm1lbnQ8bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QYXVsIExhbWJlcnQgJmx0 OzxhIGhyZWY9Im1haWx0bzpwYXVsLmxhbWJlcnRAaW50cmluc2ljLWlkLmNvbSI+cGF1bC5sYW1i ZXJ0QGludHJpbnNpYy1pZC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IYXMgYW55IHRob3VnaHQgZ29uZSBp bnRvIHdvcmQgYWxpZ25tZW50IGlzc3Vlcz88bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWFueSBwbGF0Zm9y bXMgcmVxdWlyZSBmaXJtd2FyZSBvciBvdGhlciBkYXRhIG9iamVjdHMgdG8gYmUgd29yZDxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPmFsaWduZWQuIEl0IHdhb3VsZCBiZSBlc3BlY2lhbGx5IGRlc2lyYWJsZSB0byBo YXZlIGxhcmdlIG9iamVjdHMgKGxpa2U8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGUgZmlybXdhcmUpIGJlIHBh Y2thZ2VkIHN1Y2ggdGhhdCB0aGUgZGF0YSBkb2VzIG5vdCBoYXZlIHRvIGJlPG86cD48L286cD48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PmNvcGllZDxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPnRvIGEgbmV3IGxvY2F0aW9uIGp1c3QgdG8gZW5zdXJlIHdvcmQgYWxpZ25tZW50LiBX b3JkIGFsaWdubWVudDxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj53b3VsZDxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFsc28gZmFjaWxpdGF0ZSBpbi1wbGFjZSBk ZWNyeXB0aW9uIG9mIHRoZSBmaXJtZWFyZS48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFGQUlLLCB0aGUgZmly bXdhcmUgaW1hZ2UgaXMgbm90ICppbiogdGhlIG1hbmlmZXN0LCBzbyB0aGUgYWN0dWFsPG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmZpcm13YXJl IGFsaWdubWVudCBkb2VzIG5vdCBkZXBlbmQgdXBvbiBhbnkgZmVhdHVyZSBvZiB0aGUgbWFuaWZl c3QuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoZSBmaXJtd2FyZSBpbWFnZSBjYW4gYmUgcHV0IGFueXdoZXJlIG9uZSBsaWtlcy48bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBmaW5kIGl0 IHVubGlrZWx5IHRoYXQgdGhlIG1hbmlmZXN0IGNvbnRlbnRzIHdpbGwgbmVlZCBhbnkgc3BlY2lm aWM8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ YWxpZ25tZW50IGZvciBhIGJ1bGsgb3BlcmF0aW9uLiAmbmJzcDtJZiBzbywgaXQncyBzbWFsbCBl bm91Z2ggdG8gY29weSBhcm91bmQ8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+dGhlIHBsYWNlLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T3ZlciBvbiB0aGUgbWN1Ym9vdCBsaXN0LCBp dCBzZWVtcyB0aGF0IHRoZXkgY3VycmVudGx5IHB1dHRpbmcgdGhlaXIgaW1hZ2U8bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VExWIGF0IHRoZSBl bmQgb2YgdGhlIGZpcm13YXJlIGltYWdlLCBhbmQgdGhleSB3aWxsIHBsYWNlIHRoZSBtYW5pZmVz dDxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50 aGVyZS4gJm5ic3A7VGhhdCB3b3VsZCBzZWVtIHRvIGFsaWduIHRoZSBmaXJtd2FyZSBpbWFnZSBu aWNlbHkuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpJbiBzb21lIGNhc2VzIGl0 IG1ha2VzIHNlbnNlIHRvIGNvbmNhdGVuYXRlIHRoZSBwYXlsb2FkIGFmdGVyIHRoZSBtYW5pZmVz dCB0byBzaW1wbGlmeSBkZWxpdmVyeSwgSW4gd2hpY2ggY2FzZSBJIHRoaW5rIGl0IHdvdWxkIGJl IHVzZWZ1bCB0byBoYXZlIHRoZSBvcHRpb24gb2YgcGFkZGluZy4gVGhlcmUgY291bGQgYmUgYSBi c3RyIHBhZGRpbmcgZW50cnkgYXQgdGhlIGVuZCBvZiB0aGUgbWFuaWZlc3QsIG9yIG1heWJlIGEg cGFkZGluZyBleHRlbnNpb24uPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQpTdWl0IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9 Im1haWx0bzpTdWl0QGlldGYub3JnIj5TdWl0QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3VpdCI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdWl0PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_88b73191a7344beab90cf6e6aa831db1nordicsemino_-- From nobody Fri Jun 29 08:04:05 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E12A12F1A6 for ; Fri, 29 Jun 2018 08:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=linaro.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6uYPAZp0jmKJ for ; Fri, 29 Jun 2018 08:04:00 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEA67126CC7 for ; Fri, 29 Jun 2018 08:04:00 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id q19-v6so1376248ioh.11 for ; Fri, 29 Jun 2018 08:04:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:subject:message-id:mime-version:content-disposition :user-agent; bh=Vg1BW48W6b5LmGYDxGTumLa0JhvpZnm0AALo4yi0peQ=; b=VbI2GEY8W9wGSFWGzi3BuPp7PuqpeAadPcfftUisXUMV5I1hoZUiYafnZneG/SYFpS scA8FwDFLdaXDLHvT+OF2chZwWzRC82/KpnKJ9p2NhR0XgnsX2553YULh1AUpDHVq4GC zJoyvHzG83oHi4Pv+99iR5IhUYaFo70ZA7ssE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition:user-agent; bh=Vg1BW48W6b5LmGYDxGTumLa0JhvpZnm0AALo4yi0peQ=; b=jZvYFUPkWSjtyCdf/wFxrIEQln7L5p8yQAMoe5V2lhj6uQkKRxt58yQmVxt78P7jHy LRyFxUIP65z+4vMnLG/CxjFOiDnTTAQNFG5+wSqYIZbKXKDrr6BX1XY5pkkLn3RelKhb Px34q4FtsC3PhMQgSbs7PflRCyxSN6RCCZauYnL8NMLaHzzj4C1pd6b8Gp7IatUEHRYR urrPKlu3eEY5HvjrIfoDrvcfk94X5uvWA8AiQgQkEAXPLGNExEOXp08ab6Bt0HhgINa4 2lcJ0Rq5Qc4gzvKRnQRhLmdUCxmSSUz0soD5GpU2JTDmE5QWcks0lLnmYzuH4eczxh7w OXqw== X-Gm-Message-State: APt69E0B+tNZy+GprQN6L6aE020nKBYwNs9uKR94QamMzb/jylta+7b5 9Iy2BJHI/okFA+jw9cSk+0wKrpyhjVI= X-Google-Smtp-Source: AAOMgpfdud3DoRhyz8zNgDNA6WmcmoVYpJSZa1pFq9a0ygGJ5QIu2kAtYOLX1Zh6QzPCvSSNQPR1Bw== X-Received: by 2002:a6b:1d2:: with SMTP id 201-v6mr2558705iob.140.1530284639745; Fri, 29 Jun 2018 08:03:59 -0700 (PDT) Received: from davidb.org ([2601:283:4300:987c::9]) by smtp.gmail.com with ESMTPSA id a26-v6sm4398275ioh.51.2018.06.29.08.03.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Jun 2018 08:03:59 -0700 (PDT) Date: Fri, 29 Jun 2018 09:03:57 -0600 From: David Brown To: suit Message-ID: <20180629150357.GA4926@davidb.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: [Suit] Add a user story for multiple image update X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 15:04:03 -0000 --- I'd like to propose this change to the information model to include support for multiple image support. I'm not sure that MFSR4 satisfies this requirement, or we will need another security model and/or threat to cover this case. The situation on these devices is that there are multiple firmware images, such as for a secure processor and an application processor. Sometimes, these images can be upgraded independently, but we also need to be able to capture when both must be upgraded together, atomically. This also applies to situations such as Arm's Trust Zone M, where a single CPU is partitioned into a secure and a non-secure domain. draft-ietf-suit-information-model.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/draft-ietf-suit-information-model.md b/draft-ietf-suit-information-model.md index d534c97..7cd8410 100644 --- a/draft-ietf-suit-information-model.md +++ b/draft-ietf-suit-information-model.md @@ -332,6 +332,12 @@ As an OEM or developer for IoT devices, I want to protect the IP contained in th Satisfied by: MFSR7 +### Use Case MFCU7: Multiple Images + +As an OEM or developer for IoT devices containing either multiple CPUs, or a single CPU with multiple security domains, I want to be able to update these multiple firmware images either independently, or require that both be updated together, atomically, depending on the needs of the particular update. + +Satistfied by: ??? + ## Usability Requirements The following usability requirements satisfy the user stories listed above. -- 2.16.4 From nobody Fri Jun 29 08:09:27 2018 Return-Path: X-Original-To: suit@ietfa.amsl.com Delivered-To: suit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66A0C130DC1 for ; Fri, 29 Jun 2018 08:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=linaro.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fB6uko4I0yzQ for ; Fri, 29 Jun 2018 08:09:13 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33AED130DC0 for ; Fri, 29 Jun 2018 08:09:09 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id d185-v6so8756873ioe.0 for ; Fri, 29 Jun 2018 08:09:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=1+rin+BO10VhZjF9B3iCMbkNx6Wd8ncI8FvEGrbHW6o=; b=Q4c2saBbsWKBDQ83ym22+MpfoxvvIfjuuvJx4GbqPUNrYk2aXC3rR3w7FVDbcvbGdE VNOvReeWm0AW4bv4yvQhzj/HNsyzZOYShUweA3JdhqVBmRbJGyyRmwkK8bvT/JUVb9H7 1kGqn1CrFpGmToPgLhPYHyCTgtaEsy3h11cPw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=1+rin+BO10VhZjF9B3iCMbkNx6Wd8ncI8FvEGrbHW6o=; b=meUVhPUUFbUEFfAAN4iZVeHpHIxCQLF50CUQw8dTlSvkuuZryA8ZFZ6h2NHVmVFCuZ uDm+qZ52WDJjrBILvOPh4/5Cb0/5R1XYnfyP7jQMqkPt37e9n2yuZ/uAAlMIIT/woR9X 7mKGWCu7e/csIvnTD8O5EvkEVM/pnJFTh96RJHcAMivjvbX6+83oqC7+HCyxoDMokeVD eXO8Wk2mBKsY/1A9m+rRqcnW4TvV9mCuz2PzHf6troJr0m0DdNcmI0j9Fo0pTcV/QTF7 M0vH7JV+ftkAEArP456o44VNT1U29uKPcYtw2yCpB2Z75XevSdlrofUlSEVGwQ0wJou5 3nag== X-Gm-Message-State: APt69E1wjzZdiwaHgkNvkiGyXQoVbYtpBsCGh+hHkdsFf31zbakv4vW4 v6O1YP7uN+5wmQXUxYXknJOmWBIxYtw= X-Google-Smtp-Source: AAOMgpe1VnN6UNS8mbAsElpo6BW6MJA4mWCtXG74O24Kil3ByAO3kCqAaNmMX8KS5tKqUy0T4g0mug== X-Received: by 2002:a6b:5c0c:: with SMTP id z12-v6mr1106122ioh.265.1530284948158; Fri, 29 Jun 2018 08:09:08 -0700 (PDT) Received: from davidb.org ([2601:283:4300:987c::9]) by smtp.gmail.com with ESMTPSA id d202-v6sm866095itc.30.2018.06.29.08.09.07 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Jun 2018 08:09:07 -0700 (PDT) Date: Fri, 29 Jun 2018 09:09:05 -0600 From: David Brown To: suit Message-ID: <20180629150905.GA2157@davidb.org> References: <20180629150357.GA4926@davidb.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20180629150357.GA4926@davidb.org> User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: Re: [Suit] Add a user story for multiple image update X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 15:09:25 -0000 --- An update from before, linking this user story into the dependency manifest field. draft-ietf-suit-information-model.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/draft-ietf-suit-information-model.md b/draft-ietf-suit-information-model.md index d534c97..b164330 100644 --- a/draft-ietf-suit-information-model.md +++ b/draft-ietf-suit-information-model.md @@ -332,6 +332,12 @@ As an OEM or developer for IoT devices, I want to protect the IP contained in th Satisfied by: MFSR7 +### Use Case MFCU7: Multiple Images + +As an OEM or developer for IoT devices containing either multiple CPUs, or a single CPU with multiple security domains, I want to be able to update these multiple firmware images either independently, or require that both be updated together, atomically, depending on the needs of the particular update. + +Satistfied by: Manifest Field: Dependencies + ## Usability Requirements The following usability requirements satisfy the user stories listed above. @@ -465,7 +471,7 @@ Implements: Usability Requirement MFUR2 A list of URI/Digest pairs that refer to other manifests by digest. The manifests that are linked in this way must be acquired and installed simultaneously in order to form a complete update. -Implements: Usability Requirement MFUR3 +Implements: Usability Requirement MFUR3, User Story MFCU7 ## Manifest Field: Content Key Distribution Method -- 2.16.4