X-List-Received-Date: Wed, 03 Sep 2014 01:40:01 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439AE76076TK5EX14MBXC294r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the useful review, Charlie. Responses and proposed resolutions = follow inline. Working group - please review. From: Charlie Kaufman [mailto:charliekaufman@outlook.com] Sent: Saturday, August 30, 2014 12:12 AM To: secdir@ietf.org Cc: draft-ietf-jose-json-web-algorithms.all@tools.ietf.org; iesg@ietf.org Subject: Secdir review of draft-ietf-jose-json-web-algorithms-31 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. This document sets the initial IANA registry values for the labels to be us= ed to specify choices of cryptographic algorithms in the context of the JSO= N Web Encryption, JSON Web Signature, and JSON Web Key documents (parallel = I-Ds). Some aspects of how the algorithms are used are specified here; othe= rs aspects reference other documents. The issues I found with this document (all of which are minor): Section 3.4 line 4 says Elliptic Curves are generally faster to execute (fo= r equivalent security) than RSA. While that is true for private key operati= ons (and even more dramatically so for key generation), it is generally not= true for public key operations. This is a nit in the text since these trad= e-offs are well understood. What if we were to change the phrase "with greater processing speed" to "wi= th greater processing speed for many operations"? Section 4.5 Direct Encryption: It might be too late to change existing impl= ementations, but it generally a good idea when using pre-negotiated keys to= include some key identifier in the header to remove ambiguity in the case = where there are multiple pre-negotiated keys (perhaps because they are in t= he process of being updated and they are not atomically updated on both end= s of the connection). The "kid" (Key ID) header parameter defined in the JWE spec already enables= this to be done. Section 5.1: I don't believe the pairings of AES128/HMAC-SHA256, AES192/HMA= C-SHA384, and AES256/HMAC-SHA512 are "natural" in the sense of providing eq= uivalent cryptographic strength. Without the HMAC, they would, but I believ= e HMAC-SHA256 is generally believed to have 256 bits of cryptographic stren= gth, making it suitable for pairing with any of the three AES key sizes. Th= e choices of the longer SHA2 variants are conservative, however, and so do = no harm if these pairings are already in widespread use. They are in use and are the pairings chosen by David McGrew, a just departe= d CRFG chair, and Kenny Paterson, a current CRFG chair, in draft-mcgrew-aea= d-aes-cbc-hmac-sha2. Section 5.2: Similarly, it is not appropriate to have the length of the Mes= sage Authentication Code (MAC) reflect the key length, since it does not af= fect cryptographic strength but rather the strength against on-line MAC gue= ssing attacks. For this purpose, 128 bits is generally considered adequate = for all key sizes and many implementations truncate this to 96 bits or even= 64. Again, the current specification is conservative (if slightly wasteful= of bandwidth), and so does not harm if this is already in widespread use. (Same answer as to the previous comment) Section 5.2.2.1 says "The number of octets in the input key K is the sum of= MAC_KEY_LEN and ENC_KEY_LEN." I believe it would be better to say somethin= g like "MUST BE the sum". The text goes on to say that the two keys must no= t overlap, but it is also important that an implementation not tolerate a g= ap between the two keys is a too large key is provided. OK Section 5.2.2.2 says the authenticated decryption operation has four inputs= ... . I believe it has a fifth: the IV. Alternately, the IV is pre-pended t= o the ciphertext (and hence implicitly included in 'E'). Agreed the IV is a fifth input. I'll make this change. Section 5.3 specifies AES/GCM in much less detail than the description of A= ES/HMAC in Section 5.2. Is this because the referenced document [NIST.800-3= 8D] includes all the needed details (like use of PKCS7 padding)? Yes Section 6.2.1.1: Because of the controversy over NSA allegedly planting bac= kdoors in the "NIST curves" listed, there is a growing demand that addition= al curves be supported. You might want to specify how additional curves can= be specified in-line and/or how to get additional curves added to the IANA= registry. Agreed. We can tweak the IANA language in this section (and possibly other= s using similar language) to be clearer on this point. Section 8.7: I believe the advice in this section is too strong. It is gene= rally considered secure to encrypt multiple data sets with the same key so = long as the IV is correctly chosen and it is also generally considered secu= re to encrypt the same data set with multiple different keys. There are man= y scenarios in which this is nearly impossible to avoid. It is important th= at when encryption multiple data sets with the same key that the IV be chos= en appropriately - which is very challenging when using GCM as noted in sec= tion 8.4. The current language was added to resolve issue #28 http://trac.tools.ietf.= org/wg/jose/trac/ticket/28 and is a result of a good bit of discussion with= Michael Peck, Jim Schaad, and others in the working group on the JOSE mail= ing list between June 2013 and August 2013, with the issue being closed by = Jim in October 2013. I recognize that of the problem here is that the security considerations ac= tually vary by algorithm and yet this subsection is trying to provide gener= al guidance. Is there a specific wording change that you'd like to propose that would we= aken the advice when it's OK to weaken it, but not in any other circumstanc= es? Section 8.8: I believe the advice in this section is too weak. It is genera= lly bad practice to derive cryptographic keys from passwords as passwords a= lmost never have adequate entropy. Where possible, it would be better to ha= ve a strong (i.e. randomly chosen) cryptographic key associated with an ent= ity and then use the password to acquire that cryptographic key. There are = a number of means for doing that, including having the strong key encrypted= with the password (or XORed with it) stored someplace the entity can acces= s it, by having a server that will return the key based on a provided passw= ord, or with a strong password authentication protocol. Deriving the key fr= om a password using PBES should be a last resort and demanding a longer pas= sword to derive a 256 bit key is only fooling yourself... you are never lik= ely to get more than 64 bits of entropy. Note that password-based encryption, as used by this specification, does em= ploy a randomly chosen content encryption key, and uses the password-based = encryption only to encrypt the CEK. Does that alleviate your concerns? If= not, could you supply specific proposed wording changes that would? --Charlie Thanks agai= n, -- Mike --_000_4E1F6AAD24975D4BA5B16804296739439AE76076TK5EX14MBXC294r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for the useful = review, Charlie. Responses and proposed resolutions follow inline.&nb= sp; Working group – please review.

From: Charlie = Kaufman [mailto:charliekaufman@outlook.com]
Sent: Saturday, August 30, 2014 12:12 AM
To: secdir@ietf.org
Cc: draft-ietf-jose-json-web-algorithms.all@tools.ietf.org; iesg@iet= f.org
Subject: Secdir review of draft-ietf-jose-json-web-algorithms-31

I have reviewed this document as part of the securit= y directorate's ongoing effort to review all IETF documents being processed= by the IESG. These comments were written primarily for the benefit o= f the security area directors. Document editors and WG chairs should treat these comments just like any other last= call comments.

This document sets the initial IANA registry values = for the labels to be used to specify choices of cryptographic algorithms in= the context of the JSON Web Encryption, JSON Web Signature, and JSON Web K= ey documents (parallel I-Ds). Some aspects of how the algorithms are used are specified here; others aspects = reference other documents.

The issues I found with this document (all of which = are minor):

Section 3.4 line 4 says Elliptic Curves are generall= y faster to execute (for equivalent security) than RSA. While that is true = for private key operations (and even more dramatically so for key generatio= n), it is generally not true for public key operations. This is a nit in the text since these trade-offs are well = understood.

What if we were to cha= nge the phrase “with greater processing spee= d” to “with greater processing speed for many operations”?

Section 4.5 Direct Encryption: It might be too late = to change existing implementations, but it generally a good idea when using= pre-negotiated keys to include some key identifier in the header to remove= ambiguity in the case where there are multiple pre-negotiated keys (perhaps because they are in the process = of being updated and they are not atomically updated on both ends of the co= nnection).

The “kid” = (Key ID) header parameter defined in the JWE spec already enables this to b= e done.

Section 5.1: I don't believe the pairings of AES128/= HMAC-SHA256, AES192/HMAC-SHA384, and AES256/HMAC-SHA512 are "natural&q= uot; in the sense of providing equivalent cryptographic strength. Without t= he HMAC, they would, but I believe HMAC-SHA256 is generally believed to have 256 bits of cryptographic strength, making i= t suitable for pairing with any of the three AES key sizes. The choices of = the longer SHA2 variants are conservative, however, and so do no harm if th= ese pairings are already in widespread use.

They are in use and ar= e the pairings chosen by David McGrew, a just departed CRFG chair, and Kenn= y Paterson, a current CRFG chair, in draft-mcgrew-aead-aes-cbc-hmac-sha2.

Section 5.2: Similarly, it is not appropriate to hav= e the length of the Message Authentication Code (MAC) reflect the key lengt= h, since it does not affect cryptographic strength but rather the strength = against on-line MAC guessing attacks. For this purpose, 128 bits is generally considered adequate for all key si= zes and many implementations truncate this to 96 bits or even 64. Again, th= e current specification is conservative (if slightly wasteful of bandwidth)= , and so does not harm if this is already in widespread use.

(Same answer as to the= previous comment)

Section 5.2.2.1 says "The number of octets in t= he input key K is the sum of MAC_KEY_LEN and ENC_KEY_LEN." I believe i= t would be better to say something like "MUST BE the sum". The te= xt goes on to say that the two keys must not overlap, but it is also important that an implementation not tolerate a gap between= the two keys is a too large key is provided.

Section 5.2.2.2 says the authenticated decryption op= eration has four inputs... . I believe it has a fifth: the IV. Alternately,= the IV is pre-pended to the ciphertext (and hence implicitly included in '= E').

Agreed the IV is a fif= th input. I’ll make this change.

Section 5.3 specifies AES/GCM in much less detail th= an the description of AES/HMAC in Section 5.2. Is this because the referenc= ed document [NIST.800-38D] includes all the needed details (like use of PKC= S7 padding)?

Yes<= /p>

Section 6.2.1.1: Because of the controversy over NSA= allegedly planting backdoors in the "NIST curves" listed, there = is a growing demand that additional curves be supported. You might want to = specify how additional curves can be specified in-line and/or how to get additional curves added to the IANA registry.

Agreed. We can t= weak the IANA language in this section (and possibly others using similar l= anguage) to be clearer on this point.

Section 8.7: I believe the advice in this section is= too strong. It is generally considered secure to encrypt multiple data set= s with the same key so long as the IV is correctly chosen and it is also ge= nerally considered secure to encrypt the same data set with multiple different keys. There are many scenarios i= n which this is nearly impossible to avoid. It is important that when encry= ption multiple data sets with the same key that the IV be chosen appropriat= ely – which is very challenging when using GCM as noted in section 8.4.

The current language w= as added to resolve issue #28 http://trac.t= ools.ietf.org/wg/jose/trac/ticket/28 and is a result of a good bit of d= iscussion with Michael Peck, Jim Schaad, and others in the working group on= the JOSE mailing list between June 2013 and August 2013, with the issue being closed by Jim in October 2013.<= o:p>

I recognize that of th= e problem here is that the security considerations actually vary by algorit= hm and yet this subsection is trying to provide general guidance.

Is there a specific wo= rding change that you’d like to propose that would weaken the advice = when it’s OK to weaken it, but not in any other circumstances?

Section 8.8: I believe the advice in this section is= too weak. It is generally bad practice to derive cryptographic keys from p= asswords as passwords almost never have adequate entropy. Where possible, i= t would be better to have a strong (i.e. randomly chosen) cryptographic key associated with an entity and the= n use the password to acquire that cryptographic key. There are a number of= means for doing that, including having the strong key encrypted with the p= assword (or XORed with it) stored someplace the entity can access it, by having a server that will return th= e key based on a provided password, or with a strong password authenticatio= n protocol. Deriving the key from a password using PBES should be a last re= sort and demanding a longer password to derive a 256 bit key is only fooling yourself... you are never likely t= o get more than 64 bits of entropy.

Note that password-bas= ed encryption, as used by this specification, does employ a randomly chosen= content encryption key, and uses the password-based encryption only to enc= rypt the CEK. Does that alleviate your concerns? If not, could you supply specific proposed wording changes= that would?

&nbs= p; --Charlie

&nbs= p; &= nbsp; &nbs= p; &= nbsp; &nbs= p; Thanks again,=

&nbs= p; &= nbsp; &nbs= p; &= nbsp; &nbs= p; -- Mike=

--_000_4E1F6AAD24975D4BA5B16804296739439AE76076TK5EX14MBXC294r_-- From nobody Thu Sep 4 05:02:59 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6943E1A8850; Thu, 4 Sep 2014 05:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.789 X-Spam-Level: X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, SPF_NEUTRAL=0.779] autolearn=ham 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 LK1h4xxYAdk9; Thu, 4 Sep 2014 05:02:50 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 67D321A884F; Thu, 4 Sep 2014 05:02:41 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s84C2bZi019577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 4 Sep 2014 15:02:37 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s84C2bF2006435; Thu, 4 Sep 2014 15:02:37 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21512.21725.209461.976375@fireball.kivinen.iki.fi> Date: Thu, 4 Sep 2014 15:02:37 +0300 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org, ietf@ietf.org, draft-ietf-jose-json-web-signature.all@tools.ietf.org X-Edit-Time: 19 min X-Total-Time: 18 min Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/jKQVidCDIvty76EdahPPR14tpV8 Subject: [secdir] Secdir review of draft-ietf-jose-json-web-signature-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 12:02:58 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: This document has issues. This document is part of the jose-json document set, and describres the JSON Web Signatures. The security considerations section includes text which says: The entire list of security considerations is beyond the scope of this document, but some significant considerations are listed here. but also lists quite a lot of security considerations. I think the security considerations covering this document should be in scope with the document. Of course there are generic security considerations which might be outside the scope of this document, but I do not think we need to explictly mention those. I have following issues about the draft: 1) "alg" and Protected Header 2) Hash inside "alg" and inside the signature 3) There is no explict warning about the "alg" "none". 4) Thumbprint formats There is also following nit: 5) Terminology ordering. ---------------------------------------------------------------------- 1) "alg" and Protected Header Question: Shouldn't the "alg" header parameter be protected by the signature, i.e. wouldn't it make sense to say MUST be in the "Protected Header"? If it is part of the "Unprotected Header" and is not protected by the signature, that would allow all kind of attacks, i.e. changing the "alg" to be "none" or changing the hash algorithm of the signature. If it should be part of the "Protected Header" then that would mean that "Proteced Header" cannot be empty, as "alg" is mandatory header parameter, and MUST be present. There are several cases where the text indicates that "Protected Header" could be empty, which would mean that "alg" could be part of the "Unprotected Header". (Section 5.1, 4. bullet; section 7.2, "protected" element and other places in same section). In all examples the "alg" is always in the "Proteced Header". I think the draft needs text saying something about the situation where "alg" is not in "Protected Header" in the security sections section. I.e. either say, that it has been analyzed that there is no problem even when the "alg" is not protected, and reference to such analysis, or otherwise add text/warning that it MUST/SHOULD be in the "Protected Header". I do not know enough about the proposed signature algorithms to know which one is true, especially as there might be new algorithms in the future. -- 2) Hash inside "alg" and inside the signature Also in some cases the signature itself has the hash function stored internally, i.e. RSASSA-PKCS1-V1_5 contains the hash function oid inside the signature, so what should the implementation do if the "alg" parameter outside the signature does not match the oid inside the signature? I.e the signature using "alg" of "RS256", but inside the signature the oid is using the "SHA1". Most crypto libraries will just take the oid from the signature, and use that to verify the message. Adding some description what to do in such situation would be needed. -- 3) There is no explict warning about the "alg" "none". In the section 5.2 it says that "at least one signature ... MUST successfully validate", but that does not limit alg "none" out from it. I.e. if the application policy is to "one signature needs to validate", and it gets JWS that has "none" as one of the algorithms, then it will accept it. I think there should be warning here or in the security considerations section about the "none" algorithm, especially as the algorithm itself is defined in the different draft (perhaps just reference to the section 8.5 of the [JWA] draft). -- 4) Thumbprint formats Section 4.1.7 and 4.1.8 defines a x5t and x5t#S256 thumbprints, but those are over the whole certificate. With the thumbprints, it has been noted lately, that quite often it is more useful to use the hash of the SubjectPublicKeyInfo object of the X.509 certificate, than the full X.509 certificate. This method has been used in the raw public key methods (draft-ietf-tls-oob-pubkey, draft-kivinen-ipsecme-oob-pubkey), and also in the DANE (it has two options one for the full certificate and another for the SubjectPublicKeyInfo object of the certificate). Using hash of the SubjectPublicKeyInfo object allows changing the certificate without invalidiating the certificates, i.e. when changing CAs, or switching from SHA1 to SHA2 in certificates, or just renewing the certificate. It also allows using raw public keys which do not have defined X.509 certificate format, but which can be converted to the SubjectPublicKeyInfo object when calculating the thumbprints. This is very important in the Internet of Things type of things, which might not be using the full X.509 certificates. -- 5) Terminology ordering. Terminology is not in any order. It would be useful to have it either in logical order (i.e. define terms before they are used), or in alphabetical order. Now for example the "JWS Protected Header" is used before it is defined in the "JWS Signature", and "Header Paramater" is between "JWS Signature" and "JWS Protected Header", also "JWS Signature" uses both "JWS Payload" and "JWS Protected Header", and one of those is defined before and one after the "JWS Signature". -- kivinen@iki.fi From nobody Thu Sep 4 05:55:42 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF0F1A887A for ; Thu, 4 Sep 2014 05:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.389 X-Spam-Level: X-Spam-Status: No, score=-0.389 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.668, SPF_NEUTRAL=0.779] autolearn=ham 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 rC-CpySs670T for ; Thu, 4 Sep 2014 05:55:39 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 4E8AD1A887F for ; Thu, 4 Sep 2014 05:55:39 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s84CtaUP027106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 4 Sep 2014 15:55:36 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s84CtZA8002909; Thu, 4 Sep 2014 15:55:35 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21512.24903.491821.230345@fireball.kivinen.iki.fi> Date: Thu, 4 Sep 2014 15:55:35 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/yi9xJiX3KqQAtzgSxIbdb4Q9b_E Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 12:55:41 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Catherine Meadows is next in the rotation. For telechat 2014-09-04 Reviewer LC end Draft Dan Harkins T 2014-08-22 draft-ietf-6lo-lowpan-mib-03 David Harrington T 2014-08-22 draft-ietf-ippm-lmap-path-05 For telechat 2014-09-18 Sam Hartman T 2014-08-22 draft-ietf-dnsop-child-syncronization-03 Takeshi Takahashi TR2014-08-05 draft-dukhovni-opportunistic-security-04 David Waltermire TR2014-08-04 draft-masotta-tftpexts-windowsize-opt-11 For telechat 2014-10-02 Chris Inacio T 2014-08-26 draft-ietf-tsvwg-rsvp-pcn-09 Chris Lonvick T 2014-09-30 draft-kyzivat-case-sensitive-abnf-01 Last calls and special requests: Dan Harkins 2014-06-13 draft-ietf-mmusic-rtsp-nat-evaluation-14 Jeffrey Hutzelman E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-06 Jeffrey Hutzelman 2014-08-22 draft-ietf-soc-overload-rate-control-09 Ben Laurie 2014-09-11 draft-ietf-avtcore-aria-srtp-06 Matt Lepinski 2014-09-11 draft-ietf-avtcore-srtp-aes-gcm-14 Zach Shelby 2014-06-06 draft-housley-implementer-obligations-02 Ondrej Sury 2014-07-30 draft-ietf-ipfix-text-adt-10 Brian Weis E 2014-01-16 draft-ietf-radext-dynamic-discovery-11 -- kivinen@iki.fi From nobody Fri Sep 5 08:38:08 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5B21A093B for ; Fri, 5 Sep 2014 08:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.769 X-Spam-Level: X-Spam-Status: No, score=-0.769 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=unavailable 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 D2OooEmlDHgN for ; Fri, 5 Sep 2014 08:38:04 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id CA7141A08BE for ; Fri, 5 Sep 2014 08:38:03 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta08.westchester.pa.mail.comcast.net with comcast id nPGr1o0030bG4ec58Te3J6; Fri, 05 Sep 2014 15:38:03 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta03.westchester.pa.mail.comcast.net with comcast id nTe21o00T2yZEBF3PTe27L; Fri, 05 Sep 2014 15:38:03 +0000 From: "David Harrington" To: , , Date: Fri, 5 Sep 2014 11:38:00 -0400 Message-ID: <010501cfc91f$60926610$21b73230$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac/JGGxFZFjwTBimTBKDthR2TvnD5Q== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1409931483; bh=QAcMzWvc1YfyFpjNWdsnFB4ocZi+1gwVQ5y6uzrv29Y=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=sQ41ccXQAHcf543IqOko+xTpCTJsGnI0yvEruOIXAv2znOStZNoE4lSy0M9NSC7N6 IxiHJjBjd/4QXfCZPXXZIuXLh/qQHCac4xCoyvFI/lbUSkSRKW0qtMnNtkEG0TcR+w 8nXVBlY8/5c9WlZa4l0e3XSqQixN8SELmggsNzd4Cx8VfwYk6HzWioyj7jn6u4blUl Fq90AsgY+7iKaqX3btwHn5MN5vXOQamtHjN2NUxO1jCYhNXd9lLDT2901MD8selbkz I8KV1nVkDNh7beKe5vi1BBPa48f/FZOuzfBn86eK6wo/RtCuKLQP7901PAZPABCJBE fuNh9VqyAjt5Q== Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/ceH_q2UVxE_uMFrS-MSu_ltrOsc Subject: [secdir] secdir review of draft-ietf-ippm-lmap-path-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 15:38:05 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Sorry I'm late with this review, given that the telechat was yesterday, but it is held up by discusses that are related to my comments, so maybe my comments will still be useful. Summary: Almost ready. I have a few concerns about controlling access to network management topology information. Abstract: This document defines a reference path for Large-scale Measurement of Broadband Access Performance (LMAP) and measurement points for commonly used performance metrics. Other similar measurement projects may also be able to use the extensions described here for measurement point location. This informational draft defines some terminology and methodology for describing the measurement points and paths exercised to gather metrics about broadband performance. This methodology is to enable the sharing of information in a way that can describe where in the network the metrics were generated. This draft does not define any messaging formats, and does not expose any information on the Internet. Since this does involve sharing of information between interested parties, there are potential privacy issues. Privacy is discussed in the security considerations section, and refers the reader to the LMAP Framework document that discusses privacy in more detail. The document doesn't discuss who the information is meant to be shared with - is this sharing within an administrative domain, or across (peering?) domains, or made public? This does involve exposing network management information, which might be sensitive because it exposes the network topology and might identify nodes in that topology. It might be good to at least point out that those who create the reference path descriptions be careful who they share the information with. If this were a MIB module, the reference path "management objects" would probably need to be included as read-sensitive in the MIB security boilerplate, and would recommend suitable confidentiality and access controls. I see that Benoit has suggested generalizing this information beyond LMAP. That might make this topology exposure issue more important. Which makes me, as an OPSDIR reviewer as well, wonder if there should be an associated MIB module to enable the sharing of this reference path information in a consistent manner - a manner that already has confidentiality and access controls, and for which operators/administrators are already careful about sharing network management information. Of course, having a MIB module for the reference path by itself would not be very important if the measurements themselves are not exposed via a MIB module. The quality of the text is good. I found the content understandable even though I have little background in LMAP (but I do have a background in network management so I understand the reference path issue). David Harrington dbharrington@comcast.net +1-603-828-1401 From nobody Fri Sep 5 15:04:30 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4C01A0299; Fri, 5 Sep 2014 15:04:28 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 rZP887F8jzYL; Fri, 5 Sep 2014 15:04:26 -0700 (PDT) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6157C1A01A5; Fri, 5 Sep 2014 15:04:26 -0700 (PDT) Received: by mail-pd0-f177.google.com with SMTP id r10so16613874pdi.36 for ; Fri, 05 Sep 2014 15:04:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=CPZfOeermiVQ/bcKVPIU9Oow62r0VYGRUF9BtdFNiMY=; b=P9c5d8CrAnWSySzHJErsxcuV6Glym2ze0A2t2YJ59jrMuU6cadOzYuBxsel0GBPYQ5 mor5rUNY3UXzQPwusLw8nHL4QEwF9qzqq9a8qoZqIMhn9HubN/PxKzL4n1IFMHxNMoe1 XczxKFOkhZy7bmsVVr6X3j2S6EjjYbBPmdNDgqxlhINYk1sFPHLRn+HOPn6yZo/XwIeq H7CmABX0BR5e0ROVxpBNtLsoEf1arojgs8vL+zs0sfofkCFlOgURlns8x/G3qdEfu+ps o+42m29yg7Ec3LlhQwMtzdKhef2ptFLyGmCJuAK0mjTl0ppbeHPeJRKdBNKmhSJ+14z8 r0hg== X-Received: by 10.70.34.136 with SMTP id z8mr26528027pdi.39.1409954666015; Fri, 05 Sep 2014 15:04:26 -0700 (PDT) Received: from [192.168.1.76] (172-3-137-150.lightspeed.sntcca.sbcglobal.net. [172.3.137.150]) by mx.google.com with ESMTPSA id z3sm2529921pbt.84.2014.09.05.15.04.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Sep 2014 15:04:25 -0700 (PDT) Message-ID: <540A3309.90802@gmail.com> Date: Fri, 05 Sep 2014 15:02:49 -0700 From: Chris Lonvick User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: iesg@ietf.org, secdir@ietf.org, draft-kyzivat-case-sensitive-abnf.all@tools.ietf.org Content-Type: multipart/alternative; boundary="------------040303060108000000020308" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/BSLho3kTYSx4VemdVVMV_uzTQpM Subject: [secdir] SECDIR review of draft-kyzivat-case-sensitive-abnf X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 22:04:28 -0000 This is a multi-part message in MIME format. --------------040303060108000000020308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The abstract is: This document extends the base definition of ABNF (Augmented Mackus- Naur Form) to include a way to specify ASCII string literals that are matched in a case-sensitive manner. Overall, I don't like the statement in the Security Considerations section, but it is consistent with all other documents related to defining ABNF, and I can't find any noteworthy security issues anyway. From that, I have no objection to moving this document forward. I did find some nits and have some suggestions for improving readability. 1 - "Mackus-Naur" is used in two places rather than "Backus-Naur". 2 - The last sentence of section 2.1 is: This mechanism has a clear readability disadvantage, with respect to using a literal text string with a prefix, and new the prefix mechanism is preferred. Perhaps you meant: This mechanism of using a literal text string with a prefix has a clear readability disadvantage. The prefix mechanism described in this specification can be much more easily read. 3 - This part of Section 2.1 may be cleared up some: ---vvv--- If no prefix is present then the string is case-insensitive. Hence: rulename = %i"aBc" and: rulename = "abc" will both match "abc", "Abc", "aBc", "abC", "ABc", "aBC", "AbC", and "ABC". ---^^^--- Suggested: ---vvv--- To be consistent with current implementations of ABNF, having no prefix means that the string is case-insensitive, and is equivalent to having the "%i" prefix. Hence: rulename = %i"aBc" and: rulename = "abc" are equivalent and both will match "abc", "Abc", "aBc", "abC", "ABc", "aBC", "AbC", and "ABC". ---^^^--- Best regards, Chris --------------040303060108000000020308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

The abstract is:

   This document extends the base definition of ABNF (Augmented Mackus-
   Naur Form) to include a way to specify ASCII string literals that are
   matched in a case-sensitive manner.

Overall, I don't like the statement in the Security Considerations section, but it is consistent with all other documents related to defining ABNF, and I can't find any noteworthy security issues anyway. From that, I have no objection to moving this document forward.

I did find some nits and have some suggestions for improving readability.

1 - "Mackus-Naur" is used in two places rather than "Backus-Naur".

2 - The last sentence of section 2.1 is:

   This mechanism has a clear readability
   disadvantage, with respect to using a literal text string with a
   prefix, and new the prefix mechanism is preferred.

Perhaps you meant:
   This mechanism of using a literal text string with a prefix has a clear
   readability disadvantage. The prefix mechanism described in this
   specification can be much more easily read.


3 - This part of Section 2.1 may be cleared up some:
---vvv---

If no prefix is present then the string is case-insensitive.

   Hence:

         rulename = %i"aBc"

   and:

         rulename = "abc"

   will both match "abc", "Abc", "aBc", "abC", "ABc", "aBC", "AbC", and
   "ABC".

---^^^---

Suggested:
---vvv---
     To be consistent with current implementations of ABNF, having no
     prefix means that the string is case-insensitive, and is equivalent
     to having the "%i" prefix.

   Hence:

         rulename = %i"aBc"

   and:

         rulename = "abc"

   are equivalent and both will match "abc", "Abc", "aBc", "abC", "ABc",
   "aBC", "AbC", and "ABC".
---^^^---

Best regards,
Chris

--------------040303060108000000020308-- From nobody Fri Sep 5 17:23:56 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD0D1A03DB; Fri, 5 Sep 2014 16:14:14 -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, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 frqzs54Z5i4x; Fri, 5 Sep 2014 16:14:09 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0702.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:702]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB4F71A03D8; Fri, 5 Sep 2014 16:14:08 -0700 (PDT) Received: from BN3PR0301CA0038.namprd03.prod.outlook.com (25.160.180.176) by BY2PR03MB619.namprd03.prod.outlook.com (10.255.93.41) with Microsoft SMTP Server (TLS) id 15.0.1019.16; Fri, 5 Sep 2014 23:13:45 +0000 Received: from BY2FFO11FD046.protection.gbl (2a01:111:f400:7c0c::197) by BN3PR0301CA0038.outlook.office365.com (2a01:111:e400:4000::48) with Microsoft SMTP Server (TLS) id 15.0.1024.12 via Frontend Transport; Fri, 5 Sep 2014 23:13:44 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD046.mail.protection.outlook.com (10.1.15.170) with Microsoft SMTP Server (TLS) id 15.0.1010.11 via Frontend Transport; Fri, 5 Sep 2014 23:13:44 +0000 Received: from TK5EX14MBXC292.redmond.corp.microsoft.com ([169.254.1.60]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.03.0195.002; Fri, 5 Sep 2014 23:13:05 +0000 From: Mike Jones To: Scott Kelly , "secdir@ietf.org" , "draft-ietf-jose-json-web-encryption.all@tools.ietf.org" , "iesg@ietf.org" Thread-Topic: secdir review of draft-ietf-jose-json-web-encryption-31 Thread-Index: AQHPxFQt46oyUhN9qUyAY7sezVzBjpvzIWwQ Date: Fri, 5 Sep 2014 23:13:05 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439AE9D53F@TK5EX14MBXC292.redmond.corp.microsoft.com> References: <3266E6F3-AB87-4B45-9C6F-A3B6976DBCEC@hyperthought.com> In-Reply-To: <3266E6F3-AB87-4B45-9C6F-A3B6976DBCEC@hyperthought.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.70] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439AE9D53FTK5EX14MBXC292r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019017)(438002)(51914003)(199003)(43784003)(13464003)(189002)(377454003)(52604005)(69234005)(107046002)(50986999)(84676001)(106116001)(4396001)(79102001)(81156004)(85806002)(2501002)(77982001)(106466001)(16236675004)(87936001)(33656002)(84326002)(574094002)(19300405004)(95666004)(46102001)(86362001)(92726001)(15975445006)(512884002)(86612001)(15202345003)(54356999)(16297215004)(85306004)(99396002)(31966008)(21056001)(76176999)(6806004)(19625215002)(83322001)(19617315012)(19580405001)(71186001)(83072002)(90102001)(2201001)(92566001)(230783001)(77096002)(64706001)(85852003)(74502001)(26826002)(55846006)(74662001)(81542001)(68736004)(19580395003)(80022001)(104016003)(76482001)(44976005)(20776003)(69596002)(81342001)(66066001)(2656002)(97736003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB619; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0325F6C77B Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/s83horBsWpHMTAueVJQBmjD4fRY X-Mailman-Approved-At: Fri, 05 Sep 2014 17:23:54 -0700 Cc: "jose@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-jose-json-web-encryption-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 23:14:14 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439AE9D53FTK5EX14MBXC292r_ Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Thanks for the useful review, Scott. I've cc'ed the working group in my re= ply so that they're aware of the contents of your review. Jim Schaad - als= o please see questions to you below. Replies are inline below... -----Original Message----- From: Scott Kelly [mailto:scott@hyperthought.com] Sent: Saturday, August 30, 2014 6:13 AM To: secdir@ietf.org; draft-ietf-jose-json-web-encryption.all@tools.ietf.org= ; iesg@ietf.org Subject: secdir review of draft-ietf-jose-json-web-encryption-31 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. >From the abstract, JSON Web Encryption (JWE) represents encrypted content u= sing JavaScript Object Notation (JSON) based data structures. A little like= CMS for web transactions. The security considerations section begins "All of the security issues that are pertinent to any cryptographic application must be addressed by JWS/JWE/JWK agents. Among these issues are protecting the user's asymmetric private and symmetric secret keys, preventing various attacks, and helping avoid mistakes such as inadvertently encrypting a message to the wrong recipient. The entire list of security considerations is beyond the scope of this document, but some significant considerations are listed here." "All the security considerations in the JWS specification also apply to this specification. Likewise, all the security considerations in XML Encryption 1.1 [W3C.REC-xmlenc-core1-20130411] also apply, other than those that are XML specific." If you are going to point to the JWS specification, you should use a normat= ive reference. It's fine to point at other references to avoid re-stating t= he obvious, but all security considerations *are* within scope, and require= coverage, either directly or by reference. I haven't reviewed the referenc= ed W3C spec, so I'm not sure that everything has been covered. The JWS secu= rity considerations section only talks about crypto algs and server identit= y verification. So, the ADs will want to pay attention here. We plan to remove the sentence "The entire list of security considerations = is beyond the scope of this document, but some significant considerations a= re listed here" since several reviewers have taken exception to it. I'm a bit confused by your comment about normative references, because the = JWS reference already is normative. Jim Schaad, etc., do you agree that the XMLENC reference should become norm= ative? I'd though that earlier you'd advised me that security consideratio= ns references should be informative. FYI, as part of addressing Russ Housley's comments on the Security Consider= ations section, I do expect to explicitly reference a number of security co= nsiderations called out in XMLENC, such as the text on chosen-ciphertext at= tacks, backwards compatibility attacks, etc. In section 5.1 (Message Encryption), step 16 says "Encrypt M..." without ev= er defining M. One might guess it stands for Message, but this should be st= ated. Agreed Section 8 (TLS Requirements) points at JWS, but neither document references= the channel binding problem. If you are depending on TLS to provide essent= ial and necessary security features (which, presumably, you are since TLS i= s a MUST), then you should give clear guidance as to how to effectively use= it. JWS requires combined confidentiality and integrity protection, and al= so requires server identity verification per RFC6125, but does not mention = channel binding. Scott, is there text on the channel binding problem in another specificatio= n that you'd recommend that we reference or use? If not, would you mind su= pplying proposed text for us to use? Section 11.1 (Using Matching Algorithm Strengths) says "Algorithms of matching strengths should be used together whenever possible. For instance, when AES Key Wrap is used with a given key size, using the same key size is recommended when AES GCM is also used." This doesn't quite scan for me, but editorial nits aside, it might be good = to say greater or equal key sizes should be used for wrapping. The "matching strengths" guidance came from Eric Rescorla and I believe was= supported by then-Security AD Sean Turner. It's not clear to me that the = =99 language is better than what's there now, in part because if the streng= ths don't match, it's not clear to me which way the inequality should go. And you might want to point to RFC3766 for BCPs when using public keys. The RFC 3766 reference looks like a good one. Thanks for providing it. Section 11.2 introduces the term "key tainting". "Strict key management/usa= ge policy" might be better understood. Also, it might be valuable to use SH= OULD here. Jim Schaad, you suggested using the term "key tainting". Is there a place = where this term is defined, which we could reference? Also, Jim, I believe in our in-person discussions of issue #70 (Review of 2= 119 Language) you'd suggested that we use 2119 keywords in the Security Con= siderations statements. Am I remembering that right, or would you prefer t= hat the Security Considerations sections use 2119 language? I was surprised not to see any mention of the lack of replay protection. TL= S channel binding could presumably be leveraged for this purpose, but in an= y event, the fact that JWEs can be replayed should be mentioned. It's not clear to me that being able to decrypt an encrypted object multipl= e times if you hold the correct key constitutes an attack, any more than be= ing able to check a signature multiple times does. I agree with you that some higher-level objects that may use JWE (or JWS) m= ay want replay protection. For instance, http://tools.ietf.org/html/draft-= ietf-oauth-json-web-token-25#section-4.1.7 describes a means of replay prot= ection for JWTs. At most, if we mention replay protection, I would propose= that we say that some applications using JWE encryption may choose to inco= rporate replay protection mechanisms, such as by including IDs in the prote= cted content that change with each application-level usage. Would that wor= k for you Scott, or is there something else you had in mind? As always, if you can supply specific proposed language to address your con= cern, that would probably be the clearest statement of what you'd like to s= ee. I would suggest that the authors read the security considerations in rfc565= 2; most of the same concerns apply here, and you could almost cut/paste fro= m there to here. Thanks. I expect to reference some of these as well when addressing Russ H= ousley's gen-art review comments of JWS. For the ADs: I'm not sure if one of the companion documents provides a comp= rehensive threat model, but you will want to pay attention here. This doc d= oes not. Each doc tries to list security considerations specific to that document an= d where they span documents, they are described in one and referenced in ot= hers. Thanks agai= n, Scott, -- Mike --_000_4E1F6AAD24975D4BA5B16804296739439AE9D53FTK5EX14MBXC292r_ Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable

Thanks for the usef= ul review, Scott. I’ve cc’ed the working group in my repl= y so that they’re aware of the contents of your review. Jim Schaad – also please see questions to you below. Replies are inl= ine below…

-----Original Message-----
From: Scott Kelly [mailto:scott@hyperthought.com]
Sent: Saturday, August 30, 2014 6:13 AM
To: secdir@ietf.org; draft-ietf-jose-json-web-encryption.all@tools.ietf.org= ; iesg@ietf.org
Subject: secdir review of draft-ietf-jose-json-web-encryption-31

I have reviewed this document as part of the secu= rity directorate's ongoing effort to review all IETF documents being proces= sed by the IESG. These comments were written primarily for the benefi= t of the security area directors. Document editors and WG chairs should treat these comments just like any other last= call comments.

From the abstract, JSON Web Encryption (JWE) repr= esents encrypted content using JavaScript Object Notation (JSON) based data= structures. A little like CMS for web transactions.

The security considerations section begins <= /o:p>

"All of the security issues tha= t are pertinent to any cryptographic

application must be addressed by JWS= /JWE/JWK agents. Among these

issues are protecting the user's asy= mmetric private and symmetric

secret keys, preventing various atta= cks, and helping avoid mistakes

such as inadvertently encrypting a m= essage to the wrong recipient.

The entire list of security consider= ations is beyond the scope of

this document, but some significant = considerations are listed here."

"All the security considerations in t= he JWS specification also apply

to this specification. Likewis= e, all the security considerations in

XML Encryption 1.1 [W3C.REC-xmlenc-c= ore1-20130411] also apply, other

than those that are XML specific.&qu= ot;

If you are going to point to the JWS specificatio= n, you should use a normative reference. It's fine to point at other refere= nces to avoid re-stating the obvious, but all security considerations *are*= within scope, and require coverage, either directly or by reference. I haven't reviewed the referenced W3C spe= c, so I'm not sure that everything has been covered. The JWS security consi= derations section only talks about crypto algs and server identity verifica= tion. So, the ADs will want to pay attention here.

We plan to remove t= he sentence “The entire list of security considerations is beyond the= scope of this document, but some significant considerations are listed her= e” since several reviewers have taken exception to it.

I’m a bit con= fused by your comment about normative references, because the JWS reference= already is normative.

Jim Schaad, etc., do you agree that the XMLENC reference shou= ld become normative? I’d though that earlier you’d advise= d me that security considerations references should be informative.

FYI, as part of add= ressing Russ Housley’s comments on the Security Considerations sectio= n, I do expect to explicitly reference a number of security considerations = called out in XMLENC, such as the text on chosen-ciphertext attacks, backwards compatibility attacks, etc.

In section 5.1 (Message Encryption), step 16 says= "Encrypt M..." without ever defining M. One might guess it stand= s for Message, but this should be stated.

Agreed

Section 8 (TLS Requirements) points at JWS, but n= either document references the channel binding problem. If you are dependin= g on TLS to provide essential and necessary security features (which, presu= mably, you are since TLS is a MUST), then you should give clear guidance as to how to effectively use it. JWS r= equires combined confidentiality and integrity protection, and also require= s server identity verification per RFC6125, but does not mention channel bi= nding.

Scott, is there tex= t on the channel binding problem in another specification that you’d = recommend that we reference or use? If not, would you mind supplying = proposed text for us to use?

Section 11.1 (Using Matching Algorithm Strengths)= says

"Algorithms of matching strengths sho= uld be used together whenever

possible. For instance, when A= ES Key Wrap is used with a given key

size, using the same key size is rec= ommended when AES GCM is also

used."

This doesn't quite scan for me, but editorial nit= s aside, it might be good to say greater or equal key sizes should be used = for wrapping.

The “matching= strengths” guidance came from Eric Rescorla and I believe was suppor= ted by then-Security AD Sean Turner. It’s not clear to me that = the =99 language is better than what’s there now, in part because if the s= trengths don’t match, it’s not clear to me which way the inequa= lity should go.

And you might want to point to RFC3766 for BCPs w= hen using public keys.

The RFC 3766 refere= nce looks like a good one. Thanks for providing it.=

Section 11.2 introduces the term "key tainti= ng". "Strict key management/usage policy" might be better un= derstood. Also, it might be valuable to use SHOULD here.

Jim Schaad, you suggested using the term “key tainting&= #8221;. Is there a place where this term is defined, which we could r= eference?

Also, Jim, I believe in = our in-person discussions of issue #70 (Review of 2119 Language) you’= d suggested that we use 2119 keywords in the Security Considerations statements. Am I remembering that right, or would you= prefer that the Security Considerations sections use 2119 language?

I was surprised not to see any mention of the lac= k of replay protection. TLS channel binding could presumably be leveraged f= or this purpose, but in any event, the fact that JWEs can be replayed shoul= d be mentioned.

It’s not clea= r to me that being able to decrypt an encrypted object multiple times if yo= u hold the correct key constitutes an attack, any more than being able to c= heck a signature multiple times does.

I agree with you th= at some higher-level objects that may use JWE (or JWS) may want replay prot= ection. For instance, http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-25#section-4.1.7= describes a means of replay protection for JWTs. At most, if we = mention replay protection, I would propose that we say that some applicatio= ns using JWE encryption may choose to incorporate replay protection mechanisms, such as by including IDs in the = protected content that change with each application-level usage. Woul= d that work for you Scott, or is there something else you had in mind?=

As always, if you c= an supply specific proposed language to address your concern, that would pr= obably be the clearest statement of what you’d like to see.

I would suggest that the authors read the securit= y considerations in rfc5652; most of the same concerns apply here, and you = could almost cut/paste from there to here.

Thanks. I exp= ect to reference some of these as well when addressing Russ Housley’s= gen-art review comments of JWS.

For the ADs: I'm not sure if one of the companion= documents provides a comprehensive threat model, but you will want to pay = attention here. This doc does not.

Each doc tries to l= ist security considerations specific to that document and where they span d= ocuments, they are described in one and referenced in others.

&= nbsp; &nbs= p; &= nbsp; &nbs= p; &= nbsp; Thanks again, S= cott,

&= nbsp; &nbs= p; &= nbsp; &nbs= p; &= nbsp; -- Mike

--_000_4E1F6AAD24975D4BA5B16804296739439AE9D53FTK5EX14MBXC292r_-- From nobody Fri Sep 5 17:23:59 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA0C1A03E5; Fri, 5 Sep 2014 16:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.369 X-Spam-Level: X-Spam-Status: No, score=-1.369 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668] autolearn=ham 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 mY1Af8pWK3_B; Fri, 5 Sep 2014 16:18:26 -0700 (PDT) Received: from mailgate.ece.upatras.gr (mailgate1.ece.upatras.gr [150.140.189.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61D321A03E2; Fri, 5 Sep 2014 16:18:25 -0700 (PDT) Received: from EhalepXPS (150.140.255.110) by mailgate1 (Axigen) with ESMTPA id 15649B; Sat, 6 Sep 2014 02:26:57 +0300 From: "Haleplidis Evangelos" To: "'Tom Yu'" , , , References: In-Reply-To: Date: Sat, 6 Sep 2014 02:18:10 +0300 Message-ID: <012f01cfc95f$ad1c1a90$07544fb0$@upatras.gr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac/GY8XSQz/uPOmfTiizh2BbHqkahQC8jZCgAAJojjA= Content-Language: el Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Fvx_t5yLBk2VQd2vkbGU6b0FhO8 X-Mailman-Approved-At: Fri, 05 Sep 2014 17:23:55 -0700 Subject: Re: [secdir] secdir review of draft-ietf-forces-model-extension-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 23:18:28 -0000 Greetings Tom, Thank you for the review. Please see inline. With regards, Evangelos > -----Original Message----- > From: Tom Yu [mailto:tlyu@mit.edu] > Sent: Tuesday, September 02, 2014 7:01 AM > To: iesg@ietf.org; secdir@ietf.org; draft-ietf-forces-model-=20 > extension.all@tools.ietf.org > Subject: secdir review of draft-ietf-forces-model-extension-04 >=20 > I have reviewed this document as part of the security directorate's=20 > ongoing effort to review all IETF documents being processed by the=20 > IESG. These comments were written primarily for the benefit of the=20 > security area directors. Document editors and WG chairs should treat=20 > these comments just like any other last call comments. >=20 > Summary: ready with nits >=20 > I find the Security Considerations section of this document to be=20 > reasonable. I agree that there is negligible security impact from the = > changes described in this document. >=20 > The capitalization is inconsistent for "DefaultValue" (in > typeDeclarationGroup) vs "defaultValue" (most other places). I think=20 > this poses no technical problem as written, but it could lead to=20 > surprises if human-written XML is validated against the schema=20 > (assuming I am correct in recalling that XML is case-sensitive). >=20 [=C5=C7] Actually that specific "DefaultValue" was redundant. I have = verified that and removed from the schema. Thank you for catching this. Now all defaultValue are consistent. > Editorial: >=20 > I found it difficult to identify the before/after differences in the=20 > schema fragments, especially when the quoted fragments are large. > Perhaps someone more familiar with XML schemas would not have this=20 > difficulty. I noticed that in some but not all of the schema=20 > fragments, the "" and <"!-- /Extension -->" comment=20 > annotations are helpfully used to mark portions of the schema that=20 > have changed. > Notably, in Figures 2 and 4, these annotations are missing. I would=20 > prefer that changes be shown in a "unified diff" style, but I know=20 > that is not idiomatic in the RFC format. >=20 [=C5=C7] Fixed figures 2 and 4. > It would also be a good idea to describe the "" > annotations in the text, to orient the reader to their use in the=20 > schema fragments. >=20 [=C5=C7] Done. > In Figure 4, the indentation seems incorrect and confusing. >=20 [=C5=C7] Fixed, thank you. > In Figure 5, I found the inclusion of extension annotations in the=20 > "original" excerpt from the schema to be confusing. The preceding=20 > paragraph does provide an explanation, but I wonder if it could be=20 > more clear. Figure 1 lacks this issue. >=20 [=C5=C7] Ok. To avoid confusion, I removed the extension from the = original excerpt and changed the text to specify that the new excerpt includes = both extensions. > In case future documents make further revisions to the schema, perhaps = > the extension comment annotations should include the RFC number of=20 > this document so that a reader may distinguish which changes took=20 > place in which documents. [=C5=C7] That's a very nice suggestion. I will add that. I will add: = Extension RFC XXXX and notify the RFC editor to change when appropriate. From nobody Fri Sep 5 17:29:05 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B98A31A06A3; Fri, 5 Sep 2014 17:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, J_CHICKENPOX_34=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 qm1_Z9VZUVeT; Fri, 5 Sep 2014 17:29:00 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0781.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:781]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ECAE1A0670; Fri, 5 Sep 2014 17:29:00 -0700 (PDT) Received: from CH1PR03CA006.namprd03.prod.outlook.com (10.255.156.151) by BN1PR0301MB0723.namprd03.prod.outlook.com (25.160.78.142) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Sat, 6 Sep 2014 00:28:36 +0000 Received: from BY2FFO11FD022.protection.gbl (10.255.156.132) by CH1PR03CA006.outlook.office365.com (10.255.156.151) with Microsoft SMTP Server (TLS) id 15.0.1019.16 via Frontend Transport; Sat, 6 Sep 2014 00:28:36 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD022.mail.protection.outlook.com (10.1.15.211) with Microsoft SMTP Server (TLS) id 15.0.1010.11 via Frontend Transport; Sat, 6 Sep 2014 00:28:35 +0000 Received: from TK5EX14MBXC292.redmond.corp.microsoft.com ([169.254.1.60]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.03.0195.002; Sat, 6 Sep 2014 00:28:22 +0000 From: Mike Jones To: Warren Kumari , "secdir@ietf.org" , "draft-ietf-oauth-json-web-token.all@tools.ietf.org" Thread-Topic: Review of: draft-ietf-oauth-json-web-token Thread-Index: AQHPxjXHxo1AOZ59oEC2WFnyXP3ehZvzMhKQ Date: Sat, 6 Sep 2014 00:28:21 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439AE9DB28@TK5EX14MBXC292.redmond.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.70] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439AE9DB28TK5EX14MBXC292r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019017)(438002)(189002)(377454003)(199003)(43784003)(51914003)(13464003)(51444003)(46102001)(64706001)(20776003)(81542001)(81342001)(2501002)(16236675004)(15395725005)(106466001)(86362001)(81156004)(92566001)(106116001)(2201001)(92726001)(512874002)(54356999)(77982001)(99396002)(79102001)(44976005)(50986999)(97736003)(76482001)(19580405001)(76176999)(6806004)(19580395003)(85306004)(55846006)(71186001)(68736004)(80022001)(19300405004)(83322001)(66066001)(69596002)(33656002)(31966008)(4396001)(26826002)(77096002)(90102001)(230783001)(95666004)(19617315012)(104016003)(19625215002)(74502001)(74662001)(84676001)(84326002)(85806002)(15202345003)(107046002)(86612001)(21056001)(2656002)(87936001)(15975445006)(85852003)(83072002)(372894003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR0301MB0723; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 03264AEA72 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/_MgHja4r5cfyUHAVryIKvpzL8vU Cc: "oauth@ietf.org" Subject: Re: [secdir] Review of: draft-ietf-oauth-json-web-token X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 00:29:04 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439AE9DB28TK5EX14MBXC292r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgdXNlZnVsIHJldmlldywgV2FycmVuLiAgSeKAmW0gY2PigJlpbmcgdGhl IHdvcmtpbmcgZ3JvdXAgc28gdGhleeKAmXJlIGF3YXJlIG9mIHRoZSBjb250ZW50cyBvZiB5b3Vy IHJldmlldy4gIFJlcGxpZXMgaW5saW5lIGJlbG934oCmDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogV2FycmVuIEt1bWFyaSBbbWFpbHRvOndhcnJlbkBrdW1hcmkubmV0 XQ0KU2VudDogTW9uZGF5LCBTZXB0ZW1iZXIgMDEsIDIwMTQgMzo0MCBQTQ0KVG86IHNlY2RpckBp ZXRmLm9yZzsgZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbi5hbGxAdG9vbHMuaWV0Zi5v cmcNClN1YmplY3Q6IFJldmlldyBvZjogZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbg0K DQoNCg0KQmUgeWUgbm90IGFmcmFpZCAtLSBJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBh cyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdzIG9uZ29pbmcgZWZmb3J0IHRvIHJl dmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLiAgVGhl c2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhl IHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLiAgRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJz IHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2Fs bCBjb21tZW50cy4NCg0KDQoNCkRpc2NsYWltZXI6IEkga25vdyBuZXh0IHRvIG5vdGhpbmcgYWJv dXQgSk9TRS4gSW4gcmVhZGluZyB0aGlzIGRvY3VtZW50IEkgYWxzbyB3ZW50IG9mZiBhbmQgcmVh ZCBzb21lIG90aGVyIEpPU0Ugd29yayAvIFdHIGRvY3VtZW50cy4NCg0KVGhlIG1haW4gdGhpbmcg dGhhdCBJIGxlYXJudCB3YXMgdGhhdCB0aGVtIHRoYXIgSk9TRSBmb2xrIHN1cmUgZG8gbGlrZSB0 aGVpciBhY3Jvbnltcy4uIDotKSBNeSB1bmZhbWlsaWFyaXR5IHdpdGggSk9TRSBtZWFucyB0aGF0 LCB1bmxpa2Ugd2hhdCB0aGUgYWJvdmUgYm9pbGVycGxhdGUgc2F5cywgeW91IHNob3VsZCB0cmVh dCB0aGVzZSBsZXNzIHNlcmlvdXNseSB0aGFuIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMh DQoNCg0KDQpTdW1tYXJ5Og0KDQpOZWVkcyBzb21lIHdvcmssIG5vdGhpbmcgbWFqb3IuDQoNCg0K DQpOb3RlczoNCg0KSW4gYSBudW1iZXIgb2YgcGxhY2VzIHRoZSBkb2N1bWVudCBzYXlzIHRoaW5n cyBsaWtlOiAiSWYgYW55IG9mIHRoZSBsaXN0ZWQgc3RlcHMgZmFpbHMgdGhlbiB0aGUgSldUIE1V U1QgYmUgcmVqZWN0ZWQgZm9yIHByb2Nlc3NpbmcuIiAtIGRvZXMgaXQgYWN0dWFsbHkgKm1lYW4q IHRvIHJlamVjdCBhIEpXVD8gV2hhdCBzaG91bGQgYW4gYXBwbGljYXRpb24gZG8gd2hlbiBpdCBy ZWplY3RzIGEgSlRXICh5ZXMsIEkgcmVhbGl6ZSB0aGF0IHRoaXMgaXMgc29tZXdoYXQgYXBwbGlj YXRpb24gc3BlY2lmaWMsIGJ1dCBhIGdlbmVyYWwgIkV4cGxvZGUsIGtpbGxpbmcgZXZlcnlib2R5 IGluc2lkZSIgdnMgIlNpbXBseSBwcmV0ZW5kIHlvdSBkaWRuJ3Qgbm90aWNlIHRoaXMiIHdvdWxk IGJlIGhlbHBmdWwpLg0KDQoNCg0KQXMgeW91IHBvaW50IG91dCwgd2hhdCBpdCBtZWFucyB0byBy ZWplY3QgdGhlIEpXUyBpcyBhY3R1YWxseSBhcHBsaWNhdGlvbiBzcGVjaWZpYywgc28gaXTigJlz IG5vdCBjbGVhciB3aGF0IGVsc2UgdG8gc2F5IGluIHRoaXMgcmVnYXJkIGluIHRoZSBzcGVjaWZp Y2F0aW9uLiAgSSBzdXBwb3NlIHRoYXQgd2UgY291bGQgc2F5IHRoYXQgaXQgbXVzdCBiZSByZWpl Y3RlZCBieSB0aGUgYXBwbGljYXRpb24gYW5kIGxlYXZlIGl0IGF0IHRoYXQuICBXb3VsZCB0aGF0 IHdvcmsgZm9yIHlvdT8NCg0KDQoNCkknbSBhIGxpdHRsZSBjb25mdXNlZCBieSBzb21ldGhpbmcg aW4gdGhlIFRlcm1pbm9sb2d5IHNlY3Rpb24gKFNlY3Rpb24gMik6DQoNClBsYWludGV4dCBKV1QN Cg0KQSBKV1Qgd2hvc2UgQ2xhaW1zIGFyZSBub3QgaW50ZWdyaXR5IHByb3RlY3RlZCBvciBlbmNy eXB0ZWQuDQoNCg0KDQpUaGUgdGVybSBwbGFpbnRleHQgdG8gbWUgbWVhbnMgc29tZXRoaW5nIGxp a2UgImlzIHJlYWRhYmxlIHdpdGhvdXQgZGVjcnlwdGluZyAvIG11Y2ggZGVjb2RpbmciIChzb21l dGhpbmcgbGlrZSwgaWYgeW91IGNhdCB0aGUgZmlsZSB0byBhIHRlcm1pbmFsLCB5b3Ugd2lsbCBz ZWUgdGhlIGluZm9ybWF0aW9uKS4gSW50ZWdyaXR5IHByb3RlY3RpbmcgYSBzdHJpbmcgZG9lc24n dCBtYWtlIGl0IG5vdCBlYXNpbHkgcmVhZGFibGUuIElmIHRoaXMgZG9jdW1lbnQgLyBKT1NFIHVz ZXMgInBsYWludGV4dCIgZGlmZmVyZW50bHkgKGFuZCBhIHF1aWNrIHNraW0gZGlkbid0IGZpbmQg YW55dGhpbmcgYWJvdXQNCg0KdGhpcykgaXQgbWlnaHQgYmUgZ29vZCB0byBjbGFyaWZ5LiBTZWN0 aW9uIDYgKmRvZXMqIGRpc2N1c3MgcGxhaW50ZXh0IEpXVHMsIGJ1dCBkb2Vzbid0IHJlYWxseSBj bGFyaWZ5IHRoZSAoSU1PKSB1bnVzdWFsIG1lYW5pbmcgb2YgdGhlIHRlcm0gInBsYWludGV4dCIg aGVyZS4NCg0KDQoNCknigJl2ZSBkaXNjdXNzZWQgdGhpcyB3aXRoIHRoZSBvdGhlciBkb2N1bWVu dCBlZGl0b3JzIGFuZCB3ZSBhZ3JlZSB3aXRoIHlvdSB0aGF0IOKAnHBsYWludGV4dOKAnSBpcyBu b3QgdGhlIG1vc3QgaW50dWl0aXZlIHdvcmRpbmcgY2hvaWNlIGluIHRoaXMgY29udGV4dC4gIFBv c3NpYmxlIGFsdGVybmF0aXZlIHRlcm1zIGFyZSDigJxVbnNlY3VyZWQgSldU4oCdIG9yIOKAnFVu c2lnbmVkIEpXVOKAnS4gIEkgdGhpbmsgdGhhdCDigJxVbnNlY3VyZWQgSldU4oCdIGlzIHByb2Jh Ymx5IHRoZSBwcmVmZXJyZWQgdGVybSwgc2luY2UgSldUcyB0aGF0IGFyZSBKV0VzIGFyZSBhbHNv IHVuc2lnbmVkLCBidXQgdGhleSBhcmUgc2VjdXJlZC4gIFdvcmtpbmcgZ3JvdXAg4oCTIGFyZSB5 b3UgT0sgd2l0aCB0aGlzIHBvc3NpYmxlIHRlcm1pbm9sb2d5IGNoYW5nZT8gIChOb3RlIHRoYXQg dGhlIHBhcmFsbGVsIGNoYW5nZSDigJxQbGFpbnRleHQgSldT4oCdIC0+IOKAnFVuc2VjdXJlZCBK V1PigJ0gd291bGQgYWxzbyBiZSBtYWRlIGluIHRoZSBKV1Mgc3BlYy4pDQoNCg0KDQpNQUNlZCBk b2VzIG5vdCBzZWVtIHRvIGJlIGEgd2VsbCBrbm93biB0ZXJtIC0gc3VycHJpc2luZ2x5IGVub3Vn aCBldmVuIE1BQyBkb2Vzbid0IGhhdmUgYW4gYXN0ZXJpc2sgYXQgaHR0cHM6Ly93d3cucmZjLWVk aXRvci5vcmcvcmZjLXN0eWxlLWd1aWRlL2FiYnJldi5leHBhbnNpb24udHh0DQoNCg0KDQpEbyB5 b3UgaGF2ZSBhbm90aGVyIHN1Z2dlc3Rpb24gdG8gcmVwbGFjZSDigJxNQUNlZOKAnSBhbmQg4oCc TUFDaW5n4oCdLCBvdGhlciB0aGFuIHZlcmJvc2UgZm9ybXVsYXRpb25zIGxpa2Ug4oCcdGhhdCBo YXZlIGEgTUFDIGFwcGxpZWQgdG8gdGhlbeKAnT8gIEdpdmVuIHRoYXQgaW4gRW5nbGlzaCB1c2Fn ZSBpdOKAmXMgY29tbW9uIHRvIOKAnHZlcmIgYSBub3Vu4oCdIChlLmcuLCB1c2FnZSBvZiB0aGUg dmVyYiDigJxHb29nbGXigJ0pLCBJIGRvbuKAmXQgdGhpbmsgdGhlcmXigJlzIGFjdHVhbGx5IGFu eSBhbWJpZ3VpdHkgYXMgdG8gdGhlIGludGVuZGVkIG1lYW5pbmcuDQoNCg0KDQpTZWN0aW9uIDQ6 DQoNCiIuLi4gIHJlY2lwaWVudHMgTVVTVCBlaXRoZXIgcmVqZWN0IEpXVHMgd2l0aCBkdXBsaWNh dGUgIENsYWltIE5hbWVzIG9yIHVzZSBhIEpTT04gcGFyc2VyIHRoYXQgcmV0dXJucyBvbmx5IHRo ZSBsZXhpY2FsbHkgbGFzdCAgZHVwbGljYXRlIG1lbWJlciBuYW1lLi4uIg0KDQoNCg0KVGhpcyBz b21ld2hhdCBtYWRlIG1lIGl0Y2ggLSBzb21lIGltcGxlbWVudGF0aW9ucyB3aWxsIHJlamVjdCBh IGdpdmVuIEpXVCwgc29tZSB3aWxsIGFjY2VwdCBpdCAtLSBJIGtub3cgdmVyeSBsaXR0bGUgYWJv dXQgcGFyc2luZyBKU09OLCBidXQgY291bGQgeW91IHN1Z2dlc3Qgd2hpY2ggYW4gaW1wbGVtZW50 YXRpb24gc2hvdWxkIHByZWZlcj8gQ2FuIEkgaW5zdHJ1Y3Qgc3RhbmRhcmQgcGFyc2VycyB0byBk byBYIGluIHRoaXMgY2FzZT8NCg0KDQoNCkkgdW5kZXJzdGFuZCB0aGUgaXRjaHkgZmVlbGluZy4g 4pi6DQoNCg0KDQpVbmZvcnR1bmF0ZWx5LCB0aGUgaW50ZW50aW9uYWwgbGF4bmVzcyBpbiB0aGUg c3BlYyBpbiB0aGlzIHJlZ2FyZCBpcyBhIHJlZmxlY3Rpb24gb2YgdGhlIHNlbWFudGljcyBvZiB0 aGUgYWN0dWFsIEpTT04gc3BlY2lmaWNhdGlvbnMgYW5kIGltcGxlbWVudGF0aW9ucy4gIEZvciBp bnN0YW5jZSwgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzE1OSNzZWN0aW9uLTQgc2F5 czoNCg0KDQogICBBbiBvYmplY3Qgd2hvc2UgbmFtZXMgYXJlIGFsbCB1bmlxdWUgaXMgaW50ZXJv cGVyYWJsZSBpbiB0aGUgc2Vuc2UNCiAgIHRoYXQgYWxsIHNvZnR3YXJlIGltcGxlbWVudGF0aW9u cyByZWNlaXZpbmcgdGhhdCBvYmplY3Qgd2lsbCBhZ3JlZSBvbg0KICAgdGhlIG5hbWUtdmFsdWUg bWFwcGluZ3MuICBXaGVuIHRoZSBuYW1lcyB3aXRoaW4gYW4gb2JqZWN0IGFyZSBub3QNCiAgIHVu aXF1ZSwgdGhlIGJlaGF2aW9yIG9mIHNvZnR3YXJlIHRoYXQgcmVjZWl2ZXMgc3VjaCBhbiBvYmpl Y3QgaXMNCiAgIHVucHJlZGljdGFibGUuICBNYW55IGltcGxlbWVudGF0aW9ucyByZXBvcnQgdGhl IGxhc3QgbmFtZS92YWx1ZSBwYWlyDQogICBvbmx5LiAgT3RoZXIgaW1wbGVtZW50YXRpb25zIHJl cG9ydCBhbiBlcnJvciBvciBmYWlsIHRvIHBhcnNlIHRoZQ0KICAgb2JqZWN0LCBhbmQgc29tZSBp bXBsZW1lbnRhdGlvbnMgcmVwb3J0IGFsbCBvZiB0aGUgbmFtZS92YWx1ZSBwYWlycywNCiAgIGlu Y2x1ZGluZyBkdXBsaWNhdGVzLg0KDQoNCg0KVGhpcyB0b3BpYyBoYXMgYmVlbiBoZWF2aWx5IGRp c2N1c3NlZCBieSB0aGUgd29ya2luZyBncm91cCwgYW5kIHdoaWxlIHRoZSBzcGVjcyB1c2VkIHRv IGp1c3Qgc2F5IHRoYXQgb2JqZWN0cyB3aXRoIGR1cGxpY2F0ZSBtZW1iZXIgbmFtZXMgTVVTVCBi ZSByZWplY3RlZCwgd29ya2luZyBncm91cCBtZW1iZXJzLCBpbmNsdWRpbmcgVGltIEJyYXkgKHRo ZSBlZGl0b3Igb2YgdGhlIEpTT04gc3BlYyksIHByZXZhaWxlZCBvbiB1cyB0byB3ZWFrZW4gdGhp cyBzbyB0aGF0IHBhcnNlcnMgdGhhdCBpbXBsZW1lbnQgdGhlIEVDTUFzY3JpcHQgYmVoYXZpb3Ig b2YgcmV0dXJuaW5nIG9ubHkgdGhlIGxhc3QgbWVtYmVyIG5hbWUgbWF5IGJlIGxlZ2FsbHkgdXNl ZC4gIChUaGUgYXJndW1lbnQgd2FzIG1hZGUgdGhhdCB0aGVyZSB3YXMgbW9yZSBzZWN1cml0eSBk b3duc2lkZSBpbiBlZmZlY3RpdmVseSByZXF1aXJpbmcgcGVvcGxlIHRvIHdyaXRlIGFuZCBkZWJ1 ZyB0aGVpciBvd24gc3RyaWN0IHBhcnNlcnMgdGhhbiBpbiB1c2luZyBsYXhlciwgYnV0IHdlbGwt c3VwcG9ydGVkIGFuZCBkZWJ1Z2dlZCBwYXJzZXJzLikNCg0KDQoNCkhvd2V2ZXIsIHdlIGFsc28g aW50ZW50aW9uYWxseSByZXF1aXJlIHRoYXQgcHJvZHVjZXJzIHVzZSBvbmx5IG9uZSBpbnN0YW5j ZSBvZiBlYWNoIG1lbWJlciBuYW1lLCBzbyB0aGF0IGxlZ2FsbHkgcHJvZHVjZWQgb2JqZWN0cyB3 aWxsIG5ldmVyIGV4ZXJjaXNlIHRoZSBhbWJpZ3VpdGllcyB0aGF0IGFyZSBwcmVzZW50IGluIHJl YWwgSlNPTiBwYXJzZXJzLiAgVGhhdCBzZWVtZWQgdG8gYmUgdGhlIG1vc3QgcHJhY3RpY2FsIHNv bHV0aW9uIHRvIHRoZSB3b3JraW5nIGdyb3VwLg0KDQoNCg0KU2VjdGlvbiA0LjEuNC4gImV4cCIg KEV4cGlyYXRpb24gVGltZSkgQ2xhaW0gKGFuZCBvdGhlciB0aW1lIGJhc2VkIENsYWltczoNCg0K V2hhdCBzaG91bGQgbXkgYmVoYXZpb3IgYmUgaWYgSSBzaW1wbHkgZG9uJ3Qga25vdyB3aGF0IHRo ZSB0aW1lIGlzPw0KDQooSSdtIGp1c3QgYSBkdW1iIGRldmljZSwgYW5kIG15IFJUQyBpcyBjbGFp bWluZyBpdCBpcyBKYW4xc3QsIDE5NzApIC0gSSdtIGFzc3VtaW5nIEkgbXVzdCBub3QgcHJvY2Vz cyB0aGlzIEpXVD8gRG9lcyB0aGlzIGNyZWF0ZSBib290c3RyYXBwaW5nIGlzc3Vlcz8NCg0KDQoN ClRoZSB1c2Ugb2YgYWxsIGNsYWltcyBpcyBvcHRpb25hbC4gIEl04oCZcyB1cCB0byBhcHBsaWNh dGlvbnMgd2hpY2ggb25lcyBtYWtlIHNlbnNlIGZvciB0aGVtIHRvIHVzZS4gIEluIHVzZSBjYXNl cyBpbiB3aGljaCBwYXJ0aWNpcGFudHMgZG9u4oCZdCBrbm93IHRoZSB0aW1lLCBlaXRoZXIgdGhp cyBjbGFpbSB3b3VsZCBub3QgYmUgdXNlZCBieSB0aGUgYXBwbGljYXRpb24gb3IgdGhlIGFwcGxp Y2F0aW9uIHdvdWxkIG5lZWQgdG8gZGVmaW5lIGFwcGxpY2F0aW9uLXNwZWNpZmljIGJlaGF2aW9y cyBmb3Igd2hhdCB0byBkbyBpbiB0aG9zZSBjYXNlcy4NCg0KDQoNCjUuMy4gUmVwbGljYXRpbmcg Q2xhaW1zIGFzIEhlYWRlciBQYXJhbWV0ZXJzIFRoaXMgc2VjdGlvbiBzY2FyZXMgbWUsIGFuZCBJ IGhvcGUgSSdtIHNpbXBseSBub3QgdW5kZXJzdGFuZGluZyB3aGF0IGlzIGJlaW5nIHByb3Bvc2Vk LiBJZiB5b3Ugc2VuZCB0aGUgdW5lbmNyeXB0ZWQgdmVyc2lvbiBvZiBzb21lIGVuY3J5cHRlZCBD bGFpbXMgc29tZSBpbXBsZW1lbnRhdGlvbnMgd2lsbCBtYWtlIGltcG9ydGFudCBzZWN1cml0eSBk ZWNpc2lvbnMgYmFzZWQgdXBvbiB0aG9zZSB1bmVuY3J5cHRlZCBjbGFpbXMsIGV2ZW4gaWYgeW91 IHRlbGwgdGhlbSBpbiBhIHNlcmlvdXMgdm9pY2Ugbm90IHRvLiBodHRwOi8veGtjZC5jb20vMTE4 MS8NCg0KDQoNCkZvciB3aGF0IGl04oCZcyB3b3J0aCwgdGhlIGNvbnRleHQgaW4gd2hpY2ggdGhp cyBhcm9zZSB3YXMgd2hlbiBhcHBsaWNhdGlvbiB1c2VkIGludGVybWVkaWF0ZSBzb2Z0d2FyZSB0 aGF0IGluc3BlY3RlZCB0aGUgYXVkaWVuY2Ugb2YgYW4gZW5jcnlwdGVkIEpXVCBpbiBvcmRlciB0 byByb3V0ZSBpdCB0byB0aGUgY29ycmVjdCByZWNpcGllbnQuICBPbmx5IHRoZSByZWNpcGllbnQg aGFzIHRoZSBrZXkgdG8gZGVjcnlwdCB0aGUgSldUIGFuZCBsb29rIGF0IHRoZSBlbmNyeXB0ZWQg YXVkaWVuY2UgdmFsdWUuICBCdXQgYnkgcGxhY2luZyBhbiB1bmVuY3J5cHRlZCBjb3B5IG9mIHRo ZSBhdWRpZW5jZSBpbiB0aGUgaGVhZGVyLCB0aGUgcm91dGluZyBzb2Z0d2FyZSBjb3VsZCBpbnNw ZWN0IGl0IGFuZCByb3V0ZSBpdCBjb3JyZWN0bHkuICBUaGlzIHNlZW1lZCB0byB0aGUgd29ya2lu ZyBncm91cCBsaWtlIGEgbGVnaXRpbWF0ZSB1c2UgY2FzZSwgYW5kIHNvIHdlIGRlY2lkZWQgdG8g c3VwcG9ydCBpdC4gIFRoaXMgZmVhdHVyZSB3YXMgcHJvcG9zZWQgYW5kIGRpc2N1c3NlZCBpbiB0 aGlzIHRocmVhZDogaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1 cnJlbnQvbXNnMTEzMTUuaHRtbC4NCg0KDQoNCkFsc28sIHRoZSBTSE9VTEQgaW4gIklmIHN1Y2gg cmVwbGljYXRlZCBDbGFpbXMgYXJlIHByZXNlbnQsIHRoZSBhcHBsaWNhdGlvbiByZWNlaXZpbmcg dGhlbSBTSE9VTEQgdmVyaWZ5IHRoYXQgdGhlaXIgdmFsdWVzIGFyZSBpZGVudGljYWwsIC4uLiIg LSB3aHkgaXMgdGhpcyBub3QgYSBNVVNUPyBBbmQgaWYgYW4gYXBwbGljYXRpb24gKmRvZXMqIGNv bXBhcmUgdGhlbSBhbmQgdGhleSBhcmUgbm90IGlkZW50aWNhbCwgd2hhdCBzaG91bGQgaXQgZG8/ ICBQZXJoYXBzIGEgbXVjaCBzdHJvbmdlciBqdXN0aWZpY2F0aW9uIGZvciBjYXJyeWluZyAyIGNv cGllcyBvZiB0aGUgZGF0YSBpcyBpbiBvcmRlci4NCg0KDQoNClRoZSB0ZXh0IHJpZ2h0IGFmdGVy IHRoaXMgaW4gdGhlIHNwZWMgYWxyZWFkeSBhbnN3ZXJzIHRoaXMgcXVlc3Rpb246IOKAnHVubGVz cyB0aGUgYXBwbGljYXRpb24gZGVmaW5lcyBvdGhlciBzcGVjaWZpYyBwcm9jZXNzaW5nIHJ1bGVz IGZvciB0aGVzZSBDbGFpbXPigJ0uICBJdOKAmXMgYSDigJxTSE9VTETigJ0gYmVjYXVzZSBhcHBs aWNhdGlvbnMgbWlnaHQgbmVlZCB0byBkbyB0aGlzLg0KDQoNCg0KRWRpdG9yaWFsOg0KDQpUaGUg aW50cm8gaXMgYWxtb3N0IGlkZW50aWNhbCB0byB0aGUgYWJzdHJhY3QuIE1ha2luZyB0aGUgYWJz dHJhY3QgbW9yZSBhYnN0cmFjdCwgb3IgdGhlIGludHJvIG1vcmUgaW50cm9kdWN0b3J5IChJIGhh dmUgbm8gaWRlYSB3aGF0IG1hbnkgb2YgdGhlIGFjcm9ueW1zIHdlcmUhKSB3b3VsZCBiZSBuaWNl LiBTb21ldGhpbmcgc2hvcnQgZXhwbGFpbmluZyB3aGF0IGEgSldUIGlzLCB3aHkgSSdkIGxpa2Ug b25lLHdoYXQgdGhleSBnZXQgdXNlZCBmb3IsIHdoeSBJIHNob3VsZCBrZWVwIHJlYWRpbmcgdGhp cyBkb2N1bWVudCB3b3VsZCBiZSB2ZXJ5IGhlbHBmdWwgLSBiYXNpY2FsbHkgYSBiYWNrZ3JvdW5k IHR5cGUgc2VjdGlvbi4uLg0KDQoNCg0KU3BlY2lmaWMgd29yZGluZyBzdWdnZXN0aW9ucyB3b3Vs ZCBiZSB3ZWxjb21lZC4gIEFzIGZvciBub3Qga25vd2luZyB3aGF0IHRoZSBhY3JvbnltcyBhcmUs IEnigJltIHRvbGQgdGhhdCB0aGUgc3R5bGUgZ3VpZGVzIGRvbuKAmXQgYWxsb3cgcmVmZXJlbmNl cyB0byBiZSBwdXQgaW4gdGhlIGFic3RyYWN0LiAgT3RoZXJ3aXNlLCBmb3IgaW5zdGFuY2UsIHRo ZXJlIHdvdWxkIGJlIGEgcmVmZXJlbmNlIHRoZXJlIHRvIFJGQyA3MTU5IHNvIHBlb3BsZSB3aG8g ZG9u4oCZdCBrbm93IHdoYXQgSlNPTiBpcyBrbm93IHdoZXJlIHRvIGxvb2sgdG8gZ28gZmluZCBv dXQuDQoNCg0KDQpOaXRzOg0KDQpBYnN0cmFjdA0KDQpPOiBpcyBhIGNvbXBhY3QgVVJMLXNhZmUg bWVhbnMNCg0KUDogaXMgYSBjb21wYWN0LCBVUkwtc2FmZSBtZWFucw0KDQoNCg0KVGhhbmtzDQoN Cg0KDQozLiAgSlNPTiBXZWIgVG9rZW4gKEpXVCkgT3ZlcnZpZXcNCg0KTzogVGhlIGNvbnRlbnRz IG9mIHRoZSBKT1NFIEhlYWRlciBkZXNjcmliZQ0KDQpQOiBTcGVsbCBvdXQgSk9TRTsgZmlyc3Qg dXNlIGluIGRvY3VtZW50IGFzIGZhciBhcyBJIGNvdWxkIHNlZQ0KDQoNCg0KQWN0dWFsbHksIHRo ZSBmaXJzdCB1c2Ugb2YgdGhlIHRlcm0g4oCcSk9TRSBIZWFkZXLigJ0gaXMgaW4gU2VjdGlvbiAy IChUZXJtaW5vbG9neSksIHdoZXJlIGl0IGlzIGluY29ycG9yYXRlZCBpbnRvIHRoaXMgc3BlY2lm aWNhdGlvbiBieSByZWZlcmVuY2UuDQoNCjUuMiAiY3R5IiAoQ29udGVudCBUeXBlKSBIZWFkZXIg UGFyYW1ldGVyDQoNCk86IG5vcm1hbCBjYXNlIHdoZXJlIG5lc3RlZCBzaWduaW5nDQoNClA6IG5v cm1hbCBjYXNlIGluIHdoaWNoIG5lc3RlZCBzaWduaW5nDQoNCg0KDQpUaGFua3MNCg0KDQoNCjgu ICBJbXBsZW1lbnRhdGlvbiBSZXF1aXJlbWVudHMNCg0KTzogRm9yIGluc3RhbmNlLCBhbiBhcHBs aWNhdGlvbiBtaWdodCByZXF1aXJlIHN1cHBvcnQNCg0KICAgZm9yIGVuY3J5cHRlZCBKV1RzIGFu ZCBOZXN0ZWQgSldUczsgYW5vdGhlciBtaWdodCByZXF1aXJlIHN1cHBvcnQNCg0KUDogRm9yIGlu c3RhbmNlLCBvbmUgYXBwbGljYXRpb24gbWlnaHQgcmVxdWlyZSBzdXBwb3J0IFsuLi5dLCB3aGls ZSBhbm90aGVyIG1pZ2h0IHJlcXVpcmUgc3VwcG9ydCBbLi4uXQ0KDQoNCg0KVGhhbmtzDQoNCg0K DQoxMS4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCg0KTzogVGhlIGVudGlyZSBsaXN0IG9mIHNl Y3VyaXR5IGNvbnNpZGVyYXRpb25zIGlzIGJleW9uZCB0aGUgc2NvcGUgb2YNCg0KICAgdGhpcyBk b2N1bWVudCwgYnV0IHNvbWUgc2lnbmlmaWNhbnQgY29uc2lkZXJhdGlvbnMgYXJlIGxpc3RlZCBo ZXJlLg0KDQpQOiBUaGUgZW50aXJlIGxpc3Qgb2Ygc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgaXMg YmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50Lg0KDQpSOiBBIGZldyBvZiB0aGUgY29u c2lkZXJhdGlvbnMgYXJlIGFscmVhZHkgbGlzdGVkIGFib3ZlOyB3ZSBkb24ndCBuZWVkIHRvIHJl c3RhdGUgdGhhdCB0aGV5IGFyZSBsaXN0ZWQgaGVyZSAtLSBhbmQgaWYgd2UgZG8sIHRoZSBhc3N1 bXB0aW9uIGlzIHRoYXQgc2FpZCBsaXN0IHdvdWxkIGZvbGxvdywgbm90IGJlIGFib3ZlLg0KDQoN Cg0KU2V2ZXJhbCByZXZpZXdlcnMgaGF2ZSBvYmplY3RlZCB0byB0aGlzIHNlbnRlbmNlLiAgSXRz IHJlbW92YWwgaXMgcGxhbm5lZC4NCg0KDQoNCjExLjIgU2lnbmluZyBhbmQgRW5jcnlwdGlvbiBP cmRlcg0KDQpPOiBXaGlsZSBzeW50YWN0aWNhbGx5LCB0aGUgc2lnbmluZyBhbmQgZW5jcnlwdGlv biBvcGVyYXRpb25zIGZvciBOZXN0ZWQNCg0KICAgSldUcyBtYXkgYmUgYXBwbGllZCBpbiBhbnkg b3JkZXIsDQoNClA6IFdoaWxlIHN5bnRhY3RpY2FsbHkgdGhlIHNpZ25pbmcgYW5kIGVuY3J5cHRp b24gb3BlcmF0aW9ucyBmb3IgTmVzdGVkDQoNCiAgIEpXVHMgbWF5IGJlIGFwcGxpZWQgaW4gYW55 IG9yZGVyLA0KDQoNCg0KVGhhbmtzDQoNCg0KDQotLQ0KDQpJIGRvbid0IHRoaW5rIHRoZSBleGVj dXRpb24gaXMgcmVsZXZhbnQgd2hlbiBpdCB3YXMgb2J2aW91c2x5IGEgYmFkIGlkZWEgaW4gdGhl IGZpcnN0IHBsYWNlLg0KDQpUaGlzIGlzIGxpa2UgcHV0dGluZyByYWJpZCB3ZWFzZWxzIGluIHlv dXIgcGFudHMsIGFuZCBsYXRlciBleHByZXNzaW5nIHJlZ3JldCBhdCBoYXZpbmcgY2hvc2VuIHRo b3NlIHBhcnRpY3VsYXIgcmFiaWQgd2Vhc2VscyBhbmQgdGhhdCBwYWlyIG9mIHBhbnRzLg0KDQog ICAtLS1tYWYNCg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBUaGFua3MgYWdhaW4sIFdhcnJlbiwNCg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0t IE1pa2UNCg0KDQo= --_000_4E1F6AAD24975D4BA5B16804296739439AE9DB28TK5EX14MBXC292r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0 ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5U ZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1l OiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9 DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZv cm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+VGhh bmtzIGZvciB0aGUgdXNlZnVsIHJldmlldywgV2FycmVuLiZuYnNwOyBJ4oCZbSBjY+KAmWluZyB0 aGUgd29ya2luZyBncm91cCBzbyB0aGV54oCZcmUgYXdhcmUgb2YgdGhlIGNvbnRlbnRzIG9mIHlv dXIgcmV2aWV3LiZuYnNwOyBSZXBsaWVzIGlubGluZSBiZWxvd+KApjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMw Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4t LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IFdhcnJlbiBLdW1hcmkgW21haWx0 bzp3YXJyZW5Aa3VtYXJpLm5ldF0gPGJyPg0KU2VudDogTW9uZGF5LCBTZXB0ZW1iZXIgMDEsIDIw MTQgMzo0MCBQTTxicj4NClRvOiBzZWNkaXJAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtb2F1dGgtanNv bi13ZWItdG9rZW4uYWxsQHRvb2xzLmlldGYub3JnPGJyPg0KU3ViamVjdDogUmV2aWV3IG9mOiBk cmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRva2VuPC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5CZSB5ZSBu b3QgYWZyYWlkIC0tIEkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhl IHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3Mgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRG IGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuJm5ic3A7IFRoZXNlIGNvbW1l bnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0 eSBhcmVhDQogZGlyZWN0b3JzLiZuYnNwOyBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMg c2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxs IGNvbW1lbnRzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5EaXNjbGFpbWVyOiBJIGtu b3cgbmV4dCB0byBub3RoaW5nIGFib3V0IEpPU0UuIEluIHJlYWRpbmcgdGhpcyBkb2N1bWVudCBJ IGFsc28gd2VudCBvZmYgYW5kIHJlYWQgc29tZSBvdGhlciBKT1NFIHdvcmsgLyBXRyBkb2N1bWVu dHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGUgbWFpbiB0aGlu ZyB0aGF0IEkgbGVhcm50IHdhcyB0aGF0IHRoZW0gdGhhciBKT1NFIGZvbGsgc3VyZSBkbyBsaWtl IHRoZWlyIGFjcm9ueW1zLi4gOi0pIE15IHVuZmFtaWxpYXJpdHkgd2l0aCBKT1NFIG1lYW5zIHRo YXQsIHVubGlrZSB3aGF0IHRoZSBhYm92ZSBib2lsZXJwbGF0ZSBzYXlzLCB5b3Ugc2hvdWxkIHRy ZWF0IHRoZXNlIGxlc3Mgc2VyaW91c2x5IHRoYW4gYW55IG90aGVyIGxhc3QgY2FsbA0KIGNvbW1l bnRzITxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5TdW1tYXJ5OjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+TmVlZHMgc29tZSB3b3JrLCBub3RoaW5nIG1ham9y LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Ob3Rlczo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPkluIGEgbnVtYmVyIG9mIHBsYWNlcyB0aGUgZG9jdW1lbnQg c2F5cyB0aGluZ3MgbGlrZTogJnF1b3Q7SWYgYW55IG9mIHRoZSBsaXN0ZWQgc3RlcHMgZmFpbHMg dGhlbiB0aGUgSldUIE1VU1QgYmUgcmVqZWN0ZWQgZm9yIHByb2Nlc3NpbmcuJnF1b3Q7IC0gZG9l cyBpdCBhY3R1YWxseSAqbWVhbiogdG8gcmVqZWN0IGEgSldUPyBXaGF0IHNob3VsZCBhbiBhcHBs aWNhdGlvbiBkbyB3aGVuIGl0IHJlamVjdHMgYSBKVFcgKHllcywNCiBJIHJlYWxpemUgdGhhdCB0 aGlzIGlzIHNvbWV3aGF0IGFwcGxpY2F0aW9uIHNwZWNpZmljLCBidXQgYSBnZW5lcmFsICZxdW90 O0V4cGxvZGUsIGtpbGxpbmcgZXZlcnlib2R5IGluc2lkZSZxdW90OyB2cyAmcXVvdDtTaW1wbHkg cHJldGVuZCB5b3UgZGlkbid0IG5vdGljZSB0aGlzJnF1b3Q7IHdvdWxkIGJlIGhlbHBmdWwpLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+ QXMgeW91IHBvaW50IG91dCwgd2hhdCBpdCBtZWFucyB0byByZWplY3QgdGhlIEpXUyBpcyBhY3R1 YWxseSBhcHBsaWNhdGlvbiBzcGVjaWZpYywgc28gaXTigJlzIG5vdCBjbGVhciB3aGF0IGVsc2Ug dG8gc2F5IGluIHRoaXMgcmVnYXJkIGluIHRoZSBzcGVjaWZpY2F0aW9uLiZuYnNwOyBJIHN1cHBv c2UgdGhhdCB3ZSBjb3VsZCBzYXkgdGhhdCBpdCBtdXN0IGJlIHJlamVjdGVkDQogYnkgdGhlIGFw cGxpY2F0aW9uIGFuZCBsZWF2ZSBpdCBhdCB0aGF0LiZuYnNwOyBXb3VsZCB0aGF0IHdvcmsgZm9y IHlvdT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkknbSBhIGxpdHRsZSBj b25mdXNlZCBieSBzb21ldGhpbmcgaW4gdGhlIFRlcm1pbm9sb2d5IHNlY3Rpb24gKFNlY3Rpb24g Mik6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5QbGFpbnRleHQgSldU PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5BIEpXVCB3aG9zZSBDbGFp bXMgYXJlIG5vdCBpbnRlZ3JpdHkgcHJvdGVjdGVkIG9yIGVuY3J5cHRlZC48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+VGhlIHRlcm0gcGxhaW50ZXh0IHRvIG1lIG1lYW5zIHNvbWV0aGlu ZyBsaWtlICZxdW90O2lzIHJlYWRhYmxlIHdpdGhvdXQgZGVjcnlwdGluZyAvIG11Y2ggZGVjb2Rp bmcmcXVvdDsgKHNvbWV0aGluZyBsaWtlLCBpZiB5b3UgY2F0IHRoZSBmaWxlIHRvIGEgdGVybWlu YWwsIHlvdSB3aWxsIHNlZSB0aGUgaW5mb3JtYXRpb24pLiBJbnRlZ3JpdHkgcHJvdGVjdGluZyBh IHN0cmluZyBkb2Vzbid0IG1ha2UgaXQgbm90IGVhc2lseQ0KIHJlYWRhYmxlLiBJZiB0aGlzIGRv Y3VtZW50IC8gSk9TRSB1c2VzICZxdW90O3BsYWludGV4dCZxdW90OyBkaWZmZXJlbnRseSAoYW5k IGEgcXVpY2sgc2tpbSBkaWRuJ3QgZmluZCBhbnl0aGluZyBhYm91dDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+dGhpcykgaXQgbWlnaHQgYmUgZ29vZCB0byBjbGFyaWZ5 LiBTZWN0aW9uIDYgKmRvZXMqIGRpc2N1c3MgcGxhaW50ZXh0IEpXVHMsIGJ1dCBkb2Vzbid0IHJl YWxseSBjbGFyaWZ5IHRoZSAoSU1PKSB1bnVzdWFsIG1lYW5pbmcgb2YgdGhlIHRlcm0gJnF1b3Q7 cGxhaW50ZXh0JnF1b3Q7IGhlcmUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAi PknigJl2ZSBkaXNjdXNzZWQgdGhpcyB3aXRoIHRoZSBvdGhlciBkb2N1bWVudCBlZGl0b3JzIGFu ZCB3ZSBhZ3JlZSB3aXRoIHlvdSB0aGF0IOKAnHBsYWludGV4dOKAnSBpcyBub3QgdGhlIG1vc3Qg aW50dWl0aXZlIHdvcmRpbmcgY2hvaWNlIGluIHRoaXMgY29udGV4dC4mbmJzcDsgUG9zc2libGUg YWx0ZXJuYXRpdmUgdGVybXMgYXJlIOKAnFVuc2VjdXJlZCBKV1TigJ0gb3Ig4oCcVW5zaWduZWQN CiBKV1TigJ0uJm5ic3A7IEkgdGhpbmsgdGhhdCDigJxVbnNlY3VyZWQgSldU4oCdIGlzIHByb2Jh Ymx5IHRoZSBwcmVmZXJyZWQgdGVybSwgc2luY2UgSldUcyB0aGF0IGFyZSBKV0VzIGFyZSBhbHNv IHVuc2lnbmVkLCBidXQgdGhleSBhcmUgc2VjdXJlZC4mbmJzcDsgV29ya2luZyBncm91cCDigJMg YXJlIHlvdSBPSyB3aXRoIHRoaXMgcG9zc2libGUgdGVybWlub2xvZ3kgY2hhbmdlPyZuYnNwOyAo Tm90ZSB0aGF0IHRoZSBwYXJhbGxlbCBjaGFuZ2Ug4oCcUGxhaW50ZXh0IEpXU+KAnSAtJmd0OyDi gJxVbnNlY3VyZWQNCiBKV1PigJ0gd291bGQgYWxzbyBiZSBtYWRlIGluIHRoZSBKV1Mgc3BlYy4p PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMwMDcwQzAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPk1BQ2VkIGRvZXMgbm90IHNlZW0gdG8gYmUgYSB3ZWxsIGtub3duIHRl cm0gLSBzdXJwcmlzaW5nbHkgZW5vdWdoIGV2ZW4gTUFDIGRvZXNuJ3QgaGF2ZSBhbiBhc3Rlcmlz ayBhdA0KPGEgaHJlZj0iaHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjLXN0eWxlLWd1aWRl L2FiYnJldi5leHBhbnNpb24udHh0Ij48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0 LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjLXN0eWxlLWd1 aWRlL2FiYnJldi5leHBhbnNpb24udHh0PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0i Y29sb3I6IzAwNzBDMCI+RG8geW91IGhhdmUgYW5vdGhlciBzdWdnZXN0aW9uIHRvIHJlcGxhY2Ug 4oCcTUFDZWTigJ0gYW5kIOKAnE1BQ2luZ+KAnSwgb3RoZXIgdGhhbiB2ZXJib3NlIGZvcm11bGF0 aW9ucyBsaWtlIOKAnHRoYXQgaGF2ZSBhIE1BQyBhcHBsaWVkIHRvIHRoZW3igJ0/Jm5ic3A7IEdp dmVuIHRoYXQgaW4gRW5nbGlzaCB1c2FnZSBpdOKAmXMgY29tbW9uIHRvIOKAnHZlcmIgYSBub3Vu 4oCdIChlLmcuLCB1c2FnZQ0KIG9mIHRoZSB2ZXJiIOKAnEdvb2dsZeKAnSksIEkgZG9u4oCZdCB0 aGluayB0aGVyZeKAmXMgYWN0dWFsbHkgYW55IGFtYmlndWl0eSBhcyB0byB0aGUgaW50ZW5kZWQg bWVhbmluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+U2VjdGlvbiA0OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+JnF1b3Q7Li4uJm5ic3A7IHJlY2lwaWVudHMgTVVTVCBlaXRoZXIg cmVqZWN0IEpXVHMgd2l0aCBkdXBsaWNhdGUmbmJzcDsgQ2xhaW0gTmFtZXMgb3IgdXNlIGEgSlNP TiBwYXJzZXIgdGhhdCByZXR1cm5zIG9ubHkgdGhlIGxleGljYWxseSBsYXN0Jm5ic3A7IGR1cGxp Y2F0ZSBtZW1iZXIgbmFtZS4uLiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5U aGlzIHNvbWV3aGF0IG1hZGUgbWUgaXRjaCAtIHNvbWUgaW1wbGVtZW50YXRpb25zIHdpbGwgcmVq ZWN0IGEgZ2l2ZW4gSldULCBzb21lIHdpbGwgYWNjZXB0IGl0IC0tIEkga25vdyB2ZXJ5IGxpdHRs ZSBhYm91dCBwYXJzaW5nIEpTT04sIGJ1dCBjb3VsZCB5b3Ugc3VnZ2VzdCB3aGljaCBhbiBpbXBs ZW1lbnRhdGlvbiBzaG91bGQgcHJlZmVyPyBDYW4gSSBpbnN0cnVjdCBzdGFuZGFyZCBwYXJzZXJz IHRvDQogZG8gWCBpbiB0aGlzIGNhc2U/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcw QzAiPkkgdW5kZXJzdGFuZCB0aGUgaXRjaHkgZmVlbGluZy4NCjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMwMDcwQzAiPko8L3NwYW4+PHNwYW4gc3R5bGU9 ImNvbG9yOiMwMDcwQzAiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBD MCI+VW5mb3J0dW5hdGVseSwgdGhlIGludGVudGlvbmFsIGxheG5lc3MgaW4gdGhlIHNwZWMgaW4g dGhpcyByZWdhcmQgaXMgYSByZWZsZWN0aW9uIG9mIHRoZSBzZW1hbnRpY3Mgb2YgdGhlIGFjdHVh bCBKU09OIHNwZWNpZmljYXRpb25zIGFuZCBpbXBsZW1lbnRhdGlvbnMuJm5ic3A7IEZvciBpbnN0 YW5jZSwNCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcxNTkjc2VjdGlv bi00Ij5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MTU5I3NlY3Rpb24tNDwvYT4gc2F5 czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBz dHlsZT0iY29sb3I6IzAwNzBDMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFu Zz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgQW4gb2JqZWN0IHdob3NlIG5hbWVzIGFyZSBhbGwgdW5p cXVlIGlzIGludGVyb3BlcmFibGUgaW4gdGhlIHNlbnNlPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNw YW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgdGhhdCBhbGwgc29mdHdhcmUgaW1wbGVtZW50 YXRpb25zIHJlY2VpdmluZyB0aGF0IG9iamVjdCB3aWxsIGFncmVlIG9uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFs d2F5cyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgdGhlIG5hbWUtdmFsdWUgbWFw cGluZ3MuJm5ic3A7IFdoZW4gdGhlIG5hbWVzIHdpdGhpbiBhbiBvYmplY3QgYXJlIG5vdDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFr LWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHVuaXF1ZSwg dGhlIGJlaGF2aW9yIG9mIHNvZnR3YXJlIHRoYXQgcmVjZWl2ZXMgc3VjaCBhbiBvYmplY3QgaXM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1i cmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB1bnBy ZWRpY3RhYmxlLiZuYnNwOyBNYW55IGltcGxlbWVudGF0aW9ucyByZXBvcnQgdGhlIGxhc3QgbmFt ZS92YWx1ZSBwYWlyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsmbmJzcDsgb25seS4mbmJzcDsgT3RoZXIgaW1wbGVtZW50YXRpb25zIHJlcG9ydCBhbiBlcnJv ciBvciBmYWlsIHRvIHBhcnNlIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVO IiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7Jm5ic3A7IG9iamVjdCwgYW5kIHNvbWUgaW1wbGVtZW50YXRpb25zIHJlcG9y dCBhbGwgb2YgdGhlIG5hbWUvdmFsdWUgcGFpcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4g bGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgaW5jbHVkaW5nIGR1cGxpY2F0ZXMuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMwMDcwQzAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj5UaGlzIHRvcGljIGhhcyBiZWVuIGhl YXZpbHkgZGlzY3Vzc2VkIGJ5IHRoZSB3b3JraW5nIGdyb3VwLCBhbmQgd2hpbGUgdGhlIHNwZWNz IHVzZWQgdG8ganVzdCBzYXkgdGhhdCBvYmplY3RzIHdpdGggZHVwbGljYXRlIG1lbWJlciBuYW1l cyBNVVNUIGJlIHJlamVjdGVkLCB3b3JraW5nIGdyb3VwIG1lbWJlcnMsIGluY2x1ZGluZyBUaW0g QnJheSAodGhlIGVkaXRvcg0KIG9mIHRoZSBKU09OIHNwZWMpLCBwcmV2YWlsZWQgb24gdXMgdG8g d2Vha2VuIHRoaXMgc28gdGhhdCBwYXJzZXJzIHRoYXQgaW1wbGVtZW50IHRoZSBFQ01Bc2NyaXB0 IGJlaGF2aW9yIG9mIHJldHVybmluZyBvbmx5IHRoZSBsYXN0IG1lbWJlciBuYW1lIG1heSBiZSBs ZWdhbGx5IHVzZWQuJm5ic3A7IChUaGUgYXJndW1lbnQgd2FzIG1hZGUgdGhhdCB0aGVyZSB3YXMg bW9yZSBzZWN1cml0eSBkb3duc2lkZSBpbiBlZmZlY3RpdmVseSByZXF1aXJpbmcgcGVvcGxlDQog dG8gd3JpdGUgYW5kIGRlYnVnIHRoZWlyIG93biBzdHJpY3QgcGFyc2VycyB0aGFuIGluIHVzaW5n IGxheGVyLCBidXQgd2VsbC1zdXBwb3J0ZWQgYW5kIGRlYnVnZ2VkIHBhcnNlcnMuKTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xv cjojMDA3MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+SG93ZXZlciwgd2UgYWxzbyBpbnRl bnRpb25hbGx5IHJlcXVpcmUgdGhhdCBwcm9kdWNlcnMgdXNlIG9ubHkgb25lIGluc3RhbmNlIG9m IGVhY2ggbWVtYmVyIG5hbWUsIHNvIHRoYXQgbGVnYWxseSBwcm9kdWNlZCBvYmplY3RzIHdpbGwg bmV2ZXIgZXhlcmNpc2UgdGhlIGFtYmlndWl0aWVzIHRoYXQgYXJlIHByZXNlbnQgaW4gcmVhbCBK U09OIHBhcnNlcnMuJm5ic3A7DQogVGhhdCBzZWVtZWQgdG8gYmUgdGhlIG1vc3QgcHJhY3RpY2Fs IHNvbHV0aW9uIHRvIHRoZSB3b3JraW5nIGdyb3VwLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+U2VjdGlvbiA0LjEu NC4gJnF1b3Q7ZXhwJnF1b3Q7IChFeHBpcmF0aW9uIFRpbWUpIENsYWltIChhbmQgb3RoZXIgdGlt ZSBiYXNlZCBDbGFpbXM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5X aGF0IHNob3VsZCBteSBiZWhhdmlvciBiZSBpZiBJIHNpbXBseSBkb24ndCBrbm93IHdoYXQgdGhl IHRpbWUgaXM/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4oSSdtIGp1 c3QgYSBkdW1iIGRldmljZSwgYW5kIG15IFJUQyBpcyBjbGFpbWluZyBpdCBpcyBKYW4xc3QsIDE5 NzApIC0gSSdtIGFzc3VtaW5nIEkgbXVzdCBub3QgcHJvY2VzcyB0aGlzIEpXVD8gRG9lcyB0aGlz IGNyZWF0ZSBib290c3RyYXBwaW5nIGlzc3Vlcz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6 IzAwNzBDMCI+VGhlIHVzZSBvZiBhbGwgY2xhaW1zIGlzIG9wdGlvbmFsLiAmbmJzcDtJdOKAmXMg dXAgdG8gYXBwbGljYXRpb25zIHdoaWNoIG9uZXMgbWFrZSBzZW5zZSBmb3IgdGhlbSB0byB1c2Uu Jm5ic3A7IEluIHVzZSBjYXNlcyBpbiB3aGljaCBwYXJ0aWNpcGFudHMgZG9u4oCZdCBrbm93IHRo ZSB0aW1lLCBlaXRoZXIgdGhpcyBjbGFpbSB3b3VsZCBub3QgYmUgdXNlZCBieSB0aGUgYXBwbGlj YXRpb24NCiBvciB0aGUgYXBwbGljYXRpb24gd291bGQgbmVlZCB0byBkZWZpbmUgYXBwbGljYXRp b24tc3BlY2lmaWMgYmVoYXZpb3JzIGZvciB3aGF0IHRvIGRvIGluIHRob3NlIGNhc2VzLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJj b2xvcjojMDA3MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij41LjMuIFJlcGxpY2F0aW5nIENsYWltcyBhcyBIZWFkZXIgUGFyYW1ldGVycyBU aGlzIHNlY3Rpb24gc2NhcmVzIG1lLCBhbmQgSSBob3BlIEknbSBzaW1wbHkgbm90IHVuZGVyc3Rh bmRpbmcgd2hhdCBpcyBiZWluZyBwcm9wb3NlZC4gSWYgeW91IHNlbmQgdGhlIHVuZW5jcnlwdGVk IHZlcnNpb24gb2Ygc29tZSBlbmNyeXB0ZWQgQ2xhaW1zIHNvbWUgaW1wbGVtZW50YXRpb25zIHdp bGwgbWFrZSBpbXBvcnRhbnQNCiBzZWN1cml0eSBkZWNpc2lvbnMgYmFzZWQgdXBvbiB0aG9zZSB1 bmVuY3J5cHRlZCBjbGFpbXMsIGV2ZW4gaWYgeW91IHRlbGwgdGhlbSBpbiBhIHNlcmlvdXMgdm9p Y2Ugbm90IHRvLg0KPGEgaHJlZj0iaHR0cDovL3hrY2QuY29tLzExODEvIj48c3BhbiBzdHlsZT0i Y29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cDovL3hrY2QuY29tLzEx ODEvPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+Rm9yIHdo YXQgaXTigJlzIHdvcnRoLCB0aGUgY29udGV4dCBpbiB3aGljaCB0aGlzIGFyb3NlIHdhcyB3aGVu IGFwcGxpY2F0aW9uIHVzZWQgaW50ZXJtZWRpYXRlIHNvZnR3YXJlIHRoYXQgaW5zcGVjdGVkIHRo ZSBhdWRpZW5jZSBvZiBhbiBlbmNyeXB0ZWQgSldUIGluIG9yZGVyIHRvIHJvdXRlIGl0IHRvIHRo ZSBjb3JyZWN0IHJlY2lwaWVudC4mbmJzcDsgT25seSB0aGUNCiByZWNpcGllbnQgaGFzIHRoZSBr ZXkgdG8gZGVjcnlwdCB0aGUgSldUIGFuZCBsb29rIGF0IHRoZSBlbmNyeXB0ZWQgYXVkaWVuY2Ug dmFsdWUuJm5ic3A7IEJ1dCBieSBwbGFjaW5nIGFuIHVuZW5jcnlwdGVkIGNvcHkgb2YgdGhlIGF1 ZGllbmNlIGluIHRoZSBoZWFkZXIsIHRoZSByb3V0aW5nIHNvZnR3YXJlIGNvdWxkIGluc3BlY3Qg aXQgYW5kIHJvdXRlIGl0IGNvcnJlY3RseS4mbmJzcDsgVGhpcyBzZWVtZWQgdG8gdGhlIHdvcmtp bmcgZ3JvdXAgbGlrZSBhIGxlZ2l0aW1hdGUNCiB1c2UgY2FzZSwgYW5kIHNvIHdlIGRlY2lkZWQg dG8gc3VwcG9ydCBpdC4mbmJzcDsgVGhpcyBmZWF0dXJlIHdhcyBwcm9wb3NlZCBhbmQgZGlzY3Vz c2VkIGluIHRoaXMgdGhyZWFkOg0KPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFy Y2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTEzMTUuaHRtbCI+aHR0cDovL3d3dy5pZXRmLm9y Zy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTEzMTUuaHRtbDwvYT4uPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMwMDcwQzAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPkFsc28sIHRoZSBTSE9VTEQgaW4gJnF1b3Q7SWYgc3VjaCByZXBsaWNhdGVkIENs YWltcyBhcmUgcHJlc2VudCwgdGhlIGFwcGxpY2F0aW9uIHJlY2VpdmluZyB0aGVtIFNIT1VMRCB2 ZXJpZnkgdGhhdCB0aGVpciB2YWx1ZXMgYXJlIGlkZW50aWNhbCwgLi4uJnF1b3Q7IC0gd2h5IGlz IHRoaXMgbm90IGEgTVVTVD8gQW5kIGlmIGFuIGFwcGxpY2F0aW9uICpkb2VzKiBjb21wYXJlIHRo ZW0gYW5kIHRoZXkgYXJlIG5vdCBpZGVudGljYWwsDQogd2hhdCBzaG91bGQgaXQgZG8/Jm5ic3A7 IFBlcmhhcHMgYSBtdWNoIHN0cm9uZ2VyIGp1c3RpZmljYXRpb24gZm9yIGNhcnJ5aW5nIDIgY29w aWVzIG9mIHRoZSBkYXRhIGlzIGluIG9yZGVyLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MDA3MEMwIj5UaGUgdGV4dCByaWdodCBhZnRlciB0aGlzIGluIHRoZSBzcGVjIGFscmVhZHkgYW5z d2VycyB0aGlzIHF1ZXN0aW9uOiDigJx1bmxlc3MgdGhlIGFwcGxpY2F0aW9uIGRlZmluZXMgb3Ro ZXIgc3BlY2lmaWMgcHJvY2Vzc2luZyBydWxlcyBmb3IgdGhlc2UgQ2xhaW1z4oCdLiZuYnNwOyBJ dOKAmXMgYSDigJxTSE9VTETigJ0gYmVjYXVzZSBhcHBsaWNhdGlvbnMgbWlnaHQgbmVlZCB0byBk bw0KIHRoaXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkVkaXRvcmlhbDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPlRoZSBpbnRybyBpcyBhbG1vc3QgaWRlbnRpY2FsIHRvIHRoZSBh YnN0cmFjdC4gTWFraW5nIHRoZSBhYnN0cmFjdCBtb3JlIGFic3RyYWN0LCBvciB0aGUgaW50cm8g bW9yZSBpbnRyb2R1Y3RvcnkgKEkgaGF2ZSBubyBpZGVhIHdoYXQgbWFueSBvZiB0aGUgYWNyb255 bXMgd2VyZSEpIHdvdWxkIGJlIG5pY2UuIFNvbWV0aGluZyBzaG9ydCBleHBsYWluaW5nIHdoYXQg YSBKV1QgaXMsIHdoeSBJJ2QgbGlrZSBvbmUsd2hhdA0KIHRoZXkgZ2V0IHVzZWQgZm9yLCB3aHkg SSBzaG91bGQga2VlcCByZWFkaW5nIHRoaXMgZG9jdW1lbnQgd291bGQgYmUgdmVyeSBoZWxwZnVs IC0gYmFzaWNhbGx5IGEgYmFja2dyb3VuZCB0eXBlIHNlY3Rpb24uLi48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBz dHlsZT0iY29sb3I6IzAwNzBDMCI+U3BlY2lmaWMgd29yZGluZyBzdWdnZXN0aW9ucyB3b3VsZCBi ZSB3ZWxjb21lZC4mbmJzcDsgQXMgZm9yIG5vdCBrbm93aW5nIHdoYXQgdGhlIGFjcm9ueW1zIGFy ZSwgSeKAmW0gdG9sZCB0aGF0IHRoZSBzdHlsZSBndWlkZXMgZG9u4oCZdCBhbGxvdyByZWZlcmVu Y2VzIHRvIGJlIHB1dCBpbiB0aGUgYWJzdHJhY3QuJm5ic3A7IE90aGVyd2lzZSwgZm9yIGluc3Rh bmNlLCB0aGVyZSB3b3VsZA0KIGJlIGEgcmVmZXJlbmNlIHRoZXJlIHRvIFJGQyA3MTU5IHNvIHBl b3BsZSB3aG8gZG9u4oCZdCBrbm93IHdoYXQgSlNPTiBpcyBrbm93IHdoZXJlIHRvIGxvb2sgdG8g Z28gZmluZCBvdXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPk5pdHM6PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij5BYnN0cmFjdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+TzogaXMgYSBjb21wYWN0IFVSTC1zYWZlIG1lYW5zPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5QOiBpcyBhIGNvbXBhY3QsIFVSTC1zYWZlIG1lYW5zPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6 IzAwNzBDMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPlRoYW5rczxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMw Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4z LiZuYnNwOyBKU09OIFdlYiBUb2tlbiAoSldUKSBPdmVydmlldzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+TzogVGhlIGNvbnRlbnRzIG9mIHRoZSBKT1NFIEhlYWRlciBk ZXNjcmliZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+UDogU3BlbGwg b3V0IEpPU0U7IGZpcnN0IHVzZSBpbiBkb2N1bWVudCBhcyBmYXIgYXMgSSBjb3VsZCBzZWU8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MDA3MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+QWN0dWFsbHksIHRoZSBmaXJzdCB1c2Ug b2YgdGhlIHRlcm0g4oCcSk9TRSBIZWFkZXLigJ0gaXMgaW4gU2VjdGlvbiAyIChUZXJtaW5vbG9n eSksIHdoZXJlIGl0IGlzIGluY29ycG9yYXRlZCBpbnRvIHRoaXMgc3BlY2lmaWNhdGlvbiBieSBy ZWZlcmVuY2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjUuMiAmcXVvdDtjdHkmcXVvdDsgKENvbnRlbnQgVHlwZSkgSGVh ZGVyIFBhcmFtZXRlcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Tzog bm9ybWFsIGNhc2Ugd2hlcmUgbmVzdGVkIHNpZ25pbmc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPlA6IG5vcm1hbCBjYXNlIGluIHdoaWNoIG5lc3RlZCBzaWduaW5nPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6 IzAwNzBDMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPlRoYW5rczxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMw Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij44 LiZuYnNwOyBJbXBsZW1lbnRhdGlvbiBSZXF1aXJlbWVudHM8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPk86IEZvciBpbnN0YW5jZSwgYW4gYXBwbGljYXRpb24gbWlnaHQg cmVxdWlyZSBzdXBwb3J0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDsmbmJzcDsgZm9yIGVuY3J5cHRlZCBKV1RzIGFuZCBOZXN0ZWQgSldUczsgYW5vdGhlciBt aWdodCByZXF1aXJlIHN1cHBvcnQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPlA6IEZvciBpbnN0YW5jZSwgb25lIGFwcGxpY2F0aW9uIG1pZ2h0IHJlcXVpcmUgc3VwcG9y dCBbLi4uXSwgd2hpbGUgYW5vdGhlciBtaWdodCByZXF1aXJlIHN1cHBvcnQgWy4uLl08bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3 MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+VGhhbmtzPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjExLiBT ZWN1cml0eSBDb25zaWRlcmF0aW9uczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+TzogVGhlIGVudGlyZSBsaXN0IG9mIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGlzIGJl eW9uZCB0aGUgc2NvcGUgb2Y8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOyZuYnNwOyB0aGlzIGRvY3VtZW50LCBidXQgc29tZSBzaWduaWZpY2FudCBjb25zaWRl cmF0aW9ucyBhcmUgbGlzdGVkIGhlcmUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5QOiBUaGUgZW50aXJlIGxpc3Qgb2Ygc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgaXMg YmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+UjogQSBmZXcgb2YgdGhlIGNvbnNpZGVyYXRpb25zIGFyZSBhbHJl YWR5IGxpc3RlZCBhYm92ZTsgd2UgZG9uJ3QgbmVlZCB0byByZXN0YXRlIHRoYXQgdGhleSBhcmUg bGlzdGVkIGhlcmUgLS0gYW5kIGlmIHdlIGRvLCB0aGUgYXNzdW1wdGlvbiBpcyB0aGF0IHNhaWQg bGlzdCB3b3VsZCBmb2xsb3csIG5vdCBiZSBhYm92ZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29s b3I6IzAwNzBDMCI+U2V2ZXJhbCByZXZpZXdlcnMgaGF2ZSBvYmplY3RlZCB0byB0aGlzIHNlbnRl bmNlLiZuYnNwOyBJdHMgcmVtb3ZhbCBpcyBwbGFubmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4xMS4yIFNp Z25pbmcgYW5kIEVuY3J5cHRpb24gT3JkZXI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPk86IFdoaWxlIHN5bnRhY3RpY2FsbHksIHRoZSBzaWduaW5nIGFuZCBlbmNyeXB0 aW9uIG9wZXJhdGlvbnMgZm9yIE5lc3RlZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jm5ic3A7Jm5ic3A7IEpXVHMgbWF5IGJlIGFwcGxpZWQgaW4gYW55IG9yZGVyLDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+UDogV2hpbGUgc3ludGFjdGlj YWxseSB0aGUgc2lnbmluZyBhbmQgZW5jcnlwdGlvbiBvcGVyYXRpb25zIGZvciBOZXN0ZWQ8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBKV1RzIG1h eSBiZSBhcHBsaWVkIGluIGFueSBvcmRlciw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAw NzBDMCI+VGhhbmtzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi0tPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij5JIGRvbid0IHRoaW5rIHRoZSBleGVjdXRpb24gaXMgcmVsZXZhbnQgd2hl biBpdCB3YXMgb2J2aW91c2x5IGEgYmFkIGlkZWEgaW4gdGhlIGZpcnN0IHBsYWNlLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhpcyBpcyBsaWtlIHB1dHRpbmcgcmFi aWQgd2Vhc2VscyBpbiB5b3VyIHBhbnRzLCBhbmQgbGF0ZXIgZXhwcmVzc2luZyByZWdyZXQgYXQg aGF2aW5nIGNob3NlbiB0aG9zZSBwYXJ0aWN1bGFyIHJhYmlkIHdlYXNlbHMgYW5kIHRoYXQgcGFp ciBvZiBwYW50cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw OyZuYnNwOyAtLS1tYWY8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoYW5rcyBhZ2FpbiwgV2FycmVuLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJj b2xvcjojMDA3MEMwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlr ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_4E1F6AAD24975D4BA5B16804296739439AE9DB28TK5EX14MBXC292r_-- From nobody Fri Sep 5 17:57:44 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5331A06E1; Fri, 5 Sep 2014 17:57: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, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 gjehyfZrMp5D; Fri, 5 Sep 2014 17:57:27 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0756.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:756]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 485091A0709; Fri, 5 Sep 2014 17:57:13 -0700 (PDT) Received: from BN3PR0301CA0072.namprd03.prod.outlook.com (25.160.152.168) by BN1PR03MB252.namprd03.prod.outlook.com (10.255.200.24) with Microsoft SMTP Server (TLS) id 15.0.1019.16; Sat, 6 Sep 2014 00:56:49 +0000 Received: from BN1AFFO11FD008.protection.gbl (2a01:111:f400:7c10::183) by BN3PR0301CA0072.outlook.office365.com (2a01:111:e400:401e::40) with Microsoft SMTP Server (TLS) id 15.0.1019.16 via Frontend Transport; Sat, 6 Sep 2014 00:56:50 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD008.mail.protection.outlook.com (10.58.52.68) with Microsoft SMTP Server (TLS) id 15.0.1010.11 via Frontend Transport; Sat, 6 Sep 2014 00:56:49 +0000 Received: from TK5EX14MBXC292.redmond.corp.microsoft.com ([169.254.1.60]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.03.0195.002; Sat, 6 Sep 2014 00:56:14 +0000 From: Mike Jones To: Tero Kivinen , "iesg@ietf.org" , "secdir@ietf.org" , "ietf@ietf.org" , "draft-ietf-jose-json-web-signature.all@tools.ietf.org" Thread-Topic: Secdir review of draft-ietf-jose-json-web-signature-31 Thread-Index: AQHPyDgrWdMUgOdf8EqNa4N9Ytbe4ZvzQwog Date: Sat, 6 Sep 2014 00:56:14 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439AE9DD47@TK5EX14MBXC292.redmond.corp.microsoft.com> References: <21512.21725.209461.976375@fireball.kivinen.iki.fi> In-Reply-To: <21512.21725.209461.976375@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.70] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439AE9DD47TK5EX14MBXC292r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019017)(438002)(199003)(377454003)(51914003)(189002)(13464003)(43784003)(16297215004)(19580395003)(44976005)(15975445006)(84326002)(77096002)(21056001)(68736004)(99396002)(15202345003)(6806004)(92726001)(50986999)(2201001)(85852003)(77982001)(2656002)(86362001)(87936001)(97736003)(92566001)(104016003)(55846006)(83072002)(19617315012)(90102001)(76482001)(84676001)(4396001)(83322001)(19580405001)(19300405004)(85806002)(81342001)(512954002)(71186001)(31966008)(2501002)(74502001)(74662001)(79102001)(16236675004)(81156004)(76176999)(54356999)(106466001)(64706001)(86612001)(46102001)(26826002)(19625215002)(106116001)(66066001)(69596002)(95666004)(81542001)(85306004)(107046002)(80022001)(33656002)(230783001)(20776003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR03MB252; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 03264AEA72 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/36Zz_kwQkRyrUC4ilj7Q5xFDquE Cc: "jose@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-jose-json-web-signature-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 00:57:34 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439AE9DD47TK5EX14MBXC292r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the useful review, Tero. I've cc'ed the working group to make t= hem aware of the contents of your review. Also, Richard Barnes, please see= a request for a reply from you on one issue below. Replies are inline bel= ow... -----Original Message----- From: Tero Kivinen [mailto:kivinen@iki.fi] Sent: Thursday, September 04, 2014 5:03 AM To: iesg@ietf.org; secdir@ietf.org; ietf@ietf.org; draft-ietf-jose-json-web= -signature.all@tools.ietf.org Subject: Secdir review of draft-ietf-jose-json-web-signature-31 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. Summary: This document has issues. This document is part of the jose-json document set, and describres the JSO= N Web Signatures. The security considerations section includes text which says: The entire list of security considerations is beyond the scope of this document, but some significant considerations are listed here. but also lists quite a lot of security considerations. I think the security= considerations covering this document should be in scope with the document= . Of course there are generic security considerations which might be outsid= e the scope of this document, but I do not think we need to explictly menti= on those. Several reviewers have objected to this sentence. Its removal is planned. Also, additional security considerations will be described in the process o= f resolving Russ Housley's gen-art review comments. I have following issues about the draft: 1) "alg" and Protected Header 2) Hash inside "alg" and inside the signature 3) There is no explict warning about the "alg" "none". 4) Thumbprint formats There is also following nit: 5) Terminology ordering. ---------------------------------------------------------------------- 1) "alg" and Protected Header Question: Shouldn't the "alg" header parameter be protected by the signatur= e, i.e. wouldn't it make sense to say MUST be in the "Protected Header"? If it is part of the "Unprotected Header" and is not protected by the signa= ture, that would allow all kind of attacks, i.e. changing the "alg" to be "= none" or changing the hash algorithm of the signature. If it should be part of the "Protected Header" then that would mean that "P= roteced Header" cannot be empty, as "alg" is mandatory header parameter, an= d MUST be present. There are several cases where the text indicates that "Protected Header" co= uld be empty, which would mean that "alg" could be part of the "Unprotected= Header". (Section 5.1, 4. bullet; section 7.2, "protected" element and oth= er places in same section). In all examples the "alg" is always in the "Pro= teced Header". I think the draft needs text saying something about the situation where "al= g" is not in "Protected Header" in the security sections section. I.e. eith= er say, that it has been analyzed that there is no problem even when the "a= lg" is not protected, and reference to such analysis, or otherwise add text= /warning that it MUST/SHOULD be in the "Protected Header". I do not know en= ough about the proposed signature algorithms to know which one is true, esp= ecially as there might be new algorithms in the future. Richard Barnes, do you want to answer this one? You were the primary advoc= ate for allowing the algorithm to be unprotected in the JSON Serialization. As I recall, the motivation had to do with the fact that, by default, CMS d= oes not protect the algorithm (although it was later extended to enable it = to be protected). Some others in the working group thought that having unp= rotected algorithms was a bad idea, in line with your comment above. -- 2) Hash inside "alg" and inside the signature Also in some cases the signature itself has the hash function stored intern= ally, i.e. RSASSA-PKCS1-V1_5 contains the hash function oid inside the sign= ature, so what should the implementation do if the "alg" parameter outside = the signature does not match the oid inside the signature? I.e the signatur= e using "alg" of "RS256", but inside the signature the oid is using the "SH= A1". Most crypto libraries will just take the oid from the signature, and u= se that to verify the message. Adding some description what to do in such s= ituation would be needed. I think there's some confusion here, since the JWS spec does not use any OI= Ds or ASN.1 for signatures. Rather, the cryptographic operations to be per= formed are fully specified by the "alg" value and the signatures are repres= ented as base64url encoded octet sequences representing the signature value= s produced by the signature algorithms. -- 3) There is no explict warning about the "alg" "none". In the section 5.2 it says that "at least one signature ... MUST successful= ly validate", but that does not limit alg "none" out from it. I.e. if the a= pplication policy is to "one signature needs to validate", and it gets JWS = that has "none" as one of the algorithms, then it will accept it. I think there should be warning here or in the security considerations sect= ion about the "none" algorithm, especially as the algorithm itself is defin= ed in the different draft (perhaps just reference to the section 8.5 of the= [JWA] draft). This warning is present in the spec where the algorithm is defined - specif= ically http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-31#se= ction-8.5. (Note that the working group decided to define algorithms in a = separate spec than the ones in which they are used.) Also note that it is up to applications which algorithms are acceptable in = a given context - not just "none" but also other algorithms that might be d= eprecated or inappropriate for some other reason. Unless the signature alg= orithm used is acceptable to the application, it should not accept the JWT. -- 4) Thumbprint formats Section 4.1.7 and 4.1.8 defines a x5t and x5t#S256 thumbprints, but those a= re over the whole certificate. With the thumbprints, it has been noted lately, that quite often it is more= useful to use the hash of the SubjectPublicKeyInfo object of the X.509 certificate, than the full X.509 certificate. This method has been us= ed in the raw public key methods (draft-ietf-tls-oob-pubkey, draft-kivinen-= ipsecme-oob-pubkey), and also in the DANE (it has two options one for the f= ull certificate and another for the SubjectPublicKeyInfo object of the cert= ificate). Using hash of the SubjectPublicKeyInfo object allows changing the certifica= te without invalidiating the certificates, i.e. when changing CAs, or switc= hing from SHA1 to SHA2 in certificates, or just renewing the certificate. I= t also allows using raw public keys which do not have defined X.509 certifi= cate format, but which can be converted to the SubjectPublicKeyInfo object = when calculating the thumbprints. This is very important in the Internet of= Things type of things, which might not be using the full X.509 certificate= s. This thumbprint definition matches existing practice in commonly used softw= are packages. For instance, both openssl and Windows use certificate thumb= prints of this kind. That being said, there's nothing preventing another specification from defi= ning a different thumbprint calculation over the SPKI information and a hea= der parameter used to represent it. The header parameters are extensible v= ia a registry. -- 5) Terminology ordering. Terminology is not in any order. It would be useful to have it either in lo= gical order (i.e. define terms before they are used), or in alphabetical or= der. Now for example the "JWS Protected Header" is used before it is defined in = the "JWS Signature", and "Header Paramater" is between "JWS Signature" and = "JWS Protected Header", also "JWS Signature" uses both "JWS Payload" and "J= WS Protected Header", and one of those is defined before and one after the = "JWS Signature". The terms are listed in top-down order, with related terms grouped together= . Thus "JSON Web Signature" is first, the members that make up a JWS objec= t are listed together in the order that they appear in a JWS, etc. That be= ing said, I'll plan to review the orderings and make sure that they consist= ently follow those ordering rules. -- kivinen@iki.fi Thanks agai= n, -- Mike --_000_4E1F6AAD24975D4BA5B16804296739439AE9DD47TK5EX14MBXC292r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for the usef= ul review, Tero. I’ve cc’ed the working group to make the= m aware of the contents of your review. Also, Richard Barnes, please see a request for a reply from you on one issue below. Replie= s are inline below…

-----Original Message-----
From: Tero Kivinen [mailto:kivinen@iki.fi]
Sent: Thursday, September 04, 2014 5:03 AM
To: iesg@ietf.org; secdir@ietf.org; ietf@ietf.org; draft-ietf-jose-json-web= -signature.all@tools.ietf.org
Subject: Secdir review of draft-ietf-jose-json-web-signature-31

Summary: This document has issues.

This document is part of the jose-json document s= et, and describres the JSON Web Signatures.

The security considerations section includes text= which says:

The entire list of security consider= ations is beyond the scope of

this document, but some significant = considerations are listed here.

but also lists quite a lot of security considerat= ions. I think the security considerations covering this document should be = in scope with the document. Of course there are generic security considerat= ions which might be outside the scope of this document, but I do not think we need to explictly mention those.

Several reviewers h= ave objected to this sentence. Its removal is planned.

Also, additional se= curity considerations will be described in the process of resolving Russ Ho= usley’s gen-art review comments.

I have following issues about the draft:

1) "alg" and Protected Hea= der

2) Hash inside "alg" and i= nside the signature

3) There is no explict warning about= the "alg" "none".

4) Thumbprint formats

There is also following nit:

5) Terminology ordering.<= /p>

-------------------------------------------------= ---------------------

1) "alg" and Protected Header

Question: Shouldn't the "alg" header pa= rameter be protected by the signature, i.e. wouldn't it make sense to say M= UST be in the "Protected Header"?

If it is part of the "Unprotected Header&quo= t; and is not protected by the signature, that would allow all kind of atta= cks, i.e. changing the "alg" to be "none" or changing t= he hash algorithm of the signature.

If it should be part of the "Protected Heade= r" then that would mean that "Proteced Header" cannot be emp= ty, as "alg" is mandatory header parameter, and MUST be present.<= o:p>

There are several cases where the text indicates = that "Protected Header" could be empty, which would mean that &qu= ot;alg" could be part of the "Unprotected Header". (Section = 5.1, 4. bullet; section 7.2, "protected" element and other places in same section). In all examples the "alg" is always in the &qu= ot;Proteced Header".

I think the draft needs text saying something abo= ut the situation where "alg" is not in "Protected Header&quo= t; in the security sections section. I.e. either say, that it has been anal= yzed that there is no problem even when the "alg" is not protected, and reference to such analysis, or otherwise add text/warning t= hat it MUST/SHOULD be in the "Protected Header". I do not know en= ough about the proposed signature algorithms to know which one is true, esp= ecially as there might be new algorithms in the future.

Richard Barnes, do you want to answer this one? You wer= e the primary advocate for allowing the algorithm to be unprotected in the = JSON Serialization.

As I recall, the mo= tivation had to do with the fact that, by default, CMS does not protect the= algorithm (although it was later extended to enable it to be protected).&n= bsp; Some others in the working group thought that having unprotected algorithms was a bad idea, in line with your comme= nt above.

2) Hash inside "alg" and inside the sig= nature

Also in some cases the signature itself has the h= ash function stored internally, i.e. RSASSA-PKCS1-V1_5 contains the hash fu= nction oid inside the signature, so what should the implementation do if th= e "alg" parameter outside the signature does not match the oid inside the signature? I.e the signature using "= ;alg" of "RS256", but inside the signature the oid is using = the "SHA1". Most crypto libraries will just take the oid from the= signature, and use that to verify the message. Adding some description what to do in such situation would be needed.

I think there’= ;s some confusion here, since the JWS spec does not use any OIDs or ASN.1 f= or signatures. Rather, the cryptographic operations to be performed a= re fully specified by the “alg” value and the signatures are represented as base64url encoded octet sequences representing the sign= ature values produced by the signature algorithms.

3) There is no explict warning about the "al= g" "none".

In the section 5.2 it says that "at least on= e signature ... MUST successfully validate", but that does not limit a= lg "none" out from it. I.e. if the application policy is to "= ;one signature needs to validate", and it gets JWS that has "none" as one of the algorithms, then it will accept it.

I think there should be warning here or in the se= curity considerations section about the "none" algorithm, especia= lly as the algorithm itself is defined in the different draft (perhaps just= reference to the section 8.5 of the [JWA] draft).

This warning is pre= sent in the spec where the algorithm is defined – specifically http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-31#section-8= .5. (Note that the working group decided to define algorithms in = a separate spec than the ones in which they are used.)

Also note that it i= s up to applications which algorithms are acceptable in a given context = 211; not just “none” but also other algorithms that might be de= precated or inappropriate for some other reason. Unless the signature algorithm used is acceptable to the application, it should n= ot accept the JWT.

4) Thumbprint formats

Section 4.1.7 and 4.1.8 defines a x5t and x5t#S25= 6 thumbprints, but those are over the whole certificate.

With the thumbprints, it has been noted lately, t= hat quite often it is more useful to use the hash of the SubjectPublicKeyIn= fo object of the

X.509 certificate, than the full X.509 certificat= e. This method has been used in the raw public key methods (draft-ietf-tls-= oob-pubkey, draft-kivinen-ipsecme-oob-pubkey), and also in the DANE (it has= two options one for the full certificate and another for the SubjectPublicKeyInfo object of the certificate).<= /o:p>

Using hash of the SubjectPublicKeyInfo object all= ows changing the certificate without invalidiating the certificates, i.e. w= hen changing CAs, or switching from SHA1 to SHA2 in certificates, or just r= enewing the certificate. It also allows using raw public keys which do not have defined X.509 certificate format, = but which can be converted to the SubjectPublicKeyInfo object when calculat= ing the thumbprints. This is very important in the Internet of Things type = of things, which might not be using the full X.509 certificates.

This thumbprint def= inition matches existing practice in commonly used software packages. = For instance, both openssl and Windows use certificate thumbprints of this= kind.

That being said, th= ere’s nothing preventing another specification from defining a differ= ent thumbprint calculation over the SPKI information and a header parameter= used to represent it. The header parameters are extensible via a registry.

5) Terminology ordering.

Terminology is not in any order. It would be usef= ul to have it either in logical order (i.e. define terms before they are us= ed), or in alphabetical order.

Now for example the "JWS Protected Header&qu= ot; is used before it is defined in the "JWS Signature", and &quo= t;Header Paramater" is between "JWS Signature" and "JWS= Protected Header", also "JWS Signature" uses both "JWS= Payload" and "JWS Protected Header", and one of those is defined before and one after the "J= WS Signature".

The terms are liste= d in top-down order, with related terms grouped together. Thus “= ;JSON Web Signature” is first, the members that make up a JWS object = are listed together in the order that they appear in a JWS, etc. That being said, I’ll plan to review the orderings= and make sure that they consistently follow those ordering rules.

kivinen@iki.fi=

&= nbsp; &nbs= p; &= nbsp; &nbs= p; &= nbsp; Thanks again,

&= nbsp; &nbs= p; &= nbsp; &nbs= p; &= nbsp; -- Mike

--_000_4E1F6AAD24975D4BA5B16804296739439AE9DD47TK5EX14MBXC292r_-- From nobody Sat Sep 6 07:59:16 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2D6D1A0417; Sat, 6 Sep 2014 07:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.38 X-Spam-Level: ** X-Spam-Status: No, score=2.38 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, FR_3TAG_3TAG=1.758, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 4JjekQ-jh_ZE; Sat, 6 Sep 2014 07:59:11 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EC941A0416; Sat, 6 Sep 2014 07:59:10 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id gi9so4145738lab.2 for ; Sat, 06 Sep 2014 07:59:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=8KP6OyOOUmHNBFqyu5xcaEdA2sw+25XPxd8JKHPZ+W0=; b=RlXx3ac72bWy/mRVWmkpgXyM/cKlgulwFrPlYgCoxFmPXaAVG5dCzv7R2nb3T3pJfh n1jwDITksoLzOrWmbqLfHQcniRP6p0EVx0RqsslV26AOYttaTaiL+y/ENT0+m4QIfTT5 pw3w17PvOj76TwVqXi+u56NeS8ZNiHXDSutSxJxGJbl91/P6vqZbq0bdZWps2Wo4IdZu 5p9K+lVfmpTjAtIxvWKZ+hkK+iB9LQ6s6uM2K5eWUX8pkWmoRd6U6TwYvM5FnI4qf2UA UuSLBahoRxdgfqqyLqsU+D6cBADa/E5oJNJ8mJ/hkBue/aYcWosRYWPSVE5WdIvG0Ocs ecDA== MIME-Version: 1.0 X-Received: by 10.152.8.165 with SMTP id s5mr18149064laa.3.1410015549340; Sat, 06 Sep 2014 07:59:09 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.8.45 with HTTP; Sat, 6 Sep 2014 07:59:09 -0700 (PDT) In-Reply-To: <540A3309.90802@gmail.com> References: <540A3309.90802@gmail.com> Date: Sat, 6 Sep 2014 17:59:09 +0300 X-Google-Sender-Auth: Z8igvsKLvOm3415JMgASJekJ4y8 Message-ID: From: Barry Leiba To: Chris Lonvick Content-Type: multipart/alternative; boundary=089e0153807af242ad050266d350 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/pekiLUyTtPSmbS15brSJRQEh8AQ Cc: "draft-kyzivat-case-sensitive-abnf.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: [secdir] SECDIR review of draft-kyzivat-case-sensitive-abnf X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 14:59:13 -0000 --089e0153807af242ad050266d350 Content-Type: text/plain; charset=ISO-8859-1 Hi, Chris, and thanks for the review. 2 - The last sentence of section 2.1 is: > > > This mechanism has a clear readability > disadvantage, with respect to using a literal text string with a > prefix, and new the prefix mechanism is preferred. > > > Perhaps you meant: > This mechanism of using a literal text string with a prefix has a clear > readability disadvantage. The prefix mechanism described in this > specification can be much more easily read. > No. Take the sentence in context. The context is that it's describing the was we used to do case-sensitive text, giving each character's numeric value. It's *that* mechanism that has the readability disadvantage. Do you really think that text is unclear, in the context that it's given? I suppose we could say "The old mechanism has...", to make it even clearer. Barry --089e0153807af242ad050266d350 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Chris, and thanks for the review.

2 - The last sentence of section 2.1 is:
=A0=A0 =20
   This mechanism has a clear readability
   disadvantage, with respect to using a literal text string with a
   prefix, and new the prefix mechanism is preferred.
Perhaps you meant:
=A0=A0 This mechanism of using a literal text string with a prefix has a clear
=A0=A0 readability disadvantage.=A0 The prefix mechanism described = in this
=A0=A0 specification can be much more easily read.
No. =A0Take the sentence in context. =A0The contex= t is that it's describing the was we used to do case-sensitive text, gi= ving each character's numeric value. =A0It's *that* mechanism that = has the readability disadvantage.

Do you really th= ink that text is unclear, in the context that it's given? =A0I suppose = we could say "The old mechanism has...", to make it even clearer.=

Barry

--089e0153807af242ad050266d350-- From nobody Sat Sep 6 09:12:38 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39A371A047E for ; Sat, 6 Sep 2014 09:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.465 X-Spam-Level: * X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 x5im3XsGzpjf for ; Sat, 6 Sep 2014 09:12:34 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7ED1A0478 for ; Sat, 6 Sep 2014 09:12:34 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta05.westchester.pa.mail.comcast.net with comcast id ns7k1o0020mv7h055sCZcv; Sat, 06 Sep 2014 16:12:33 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by omta11.westchester.pa.mail.comcast.net with comcast id nsCZ1o00G3Ge9ey3XsCZSo; Sat, 06 Sep 2014 16:12:33 +0000 Message-ID: <540B3271.5060502@alum.mit.edu> Date: Sat, 06 Sep 2014 12:12:33 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Chris Lonvick , iesg@ietf.org, secdir@ietf.org, draft-kyzivat-case-sensitive-abnf.all@tools.ietf.org References: <540A3309.90802@gmail.com> In-Reply-To: <540A3309.90802@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1410019953; bh=ZOg2+8hwWVbGSdJqzyH56kgcr2ZKNFVEM0d8C8p6qLQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=W8vonDM6xNyZ7dBpLnZF25q8ds2x6AqJycLprdLPplu97AQSVf9LraRuDHYlPSe2g Bfr+yfImcieajGGV7uUkh9k5kw7OvSIVFWyozV0zIzE9XxBqR8i6vU2SYSns35ehCH G4mu1ycpl+xcQzKh/d4+vx9Y8rjK20S7Qr2r4l6KXxm22oDi1baYYOe1UjVk6DlIGj jYvUJvquwFrWukMFfahiIF/XpOAwggvOuw50nuLSMVutIuS0/lOKD4goB4+OHr766D xZXFVf2dx0l/lA47c8tiPcpt7/llSCGwMX3ScK47/6qt0waMbAWWPd/nmRwroC6Uvd 5hHGmN0qFwA2w== Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Zwf6vyhVCsjUPLykz-XUsgmDylA Subject: Re: [secdir] SECDIR review of draft-kyzivat-case-sensitive-abnf X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 16:12:35 -0000 Chris, Thanks for the comments. On 9/5/14 6:02 PM, Chris Lonvick wrote: > Hi, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security > area directors. Document editors and WG chairs should treat these > comments just like any other last call comments. > > The abstract is: > > This document extends the base definition of ABNF (Augmented Mackus- > Naur Form) to include a way to specify ASCII string literals that are > matched in a case-sensitive manner. > > > Overall, I don't like the statement in the Security Considerations > section, but it is consistent with all other documents related to > defining ABNF, and I can't find any noteworthy security issues anyway. > From that, I have no objection to moving this document forward. As you can see, I just followed precedent since I wasn't doing anything that would alter the security implications in any way. But I am open to suggestions for something better to say. > I did find some nits and have some suggestions for improving readability. > > 1 - "Mackus-Naur" is used in two places rather than "Backus-Naur". Yes. I don't know how that happened. > 2 - The last sentence of section 2.1 is: > > This mechanism has a clear readability > disadvantage, with respect to using a literal text string with a > prefix, and new the prefix mechanism is preferred. > > > Perhaps you meant: > This mechanism of using a literal text string with a prefix has a clear > readability disadvantage. The prefix mechanism described in this > specification can be much more easily read. No. "This mechanism" refers to "the way that has been used in the past" (specify the individual characters numerically). How about: "The new way (using a literal text string with a prefix) has a clear readability advantage over the old way." > 3 - This part of Section 2.1 may be cleared up some: > ---vvv--- > > If no prefix is present then the string is case-insensitive. > > Hence: > > rulename = %i"aBc" > > and: > > rulename = "abc" > > will both match "abc", "Abc", "aBc", "abC", "ABc", "aBC", "AbC", and > "ABC". > > > ---^^^--- > > Suggested: > ---vvv--- > To be consistent with current implementations of ABNF, having no > prefix means that the string is case-insensitive, and is equivalent > to having the "%i" prefix. This seems good, except for the use of "current". That doesn't age well. I suggest replacing "current" with "prior". Thanks, Paul > Hence: > > rulename = %i"aBc" > > and: > > rulename = "abc" > > are equivalent and both will match "abc", "Abc", "aBc", "abC", "ABc", > "aBC", "AbC", and "ABC". > ---^^^--- > > Best regards, > Chris > From nobody Sat Sep 6 10:37:24 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE191A06FC; Sat, 6 Sep 2014 10:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.881 X-Spam-Level: X-Spam-Status: No, score=0.881 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 rgEsjPmTBxmb; Sat, 6 Sep 2014 10:37:15 -0700 (PDT) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F3A51A06FA; Sat, 6 Sep 2014 10:37:15 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id p10so1131855pdj.16 for ; Sat, 06 Sep 2014 10:37:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=NYS+oXSiDTStlotM3VIczVXUSKWur5ymZXF4FK2OqxA=; b=KG6+hAxThtXBGJMmUSkmrwOVMMptVjNMH50gzIh+dzD8CMU8yDsEfcp/EKwuHTPQK7 HpNJsgUxkiZyHrueLj74ClQQUaphhDKpQ75m+wOU0oiFXHyBv61miPZ6sx1EHI+8jp2p 2AO60b7l5GAkQYkDoH3ABFCWfCUgioxVP5GOjDVj6s9CEc5Id47ZLYfyDli2DkP0BlWw +d//f18EL9TdtVwKk/+XDMBXSDeTnTe4XDK8r/MdMicV+RKgr6bFwK/9N3pKt4OjTCFw uQK8EGVde+B4qwRl4ot+NL8BfTLbTC6BTwwR+/tDWyVkxBWUeU42aSB4/4FCsxm7Err5 gMSA== X-Received: by 10.66.246.109 with SMTP id xv13mr4575060pac.144.1410025034987; Sat, 06 Sep 2014 10:37:14 -0700 (PDT) Received: from [192.168.1.76] (172-3-137-150.lightspeed.sntcca.sbcglobal.net. [172.3.137.150]) by mx.google.com with ESMTPSA id ba5sm4783426pbd.72.2014.09.06.10.37.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 06 Sep 2014 10:37:14 -0700 (PDT) Message-ID: <540B4648.4080002@gmail.com> Date: Sat, 06 Sep 2014 10:37:12 -0700 From: Chris Lonvick User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Barry Leiba References: <540A3309.90802@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070905090307000807080705" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/TNAvwfNnHsbljBdjVxyJN3C0ijc Cc: "draft-kyzivat-case-sensitive-abnf.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-kyzivat-case-sensitive-abnf X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 17:37:17 -0000 This is a multi-part message in MIME format. --------------070905090307000807080705 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Barry, On 9/6/14, 7:59 AM, Barry Leiba wrote: > Hi, Chris, and thanks for the review. > > 2 - The last sentence of section 2.1 is: > > This mechanism has a clear readability > disadvantage, with respect to using a literal text string with a > prefix, and new the prefix mechanism is preferred. > > > Perhaps you meant: > This mechanism of using a literal text string with a prefix has > a clear > readability disadvantage. The prefix mechanism described in this > specification can be much more easily read. > > > No. Take the sentence in context. The context is that it's > describing the was we used to do case-sensitive text, giving each > character's numeric value. It's *that* mechanism that has the > readability disadvantage. > > Do you really think that text is unclear, in the context that it's > given? I suppose we could say "The old mechanism has...", to make it > even clearer. The sentence is consistent with the context of the section and I get that. What I was raising a concern about was the nearly unparsable last clause: "and new the prefix mechanism is preferred." :-) Obviously I muddied the waters with my suggestion and I don't see the point of belaboring this with explanations of %d or %h prefixes make literal strings unreadable, so just find some way to clean up that last clause. Best regards, Chris > > Barry > --------------070905090307000807080705 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Barry,

On 9/6/14, 7:59 AM, Barry Leiba wrote:

Hi, Chris, and thanks for the review.

2 - The last sentence of section 2.1 is:

This mechanism has a clear readability disadvantage, with respect to using a literal text string with a prefix, and new the prefix mechanism is preferred.

Perhaps you meant:
   This mechanism of using a literal text string with a prefix has a clear
   readability disadvantage. The prefix mechanism described in this
   specification can be much more easily read.

No. Take the sentence in context. The context is that it's describing the was we used to do case-sensitive text, giving each character's numeric value. It's *that* mechanism that has the readability disadvantage.

Do you really think that text is unclear, in the context that it's given? I suppose we could say "The old mechanism has...", to make it even clearer.

The sentence is consistent with the context of the section and I get that. What I was raising a concern about was the nearly unparsable last clause: "and new the prefix mechanism is preferred." :-) Obviously I muddied the waters with my suggestion and I don't see the point of belaboring this with explanations of %d or %h prefixes make literal strings unreadable, so just find some way to clean up that last clause.

Best regards,
Chris

Barry

--------------070905090307000807080705-- From nobody Sat Sep 6 10:38:20 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8E1E1A06FC; Sat, 6 Sep 2014 10:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.3 X-Spam-Level: * X-Spam-Status: No, score=1.3 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_41=0.6, SPF_PASS=-0.001] autolearn=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 7pt2kzG5N_UV; Sat, 6 Sep 2014 10:38:17 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5FB31A0705; Sat, 6 Sep 2014 10:38:17 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id eu11so24396028pac.19 for ; Sat, 06 Sep 2014 10:38:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=TcRykyYTqZRn5V0NgJLpUrBZi2voEnummdF3y6KT1MQ=; b=qvHFUOeAALHFZPXshMl0BSk9O6Ri0ENB6AMUiJ+eO5YpUoirkUyrfyCiOff8I0kq+j nwbcF5vOWhkXpn39xpHp8sTI0FFPo8L9eoBSXWRUiomrlaP8eP8KXlhn6shJpQRf9pZS LktSlv0GES0cNVswQW51TpT7h0+FjF3iIoKzhqdNrLvNRD0zazBrE6TfTHSJ/1omRZLm FajQmuR/Yfj6IWn30uFHZa2SbrVAuw9KPy393TkoJ6UibVgWjX3eevWKuxduVkzWsELV T8Oc7KNc8BTutnl6Kh4vzThk9Z2xA+tscOCkiCxmpo0gAAvJbal4RN4KtYd1Zh8CRwC7 GuDg== X-Received: by 10.66.65.130 with SMTP id x2mr31858790pas.79.1410025097481; Sat, 06 Sep 2014 10:38:17 -0700 (PDT) Received: from [192.168.1.76] (172-3-137-150.lightspeed.sntcca.sbcglobal.net. [172.3.137.150]) by mx.google.com with ESMTPSA id gf5sm4775346pbc.89.2014.09.06.10.38.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 06 Sep 2014 10:38:16 -0700 (PDT) Message-ID: <540B4686.2060305@gmail.com> Date: Sat, 06 Sep 2014 10:38:14 -0700 From: Chris Lonvick User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Paul Kyzivat , iesg@ietf.org, secdir@ietf.org, draft-kyzivat-case-sensitive-abnf.all@tools.ietf.org References: <540A3309.90802@gmail.com> <540B3271.5060502@alum.mit.edu> In-Reply-To: <540B3271.5060502@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/yXG6An1X0OrdiuuZ0CrsBf5OjlI Subject: Re: [secdir] SECDIR review of draft-kyzivat-case-sensitive-abnf X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Sep 2014 17:38:19 -0000 Hi Paul, On 9/6/14, 9:12 AM, Paul Kyzivat wrote: > Chris, > > Thanks for the comments. > > On 9/5/14 6:02 PM, Chris Lonvick wrote: >> Hi, >> >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the IESG. >> These comments were written primarily for the benefit of the security >> area directors. Document editors and WG chairs should treat these >> comments just like any other last call comments. >> >> The abstract is: >> >> This document extends the base definition of ABNF (Augmented Mackus- >> Naur Form) to include a way to specify ASCII string literals that >> are >> matched in a case-sensitive manner. >> >> >> Overall, I don't like the statement in the Security Considerations >> section, but it is consistent with all other documents related to >> defining ABNF, and I can't find any noteworthy security issues anyway. >> From that, I have no objection to moving this document forward. > > As you can see, I just followed precedent since I wasn't doing > anything that would alter the security implications in any way. > > But I am open to suggestions for something better to say. Nah, I like the consistency. The only concern (very minor) that I have is about how older ABNF interpreters would react to seeing these new literals. I don't think that they're mission critical in any way and the one that I tried (BAP) just gave me an error. > >> I did find some nits and have some suggestions for improving >> readability. >> >> 1 - "Mackus-Naur" is used in two places rather than "Backus-Naur". > > Yes. I don't know how that happened. Kind'a funny - you're not the first to make that error. http://publib.boulder.ibm.com/infocenter/wtelecom/v6r2m0/index.jsp?topic=/com.ibm.diameter.rf.doc/rf_rawinterface_r.html > >> 2 - The last sentence of section 2.1 is: >> >> This mechanism has a clear readability >> disadvantage, with respect to using a literal text string with a >> prefix, and new the prefix mechanism is preferred. >> >> >> Perhaps you meant: >> This mechanism of using a literal text string with a prefix has a >> clear >> readability disadvantage. The prefix mechanism described in this >> specification can be much more easily read. > > No. "This mechanism" refers to "the way that has been used in the > past" (specify the individual characters numerically). How about: > > "The new way (using a literal text string with a prefix) has a clear > readability advantage over the old way." Works for me. See the response I sent to Barry. > >> 3 - This part of Section 2.1 may be cleared up some: >> ---vvv--- >> >> If no prefix is present then the string is case-insensitive. >> >> Hence: >> >> rulename = %i"aBc" >> >> and: >> >> rulename = "abc" >> >> will both match "abc", "Abc", "aBc", "abC", "ABc", "aBC", "AbC", and >> "ABC". >> >> >> ---^^^--- >> >> Suggested: >> ---vvv--- >> To be consistent with current implementations of ABNF, having no >> prefix means that the string is case-insensitive, and is >> equivalent >> to having the "%i" prefix. > > This seems good, except for the use of "current". That doesn't age > well. I suggest replacing "current" with "prior". > Works for me as well. Best regards, Chris > Thanks, > Paul > >> Hence: >> >> rulename = %i"aBc" >> >> and: >> >> rulename = "abc" >> >> are equivalent and both will match "abc", "Abc", "aBc", "abC", >> "ABc", >> "aBC", "AbC", and "ABC". >> ---^^^--- >> >> Best regards, >> Chris >> > From nobody Sun Sep 7 06:34:42 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D72671A03A9 for ; Sun, 7 Sep 2014 06:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable 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 ci6N1HtyTFPM for ; Sun, 7 Sep 2014 06:34:33 -0700 (PDT) Received: from smtp98.ord1c.emailsrvr.com (smtp98.ord1c.emailsrvr.com [108.166.43.98]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9953A1A0359 for ; Sun, 7 Sep 2014 06:34:33 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp5.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id E005B180346; Sun, 7 Sep 2014 09:34:32 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp5.relay.ord1c.emailsrvr.com (Authenticated sender: scott-AT-hyperthought.com) with ESMTPSA id BCECF1802AD; Sun, 7 Sep 2014 09:34:31 -0400 (EDT) X-Sender-Id: scott@hyperthought.com Received: from [192.168.128.24] (c-76-21-94-29.hsd1.ca.comcast.net [76.21.94.29]) (using TLSv1 with cipher AES128-SHA) by 0.0.0.0:587 (trex/5.2.10); Sun, 07 Sep 2014 13:34:32 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 $1878.6$) From: Scott Kelly In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439AE9D53F@TK5EX14MBXC292.redmond.corp.microsoft.com> Date: Sun, 7 Sep 2014 06:34:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <88AAAE10-880A-410A-A582-245FBB07E592@hyperthought.com> References: <3266E6F3-AB87-4B45-9C6F-A3B6976DBCEC@hyperthought.com> <4E1F6AAD24975D4BA5B16804296739439AE9D53F@TK5EX14MBXC292.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/67wDxcH1qwioeUleV270O5JCxig Cc: "draft-ietf-jose-json-web-encryption.all@tools.ietf.org" , "iesg@ietf.org" , "jose@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-jose-json-web-encryption-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Sep 2014 13:34:36 -0000 Hi Mike, Responses inline below=E2=80=A6 On Sep 5, 2014, at 4:13 PM, Mike Jones = wrote: > Thanks for the useful review, Scott. I=E2=80=99ve cc=E2=80=99ed the = working group in my reply so that they=E2=80=99re aware of the contents = of your review. Jim Schaad =E2=80=93 also please see questions to you = below. Replies are inline below=E2=80=A6 > =20 > -----Original Message----- > From: Scott Kelly [mailto:scott@hyperthought.com]=20 > Sent: Saturday, August 30, 2014 6:13 AM > To: secdir@ietf.org; = draft-ietf-jose-json-web-encryption.all@tools.ietf.org; iesg@ietf.org > Subject: secdir review of draft-ietf-jose-json-web-encryption-31 > =20 > I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. > =20 > =46rom the abstract, JSON Web Encryption (JWE) represents encrypted = content using JavaScript Object Notation (JSON) based data structures. A = little like CMS for web transactions. > =20 > The security considerations section begins > =20 > "All of the security issues that are pertinent to any cryptographic > application must be addressed by JWS/JWE/JWK agents. Among these > issues are protecting the user's asymmetric private and symmetric > secret keys, preventing various attacks, and helping avoid mistakes > such as inadvertently encrypting a message to the wrong recipient. > The entire list of security considerations is beyond the scope of > this document, but some significant considerations are listed = here." > =20 > "All the security considerations in the JWS specification also apply > to this specification. Likewise, all the security considerations = in > XML Encryption 1.1 [W3C.REC-xmlenc-core1-20130411] also apply, = other > than those that are XML specific." > =20 > If you are going to point to the JWS specification, you should use a = normative reference. It's fine to point at other references to avoid = re-stating the obvious, but all security considerations *are* within = scope, and require coverage, either directly or by reference. I haven't = reviewed the referenced W3C spec, so I'm not sure that everything has = been covered. The JWS security considerations section only talks about = crypto algs and server identity verification. So, the ADs will want to = pay attention here. > =20 > We plan to remove the sentence =E2=80=9CThe entire list of security = considerations is beyond the scope of this document, but some = significant considerations are listed here=E2=80=9D since several = reviewers have taken exception to it. > =20 > I=E2=80=99m a bit confused by your comment about normative references, = because the JWS reference already is normative. I started by reading the security considerations, and that comment was = triggered by the fact that it says =E2=80=9Cthe JWS specification=E2=80=9D= rather than [JWS]. This is a nit, not sure its important so long as you = do already have the reference. > =20 > Jim Schaad, etc., do you agree that the XMLENC reference should become = normative? I=E2=80=99d though that earlier you=E2=80=99d advised me = that security considerations references should be informative. See https://www.ietf.org/iesg/statement/normative-informative.html, = where it says "Within an RFC, references to other documents fall into two general=20= categories: "normative" and "informative". Normative references = specify documents that must be read to understand or implement the = technology=20 in the new RFC, or whose technology must be present for the = technology in the new RFC to work. An informative reference is not normative;=20= rather, it only provides additional information. For example, an=20 informative reference might provide background or historical = information. Informative references are not required to implement the technology = in=20 the RFC." If what is being described are security *requirements*, then I think the = reference should be normative. > =20 > FYI, as part of addressing Russ Housley=E2=80=99s comments on the = Security Considerations section, I do expect to explicitly reference a = number of security considerations called out in XMLENC, such as the text = on chosen-ciphertext attacks, backwards compatibility attacks, etc. > =20 > In section 5.1 (Message Encryption), step 16 says "Encrypt M..." = without ever defining M. One might guess it stands for Message, but this = should be stated. > =20 > Agreed > =20 > Section 8 (TLS Requirements) points at JWS, but neither document = references the channel binding problem. If you are depending on TLS to = provide essential and necessary security features (which, presumably, = you are since TLS is a MUST), then you should give clear guidance as to = how to effectively use it. JWS requires combined confidentiality and = integrity protection, and also requires server identity verification per = RFC6125, but does not mention channel binding. > =20 > Scott, is there text on the channel binding problem in another = specification that you=E2=80=99d recommend that we reference or use? If = not, would you mind supplying proposed text for us to use? RFC5056 covers channel bindings, and RFC5929 covers channel bindings for = TLS. My comment is related to the requirement for TLS, which is = described in the JWS document. Note that I didn=E2=80=99t say channel = bindings are definitely a problem here, only that I=E2=80=99m surprised = they are not mentioned. Whether or not channel bindings need to be addressed depends on the = threats you intend to address. Some of my other comments were intended = to indicate that the scope of threats/protections are not explicit in = this draft, and after a quick scan of JWS, they still were not clear to = me. Any ADs reading all the drafts will have information/context I lack, = so the comment was intended as a heads up. > =20 > Section 11.1 (Using Matching Algorithm Strengths) says > =20 > "Algorithms of matching strengths should be used together whenever > possible. For instance, when AES Key Wrap is used with a given key > size, using the same key size is recommended when AES GCM is also > used." > =20 > This doesn't quite scan for me, but editorial nits aside, it might be = good to say greater or equal key sizes should be used for wrapping. > =20 > The =E2=80=9Cmatching strengths=E2=80=9D guidance came from Eric = Rescorla and I believe was supported by then-Security AD Sean Turner. = It=E2=80=99s not clear to me that the =E2=89=A5 language is better than = what=E2=80=99s there now, in part because if the strengths don=E2=80=99t = match, it=E2=80=99s not clear to me which way the inequality should go. Ruling out the use of stronger keys for wrapping seems non-intuitive to = me, but your point illustrates that this may introduce additional = security considerations. Personally, I like the language in the security = considerations section of RFC5652: "When using key-agreement algorithms or previously distributed symmetric key-encryption keys, a key-encryption key is used to encrypt the content-encryption key. If the key-encryption and content-encryption algorithms are different, the effective security is determined by the weaker of the two algorithms. If, for example, content is encrypted with Triple-DES using a 168-bit Triple-DES content-encryption key, and the content-encryption key is wrapped with RC2 using a 40-bit RC2 key-encryption key, then at most 40 bits of protection is provided. A trivial search to determine the value of the 40-bit RC2 key can recover the Triple-DES key, and then the Triple-DES key can be used to decrypt the content. Therefore, implementers must ensure that key-encryption algorithms are as strong or stronger than content-encryption algorithms.=E2=80=9D > And you might want to point to RFC3766 for BCPs when using public = keys. > =20 > The RFC 3766 reference looks like a good one. Thanks for providing = it. > =20 > Section 11.2 introduces the term "key tainting". "Strict key = management/usage policy" might be better understood. Also, it might be = valuable to use SHOULD here. > =20 > Jim Schaad, you suggested using the term =E2=80=9Ckey tainting=E2=80=9D.= Is there a place where this term is defined, which we could reference? > =20 > Also, Jim, I believe in our in-person discussions of issue #70 (Review = of 2119 Language) you=E2=80=99d suggested that we use 2119 keywords in = the Security Considerations statements. Am I remembering that right, or = would you prefer that the Security Considerations sections use 2119 = language? > =20 > I was surprised not to see any mention of the lack of replay = protection. TLS channel binding could presumably be leveraged for this = purpose, but in any event, the fact that JWEs can be replayed should be = mentioned. > =20 > It=E2=80=99s not clear to me that being able to decrypt an encrypted = object multiple times if you hold the correct key constitutes an attack, = any more than being able to check a signature multiple times does. One example: once a symmetric key is compromised (wrapping or wrapped = key), the bad actor who holds that key can impersonate the server and = provide the wrapped key to the target client. This is one of the threats = you may be intending to mitigate with TLS, but based on my reading, that = is not clear to me. And I think that to fully leverage TLS for this = purpose, you must address the channel bindings problem. =20 (I think you allude to this in the next paragraph of your reply, but it = seems less confusing to insert this comment here) > I agree with you that some higher-level objects that may use JWE (or = JWS) may want replay protection. For = instance,http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-25#sec= tion-4.1.7 describes a means of replay protection for JWTs. At most, if = we mention replay protection, I would propose that we say that some = applications using JWE encryption may choose to incorporate replay = protection mechanisms, such as by including IDs in the protected content = that change with each application-level usage. Would that work for you = Scott, or is there something else you had in mind? > =20 > As always, if you can supply specific proposed language to address = your concern, that would probably be the clearest statement of what = you=E2=80=99d like to see. > =20 > I would suggest that the authors read the security considerations in = rfc5652; most of the same concerns apply here, and you could almost = cut/paste from there to here. > =20 > Thanks. I expect to reference some of these as well when addressing = Russ Housley=E2=80=99s gen-art review comments of JWS. > =20 > For the ADs: I'm not sure if one of the companion documents provides a = comprehensive threat model, but you will want to pay attention here. = This doc does not. > =20 > Each doc tries to list security considerations specific to that = document and where they span documents, they are described in one and = referenced in others. > =20 > Thanks = again, Scott, > -- = Mike One more comment related to security considerations, comprehensive = threat model, etc.: RFC3552 gives a roadmap for security considerations. = Your family of documents should cover that roadmap. I understand that = you don=E2=80=99t want to repeat things in every document, but the ADs = will have to ensure that, however you approach it, everything is = covered. That was my point. =E2=80=94Scott =20= From nobody Mon Sep 8 09:12:25 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0E741A88A9 for ; Mon, 8 Sep 2014 09:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable 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 NQBqdzyIDzvb for ; Mon, 8 Sep 2014 09:10:53 -0700 (PDT) Received: from na6sys009bog011.obsmtp.com (na6sys009bog011.obsmtp.com [74.125.150.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B2A11A8898 for ; Mon, 8 Sep 2014 09:10:52 -0700 (PDT) Received: from mail-ie0-f180.google.com ([209.85.223.180]) (using TLSv1) by na6sys009bob011.postini.com ([74.125.148.12]) with SMTP ID DSNKVA3VCmTloa80NgfVgvlI0VnVZtjycCg9@postini.com; Mon, 08 Sep 2014 09:10:52 PDT Received: by mail-ie0-f180.google.com with SMTP id rd18so1125580iec.11 for ; Mon, 08 Sep 2014 09:10:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=uuv/49iVYSChMtiBCB0n6CimZAflL9W7lSDBtbzd4+I=; b=GjQPo1UyaSH6POzue2hLJk6GBDQIX/7Wn/n12K2fnheqFEmpbpDzS5z5wZI0YiY/OQ 76oI5yHkZiFvKEGoh792BmeSA/evQntB6JQ7fGFzmrlw03z9tLkZyVFI7GKi3LCoR8WP JlUBtDPHNLC8RHac6xc2vm/4+d9Rkhxb9s7xVhJHJz+9SUXd5Hxb67ir6nsPXYqbXRFW LgOLfX5ZsUfZ2qLkqxfMphaGwrZqQa8hvocwik+VrltiSOglfzo7RRJpwHdGMho7Y0Eq KN1XaFfhu8QXdjN7LA0PtZfYl24uITCHYZZ5xjZLflFhum/6eTxv8PCH2t+xKrZorUxC 1Hmg== X-Gm-Message-State: ALoCoQm90yfg65QnytfY4Xl1z15ZJbJD+yC8KU2BKUQB04jgrHPIarcKCE9In4hq+J4xBLlQeBRKnWHmtRsKEwuVGMIsFdL8Nj99/rftrmsTmUZgA+YDltoYLrpz6FKQ60Af21wgPkZ8dlO9SrqX9ciereRzMb/9Ag== X-Received: by 10.42.4.136 with SMTP id 8mr9009671ics.57.1410192650265; Mon, 08 Sep 2014 09:10:50 -0700 (PDT) X-Received: by 10.42.4.136 with SMTP id 8mr9009655ics.57.1410192650158; Mon, 08 Sep 2014 09:10:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.12.137 with HTTP; Mon, 8 Sep 2014 09:10:19 -0700 (PDT) From: Brian Campbell Date: Mon, 8 Sep 2014 10:10:19 -0600 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=001a1134476cfa619c0502900fd8 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/QF5vtOr3znbgIGiiFj7m8PkawwE X-Mailman-Approved-At: Mon, 08 Sep 2014 09:12:12 -0700 Cc: "draft-ietf-oauth-json-web-token.all@tools.ietf.org" , "oauth@ietf.org" , "jose@ietf.org" , "secdir@ietf.org" Subject: [secdir] alternative term to "plaintext" for the "none" alg (was Re: [OAUTH-WG] Review of: draft-ietf-oauth-json-web-token) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 16:10:57 -0000 --001a1134476cfa619c0502900fd8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable cc'ing JOSE on a minor JWT review comment that might impact JWS/JWA. I agree that "plaintext=E2=80=9D is not the most intuitive wording choice a= nd that "unsecured" might better convey what's going on with the "none" JWS algorithm. Mike mentioned that, if this change is made in JWT, there are parallel changes in JWS. But note that there are also such changes in JWA (more than in JWS actually). On Fri, Sep 5, 2014 at 6:28 PM, Mike Jones wrote: > -----Original Message----- > From: Warren Kumari [mailto:warren@kumari.net] > Sent: Monday, September 01, 2014 3:40 PM > To: secdir@ietf.org; draft-ietf-oauth-json-web-token.all@tools.ietf.org > Subject: Review of: draft-ietf-oauth-json-web-token > > I'm a little confused by something in the Terminology section (Section 2)= : > > Plaintext JWT > > A JWT whose Claims are not integrity protected or encrypted. > > The term plaintext to me means something like "is readable without > decrypting / much decoding" (something like, if you cat the file to a > terminal, you will see the information). Integrity protecting a string > doesn't make it not easily readable. If this document / JOSE uses > "plaintext" differently (and a quick skim didn't find anything about > > this) it might be good to clarify. Section 6 *does* discuss plaintext > JWTs, but doesn't really clarify the (IMO) unusual meaning of the term > "plaintext" here. > > > > I=E2=80=99ve discussed this with the other document editors and we agree = with you > that =E2=80=9Cplaintext=E2=80=9D is not the most intuitive wording choice= in this context. > Possible alternative terms are =E2=80=9CUnsecured JWT=E2=80=9D or =E2=80= =9CUnsigned JWT=E2=80=9D. I think > that =E2=80=9CUnsecured JWT=E2=80=9D is probably the preferred term, sinc= e JWTs that are > JWEs are also unsigned, but they are secured. Working group =E2=80=93 ar= e you OK > with this possible terminology change? (Note that the parallel change > =E2=80=9CPlaintext JWS=E2=80=9D -> =E2=80=9CUnsecured JWS=E2=80=9D would = also be made in the JWS spec.) > > > --001a1134476cfa619c0502900fd8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
cc'ing JOSE on a minor JWT review comment that might i= mpact JWS/JWA.

I agree that "plaintext=E2=80=9D is not th= e most intuitive wording choice and that "unsecured" might better= convey what's going on with the "none" JWS algorithm.
Mike mentioned that, if this change is made in JWT, there are = parallel changes in JWS. But note that there are also such changes in JWA (= more than in JWS actually).
<= br>
On Fri, Sep 5, 2014 at 6:28 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

-----Original Message-----
From: Warren Kumari [mailto:warren@kumari.net]
Sent: Monday, September 01, 2014 3:40 PM
To: secdir@ietf.org; draft-ietf-oauth-json-web-token.all@tools.ietf.org
Subject: Review of: draft-ietf-oauth-json-web-token

I'm a little confused by something in the Terminology section (Secti= on 2):

Plaintext JWT

A JWT whose Claims are not integrity protected or encrypted.

The term plaintext to me means something like "is readable without = decrypting / much decoding" (something like, if you cat the file to a = terminal, you will see the information). Integrity protecting a string does= n't make it not easily readable. If this document / JOSE uses "plaintext" differently (= and a quick skim didn't find anything about

this) it might be good to clarify. Section 6 *does* discuss plaintext JW= Ts, but doesn't really clarify the (IMO) unusual meaning of the term &q= uot;plaintext" here.

=C2=A0

I=E2=80=99ve discussed this with th= e other document editors and we agree with you that =E2=80=9Cplaintext=E2= =80=9D is not the most intuitive wording choice in this context.=C2=A0 Poss= ible alternative terms are =E2=80=9CUnsecured JWT=E2=80=9D or =E2=80=9CUnsi= gned JWT=E2=80=9D.=C2=A0 I think that =E2=80=9CUnsecured JWT=E2=80=9D is probab= ly the preferred term, since JWTs that are JWEs are also unsigned, but they= are secured.=C2=A0 Working group =E2=80=93 are you OK with this possible t= erminology change?=C2=A0 (Note that the parallel change =E2=80=9CPlaintext = JWS=E2=80=9D -> =E2=80=9CUnsecured JWS=E2=80=9D would also be made in the JWS spec.)

=C2=A0
--001a1134476cfa619c0502900fd8-- From nobody Wed Sep 10 14:07:50 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D826B1A9143 for ; Wed, 10 Sep 2014 14:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 Zhqcxv6yjgXC for ; Wed, 10 Sep 2014 14:07:47 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 103011A9248 for ; Wed, 10 Sep 2014 14:07:45 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta13.westchester.pa.mail.comcast.net with comcast id pY341o0020bG4ec5DZ7lPk; Wed, 10 Sep 2014 21:07:45 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by omta03.westchester.pa.mail.comcast.net with comcast id pZ7k1o0073Ge9ey3PZ7kvT; Wed, 10 Sep 2014 21:07:45 +0000 Message-ID: <5410BDA0.7050305@alum.mit.edu> Date: Wed, 10 Sep 2014 17:07:44 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Chris Lonvick , iesg@ietf.org, secdir@ietf.org, draft-kyzivat-case-sensitive-abnf.all@tools.ietf.org References: <540A3309.90802@gmail.com> In-Reply-To: <540A3309.90802@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1410383265; bh=wSj3tga9g9b07yroRWrQSBgMHYTKJEVMF4P3Q6pa5Qk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hQ/xBL4gHB7KDypPPwXjpwGfJdtbSk2C8p8ykvQ88wpayhDlyU+EZQCzSB5zqwxo8 SkAZ83ziFPM5wY1UPs3cBrnzHAZd60rrQRHrVVExkKcfDIQzxfykzWYP1TKYkzJrUn X71ibTvGRytslmlFE4pmbWnRsLzhAR1H0xM+K14Mt4zDupPEFCO1A5ZTv9qym9yYVx slQWrBav51M+7c3C5LuAfAfB3bIdA+f1ko4xh77ahaPuj5DizV/klvayE9pI/jBp9W Q9MWsbYVU0QqBHJIq4idQWA6MAA0ihIc97cO4L4hv93hPC1WpUM6iLoZBNyJx7iq0D 5OJPnTZ+B+Ukw== Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/v9iu-DwBiRjxrv44RC0xUz_s1ig Subject: Re: [secdir] SECDIR review of draft-kyzivat-case-sensitive-abnf X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 21:07:49 -0000 Chris, Based on discussions in this thread I've posted an -02 version that hopefully addresses all of your comments. Thanks, Paul On 9/5/14 6:02 PM, Chris Lonvick wrote: > Hi, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security > area directors. Document editors and WG chairs should treat these > comments just like any other last call comments. > > The abstract is: > > This document extends the base definition of ABNF (Augmented Mackus- > Naur Form) to include a way to specify ASCII string literals that are > matched in a case-sensitive manner. > > > Overall, I don't like the statement in the Security Considerations > section, but it is consistent with all other documents related to > defining ABNF, and I can't find any noteworthy security issues anyway. > From that, I have no objection to moving this document forward. > > I did find some nits and have some suggestions for improving readability. > > 1 - "Mackus-Naur" is used in two places rather than "Backus-Naur". > > 2 - The last sentence of section 2.1 is: > > This mechanism has a clear readability > disadvantage, with respect to using a literal text string with a > prefix, and new the prefix mechanism is preferred. > > > Perhaps you meant: > This mechanism of using a literal text string with a prefix has a clear > readability disadvantage. The prefix mechanism described in this > specification can be much more easily read. > > > 3 - This part of Section 2.1 may be cleared up some: > ---vvv--- > > If no prefix is present then the string is case-insensitive. > > Hence: > > rulename = %i"aBc" > > and: > > rulename = "abc" > > will both match "abc", "Abc", "aBc", "abC", "ABc", "aBC", "AbC", and > "ABC". > > > ---^^^--- > > Suggested: > ---vvv--- > To be consistent with current implementations of ABNF, having no > prefix means that the string is case-insensitive, and is equivalent > to having the "%i" prefix. > > Hence: > > rulename = %i"aBc" > > and: > > rulename = "abc" > > are equivalent and both will match "abc", "Abc", "aBc", "abC", "ABc", > "aBC", "AbC", and "ABC". > ---^^^--- > > Best regards, > Chris > From nobody Wed Sep 10 17:58:11 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 932D91A01C3; Wed, 10 Sep 2014 17:58:02 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 Mm1MFgbdSMJv; Wed, 10 Sep 2014 17:57:50 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0140.outbound.protection.outlook.com [207.46.100.140]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AD271A01A5; Wed, 10 Sep 2014 17:57:50 -0700 (PDT) Received: from CH1PR03CA004.namprd03.prod.outlook.com (10.255.156.149) by BN3PR0301MB1201.namprd03.prod.outlook.com (25.161.207.154) with Microsoft SMTP Server (TLS) id 15.0.1019.16; Thu, 11 Sep 2014 00:57:48 +0000 Received: from BY2FFO11FD038.protection.gbl (10.255.156.132) by CH1PR03CA004.outlook.office365.com (10.255.156.149) with Microsoft SMTP Server (TLS) id 15.0.1024.12 via Frontend Transport; Thu, 11 Sep 2014 00:57:47 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD038.mail.protection.outlook.com (10.1.14.223) with Microsoft SMTP Server (TLS) id 15.0.1019.14 via Frontend Transport; Thu, 11 Sep 2014 00:57:46 +0000 Received: from TK5EX14MBXC292.redmond.corp.microsoft.com ([169.254.1.60]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.03.0195.002; Thu, 11 Sep 2014 00:57:37 +0000 From: Mike Jones To: Stephen Kent , "secdir@ietf.org" , "jose-chairs@tools.ietf.org" , "Moriarty, Kathleen" Thread-Topic: SECDIR review of draft-ietf-jose-json-web-key-31 Thread-Index: Ac/NW1FjzMdOWVrURg2Daf2ptprAcw== Date: Thu, 11 Sep 2014 00:57:36 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439AEB89F6@TK5EX14MBXC292.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.78] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439AEB89F6TK5EX14MBXC292r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(438002)(43784003)(189002)(199003)(377454003)(3905002)(19300405004)(6806004)(33656002)(26826002)(83072002)(92726001)(85852003)(2201001)(92566001)(86362001)(69596002)(19580405001)(44976005)(83322001)(19580395003)(87936001)(68736004)(230783001)(97736003)(19617315012)(81156004)(106466001)(85306004)(54356999)(104016003)(2501002)(16236675004)(107046002)(99396002)(50986999)(19625215002)(95666004)(46102001)(77096002)(512954002)(15202345003)(84676001)(86612001)(90102001)(84326002)(79102001)(20776003)(74502001)(31966008)(74662001)(2656002)(64706001)(77982001)(55846006)(21056001)(80022001)(81542001)(4396001)(85806002)(66066001)(81342001)(15975445006)(76482001)(71186001)(7059017)(569005); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1201; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 03319F6FEF Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Bli3zoC8cQREwbeQqzn5tXdzNnc Cc: "jose@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-jose-json-web-key-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 00:58:03 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439AEB89F6TK5EX14MBXC292r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Stephen. Thanks for your detailed and useful review. I've cc'ed the wo= rking group in my reply so they're aware of the contents of your review. R= eplies are inline below... From: Stephen Kent [mailto:kent@bbn.com] Sent: Tuesday, September 02, 2014 1:09 PM To: secdir@ietf.org; Mike Jones; jose-chairs@tools.= ietf.org; Moriarty, Kathleen Subject: SECDIR review of draft-ietf-jose-json-web-key-31 Bottom Line: This needs work before it's ready for publication. I encountered many examples of confusing wording, some of which I fixed; ot= hers can be fixed based on my comments. I also found some worrisome require= ments that need more careful evaluation: A MUST that probably is a SHOULD, = alternatives to using an IANA registry (without a rationale for such an opt= ion, etc.). This document is part of a series from the JOSE WG, defining formats and pr= ocedures for using JSON to convey keys, encrypted, authenticated, and/or si= gned data. This document focuses on keys. A significant portion (about 50%)= of the document is devoted to appendices, several of which provide detaile= d examples of JOSE headers conveying key material. I am not knowledgeable about JSON. I anticipate that the intended audience = for the doc is. So, I started by jumping to the Security Considerations sec= tion. This section addresses several good topics, but the wording is very a= wkward in places. For example, the section begins by saying: All of the security issues that are pertinent to any cryptographic application must be addressed by JWS/JWE/JWK agents. Among these issues are protecting the user's asymmetric private and symmetric secret keys, preventing various attacks, and helping avoid mistakes such as inadvertently encrypting a message to the wrong recipient. Many attacks cannot be prevented; one can employ countermeasures so that th= e attacks are not successful, but that's not what the text says. Also, hel= ping avoid a mistake such as sending an encrypted message to the wring reci= pient is a laudable goal, but it seems like a poor example for this documen= t (and it is likely to be impossible in many cases). I agree that "employing countermeasures to" is more accurate than "preventi= ng". I also agree that the "avoiding mistakes" language is not actionable = - I propose to just remove it. Another questionable example appears at the beginning of 9.1: One should place no more trust in the data associated with a key than in than the method by which it was obtained and in the trustworthiness of the entity asserting an association with the key. Even removing the apparently redundant "than in" this sounds like advice sp= oken by Yoda. Actually, it was spoken by then-Security AD Sean Turner. ;-) It's not clear whether the author is referring to the data about a key, vs.= data decrypted or authenticated using a key. This point needs to be made m= ore clearly. How about changing "data associated with a key" to "data cryptographically = secured by a key"? (And of course, deleting the extraneous "than".) Section 9.2 discusses the importance of protecting private and symmetric ke= ys. It says: Private and symmetric keys MUST be protected from disclosure to unintended parties. One recommended means of doing so is to encrypt JWKs or JWK Sets containing them by using the JWK or JWK Set value as the plaintext of a JWE. The wording above is needlessly awkward. Nonetheless, this says that key se= ts containing symmetric or private keys should be encrypted by embedding th= em in another JSON crypto format (JWE). It would be nice to add that this i= mplies a that there is secure way to deliver the needed decryption key for = the JWE, else this recommendation just adds a layer of indirection, and doe= s not solve the problem. Fair enough. I propose that we add something along those lines. Section 9.3 discusses a countermeasure against a specific attack on RSA key= use. This seems unduly narrow, since this spec is intended for use with RS= A, DH, DSS, and ECDH keys. Why devote a long paragraph to this one issue, w= hile saying nothing about equally serious concerns that arise for other alg= orithms? This particular attack is described both because the countermeasure require= s specific key representation actions and because a working group member as= ked it to be included. For what it's worth, I expect that additional secur= ity considerations will be added when resolving Russ Housley's gen-art revi= ew of the JWS specification. Returning to the body of the document, I noticed an awkward sentence in the= introduction: Goals for this specification do not include representing new kinds of certificate chains, representing new kinds of certified keys, or replacing X.509 certificates. This seems like an arbitrary set of non-goals. Perhaps the JOSE WG discussi= ons prompted this declaration. If so, more text to establish that context w= ould be helpful. These non-goals were agreed to by the working group from the very beginning= , while the working group was still being chartered. The group wanted to b= uild something simple and easily deployable to represent keys in JSON - not= reinvent all the work that the PKIX working group did on certificates and = certificate chains, etc. Do any working group members want to suggest spec= ific wording to try to capture this sentiment? The example that comprises Section 3 should include an explanation of the p= arameters, else it's not a great example. The parameters and values of them are explained in the paragraph preceding = the example text. It says: The following example JWK declares that the key is an Elliptic Curve [DSS] key, it is used with the P-256 Elliptic Curve, and its x and y coordinates are the base64url encoded values shown. A key identifier is also provided for the key. Each statement above corresponds to a parameter in the example, and in the = same order. I suppose that one option is to be more verbose above and add parenthetical= remarks after each statement above saying which parameter does this. So f= or instance, the parenthetical phrase "("kty" parameter)" could be added be= fore the first comma. Do others in the working group think that would make= the example easier to read, harder to read, or do any of you have an alter= native suggestion? Section 4 starts with awkward wording, to wit: In addition to the common parameters, each JWK will have members that are specific to the kind of key being represented. These members represent the parameters of the key. The reuse of the word "parameters" in the two sentences above creates an ap= parent conflict: How about: In addition to the common parameters, each JWK will have members that are algorithm-specific. They're not algorithm-specific - they're key type-specific. Another way of= eliminating the repeated use of the word "parameters" is to replace the se= cond sentence with "These members represent the key value". Would that wor= k for you (and the working group)? This section imposes a rather wimpy constraint on parameter names: The member names within a JWK MUST be unique; recipients MUST either reject JWKs with duplicate member names or use a JSON parser that returns only the lexically last duplicate member name, as specified in Section 15.12 (The JSON Object) of ECMAScript 5.1 [ECMAScript]. This text says that member names MUST be unique, but if they are not, that'= s OK too; just use the last instance of a member with a duplicate name. Thi= s seems like a terrible design principle. It imposes what appears to be a r= equirement, then says how to accommodate data structures that fail to meet = the requirement. This would seem to encourage sloppy implementations (for J= WK generation). I'd like to see the rationale for this. Unfortunately, the intentional laxness in the spec in this regard is a refl= ection of the semantics of the actual JSON specifications and implementatio= ns. For instance, http://tools.ietf.org/html/rfc7159#section-4 says: An object whose names are all unique is interoperable in the sense that all software implementations receiving that object will agree on the name-value mappings. When the names within an object are not unique, the behavior of software that receives such an object is unpredictable. Many implementations report the last name/value pair only. Other implementations report an error or fail to parse the object, and some implementations report all of the name/value pairs, including duplicates. This topic has been heavily discussed by the working group, and while the s= pecs used to just say that objects with duplicate member names MUST be reje= cted, working group members, including Tim Bray (the editor of the JSON spe= c), prevailed on us to weaken this so that parsers that implement the ECMAs= cript behavior of returning only the last member name may be legally used. = (The argument was made that there was more security downside in effectivel= y requiring people to write and debug their own strict parsers than in usin= g laxer, but well-supported and debugged parsers.) However, we also intentionally require that producers use only one instance= of each member name, so that legally produced objects will never exercise = the ambiguities that are present in real JSON parsers. That seemed to be t= he most practical solution to the working group. The next paragraph defines a rather wimpy requirement: Member names used for representing key parameters for different keys [sic] types need not be distinct. Any new member name should either be registered in the IANA JSON Web Key Parameters registry defined in Section 8.1 or be a value that contains a Collision-Resistant Name. The text should include a pointer to the definition of "Collision-Resistant= Name in the JWS doc (or add it to the terminology section here), to make t= his requirement less mysterious. The term is used extensively in this secti= on. Since it is repeatedly offered as an alternative to IANA registration o= f a member name; I examined the definition in the JWS document, to discover= what a C-R name is. The definition there emphasizes examples, one of which= ensure uniqueness (OIDs) but the other, despite its name, does not. The te= xt here should explain why using a C-R name is a good alternative to the us= e of am IANA registry and thus when use a C-R name is a good idea. The term "Collision-Resistant Name" is already present in the Terminology s= ection. However, previous reviewers had requested that definitions not be = repeated in multiple specs, so it's incorporated by reference, rather than = repeating the definition here. The notion is that of an implementation wan= ts to use a collision-resistant name such as "http://names.example.com/the-= name", it can do so without having to create a public specification and reg= ister the name with IANA. In 4.2, the description of the "use" member, due to its name, creates a lot= of awkward sentences. These can (and should) be fixed. For example: Use of the "use" member is OPTIONAL, unless the application requires its presence. can become: The "use" member need not be present in a JWK, unless the application consuming the JWK requires it. Thanks This section says that a use type of enc SHOULD be employed when describing= public keys used for key agreement. The use of SHOULD here raises the obvi= ous question: When is it OK to not employ that use value for a key agreemen= t key? I agree that the "SHOULD" language is awkward. Rather than saying "SHOULD = be used", we could change it to just say "is used". The mysterious SHOULD noted above is followed by an even more mysterious pa= renthetical statement: (The "alg" member can be used to specify the particular cryptographic operation to be performed, when desired.) This comment conveys no clear meaning in this context, especially since the= alg parameter not is defined until 4.4. Would the language "The "alg" member can be used to specify the cryptograph= ic operation that the key is intended to be used for" work better for you? = Or would people like to just see the parenthetical remark deleted? Section 4.5 defines the key_ops parameter. It's not clear how this paramete= rs and "use" relate. There is also an odd sentence at the end of the first = paragraph: The "key_ops" parameter is intended for use cases in which public, private, or symmetric keys may be present. This seems to encompass all of the types of keys that JWK carries, so the s= entence seems to add no useful qualification for when this parameter is int= ended to be used. This is in contrast to the related statement in the "use" definition: The "use" parameter is intended for use cases in which it is useful to distinguish between public signing keys and public encryption keys. I am sorry to see this document defining "sign" as an operation that refers= to both signatures and MACs. The IETF has done a disservice to the communi= ty by using the term "signature" to refer to message authentication codes i= n several RFCs. The text notes that the values for this parameter match tho= se used in the Web Crypto API, a W3C document for key usage; this is true. = However, I examined that document and found 35 instances of the term "signa= ture." Only about 3 of these refer to a MAC vs. a digital signature. I also= note that the cited document is not yet final, as per the W3C web site. Ma= ybe it's not too late to fix this. If you want to see this parameter name changed, you'll need to file a bug a= gainst the WebCrypto spec and get it changed there. Then I'm sure that JOS= E will gladly follow. The list of key_ops values is followed by this text: Other values MAY be used. Key operation values can be registered in the IANA JSON Web Key Operations registry defined in Section 8.3. The key operation values are case-sensitive strings. The text says that it's OK to use values not in the list, and one "can" reg= ister new values, but, why bother? This seems to be a questionable approach= to extensibility, one that could easily cause confusion when non-registere= d values are employed. The editor should explain why this approach is a goo= d one. This specification will be used both in open environments, in which multipl= e organizations will need to have a common understanding of any extensions = used, and closed environments, which the producing and consuming organizati= on will always be the same and private values could be safely used. IANA r= egistration is definitely the right thing to do for open environments. It'= s probably unnecessary for deployments in closed environments. Section 4.4 presents another register the parameter, or not, choice. Same c= omments as above. This parameter is cited as optional; this merits an expla= nation, since one can imagine a lot of bad outcomes if the algorithm is not= identified. Same answer as for Section 4. The description of kid in 4.5 says: The "kid" (key ID) member can be used to match a specific key. What else would a key ID be used for? "Can" is being used as a non-2119 synonym for "MAY" here. That being said,= we could just change "can be" to "is", since it's explicitly said that its= use is optional at the end of the paragraph. In 4.6 there is a very confusing statement: While there is no requirement that members other than those representing the public key be populated when an "x5u" member is present, doing so may improve interoperability for applications that do not handle PKIX certificates. This assertion, in addition to being an overly-long sentence, begs for an e= xplanation. The parameter is a pointer to an X.509 cert, so how will its in= clusion "improve interoperability" for an application that does not handle = such certs? It also is confusing that this parameter can point to either a = single cert or a cert chain, and the x5c parameter points to a chain, or a = single cert. Why are there two different parameters? Is it just an encoding= difference? If so, more descriptive names ought to be used for these two p= arameters. It's the inclusion of other metadata about the key that might improve inter= operability that's being referred to - not the inclusion of the cert refere= nce. For instance, including "use" or "alg" parameters might be useful to = applications that can't process the certificate. As for the cert vs. cert chain question, in the general case, a chain may b= e required to establish trust. However, a chain of length one (a single ce= rtificate) will also be sufficient in some use cases. We're not inventing = anything new here. The data format is specified in RFC 1421. This section ends with an odd statement: Similarly, if the "alg" member is present, it should represent an algorithm that the certificate allows. A cert always specifies the algorithm with which the public key in the cert= is to be used. So the term "allows" above is odd, at best. I had thought there were uses of RSA keys where the same key is used both f= or signing and encryption (even though this is a deprecated practice). But we could change this to "Similarly, if the "alg" member is present, it = SHOULD correspond to the algorithm specified in the certificate." Or is th= at overly strong for some certificates and uses of them? Section 4.7 includes inaccurate terminology. It says: This MAY be followed by additional certificates, with each subsequent certificate being the one used to certify the previous one. Replace "certify" with "validate." OK Also, the name seems misleading since the chain MAY contain additional cert= s, and hence may not be a chain at all! I'm not sure if I'm following you here. Are you suggesting the possibility= of having multiple certificates not chaining to one another in the represe= ntation? This isn't allowed by the specification, as written. Are you sug= gesting that it needs to be allowed? Section 4.8 refers to a "thumbprint" of a certificate, and describes it inf= ormally as a "digest." The more common technical term is a one-way hash. Th= umbprint seems to be a Microsoft term; "fingerprint" strikes me as more com= mon. The text here, and in 4.9 should point to Appendix C of the JWS docume= nt, where the base64URL encoding is defined. That document should note that= the appendix is normative. Thumbprint is the term used in the Windows libraries, such as http://msdn.m= icrosoft.com/en-us/library/system.security.cryptography.x509certificates.x5= 09certificate2.thumbprint(v=3Dvs.110).aspx. Whereas OpenSSL uses fingerpri= nt http://www.openssl.org/docs/apps/x509.html. I know that there would be = an uproar if we tried to make a breaking change to the "x5t" name at this p= oint, because it's in widespread production use. However, we could add lan= guage saying that certificate thumbprints are also known as certificate fin= gerprints, so people familiar with either term will know what this is. The term "base64url" is incorporated by reference in the terminology sectio= n (Section 2). Actually, Appendix C in JWS is not normative. It's just example code. The= normative definition of the encoding is in Section 5 of RFC 4648. Section 5 again repeats the semi-requirement description of name uniqueness= that appeared at the beginning of Section 4. The same comments apply here,= as there. Same answer. Section 7 begins with a rather wordy statement: Access to JWKs containing non-public key material by parties without legitimate access to the non-public information MUST be prevented. This can be accomplished by encrypting the JWK when potentially observable by such parties to prevent the disclosure of private or symmetric key values. The use of an Encrypted JWK, which is a JWE with the UTF-8 encoding of a JWK as its plaintext value, is recommended for this purpose. How about a simpler way to say this: When private or symmetric keys are transported by JWK, the confidentiality of these keys MUST be ensured. It is RECOMMENDED that confidentiality be provided by encrypting the JWK when the data might be observable by unauthorized parties. Thanks This section then goes on to say: A "cty" (content type) Header Parameter value of "jwk+json" MUST be used to indicate that the content of the JWE is a JWK, unless the application knows that the encrypted content is a JWK by another means or convention, in which case the "cty" value would typically be omitted. Given the rather large loopholes here, this sounds more like a SHOULD, foll= owed by a description of exception conditions, rather than a MUST. It used to be a "SHOULD" but the working group felt that the "MUST ... unle= ss" wording was a more accurate statement of the requirement. Section 8 (IANA Considerations) establishes a two-week review period for cr= eating new (IANA) registry items. This seems too short; some people take mu= lti-week vacations. I note that the same text appears in the JWS and JWE do= cuments. This text was taken from RFC 6749. Typo: Criteria that should be applied by the Designated Expert(s) includes Should be: Criteria that should be applied by the Designated Expert(s) include Thanks I did not review all of the initial registry content defined in 8.1.2, 8.2.= 2, 8.3.2, or 8.4.2. The Appendices appear to be informative; they should be labeled as such. I = did not review the context of the Appendices. But, I did note the following= : Aren't appendices normally informative? In C.2, the text says: o the Plaintext is encrypted using the AES_128_CBC_HMAC_SHA_256 algorithm to produce the Ciphertext The algorithms described here (AES 128 in CBC mode, plus an HMAC computed u= sing SHA-256) provide both encryption and integrity. Thus it may be confusi= ng to refer to this as only "encryption." We could be more explicit and talk about performing authenticated encryptio= n. I also note that the algorithms (algorithm suites) used in the examples in = the appendices lack citations to documents that define these algorithms. Thanks - they can be added. Thanks again, S= tephen, -- Mike --_000_4E1F6AAD24975D4BA5B16804296739439AEB89F6TK5EX14MBXC292r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Stephen. Thanks = for your detailed and useful review. I’ve cc’ed the worki= ng group in my reply so they’re aware of the contents of your review.= Replies are inline below…

<= /p>

From: Stephen Kent [mailto:kent@bbn.com= ]
Sent: Tuesday, September 02, 2014 1:09 PM
To: secdir@iet= f.org; Mike Jones; jose-chair= s@tools.ietf.org; Moriarty, Kathlee= n
Subject: SECDIR review of draft-ietf-jose-json-web-key-31=

Bottom Line: Thi= s needs work before it's ready for publication.
I encountered many examples of confusing wording, some of which I fixed; ot= hers can be fixed based on my comments. I also found some worrisome requirement= s that need more careful evaluation: A MUST that probably is a SHOULD, alte= rnatives to using an IANA registry (without a rationale for such an option,= etc.).

This document is= part of a series from the JOSE WG, defining formats and procedures for usi= ng JSON to convey keys, encrypted, authenticated, and/or signed data. This = document focuses on keys. A significant portion (about 50%) of the document is devoted to appendices, several of w= hich provide detailed examples of JOSE headers conveying key material.

I am not knowled= geable about JSON. I anticipate that the intended audience for the doc is. = So, I started by jumping to the Security Considerations section. This secti= on addresses several good topics, but the wording is very awkward in places.

For example, the= section begins by saying:

   All of the security issues that are = pertinent to any cryptographic

   application must be addressed by JWS= /JWE/JWK agents. Among these

   issues are protecting the user's asy= mmetric private and symmetric

   secret keys, preventing various atta= cks, and helping avoid

   mistakes such as inadvertently encry= pting a message to the wrong

   recipient.

Many attacks can= not be prevented; one can employ countermeasures so that the attacks are no= t successful, but that’s not what the text says. Also, helping = avoid a mistake such as sending an encrypted message to the wring recipient is a laudable goal, but it seems like a poor exampl= e for this document (and it is likely to be impossible in many cases).

I agree that “emplo= ying countermeasures to” is more accurate than “preventing̶= 1;. I also agree that the “avoiding mistakes” language is= not actionable – I propose to just remove it.

<= /p>
Another question= able example appears at the beginning of 9.1:

   One should place no more trust in th= e data associated with a key than

   in than the method by which it was o= btained and in the trustworthiness

   of the entity asserting an associati= on with the key.

Even removing th= e apparently redundant “than in” this sounds like advice spoken= by Yoda. =

<= /p>
Actually, it was spoken b= y then-Security AD Sean Turner. ;-)

<= /p>
It’s not c= lear whether the author is referring to the data about a key, vs. data decr= ypted or authenticated using a key. This point needs to be made more clearl= y.

How about changing “= ;data associated with a key” to “data cryptographically secured= by a key”? (And of course, deleting the extraneous “than= ”.)

<= /p>
Section 9.2 disc= usses the importance of protecting private and symmetric keys. It says:

   Private and symmetric keys MUST be p= rotected from disclosure to

   unintended parties. One recomm= ended means of doing so is to encrypt

   JWKs or JWK Sets containing them by = using the JWK or JWK Set value as

   the plaintext of a JWE.

The wording abov= e is needlessly awkward. Nonetheless, this says that key sets containing sy= mmetric or private keys should be encrypted by embedding them in another JS= ON crypto format (JWE). It would be nice to add that this implies a that there is secure way to deliver the ne= eded decryption key for the JWE, else this recommendation just adds a layer= of indirection, and does not solve the problem.

Fair enough. I prop= ose that we add something along those lines.

<= /p>
Section 9.3 disc= usses a countermeasure against a specific attack on RSA key use. This seems= unduly narrow, since this spec is intended for use with RSA, DH, DSS, and = ECDH keys. Why devote a long paragraph to this one issue, while saying nothing about equally serious concerns tha= t arise for other algorithms?

This particular attack is= described both because the countermeasure requires specific key representa= tion actions and because a working group member asked it to be included. For what it’s worth, I expect that additional = security considerations will be added when resolving Russ Housley’s g= en-art review of the JWS specification.

<= /p>
Returning to the= body of the document, I noticed an awkward sentence in the introduction:

   Goals for this specification do not = include representing new kinds of

   certificate chains, representing new= kinds of certified keys, or

   replacing X.509 certificates.

This seems like = an arbitrary set of non-goals. Perhaps the JOSE WG discussions prompted thi= s declaration. If so, more text to establish that context would be helpful.=

These non-goals were agre= ed to by the working group from the very beginning, while the working group= was still being chartered. The group wanted to build something simple and easily deployable to represent keys in JSON – not reinven= t all the work that the PKIX working group did on certificates and certific= ate chains, etc. Do any working group members want to suggest specifi= c wording to try to capture this sentiment?

<= /p>
The example that= comprises Section 3 should include an explanation of the parameters, else = it’s not a great example.

The parameters and values= of them are explained in the paragraph preceding the example text. I= t says:

<= /p>
   The = following example JWK

   decl= ares that the key is an Elliptic Curve [DSS] key, it is used with

   the = P-256 Elliptic Curve, and its x and y coordinates are the=

   base= 64url encoded values shown. A key identifier is also provided

   for = the key.

Each statement above corr= esponds to a parameter in the example, and in the same order.

<= /p>
I suppose that one option= is to be more verbose above and add parenthetical remarks after each state= ment above saying which parameter does this. So for instance, the parenthetical phrase “(“kty” parameter)” could= be added before the first comma. Do others in the working group thin= k that would make the example easier to read, harder to read, or do any of = you have an alternative suggestion?

<= /p>
Section 4 starts= with awkward wording, to wit:

In addition to the common parameters, each= JWK will have members that

are specific to the kind of key being repr= esented. These members

represent the parameters of the key. =

The reuse of the= word “parameters” in the two sentences above creates an appare= nt conflict: How about:

In addition to the common parameters, each= JWK will have members that

are algorithm-specific.

They’re not algo= rithm-specific – they’re key type-specific. Another way o= f eliminating the repeated use of the word “parameters” is to r= eplace the second sentence with “These members represent the key value”. W= ould that work for you (and the working group)?

This section imp= oses a rather wimpy constraint on parameter names:

   The member names within a JWK MUST b= e unique; recipients MUST either

   reject JWKs with duplicate member na= mes or use a JSON parser that

   returns only the lexically last dupl= icate member name, as specified

   in Section 15.12 (The JSON Object) o= f ECMAScript 5.1 [ECMAScript].

This text says t= hat member names MUST be unique, but if they are not, that’s OK too; = just use the last instance of a member with a duplicate name. This seems li= ke a terrible design principle. It imposes what appears to be a requirement, then says how to accommodate data struct= ures that fail to meet the requirement. This would seem to encourage sloppy= implementations (for JWK generation). I’d like to see the rationale = for this.

Unfortunately, the int= entional laxness in the spec in this regard is a reflection of the semantic= s of the actual JSON specifications and implementations. For instance, http://tools.ietf.org/html/rfc7159#section-4 says:

   An object whose= names are all unique is interoperable in the sense=

   that all softwa= re implementations receiving that object will agree on
   the name-value = mappings. When the names within an object are not
   unique, the beh= avior of software that receives such an object is

   unpredictable.&= nbsp; Many implementations report the last name/value pair

   only. Oth= er implementations report an error or fail to parse the
   object, and som= e implementations report all of the name/value pairs,

   including dupli= cates.

This topic has been he= avily discussed by the working group, and while the specs used to just say = that objects with duplicate member names MUST be rejected, working group members, including Tim Bray (the editor of the JSON spec), p= revailed on us to weaken this so that parsers that implement the ECMAscript= behavior of returning only the last member name may be legally used. = (The argument was made that there was more security downside in effectively requiring people to write and debug = their own strict parsers than in using laxer, but well-supported and debugg= ed parsers.)

However, we also inten= tionally require that producers use only one instance of each member name, = so that legally produced objects will never exercise the ambiguities that are present in real JSON parsers. That seemed to be= the most practical solution to the working group.

The next paragra= ph defines a rather wimpy requirement:

   Member names used for representing k= ey parameters for different keys

   [sic] types need not be distinct.&nb= sp; Any new member name should either be

   registered in the IANA JSON Web Key = Parameters registry defined in

   Section 8.1 or be a value that conta= ins a Collision-Resistant Name.

The text should = include a pointer to the definition of “Collision-Resistant Name in t= he JWS doc (or add it to the terminology section here), to make this requir= ement less mysterious. The term is used extensively in this section. Since it is repeatedly offered as an alternative to IANA = registration of a member name; I examined the definition in the JWS documen= t, to discover what a C-R name is. The definition there emphasizes examples= , one of which ensure uniqueness (OIDs) but the other, despite its name, does not. The text here should exp= lain why using a C-R name is a good alternative to the use of am IANA regis= try and thus when use a C-R name is a good idea.

The term "Collision-Resistant Name" is already present in the Terminology section. H= owever, previous reviewers had requested that definitions not be repeated in multiple specs, so it’s incorporated by reference, rather than re= peating the definition here. The notion is that of an implementation = wants to use a collision-resistant name such as “http://names.example= .com/the-name”, it can do so without having to create a public specification and register the name with IANA.<= /p>

In 4.2, the desc= ription of the “use” member, due to its name, creates a lot of = awkward sentences. These can (and should) be fixed. For example:=

   Use of the "use" member is= OPTIONAL, unless the application requires

   its presence.

can become:=

The “use” member need not be p= resent in a JWK, unless the

application consuming the JWK requires it.=

Thanks

This section say= s that a use type of enc SHOULD be employed when describing public keys use= d for key agreement. The use of SHOULD here raises the obvious question: Wh= en is it OK to not employ that use value for a key agreement key?

I agree that the ̶= 0;SHOULD” language is awkward. Rather than saying “SHOULD= be used”, we could change it to just say “is used”.=

The mysterious S= HOULD noted above is followed by an even more mysterious parenthetical stat= ement:

   (The "alg" member can be u= sed to specify the particular

   cryptographic operation to be perfor= med, when desired.)

This comment con= veys no clear meaning in this context, especially since the alg parameter n= ot is defined until 4.4.

Would the language = 220;The “alg” member can be used to specify the cryptographic o= peration that the key is intended to be used for” work better for you= ? Or would people like to just see the parenthetical remark deleted?=

Section 4.5 defi= nes the key_ops parameter. It’s not clear how this parameters and = 220;use” relate. There is also an odd sentence at the end of the firs= t paragraph:

   The "key_ops" parameter is= intended for use cases in which public,

   private, or symmetric keys may be pr= esent.

This seems to en= compass all of the types of keys that JWK carries, so the sentence seems to= add no useful qualification for when this parameter is intended to be used= .

<= o:p>

T= his is in contrast to the related statement in the “use” defini= tion:

<= o:p>

  = ; The "use" parameter is intended for use cases in which

  = ; it is useful to distinguish between public signing keys and public

  = ; encryption keys.

<= o:p>

I am sorry to se= e this document defining “sign” as an operation that refers to = both signatures and MACs. The IETF has done a disservice to the community b= y using the term “signature” to refer to message authentication codes in several RFCs. The text notes that the values for t= his parameter match those used in the Web Crypto API, a W3C document for ke= y usage; this is true. However, I examined that document and found 35 insta= nces of the term “signature.” Only about 3 of these refer to a MAC vs. a digital signature. I also note that = the cited document is not yet final, as per the W3C web site. Maybe it̵= 7;s not too late to fix this.

<= o:p>

I= f you want to see this parameter name changed, you’ll need to file a = bug against the WebCrypto spec and get it changed there. Then I’m sure that JOSE will gladly follow.

<= o:p>

The list of key_= ops values is followed by this text:

   Other values MAY be used. Key = operation values can be registered in

   the IANA JSON Web Key Operations reg= istry defined in Section 8.3.

   The key operation values are case-se= nsitive strings.

The text says th= at it’s OK to use values not in the list, and one “can” r= egister new values, but, why bother? This seems to be a questionable approa= ch to extensibility, one that could easily cause confusion when non-registered values are employed. The editor should explain why thi= s approach is a good one.

<= o:p>

T= his specification will be used both in open environments, in which multiple= organizations will need to have a common understanding of any extensions used, and closed environments, which the producing and c= onsuming organization will always be the same and private values could be s= afely used. IANA registration is definitely the right thing to do for= open environments. It’s probably unnecessary for deployments in closed environments.

<= o:p>

Section 4.4 pres= ents another register the parameter, or not, choice. Same comments as above= . This parameter is cited as optional; this merits an explanation, since on= e can imagine a lot of bad outcomes if the algorithm is not identified.

<= o:p>

S= ame answer as for Section 4.

<= o:p>

The description = of kid in 4.5 says:

     The "kid" (key= ID) member can be used to match a specific key.

What else would = a key ID be used for?

<= o:p>

&= #8220;Can” is being used as a non-2119 synonym for “MAY” = here. That being said, we could just change “can be” to &= #8220;is”, since it’s explicitly said that its use is optional at the end of the paragraph.

<= o:p>

In 4.6 there is = a very confusing statement:

While there is no requirement that m= embers other than those

   representing the public key be popul= ated when an "x5u" member is

   present, doing so may improve intero= perability for applications that

   do not handle PKIX certificates.&nbs= p;

This assertion, = in addition to being an overly-long sentence, begs for an explanation. The = parameter is a pointer to an X.509 cert, so how will its inclusion “i= mprove interoperability” for an application that does not handle such certs? It also is confusing that this parameter = can point to either a single cert or a cert chain, and the x5c parameter po= ints to a chain, or a single cert. Why are there two different parameters? = Is it just an encoding difference? If so, more descriptive names ought to be used for these two parameters.

<= o:p>

I= t’s the inclusion of other metadata about the key that might improve = interoperability that’s being referred to – not the inclusion of the cert reference. For instance, including “use” or = “alg” parameters might be useful to applications that can’= ;t process the certificate.

<= o:p>

A= s for the cert vs. cert chain question, in the general case, a chain may be= required to establish trust. However, a chain of length one (a single certificate) will also be sufficient in some use cases. = ; We’re not inventing anything new here. The data format is spe= cified in RFC 1421.

<= o:p>

This section end= s with an odd statement:

   Similarly, if the "alg" me= mber is present, it should represent an

   algorithm that the certificate = allows.

A cert always sp= ecifies the algorithm with which the public key in the cert is to be used. = So the term “allows” above is odd, at best.
<= o:p>

I= had thought there were uses of RSA keys where the same key is used both fo= r signing and encryption (even though this is a deprecated practice).

<= o:p>

B= ut we could change this to “Similarly, if the “alg” membe= r is present, it SHOULD correspond to the algorithm specified in the certif= icate.” Or is that overly strong for some certificates and uses of them?

<= o:p>

Section 4.7 incl= udes inaccurate terminology. It says:

   This MAY be followed by additional c= ertificates, with

   each subsequent certificate being th= e one used to certify the

   previous one.

Replace “c= ertify” with “validate.”

<= o:p>

O= K

<= o:p>

Also, the name s= eems misleading since the chain MAY contain additional certs, and hence may= not be a chain at all!

<= o:p>

I= ’m not sure if I’m following you here. Are you suggesting= the possibility of having multiple certificates not chaining to one anothe= r in the representation? This isn’t allowed by the specification= , as written. Are you suggesting that it needs to be allowed?

<= o:p>

Section 4.8 refe= rs to a “thumbprint” of a certificate, and describes it informa= lly as a “digest.” The more common technical term is a one-way = hash. Thumbprint seems to be a Microsoft term; “fingerprint” strikes me as more common. The text here, and in 4.9 should point to Appen= dix C of the JWS document, where the base64URL encoding is defined. That do= cument should note that the appendix is normative.

Thumbprint is the term used in the Wind= ows libraries, such as http://msdn.microsoft.com/en-u= s/library/system.security.cryptography.x509certificates.x509certificate2.th= umbprint(v=3Dvs.110).aspx. Whereas OpenSSL uses fingerprint http://ww= w.openssl.org/docs/apps/x509.html.&nb= sp; I know that there would be an uproar if we tried to make a breaking change= to the “x5t” name at this point, because it’s in widespr= ead production use. However, we could add language saying that certif= icate thumbprints are also known as certificate fingerprints, so people familiar with either term will know what this is.

The term “base64url= ” is incorporated by reference in the terminology section (Section 2)= .

<= /p>
Actually, Appendix C in J= WS is not normative. It’s just example code. The normativ= e definition of the encoding is in Section 5 of RFC 4648.=

<= /p>
Section 5 again = repeats the semi-requirement description of name uniqueness that appeared a= t the beginning of Section 4. The same comments apply here, as there.<= /o:p>

<= /p>
Same answer.

<= /p>
Section 7 begins= with a rather wordy statement:

   Access to JWKs containing non-public= key material by parties without

   legitimate access to the non-public = information MUST be prevented.

   This can be accomplished by encrypti= ng the JWK when potentially

   observable by such parties to preven= t the disclosure of private or

   symmetric key values. The use of an = Encrypted JWK, which is a JWE

   with the UTF-8 encoding of a JWK as = its plaintext value, is

   recommended for this purpose. =

How about a simp= ler way to say this:

    When private or symmetric keys= are transported by JWK, the

     confidentiality of these= keys MUST be ensured. It is RECOMMENDED

     that confidentiality be = provided by encrypting the JWK when the data

     might be observable by u= nauthorized parties.

<= /p>
Thanks<= /p>
<= /p>
This section the= n goes on to say:

   A "cty" (content type) Hea= der Parameter value of "jwk+json" MUST be

   used to indicate that the content of= the JWE is a JWK, unless the

   application knows that the encrypted= content is a JWK by another means

   or convention, in which case t= he "cty" value would typically be

   omitted.

Given the rather= large loopholes here, this sounds more like a SHOULD, followed by a descri= ption of exception conditions, rather than a MUST.

It used to be a “SH= OULD” but the working group felt that the “MUST … unless&= #8221; wording was a more accurate statement of the requirement.=

<= /p>
Section 8 (IANA = Considerations) establishes a two-week review period for creating new (IANA= ) registry items. This seems too short; some people take multi-week vacatio= ns. I note that the same text appears in the JWS and JWE documents.

This text was taken from = RFC 6749.

<= /p>
Typo:=

   Criteria that should be applied by t= he Designated Expert(s) includes

Should be:<= /o:p>

   Criteria that should be applied by t= he Designated Expert(s) include

Thanks<= /p>
<= /p>
I did not review= all of the initial registry content defined in 8.1.2, 8.2.2, 8.3.2, or 8.4= .2.

The Appendices a= ppear to be informative; they should be labeled as such. I did not review t= he context of the Appendices. But, I did note the following:

<= /p>
Aren’t appendices n= ormally informative?

<= /p>
In C.2, the text= says:

      o the Plaint= ext is encrypted using the AES_128_CBC_HMAC_SHA_256

      algorithm to produ= ce the Ciphertext

The algorithms d= escribed here (AES 128 in CBC mode, plus an HMAC computed using SHA-256) pr= ovide both encryption and integrity. Thus it may be confusing to refer to t= his as only “encryption.”

<= /p>
We could be more explicit= and talk about performing authenticated encryption.

<= /p>
I also note that= the algorithms (algorithm suites) used in the examples in the appendices l= ack citations to documents that define these algorithms.<= /p>
<= /p>
Thanks – they can b= e added.

<= /p>
    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     Thanks again, Stephen,

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     -- Mike

<= /p>
--_000_4E1F6AAD24975D4BA5B16804296739439AEB89F6TK5EX14MBXC292r_-- From nobody Thu Sep 11 04:39:39 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD761A6EE1 for ; Thu, 11 Sep 2014 04:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.123 X-Spam-Level: * X-Spam-Status: No, score=1.123 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_NEUTRAL=0.779] autolearn=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 HX44gdEexwdK for ; Thu, 11 Sep 2014 04:39:35 -0700 (PDT) Received: from mail.kivinen.iki.fi (unknown [IPv6:2001:1bc8:100d::2]) (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 0AADF1A6F2F for ; Thu, 11 Sep 2014 04:39:26 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s8BBdOvX014126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 11 Sep 2014 14:39:24 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s8BBdOPf013745; Thu, 11 Sep 2014 14:39:24 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21521.35308.526293.718289@fireball.kivinen.iki.fi> Date: Thu, 11 Sep 2014 14:39:24 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/fvWxaRUg9XchCoXC8ovYgy22Q8Q Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 11:39:36 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Adam Montville is next in the rotation. For telechat 2014-09-18 Reviewer LC end Draft Sam Hartman T 2014-08-22 draft-ietf-dnsop-child-syncronization-03 Takeshi Takahashi TR2014-08-05 draft-dukhovni-opportunistic-security-04 David Waltermire TR2014-08-04 draft-masotta-tftpexts-windowsize-opt-11 For telechat 2014-10-02 Chris Inacio T 2014-08-26 draft-ietf-tsvwg-rsvp-pcn-09 Last calls and special requests: Dan Harkins 2014-06-13 draft-ietf-mmusic-rtsp-nat-evaluation-14 Jeffrey Hutzelman E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-06 Jeffrey Hutzelman 2014-08-22 draft-ietf-soc-overload-rate-control-09 Ben Laurie 2014-09-11 draft-ietf-avtcore-aria-srtp-06 Matt Lepinski 2014-09-11 draft-ietf-avtcore-srtp-aes-gcm-14 Catherine Meadows 2014-09-22 draft-ietf-grow-ix-bgp-route-server-operations-03 Alexey Melnikov 2014-09-22 draft-ietf-opsec-bgp-security-05 Zach Shelby 2014-06-06 draft-housley-implementer-obligations-02 Ondrej Sury 2014-07-30 draft-ietf-ipfix-text-adt-10 Brian Weis E 2014-01-16 draft-ietf-radext-dynamic-discovery-11 -- kivinen@iki.fi From nobody Thu Sep 11 08:13:51 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 787E21A00BB; Thu, 11 Sep 2014 08:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.852 X-Spam-Level: X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham 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 XPsi0r0wEgQD; Thu, 11 Sep 2014 08:13:36 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 485301A02DD; Thu, 11 Sep 2014 08:13:36 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:52628 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XS63u-000CEg-Ox; Thu, 11 Sep 2014 11:13:31 -0400 Message-ID: <5411BC12.9040808@bbn.com> Date: Thu, 11 Sep 2014 11:13:22 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Mike Jones , "secdir@ietf.org" , "jose-chairs@tools.ietf.org" , "Moriarty, Kathleen" References: <4E1F6AAD24975D4BA5B16804296739439AEB89F6@TK5EX14MBXC292.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439AEB89F6@TK5EX14MBXC292.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary="------------070805010902070802040207" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/nY8jIYgleF8v-M-dLvlxVtx88tY Cc: "jose@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-jose-json-web-key-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 15:13:45 -0000 This is a multi-part message in MIME format. --------------070805010902070802040207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mike, Thanks for the reply to my comments. I've retained your replies and responded to them, below. > > ** > I agree that "employing countermeasures to" is more accurate than > "preventing". I also agree that the "avoiding mistakes" language is > not actionable -- I propose to just remove it. > Great. > > Actually, it was spoken by then-Security AD Sean Turner. ;-) > gee, I thought Sean was wise, but I didn't realize he was a Jedi ;-). > > How about changing "data associated with a key" to "data > cryptographically secured by a key"? (And of course, deleting the > extraneous "than".) > OK. > > The wording above is needlessly awkward. Nonetheless, this says that > key sets containing symmetric or private keys should be encrypted by > embedding them in another JSON crypto format (JWE). It would be nice > to add that this implies a that there is secure way to deliver the > needed decryption key for the JWE, else this recommendation just adds > a layer of indirection, and does not solve the problem. > > Fair enough. I propose that we add something along those lines. > OK, I look forward to seeing the revised wording here. > > Section 9.3 discusses a countermeasure against a specific attack on > RSA key use. This seems unduly narrow, since this spec is intended for > use with RSA, DH, DSS, and ECDH keys. Why devote a long paragraph to > this one issue, while saying nothing about equally serious concerns > that arise for other algorithms? > > This particular attack is described both because the countermeasure > requires specific key representation actions and because a working > group member asked it to be included. For what it's worth, I expect > that additional security considerations will be added when resolving > Russ Housley's gen-art review of the JWS specification. > If comparable alg-specific countermeasures are added based on Russ's comments then this may be OK, but in isolation this RSA-specific attack seem out of place. > > These non-goals were agreed to by the working group from the very > beginning, while the working group was still being chartered. The > group wanted to build something simple and easily deployable to > represent keys in JSON -- not reinvent all the work that the PKIX > working group did on certificates and certificate chains, etc. Do any > working group members want to suggest specific wording to try to > capture this sentiment? > OK. > > The example that comprises Section 3 should include an explanation of > the parameters, else it's not a great example. > > The parameters and values of them are explained in the paragraph > preceding the example text. It says: > > The following example JWK > declares that the key is an Elliptic Curve [DSS ] key, it is used with > the P-256 Elliptic Curve, and its x and y coordinates are the > base64url encoded values shown. A key identifier is also provided > for the key. > > Each statement above corresponds to a parameter in the example, and in > the same order. > OK. I missed that. > > I suppose that one option is to be more verbose above and add > parenthetical remarks after each statement above saying which > parameter does this. So for instance, the parenthetical phrase > "("kty" parameter)" could be added before the first comma. Do others > in the working group think that would make the example easier to read, > harder to read, or do any of you have an alternative suggestion? > I defer to the WG on this presentation issue. > > In addition to the common parameters, each JWK will have members that > > are algorithm-specific. > > They're not algorithm-specific -- they're key type-specific. Another > way of eliminating the repeated use of the word "parameters" is to > replace the second sentence with "These members represent the key > value". Would that work for you (and the working group)? > Yes, I meant key-type specific. But if one were to use that term instead of "algorithm specific" I still think my wording is better. > > This topic has been heavily discussed by the working group, and while > the specs used to just say that objects with duplicate member names > MUST be rejected, working group members, including Tim Bray (the > editor of the JSON spec), prevailed on us to weaken this so that > parsers that implement the ECMAscript behavior of returning only the > last member name may be legally used. (The argument was made that > there was more security downside in effectively requiring people to > write and debug their own strict parsers than in using laxer, but > well-supported and debugged parsers.) > I find that argument unpersuasive, but I defer to the cognizant Ad on this. > > However, we also intentionally require that producers use only one > instance of each member name, so that legally produced objects will > never exercise the ambiguities that are present in real JSON parsers. > That seemed to be the most practical solution to the working group. > Based on year of experience in PKIX that is not a great solution. If the consumer of a data structure fails to strictly enforce the requirement imposed on the producer of the data structure, the result is that non-conforming producers do not receive "appropriate" feedback. > > > The term "Collision-Resistant Name" is already present in the > Terminology section. However, previous reviewers had requested that > definitions not be repeated in multiple specs, so it's incorporated by > reference, rather than repeating the definition here. The notion is > that of an implementation wants to use a collision-resistant name such > as "http://names.example.com/the-name", it can do so without having to > create a public specification and register the name with IANA. > I found the definition by reading one of the other specs, but I didn't see a clear explanation of why this is a reasonable alternative to using an IANA registry. The text above does still does not provide a rationale. > > I agree that the "SHOULD" language is awkward. Rather than saying > "SHOULD be used", we could change it to just say "is used". OK. > > Would the language "The "alg" member can be used to specify the > cryptographic operation that the key is intended to be used for" work > better for you? Or would people like to just see the parenthetical > remark deleted? > How about: The "alg" member is used to specify the algorithm with which the key is to be used. > Section 4.5 defines the key_ops parameter. It's not clear how this > parameters and "use" relate. There is also an odd sentence at the end > of the first paragraph: > > The "key_ops" parameter is intended for use cases in which public, > > private, or symmetric keys may be present. > > This seems to encompass all of the types of keys that JWK carries, so > the sentence seems to add no useful qualification for when this > parameter is intended to be used. > > This is in contrast to the related statement in the "use" definition: > > The "use" parameter is intended for use cases in which > > it is useful to distinguish between public signing keys and public > > encryption keys. > Too subtle for me, and the language above seems a bit wimpy. Why not say: The "use" parameter is employed to indicate whether a public key is for encrypting data or verifying the signature on data. > If you want to see this parameter name changed, you'll need to file a > bug against the WebCrypto spec and get it changed there. Then I'm > sure that JOSE will gladly follow. > My request is directed to the IESG, suggesting that they take this action. > > > This specification will be used both in open environments, in which > multiple organizations will need to have a common understanding of any > extensions used, and closed environments, which the producing and > consuming organization will always be the same and private values > could be safely used. IANA registration is definitely the right thing > to do for open environments. It's probably unnecessary for > deployments in closed environments. Then say this. > > Same answer as for Section 4. > ibid. > > "Can" is being used as a non-2119 synonym for "MAY" here. That being > said, we could just change "can be" to "is", since it's explicitly > said that its use is optional at the end of the paragraph. please revise accordingly. > > It's the inclusion of other metadata about the key that might improve > interoperability that's being referred to -- not the inclusion of the > cert reference. For instance, including "use" or "alg" parameters > might be useful to applications that can't process the certificate. that's not what the text said, hence my confusion. > > As for the cert vs. cert chain question, in the general case, a chain > may be required to establish trust. However, a chain of length one (a > single certificate) will also be sufficient in some use cases. We're > not inventing anything new here. The data format is specified in RFC 1421. > could you point specifically to where 1421 uses two names to identify equivalent data structures for transport of certs/cert chains? I trued a quick search of the text and didn't locate the text to which you appear to refer. > > I had thought there were uses of RSA keys where the same key is used > both for signing and encryption (even though this is a deprecated > practice). > Yes, that practice is frowned upon, and we prefer that certs use an OID that makes it clear how a key is to be used. How about the following text: Similarly, if the "alg" member is present, it MUST be consistent with the algorithm specified in the certificate. > But we could change this to "Similarly, if the "alg" member is > present, it SHOULD correspond to the algorithm specified in the > certificate." Or is that overly strong for some certificates and uses > of them? > I prefer this text. > > Also, the name seems misleading since the chain MAY contain additional > certs, and hence may not be a chain at all! > > I'm not sure if I'm following you here. Are you suggesting the > possibility of having multiple certificates not chaining to one > another in the representation? This isn't allowed by the > specification, as written. Are you suggesting that it needs to be > allowed? > > Thumbprint is the term used in the Windows libraries, such as > http://msdn.microsoft.com/en-us/library/system.security.cryptography.x509certificates.x509certificate2.thumbprint(v=vs.110).aspx > . > Whereas OpenSSL uses fingerprint > http://www.openssl.org/docs/apps/x509.html. I know that there would be > an uproar if we tried to make a breaking change to the "x5t" name at > this point, because it's in widespread production use. However, we > could add language saying that certificate thumbprints are also known > as certificate fingerprints, so people familiar with either term will > know what this is. > Yes, do add that explanatory text. > > The term "base64url" is incorporated by reference in the terminology > section (Section 2). > > Actually, Appendix C in JWS is not normative. It's just example > code. The normative definition of the encoding is in Section 5 of RFC > 4648. > Then 4648 should be cited. > > It used to be a "SHOULD" but the working group felt that the "MUST ... > unless" wording was a more accurate statement of the requirement. > I defer to the cognizant AD here, but the notion of SHOULD is really MUST ... unless ... > > Section 8 (IANA Considerations) establishes a two-week review period > for creating new (IANA) registry items. This seems too short; some > people take multi-week vacations. I note that the same text appears in > the JWS and JWE documents. > > This text was taken from RFC 6749. > I didn't review that RFC. My comment still stands. > > Aren't appendices normally informative? > normally, but not always. > > We could be more explicit and talk about performing authenticated > encryption. > please do. Steve --------------070805010902070802040207 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mike,

Thanks for the reply to my comments.

I've retained your replies and responded to them, below.

I agree that “employing countermeasures to” is more accurate than “preventing”. I also agree that the “avoiding mistakes” language is not actionable – I propose to just remove it.

Great.

Actually, it was spoken by then-Security AD Sean Turner. ;-)

gee, I thought Sean was wise, but I didn't realize he was a Jedi ;-).

How about changing “data associated with a key” to “data cryptographically secured by a key”? (And of course, deleting the extraneous “than”.)

OK.

The wording above is needlessly awkward. Nonetheless, this says that key sets containing symmetric or private keys should be encrypted by embedding them in another JSON crypto format (JWE). It would be nice to add that this implies a that there is secure way to deliver the needed decryption key for the JWE, else this recommendation just adds a layer of indirection, and does not solve the problem.

Fair enough. I propose that we add something along those lines.

OK, I look forward to seeing the revised wording here.

Section 9.3 discusses a countermeasure against a specific attack on RSA key use. This seems unduly narrow, since this spec is intended for use with RSA, DH, DSS, and ECDH keys. Why devote a long paragraph to this one issue, while saying nothing about equally serious concerns that arise for other algorithms?

This particular attack is described both because the countermeasure requires specific key representation actions and because a working group member asked it to be included. For what it’s worth, I expect that additional security considerations will be added when resolving Russ Housley’s gen-art review of the JWS specification.

If comparable alg-specific countermeasures are added based on Russ's comments then
this may be OK, but in isolation this RSA-specific attack seem out of place.

These non-goals were agreed to by the working group from the very beginning, while the working group was still being chartered. The group wanted to build something simple and easily deployable to represent keys in JSON – not reinvent all the work that the PKIX working group did on certificates and certificate chains, etc. Do any working group members want to suggest specific wording to try to capture this sentiment?

OK.

The example that comprises Section 3 should include an explanation of the parameters, else it’s not a great example.

The parameters and values of them are explained in the paragraph preceding the example text. It says:

   The following example JWK

   declares that the key is an Elliptic Curve [DSS] key, it is used with

   the P-256 Elliptic Curve, and its x and y coordinates are the

   base64url encoded values shown. A key identifier is also provided

   for the key.

Each statement above corresponds to a parameter in the example, and in the same order.

OK. I missed that.

I suppose that one option is to be more verbose above and add parenthetical remarks after each statement above saying which parameter does this. So for instance, the parenthetical phrase “(“kty” parameter)” could be added before the first comma. Do others in the working group think that would make the example easier to read, harder to read, or do any of you have an alternative suggestion?

I defer to the WG on this presentation issue.

In addition to the common parameters, each JWK will have members that

are algorithm-specific.

They’re not algorithm-specific – they’re key type-specific. Another way of eliminating the repeated use of the word “parameters” is to replace the second sentence with “These members represent the key value”. Would that work for you (and the working group)?

Yes, I meant key-type specific. But if one were to use that term instead of "algorithm specific"
I still think my wording is better.

This topic has been heavily discussed by the working group, and while the specs used to just say that objects with duplicate member names MUST be rejected, working group members, including Tim Bray (the editor of the JSON spec), prevailed on us to weaken this so that parsers that implement the ECMAscript behavior of returning only the last member name may be legally used. (The argument was made that there was more security downside in effectively requiring people to write and debug their own strict parsers than in using laxer, but well-supported and debugged parsers.)

I find that argument unpersuasive, but I defer to the cognizant Ad on this.

However, we also intentionally require that producers use only one instance of each member name, so that legally produced objects will never exercise the ambiguities that are present in real JSON parsers. That seemed to be the most practical solution to the working group.

Based on year of experience in PKIX that is not a great solution. If the consumer of a data
structure fails to strictly enforce the requirement imposed on the producer of the data structure,
the result is that non-conforming producers do not receive "appropriate" feedback.

The term "Collision-Resistant Name" is already present in the Terminology section. However, previous reviewers had requested that definitions not be repeated in multiple specs, so it’s incorporated by reference, rather than repeating the definition here. The notion is that of an implementation wants to use a collision-resistant name such as “http://names.example.com/the-name”, it can do so without having to create a public specification and register the name with IANA.

I found the definition by reading one of the other specs, but I didn't see a clear explanation of
why this is a reasonable alternative to using an IANA registry. The text above does still does
not provide a rationale.

I agree that the “SHOULD” language is awkward. Rather than saying “SHOULD be used”, we could change it to just say “is used”.

OK.

Would the language “The “alg” member can be used to specify the cryptographic operation that the key is intended to be used for” work better for you? Or would people like to just see the parenthetical remark deleted?

How about:

The "alg" member is used to specify the algorithm with which the key is to be used.

Section 4.5 defines the key_ops parameter. It’s not clear how this parameters and “use” relate. There is also an odd sentence at the end of the first paragraph:

   The "key_ops" parameter is intended for use cases in which public,

   private, or symmetric keys may be present.

This seems to encompass all of the types of keys that JWK carries, so the sentence seems to add no useful qualification for when this parameter is intended to be used.

This is in contrast to the related statement in the “use” definition:

   The "use" parameter is intended for use cases in which

   it is useful to distinguish between public signing keys and public

   encryption keys.

Too subtle for me, and the language above seems a bit wimpy. Why not say:

The "use" parameter is employed to indicate whether a public key is for encrypting
data or verifying the signature on data.

If you want to see this parameter name changed, you’ll need to file a bug against the WebCrypto spec and get it changed there. Then I’m sure that JOSE will gladly follow.

My request is directed to the IESG, suggesting that they take this action.

This specification will be used both in open environments, in which multiple organizations will need to have a common understanding of any extensions used, and closed environments, which the producing and consuming organization will always be the same and private values could be safely used. IANA registration is definitely the right thing to do for open environments. It’s probably unnecessary for deployments in closed environments.

Then say this.

Same answer as for Section 4.

ibid.

“Can” is being used as a non-2119 synonym for “MAY” here. That being said, we could just change “can be” to “is”, since it’s explicitly said that its use is optional at the end of the paragraph.

please revise accordingly.

It’s the inclusion of other metadata about the key that might improve interoperability that’s being referred to – not the inclusion of the cert reference. For instance, including “use” or “alg” parameters might be useful to applications that can’t process the certificate.

that's not what the text said, hence my confusion.

As for the cert vs. cert chain question, in the general case, a chain may be required to establish trust. However, a chain of length one (a single certificate) will also be sufficient in some use cases. We’re not inventing anything new here. The data format is specified in RFC 1421.

could you point specifically to where 1421 uses two names to identify equivalent data structures
for transport of certs/cert chains? I trued a quick search of the text and didn't locate the
text to which you appear to refer.

I had thought there were uses of RSA keys where the same key is used both for signing and encryption (even though this is a deprecated practice).

Yes, that practice is frowned upon, and we prefer that certs use an OID that makes it clear
how a key is to be used. How about the following text:

   Similarly, if the "alg" member is present, it MUST be consistent with

   the algorithm specified in the certificate.

But we could change this to “Similarly, if the “alg” member is present, it SHOULD correspond to the algorithm specified in the certificate.” Or is that overly strong for some certificates and uses of them?

I prefer this text.

Also, the name seems misleading since the chain MAY contain additional certs, and hence may not be a chain at all!

I’m not sure if I’m following you here. Are you suggesting the possibility of having multiple certificates not chaining to one another in the representation? This isn’t allowed by the specification, as written. Are you suggesting that it needs to be allowed?

Thumbprint is the term used in the Windows libraries, such as http://msdn.microsoft.com/en-us/library/system.security.cryptography.x509certificates.x509certificate2.thumbprint(v=vs.110).aspx. Whereas OpenSSL uses fingerprint http://www.openssl.org/docs/apps/x509.html. I know that there would be an uproar if we tried to make a breaking change to the “x5t” name at this point, because it’s in widespread production use. However, we could add language saying that certificate thumbprints are also known as certificate fingerprints, so people familiar with either term will know what this is.

Yes, do add that explanatory text.

The term “base64url” is incorporated by reference in the terminology section (Section 2).

Actually, Appendix C in JWS is not normative. It’s just example code. The normative definition of the encoding is in Section 5 of RFC 4648.

Then 4648 should be cited.

It used to be a “SHOULD” but the working group felt that the “MUST … unless” wording was a more accurate statement of the requirement.

I defer to the cognizant AD here, but the notion of SHOULD is really MUST ... unless ...

Section 8 (IANA Considerations) establishes a two-week review period for creating new (IANA) registry items. This seems too short; some people take multi-week vacations. I note that the same text appears in the JWS and JWE documents.

This text was taken from RFC 6749.

I didn't review that RFC. My comment still stands.

Aren’t appendices normally informative?

normally, but not always.

We could be more explicit and talk about performing authenticated encryption.

please do.

Steve
--------------070805010902070802040207-- From nobody Thu Sep 11 11:02:24 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ADA11A8A53; Thu, 11 Sep 2014 11:02:17 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 1tnlHbCTo2cr; Thu, 11 Sep 2014 11:02:15 -0700 (PDT) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B1611A8A54; Thu, 11 Sep 2014 10:59:56 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id ft15so11811465pdb.32 for ; Thu, 11 Sep 2014 10:59:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=wiCedceowg7XAe5FP4i+p2FxTTyJxYNCFFL2OOHPbgc=; b=FGEAiOcu6NGLtHguwNXDxrMwi4xKgMZ0QiwT1EXyaJMoCgvBabqoYWuDjXBG2P1rRd 4GVqmnDGUX/KRFLM1qkEiPkJabXmJC5xrUpavtI4qAqfmm1SRiu00Zuh/vf7sfKRR0GQ FBQXQqSKogg/cBM45fPdWb3NJii4PytXfLWTbmoQkKCYO/SVzwD/NQE1qY/F5zmkt0o5 FtMu1GKnAPz7E/kmcF/6SYUxFy4paCfqC5w4FU14o4oNOrunfv0lY/m8aoe8U0BGohy8 bsZhWbRgwyIKN1iVdv9kvsx3oVrhhELQGpYN1kjcVPNMsYKXIeI3xBFuzvn5lPy4fgQk Gcsw== X-Received: by 10.68.220.105 with SMTP id pv9mr4099956pbc.8.1410458395688; Thu, 11 Sep 2014 10:59:55 -0700 (PDT) Received: from [192.168.1.76] (172-3-137-150.lightspeed.sntcca.sbcglobal.net. [172.3.137.150]) by mx.google.com with ESMTPSA id i2sm1798870pat.3.2014.09.11.10.59.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Sep 2014 10:59:54 -0700 (PDT) Message-ID: <5411E318.7020106@gmail.com> Date: Thu, 11 Sep 2014 10:59:52 -0700 From: Chris Lonvick User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Paul Kyzivat , iesg@ietf.org, secdir@ietf.org, draft-kyzivat-case-sensitive-abnf.all@tools.ietf.org References: <540A3309.90802@gmail.com> <5410BDA0.7050305@alum.mit.edu> In-Reply-To: <5410BDA0.7050305@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/dTX3Eh-dKggh8a5Wh-HwEKpzBQk Subject: Re: [secdir] SECDIR review of draft-kyzivat-case-sensitive-abnf X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 18:02:17 -0000 Hi Paul, It looks good to me. I recommend progressing this forward. Best regards, Chris On 9/10/14, 2:07 PM, Paul Kyzivat wrote: > Chris, > > Based on discussions in this thread I've posted an -02 version that > hopefully addresses all of your comments. > > Thanks, > Paul > > On 9/5/14 6:02 PM, Chris Lonvick wrote: >> Hi, >> >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the IESG. >> These comments were written primarily for the benefit of the security >> area directors. Document editors and WG chairs should treat these >> comments just like any other last call comments. >> >> The abstract is: >> >> This document extends the base definition of ABNF (Augmented Mackus- >> Naur Form) to include a way to specify ASCII string literals that >> are >> matched in a case-sensitive manner. >> >> >> Overall, I don't like the statement in the Security Considerations >> section, but it is consistent with all other documents related to >> defining ABNF, and I can't find any noteworthy security issues anyway. >> From that, I have no objection to moving this document forward. >> >> I did find some nits and have some suggestions for improving >> readability. >> >> 1 - "Mackus-Naur" is used in two places rather than "Backus-Naur". >> >> 2 - The last sentence of section 2.1 is: >> >> This mechanism has a clear readability >> disadvantage, with respect to using a literal text string with a >> prefix, and new the prefix mechanism is preferred. >> >> >> Perhaps you meant: >> This mechanism of using a literal text string with a prefix has a >> clear >> readability disadvantage. The prefix mechanism described in this >> specification can be much more easily read. >> >> >> 3 - This part of Section 2.1 may be cleared up some: >> ---vvv--- >> >> If no prefix is present then the string is case-insensitive. >> >> Hence: >> >> rulename = %i"aBc" >> >> and: >> >> rulename = "abc" >> >> will both match "abc", "Abc", "aBc", "abC", "ABc", "aBC", "AbC", and >> "ABC". >> >> >> ---^^^--- >> >> Suggested: >> ---vvv--- >> To be consistent with current implementations of ABNF, having no >> prefix means that the string is case-insensitive, and is >> equivalent >> to having the "%i" prefix. >> >> Hence: >> >> rulename = %i"aBc" >> >> and: >> >> rulename = "abc" >> >> are equivalent and both will match "abc", "Abc", "aBc", "abC", >> "ABc", >> "aBC", "AbC", and "ABC". >> ---^^^--- >> >> Best regards, >> Chris >> > From nobody Thu Sep 11 16:56:52 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E8C1A010F; Thu, 11 Sep 2014 13:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 oBFQOx5z0qJQ; Thu, 11 Sep 2014 13:29:59 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A00D1A0054; Thu, 11 Sep 2014 13:29:58 -0700 (PDT) Received: from Philemon (173-8-216-38-Oregon.hfc.comcastbusiness.net [173.8.216.38]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 818F02CA06; Thu, 11 Sep 2014 13:29:57 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" , "'Scott Kelly'" , , , References: <3266E6F3-AB87-4B45-9C6F-A3B6976DBCEC@hyperthought.com> <4E1F6AAD24975D4BA5B16804296739439AE9D53F@TK5EX14MBXC292.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439AE9D53F@TK5EX14MBXC292.redmond.corp.microsoft.com> Date: Thu, 11 Sep 2014 13:27:33 -0700 Message-ID: <025e01cfcdfe$d2b3f4f0$781bded0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_025F_01CFCDC4.265B1060" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQF5vuWrAfXHovFlfTmsz9vU+FyzJQI1m+fjnJbPWAA= Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/9vZR1f3w7bDQupuUMynZo_hy83c X-Mailman-Approved-At: Thu, 11 Sep 2014 16:56:47 -0700 Cc: jose@ietf.org Subject: Re: [secdir] [jose] secdir review of draft-ietf-jose-json-web-encryption-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 20:30:04 -0000 This is a multipart message in MIME format. ------=_NextPart_000_025F_01CFCDC4.265B1060 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones Sent: Friday, September 05, 2014 4:13 PM To: Scott Kelly; secdir@ietf.org; draft-ietf-jose-json-web-encryption.all@tools.ietf.org; iesg@ietf.org Cc: jose@ietf.org Subject: Re: [jose] secdir review of draft-ietf-jose-json-web-encryption-31 Thanks for the useful review, Scott. I've cc'ed the working group in my reply so that they're aware of the contents of your review. Jim Schaad - also please see questions to you below. Replies are inline below: -----Original Message----- From: Scott Kelly [mailto:scott@hyperthought.com] Sent: Saturday, August 30, 2014 6:13 AM To: secdir@ietf.org; draft-ietf-jose-json-web-encryption.all@tools.ietf.org; iesg@ietf.org Subject: secdir review of draft-ietf-jose-json-web-encryption-31 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. >From the abstract, JSON Web Encryption (JWE) represents encrypted content using JavaScript Object Notation (JSON) based data structures. A little like CMS for web transactions. The security considerations section begins "All of the security issues that are pertinent to any cryptographic application must be addressed by JWS/JWE/JWK agents. Among these issues are protecting the user's asymmetric private and symmetric secret keys, preventing various attacks, and helping avoid mistakes such as inadvertently encrypting a message to the wrong recipient. The entire list of security considerations is beyond the scope of this document, but some significant considerations are listed here." "All the security considerations in the JWS specification also apply to this specification. Likewise, all the security considerations in XML Encryption 1.1 [W3C.REC-xmlenc-core1-20130411] also apply, other than those that are XML specific." If you are going to point to the JWS specification, you should use a normative reference. It's fine to point at other references to avoid re-stating the obvious, but all security considerations *are* within scope, and require coverage, either directly or by reference. I haven't reviewed the referenced W3C spec, so I'm not sure that everything has been covered. The JWS security considerations section only talks about crypto algs and server identity verification. So, the ADs will want to pay attention here. We plan to remove the sentence "The entire list of security considerations is beyond the scope of this document, but some significant considerations are listed here" since several reviewers have taken exception to it. I'm a bit confused by your comment about normative references, because the JWS reference already is normative. Jim Schaad, etc., do you agree that the XMLENC reference should become normative? I'd though that earlier you'd advised me that security considerations references should be informative. [JLS] Does this need to be understood in order to implement the content covered in the core of the document? I would question that needing to understand the entire XML Encryption document is necessary. If the material is core then it might be a better candidate for copy and paste in any event. This is esp. true given that the material is qualified as - anything that is not XML and the exercise of making that determination is left up to the reader. FYI, as part of addressing Russ Housley's comments on the Security Considerations section, I do expect to explicitly reference a number of security considerations called out in XMLENC, such as the text on chosen-ciphertext attacks, backwards compatibility attacks, etc. In section 5.1 (Message Encryption), step 16 says "Encrypt M..." without ever defining M. One might guess it stands for Message, but this should be stated. Agreed Section 8 (TLS Requirements) points at JWS, but neither document references the channel binding problem. If you are depending on TLS to provide essential and necessary security features (which, presumably, you are since TLS is a MUST), then you should give clear guidance as to how to effectively use it. JWS requires combined confidentiality and integrity protection, and also requires server identity verification per RFC6125, but does not mention channel binding. Scott, is there text on the channel binding problem in another specification that you'd recommend that we reference or use? If not, would you mind supplying proposed text for us to use? Section 11.1 (Using Matching Algorithm Strengths) says "Algorithms of matching strengths should be used together whenever possible. For instance, when AES Key Wrap is used with a given key size, using the same key size is recommended when AES GCM is also used." This doesn't quite scan for me, but editorial nits aside, it might be good to say greater or equal key sizes should be used for wrapping. The "matching strengths" guidance came from Eric Rescorla and I believe was supported by then-Security AD Sean Turner. It's not clear to me that the ? language is better than what's there now, in part because if the strengths don't match, it's not clear to me which way the inequality should go. And you might want to point to RFC3766 for BCPs when using public keys. The RFC 3766 reference looks like a good one. Thanks for providing it. Section 11.2 introduces the term "key tainting". "Strict key management/usage policy" might be better understood. Also, it might be valuable to use SHOULD here. Jim Schaad, you suggested using the term "key tainting". Is there a place where this term is defined, which we could reference? [JLS] There was a definition in the W3C document, but it appears to have disappeared. The text they had was "Such mitigations may include restricting a generic key ("tainting") > once it has been used with a specific algorithm or operation, and only > permit applications to use that key with that same algorithm or > operation in the future." Also, Jim, I believe in our in-person discussions of issue #70 (Review of 2119 Language) you'd suggested that we use 2119 keywords in the Security Considerations statements. Am I remembering that right, or would you prefer that the Security Considerations sections use 2119 language? I am generically opposed to the use of 2119 language in security considerations and appendixes. If it is of sufficient importance to warrant this type of language it should be in the core document not in a considerations section. However I am not in the majority on this position. I was surprised not to see any mention of the lack of replay protection. TLS channel binding could presumably be leveraged for this purpose, but in any event, the fact that JWEs can be replayed should be mentioned. It's not clear to me that being able to decrypt an encrypted object multiple times if you hold the correct key constitutes an attack, any more than being able to check a signature multiple times does. I agree with you that some higher-level objects that may use JWE (or JWS) may want replay protection. For instance, http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-25#section-4.1.7 describes a means of replay protection for JWTs. At most, if we mention replay protection, I would propose that we say that some applications using JWE encryption may choose to incorporate replay protection mechanisms, such as by including IDs in the protected content that change with each application-level usage. Would that work for you Scott, or is there something else you had in mind? As always, if you can supply specific proposed language to address your concern, that would probably be the clearest statement of what you'd like to see. I would suggest that the authors read the security considerations in rfc5652; most of the same concerns apply here, and you could almost cut/paste from there to here. Thanks. I expect to reference some of these as well when addressing Russ Housley's gen-art review comments of JWS. For the ADs: I'm not sure if one of the companion documents provides a comprehensive threat model, but you will want to pay attention here. This doc does not. Each doc tries to list security considerations specific to that document and where they span documents, they are described in one and referenced in others. Thanks again, Scott, -- Mike ------=_NextPart_000_025F_01CFCDC4.265B1060 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable

From:= = jose [mailto:jose-bounces@ietf.org] On Behalf Of Mike = Jones
Sent: Friday, September 05, 2014 4:13 PM
To: = Scott Kelly; secdir@ietf.org; = draft-ietf-jose-json-web-encryption.all@tools.ietf.org; = iesg@ietf.org
Cc: jose@ietf.org
Subject: Re: [jose] = secdir review of = draft-ietf-jose-json-web-encryption-31
<= p class=3DMsoNormal>
Thanks for the useful review, Scott. = I’ve cc’ed the working group in my reply so that = they’re aware of the contents of your review. Jim Schaad = – also please see questions to you below. Replies are inline = below…

-----Original Message-----
From: Scott Kelly [mailto:scott@hyperthought.com]=
Sent: Saturday, August 30, 2014 6:13 AM
To: secdir@ietf.org; dr= aft-ietf-jose-json-web-encryption.all@tools.ietf.org; iesg@ietf.org
Subject: secdir = review of draft-ietf-jose-json-web-encryption-31

I have = reviewed this document as part of the security directorate's ongoing = effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments.

From = the abstract, JSON Web Encryption (JWE) represents encrypted content = using JavaScript Object Notation (JSON) based data structures. A little = like CMS for web transactions.

The = security considerations section begins

   "All of the security issues that = are pertinent to any cryptographic
   application must be addressed by = JWS/JWE/JWK agents. Among these
   issues are protecting the user's = asymmetric private and symmetric
   secret keys, preventing various = attacks, and helping avoid mistakes
   such as inadvertently encrypting a = message to the wrong recipient.
   The entire list of security = considerations is beyond the scope of
   this document, but some significant = considerations are listed here."

= "All the security considerations in the JWS specification also = apply
   to this = specification. Likewise, all the security considerations = in
   XML Encryption 1.1 = [W3C.REC-xmlenc-core1-20130411] also apply, other
   than those that are XML = specific."

If you = are going to point to the JWS specification, you should use a normative = reference. It's fine to point at other references to avoid re-stating = the obvious, but all security considerations *are* within scope, and = require coverage, either directly or by reference. I haven't reviewed = the referenced W3C spec, so I'm not sure that everything has been = covered. The JWS security considerations section only talks about crypto = algs and server identity verification. So, the ADs will want to pay = attention here.

We plan to remove the = sentence “The entire list of security considerations is beyond the = scope of this document, but some significant considerations are listed = here” since several reviewers have taken exception to = it.

I’m a bit = confused by your comment about normative references, because the JWS = reference already is normative.

Jim Schaad, etc., do you agree that the XMLENC reference = should become normative? I’d though that earlier you’d = advised me that security considerations references should be = informative.

[JLS] Does this need = to be understood in order to implement the content covered in the core = of the document?=9A I would question that needing to understand the = entire XML Encryption document is necessary.=9A If the material is core = then it might be a better candidate for copy and paste in any event.=9A = This is esp. true given that the material is qualified as – = anything that is not XML and the exercise of making that determination = is left up to the reader.

FYI, as part of = addressing Russ Housley’s comments on the Security Considerations = section, I do expect to explicitly reference a number of security = considerations called out in XMLENC, such as the text on = chosen-ciphertext attacks, backwards compatibility attacks, = etc.

In section 5.1 (Message Encryption), step 16 says = "Encrypt M..." without ever defining M. One might guess it = stands for Message, but this should be stated.

Agreed

Section 8 (TLS Requirements) points at JWS, but = neither document references the channel binding problem. If you are = depending on TLS to provide essential and necessary security features = (which, presumably, you are since TLS is a MUST), then you should give = clear guidance as to how to effectively use it. JWS requires combined = confidentiality and integrity protection, and also requires server = identity verification per RFC6125, but does not mention channel = binding.

Scott, is there text = on the channel binding problem in another specification that you’d = recommend that we reference or use? If not, would you mind = supplying proposed text for us to use?

Section 11.1 (Using Matching Algorithm Strengths) = says

"Algorithms of matching strengths = should be used together whenever
   possible. For instance, when AES = Key Wrap is used with a given key
   size, using the same key size is = recommended when AES GCM is also
   used."

This = doesn't quite scan for me, but editorial nits aside, it might be good to = say greater or equal key sizes should be used for = wrapping.

The “matching = strengths” guidance came from Eric Rescorla and I believe was = supported by then-Security AD Sean Turner. It’s not clear to = me that the =99 language is better than what’s there now, in part = because if the strengths don’t match, it’s not clear to me = which way the inequality should go.

And you might want to point to RFC3766 for BCPs = when using public keys.

The RFC 3766 = reference looks like a good one. Thanks for providing = it.

Section 11.2 introduces the term "key = tainting". "Strict key management/usage policy" might be = better understood. Also, it might be valuable to use SHOULD = here.

Jim Schaad, you suggested using the term “key = tainting”. Is there a place where this term is defined, = which we could reference?

[JLS] There was a = definition in the W3C document, but it appears to have disappeared.=9A = The text they had was

“Such mitigations may include restricting a generic key = ("tainting")
> once it has = been used with a specific algorithm or operation, and only =
> permit = applications to use that key with that same algorithm or =
> operation in = the future.”

Also, Jim, I believe = in our in-person discussions of issue #70 (Review of 2119 Language) = you’d suggested that we use 2119 keywords in the Security = Considerations statements. Am I remembering that right, or would = you prefer that the Security Considerations sections use 2119 = language?

I am generically = opposed to the use of 2119 language in security considerations and = appendixes.=9A If it is of sufficient importance to warrant this type of = language it should be in the core document not in a considerations = section.=9A However I am not in the majority on this = position.

I was surprised not to see any mention of the lack = of replay protection. TLS channel binding could presumably be leveraged = for this purpose, but in any event, the fact that JWEs can be replayed = should be mentioned.

It’s not clear = to me that being able to decrypt an encrypted object multiple times if = you hold the correct key constitutes an attack, any more than being able = to check a signature multiple times does.

I agree with you that = some higher-level objects that may use JWE (or JWS) may want replay = protection. For instance, http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-25= #section-4.1.7 describes a means of replay protection for = JWTs. At most, if we mention replay protection, I would propose = that we say that some applications using JWE encryption may choose to = incorporate replay protection mechanisms, such as by including IDs in = the protected content that change with each application-level = usage. Would that work for you Scott, or is there something else = you had in mind?

As always, if you can = supply specific proposed language to address your concern, that would = probably be the clearest statement of what you’d like to = see.

I would suggest that the authors read the security = considerations in rfc5652; most of the same concerns apply here, and you = could almost cut/paste from there to here.

Thanks. I = expect to reference some of these as well when addressing Russ = Housley’s gen-art review comments of JWS.

For the ADs: I'm not sure if one of the companion = documents provides a comprehensive threat model, but you will want to = pay attention here. This doc does not.

Each doc tries to = list security considerations specific to that document and where they = span documents, they are described in one and referenced in = others.

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;       Thanks again, = Scott,
        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;       -- Mike

------=_NextPart_000_025F_01CFCDC4.265B1060-- From nobody Thu Sep 11 16:56:55 2014 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 438271A010F; Thu, 11 Sep 2014 13:25:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1410467121; bh=YRzcyxo/vBv+lon7dMYKLNWpJSzjPCWJh674AkUFJVI=; h=To:Date:MIME-Version:From:Message-ID:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Transfer-Encoding:Content-Type:Sender; b=TefcXnVyGgoWVCE/+yQ+9pRowWwC8LeWT0z1gogqcT3m6ywuy4mfsp3gqJ8QABwnN 9IsbtxdxgKIRg0eUNqSdMf8ku7wD3/a0zRMzNDvWwfCcTDRKZoU6jemTFmC0Phq6wJ mhkqwrB3LVgT4rg8qqZbfjBPnj4PZAlLAnrSHVw8= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9E2D1A005C for ; Thu, 11 Sep 2014 13:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 8P_eW2e4Ms-9 for ; Thu, 11 Sep 2014 13:25:18 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 105AA1A010F for ; Thu, 11 Sep 2014 13:25:18 -0700 (PDT) Received: from eb.bleuazur.com ([88.173.33.195] helo=sith.local) by jay.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1XSAvc-0003Gc-U9; Thu, 11 Sep 2014 16:25:17 -0400 To: new-work@ietf.org Date: Thu, 11 Sep 2014 22:25:15 +0200 MIME-Version: 1.0 From: "Coralie Mercier" Organization: W3C Message-ID: User-Agent: Opera Mail/1.0 (MacIntel) Archived-At: http://mailarchive.ietf.org/arch/msg/new-work/vGr928AZpsoxt-Sp8-5g1HjK7YM X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/RYa_2IkRrSijyGzuRZLs04C4vVM X-Mailman-Approved-At: Thu, 11 Sep 2014 16:56:48 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Web Payments Interest Group (until 2014-10-10) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 20:25:21 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to review the Web Payments Activity (see the W3C Process Document description of Activity Proposals [1]): Web Payments Activity proposal: https://www.w3.org/2014/04/payments/activity_proposal.html This proposal includes a draft charter for the Web Payments Interest Group: http://www.w3.org/2014/04/payments/webpayments_charter.html As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2014-10-10 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [2], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Stephane Boyera, Proposed Staff Contact . Thank you, Coralie Mercier, W3C Communications [1] http://www.w3.org/2014/Process-20140801/#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Coralie Mercier - W3C Communications Team - http://www.w3.org mailto:coralie@w3.org +336 4322 0001 http://www.w3.org/People/CMercier/ _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Fri Sep 12 04:59:58 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 176391A070F; Fri, 12 Sep 2014 04:59:54 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 0tySfm2PeyK2; Fri, 12 Sep 2014 04:59:51 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F21D61A06DA; Fri, 12 Sep 2014 04:59:50 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id b17so786785lan.18 for ; Fri, 12 Sep 2014 04:59:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=2MP268llEyTf+de0rMONvTc2T9CMaqPxImKVQtZa4r8=; b=OnLkA0eONOw13TQrp6Tw9s+lIJYkmoQnhyx1UwfT2ey9mL+4I7/axGHc5soOTuyItM P8ZIpK4deNWutMGv3fPtxBDp00B+FfcU3HeX1f3MnDIS8yv6Nod1O53LX3o02V21POb7 RT/X06+P8eXkEZdBoXdi+f/s2R7tYpKChXCXMfgYwt5krY2xEGhUH21LyIzlNIZYoxld 0ZwGoiTIpLQ0x/Fvy1JGSz2RlhM5I13CgqJpUXtEj/iK3uwSjsYuTASwyAvxQ57sfruO WtJ5oSYTXz0ihl08M0IiLiqSqwnlbwk8+4i0QYIQopXANir6v+qCsA1vJTOdxiP9q6VM UfCw== MIME-Version: 1.0 X-Received: by 10.112.138.201 with SMTP id qs9mr7849650lbb.41.1410523189246; Fri, 12 Sep 2014 04:59:49 -0700 (PDT) Received: by 10.112.64.170 with HTTP; Fri, 12 Sep 2014 04:59:49 -0700 (PDT) Date: Fri, 12 Sep 2014 07:59:49 -0400 Message-ID: From: Kathleen Moriarty To: "jose@ietf.org" , "jose-chairs@tools.ietf.org" , draft-ietf-jose-json-web-key.all@tools.ietf.org, secdir@ietf.org, Stephen Kent , Michael Jones Content-Type: multipart/alternative; boundary=089e01176ff9a47e120502dd0541 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/glL1UrNLvRjJw0E9kGvX9di1ZTg Subject: [secdir] JWK member names, was: [jose] SECDIR review of draft-ietf-jose-json-web-key-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 11:59:54 -0000 --089e01176ff9a47e120502dd0541 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Mike, The text Steve called out below has been very problematic as you know. Could you call out some options here as the last time this came up, we didn't resolve it. The working group was asked for suggestions, but none came through. If you could provide some options and then have the working group weigh in, I think that would be good. I snipped away the rest of the review and changed the subject as not to get in the way of the current dialog. Thanks. On Wed, Sep 10, 2014 at 8:57 PM, Mike Jones wrote: > Hi Stephen. Thanks for your detailed and useful review. I=E2=80=99ve c= c=E2=80=99ed the > working group in my reply so they=E2=80=99re aware of the contents of you= r review. > Replies are inline below=E2=80=A6 > > > > *From:* Stephen Kent [mailto:kent@bbn.com ] > *Sent:* Tuesday, September 02, 2014 1:09 PM > *To:* secdir@ietf.org; Mike Jones; jose-chairs@tools.ietf.org; Moriarty, > Kathleen > *Subject:* SECDIR review of draft-ietf-jose-json-web-key-31 > > > > [snip] > > > This section imposes a rather wimpy constraint on parameter names: > > > > The member names within a JWK MUST be unique; recipients MUST either > > reject JWKs with duplicate member names or use a JSON parser that > > returns only the lexically last duplicate member name, as specified > > in Section 15.12 (The JSON Object) of ECMAScript 5.1 [ECMAScript]. > > > > This text says that member names MUST be unique, but if they are not, > that=E2=80=99s OK too; just use the last instance of a member with a dupl= icate > name. This seems like a terrible design principle. It imposes what appear= s > to be a requirement, then says how to accommodate data structures that fa= il > to meet the requirement. This would seem to encourage sloppy > implementations (for JWK generation). I=E2=80=99d like to see the rationa= le for > this. > > > > > > Unfortunately, the intentional laxness in the spec in this regard is a > reflection of the semantics of the actual JSON specifications and > implementations. For instance, > http://tools.ietf.org/html/rfc7159#section-4 says: > > > > An object whose names are all unique is interoperable in the sense > > that all software implementations receiving that object will agree on > > the name-value mappings. When the names within an object are not > > unique, the behavior of software that receives such an object is > > unpredictable. Many implementations report the last name/value pair > > only. Other implementations report an error or fail to parse the > > object, and some implementations report all of the name/value pairs, > > including duplicates. > > > > This topic has been heavily discussed by the working group, and while the > specs used to just say that objects with duplicate member names MUST be > rejected, working group members, including Tim Bray (the editor of the JS= ON > spec), prevailed on us to weaken this so that parsers that implement the > ECMAscript behavior of returning only the last member name may be legally > used. (The argument was made that there was more security downside in > effectively requiring people to write and debug their own strict parsers > than in using laxer, but well-supported and debugged parsers.) > > > > However, we also intentionally require that producers use only one > instance of each member name, so that legally produced objects will never > exercise the ambiguities that are present in real JSON parsers. That > seemed to be the most practical solution to the working group. > > > > [snip] > > Thanks again, > Stephen, > > -- Mike > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --=20 Best regards, Kathleen --=20 Best regards, Kathleen --089e01176ff9a47e120502dd0541 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Mike,

The text Steve called out below has been very problematic= as you know. =C2=A0Could you call out some options here as the last time t= his came up, we didn't resolve it. =C2=A0The working group was asked fo= r suggestions, but none came through. =C2=A0If you could provide some optio= ns and then have the working group weigh in, I think that would be good.=C2= =A0

I snipped away the rest of the review and chan= ged the subject as not to get in the way of the current dialog.=C2=A0
=

Thanks.

On Wed, Sep 10, 2014 at 8:57 PM, Mike Jones = <Michael.Jones@microsoft.com> wrote:

Hi Stephen.=C2=A0 Thanks = for your detailed and useful review.=C2=A0 I=E2=80=99ve cc=E2=80=99ed the w= orking group in my reply so they=E2=80=99re aware of the contents of your r= eview.=C2=A0 Replies are inline below=E2=80=A6

=C2=A0

From: Stephen Kent [mailto:kent@bbn.com]
Sent: Tuesday, September 02, 2014 1:09 PM
To: secdir@ietf.org; Mike Jones= ; jose-chairs@tools.ietf.org;= Moriarty, Kathleen
Subject: SECDIR review of draft-ietf-jose-json-web-key-31<= /u>

=C2=A0

[snip]=C2=A0

=C2=A0=C2=A0

This section imp= oses a rather wimpy constraint on parameter names:

=C2=A0

=C2=A0=C2=A0 The member names within a JWK MUST be unique; recipients MU= ST either

=C2=A0=C2=A0 reject JWKs with duplicate member names or use a JSON parse= r that

=C2=A0=C2=A0 returns only the lexically last duplicate member name, as s= pecified

=C2=A0=C2=A0 in Section 15.12 (The JSON Object) of ECMAScript 5.1 [ECMAS= cript].

=C2=A0

This text says t= hat member names MUST be unique, but if they are not, that=E2=80=99s OK too= ; just use the last instance of a member with a duplicate name. This seems = like a terrible design principle. It imposes what appears to be a requirement, then says how to accommodate data struct= ures that fail to meet the requirement. This would seem to encourage sloppy= implementations (for JWK generation). I=E2=80=99d like to see the rational= e for this.

=C2=A0

=C2=A0

Unfortunately, the intentional laxness in the= spec in this regard is a reflection of the semantics of the actual JSON sp= ecifications and implementations.=C2=A0 For instance, http://tools.ietf.org/html/rfc7159#secti= on-4 says:

=C2=A0

=C2=A0=C2=A0 An object whose names are all unique is interopera= ble in the sense

=C2=A0=C2=A0 that all software implementations receiving that o= bject will agree on

=C2=A0=C2=A0 the name-value mappings.=C2=A0 When the names with= in an object are not

=C2=A0=C2=A0 unique, the behavior of software that receives suc= h an object is

=C2=A0=C2=A0 unpredictable.=C2=A0 Many implementations report t= he last name/value pair

=C2=A0=C2=A0 only.=C2=A0 Other implementations report an error = or fail to parse the

=C2=A0=C2=A0 object, and some implementations report all of the= name/value pairs,

=C2=A0=C2=A0 including duplicates.

=C2=A0

This topic has been heavily discussed by the = working group, and while the specs used to just say that objects with dupli= cate member names MUST be rejected, working group members, including Tim Bray (the editor of the JSON spec), p= revailed on us to weaken this so that parsers that implement the ECMAscript= behavior of returning only the last member name may be legally used.=C2=A0= (The argument was made that there was more security downside in effectively requiring people to write and debug = their own strict parsers than in using laxer, but well-supported and debugg= ed parsers.)

=C2=A0

However, we also intentionally require that p= roducers use only one instance of each member name, so that legally produce= d objects will never exercise the ambiguities that are present in real JSON parsers.=C2=A0 That seemed to be= the most practical solution to the working group.

=C2=A0

[snip]

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thanks again, Stephen,<= /p>
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike

=C2=A0

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

Bes= t regards,

Kathleen

Best regards,

Kathleen

--089e01176ff9a47e120502dd0541-- From nobody Fri Sep 12 08:20:06 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65BFB1A6F17; Fri, 12 Sep 2014 08:19:57 -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, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 44oYh0rCo-0e; Fri, 12 Sep 2014 08:19:51 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0792.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::792]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D0CA1A0BEB; Fri, 12 Sep 2014 08:19:51 -0700 (PDT) Received: from CH1PR03CA004.namprd03.prod.outlook.com (10.255.156.149) by CH1PR03MB611.namprd03.prod.outlook.com (10.255.156.167) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Fri, 12 Sep 2014 15:19:27 +0000 Received: from BL2FFO11FD053.protection.gbl (10.255.156.132) by CH1PR03CA004.outlook.office365.com (10.255.156.149) with Microsoft SMTP Server (TLS) id 15.0.1029.13 via Frontend Transport; Fri, 12 Sep 2014 15:19:26 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD053.mail.protection.outlook.com (10.173.161.181) with Microsoft SMTP Server (TLS) id 15.0.1019.14 via Frontend Transport; Fri, 12 Sep 2014 15:19:26 +0000 Received: from TK5EX14MBXC292.redmond.corp.microsoft.com ([169.254.1.60]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.03.0195.002; Fri, 12 Sep 2014 15:18:44 +0000 From: Mike Jones To: Kathleen Moriarty , "jose@ietf.org" , "jose-chairs@tools.ietf.org" , "draft-ietf-jose-json-web-key.all@tools.ietf.org" , "secdir@ietf.org" , Stephen Kent Thread-Topic: JWK member names, was: [jose] SECDIR review of draft-ietf-jose-json-web-key-31 Thread-Index: AQHPzoESD2WvkanDakGRB2XPz/nr6pv9mXgQ Date: Fri, 12 Sep 2014 15:18:42 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439AEC00DB@TK5EX14MBXC292.redmond.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439AEC00DBTK5EX14MBXC292r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(438002)(189002)(377454003)(199003)(43784003)(51444003)(24454002)(19300405004)(74662001)(33656002)(15975445006)(79102001)(85806002)(80022001)(87936001)(99396002)(86612001)(81156004)(71186001)(66066001)(85852003)(16236675004)(83072002)(2501002)(85306004)(50986999)(46102001)(106116001)(97736003)(104016003)(19625215002)(19617315012)(512874002)(95666004)(19580405001)(92566001)(19580395003)(76176999)(107046002)(77096002)(83322001)(77982001)(107886001)(2656002)(44976005)(26826002)(92726001)(69596002)(31966008)(81542001)(84326002)(84676001)(74502001)(81342001)(2201001)(230783001)(106466001)(68736004)(21056001)(54356999)(64706001)(15202345003)(4396001)(6806004)(90102001)(20776003)(76482001)(55846006)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:CH1PR03MB611; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0332AACBC3 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/tvQmaIVCygk5vt7mJ9L1dKPu96Q Subject: Re: [secdir] JWK member names, was: [jose] SECDIR review of draft-ietf-jose-json-web-key-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 15:19:57 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439AEC00DBTK5EX14MBXC292r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VyZS4gIEhlcmXigJlzIGFuIGFuYWx5c2lzIG9mIHRoZSByZXF1aXJlbWVudHMgYWJvdXQgZHVw bGljYXRlIG1lbWJlciBuYW1lcy4NCg0KVGhlcmUgY291bGQgYmUgdHdvIHZlcnkgZGlmZmVyZW50 IGtpbmRzIG9mIG9iamVjdGlvbnMgdG8gdGhlIHByZXNlbnQgdGV4dDoNCkEuICBQZW9wbGUgdGhp bmsgd2UgaGF2ZSB0aGUgc2VtYW50aWNzIGZvciBkdXBsaWNhdGUgaWRlbnRpZmllcnMgd3Jvbmcu DQpCLiAgUGVvcGxlIHRoaW5rIHdlIHNob3VsZCBleHBsYWluIHRoZSBjdXJyZW50IHNlbWFudGlj cyBmb3IgZHVwbGljYXRlIGlkZW50aWZpZXJzIG1vcmUgY2xlYXJseS4NCg0KSSBzdXJlIGhvcGUg dGhhdCB3ZeKAmXJlIGRlYWxpbmcgd2l0aCBCIGFuZCBub3QgQS4gIFN0ZXBoZW4sIHdoaWNoIGlz IHRoZSBuYXR1cmUgb2YgeW91ciBjcml0aXF1ZSBvZiB0aGlzIHRleHQ/DQoNCklmIHdl4oCZcmUg aW4gdGhlIHJlYWxtIG9mIEEsIEkgdGhpbmsgdGhlcmUgYXJlIHRocmVlIHBvc3NpYmlsaXRpZXMg Zm9yIHRoZSBzZW1hbnRpY3M6DQoNCjEuICBSZXF1aXJlIHByb2R1Y2VycyBub3QgdXNlIGR1cGxp Y2F0ZSBtZW1iZXJzIGFuZCByZXF1aXJlIGNvbnN1bWVycyB0byByZWplY3QgaW5wdXRzIHdpdGgg ZHVwbGljYXRlIG1lbWJlciBuYW1lcy4NClByb3M6ICBUaGlzIGlzIHRoZSBtb3N0IGxvY2tlZC1k b3duLCBjb25zaXN0ZW50LCBhbmQgYWx0ZXJuYXRpdmUuDQpDb25zOiAgUmVhbCBKU09OIHBhcnNl cnMgZG9u4oCZdCBhbGwgcmVqZWN0IGR1cGxpY2F0ZSBpbnB1dHMuICBJZiB3ZSBmb3JjZSBwZW9w bGUgdG8gd3JpdGUgY3VzdG9tIHBhcnNlcnMsIHRoaXMgd2lsbCByZXN1bHQgaW4gZXhwbG9pdGFi bGUgYnVncyAoYW5kIHNvbWUganVzdCB3b27igJl0IGRvIGl0IGFuZCB3b27igJl0IGJlIGNvbmZv cm1hbnQpLg0KDQoyLiAgUmVxdWlyZSBwcm9kdWNlcnMgbm90IHRvIHVzZSBkdXBsaWNhdGUgbWVt YmVycyBidXQgYWxsb3cgY29uc3VtZXJzIHRvIGFjY2VwdCBpbnB1dHMgd2l0aCBkdXBsaWNhdGUg bWVtYmVyIG5hbWVzIGluIHRoZSBtYW5uZXIgZGVmaW5lZCBpbiBFQ01Bc2NyaXB0LiAgKFRoaXMg aXMgdGhlIGN1cnJlbnQgY2hvaWNlLikNClByb3M6ICBQZW9wbGUgY2FuIHVzZSBhbGwgc3RhbmRh cmQgSlNPTiBwYXJzZXJzLiAgUHJvZHVjZXJzIGFyZSBzdGlsbCByZXF1aXJlZCB0byBwcm9kdWNl IHdlbGwtZm9ybWVkIGRhdGEgc3RydWN0dXJlcy4NCkNvbnM6ICBUaGUgcmVxdWlyZW1lbnRzIG9u IHByb2R1Y2VycyBhcmUgc3RyaWN0ZXIgdGhhbiB0aG9zZSBvbiBjb25zdW1lcnMuDQoNCjMuICBB bGxvdyBib3RoIHByb2R1Y2VycyBhbmQgY29uc3VtZXJzIHRvIHVzZSBkdXBsaWNhdGUgbWVtYmVy cywgd2l0aCBkdXBsaWNhdGUgbWVtYmVyIG5hbWVzIGhhbmRsZWQgaW4gdGhlIG1hbm5lciBkZWZp bmVkIGluIEVDTUFzY3JpcHQuDQpQcm9zOiAgUGVvcGxlIGNhbiB1c2UgRUNNQXNjcmlwdCBwYXJz ZXJzICh3aGljaCBhcmUgbW9yZSBsaWJlcmFsIHRoYW4gc29tZSBKU09OIHBhcnNlcnMpLiAgVGhl IHJlcXVpcmVtZW50cyBvbiBwcm9kdWNlcnMgYW5kIGNvbnN1bWVycyBhcmUgdGhlIHNhbWUuDQpD b25zOiAgSGlkZGVuIGNvbnRlbnQgY2FuIGJlIGluc2VydGVkIGludG8gZHVwbGljYXRlIG1lbWJl ciBuYW1lcy4gIFRoaXMgY291bGQgZ2l2ZSBhdHRhY2tlcnMgYSB3YXkgdG8gbWFuaXB1bGF0ZSB0 aGUgaW5wdXRzIHRvIGNyeXB0byBvcGVyYXRpb25zLiAgU3RyaWN0IEpTT04gcGFyc2VycyAodGhh dCByZWplY3QgaW5wdXRzIHdpdGggZHVwbGljYXRlIG1lbWJlcnMpIGNhbuKAmXQgYmUgdXNlZC4N Cg0KUHJhY3RpY2FsbHksIEkgdGhpbmsgd2VyZSB3ZSBwcmVzZW50bHkgYXJlICgyKSBpcyB0aGUg YmVzdCBjb21wcm9taXNlIGJldHdlZW4gaW1wbGVtZW50YWJpbGl0eSwgY29uc2lzdGVuY3ksIGFu ZCBzZWN1cml0eS4gIFRoZSB3b3JraW5nIGdyb3VwIHB1dCBhIGxvdCBvZiBkaXNjdXNzaW9uIGlu dG8gdGhpcywgaW5jbHVkaW5nIGNoYW5naW5nIGZyb20gKDEpIHRvICgyKSBhbmQgaXTigJlzIG15 IHNlbnNlIHRoYXQgbW9zdCBhZ3JlZSB3ZeKAmXZlIGxhbmRlZCBpbiB0aGUgcmlnaHQgcGxhY2Uu ICBGcm9tIGEgc2VjdXJpdHkgcGVyc3BlY3RpdmUsIEkgZG9u4oCZdCB0aGluayB0aGF0ICgzKSBp cyBhIHZpYWJsZSBvcHRpb24uDQoNCklmIHBlb3BsZSB0aGluayB0aGF0IHRoZSBjdXJyZW50IHNl bWFudGljcyBhcmUgcmlnaHQgYnV0IGFyZSBub3Qgc3VmZmljaWVudGx5IGNsZWFybHkgZXhwbGFp bmVkIG9yIG1vdGl2YXRlZCwgSeKAmWQgY2VydGFpbmx5IHdlbGNvbWUgcHJvcG9zZWQgdGV4dCB0 byBjbGFyaWZ5IHRoZSBleHBsYW5hdGlvbi4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBLYXRobGVl biBNb3JpYXJ0eSBbbWFpbHRvOmthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tXQ0KU2Vu dDogRnJpZGF5LCBTZXB0ZW1iZXIgMTIsIDIwMTQgNTowMCBBTQ0KVG86IGpvc2VAaWV0Zi5vcmc7 IGpvc2UtY2hhaXJzQHRvb2xzLmlldGYub3JnOyBkcmFmdC1pZXRmLWpvc2UtanNvbi13ZWIta2V5 LmFsbEB0b29scy5pZXRmLm9yZzsgc2VjZGlyQGlldGYub3JnOyBTdGVwaGVuIEtlbnQ7IE1pa2Ug Sm9uZXMNClN1YmplY3Q6IEpXSyBtZW1iZXIgbmFtZXMsIHdhczogW2pvc2VdIFNFQ0RJUiByZXZp ZXcgb2YgZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWtleS0zMQ0KDQpIaSBNaWtlLA0KDQpUaGUg dGV4dCBTdGV2ZSBjYWxsZWQgb3V0IGJlbG93IGhhcyBiZWVuIHZlcnkgcHJvYmxlbWF0aWMgYXMg eW91IGtub3cuICBDb3VsZCB5b3UgY2FsbCBvdXQgc29tZSBvcHRpb25zIGhlcmUgYXMgdGhlIGxh c3QgdGltZSB0aGlzIGNhbWUgdXAsIHdlIGRpZG4ndCByZXNvbHZlIGl0LiAgVGhlIHdvcmtpbmcg Z3JvdXAgd2FzIGFza2VkIGZvciBzdWdnZXN0aW9ucywgYnV0IG5vbmUgY2FtZSB0aHJvdWdoLiAg SWYgeW91IGNvdWxkIHByb3ZpZGUgc29tZSBvcHRpb25zIGFuZCB0aGVuIGhhdmUgdGhlIHdvcmtp bmcgZ3JvdXAgd2VpZ2ggaW4sIEkgdGhpbmsgdGhhdCB3b3VsZCBiZSBnb29kLg0KDQpJIHNuaXBw ZWQgYXdheSB0aGUgcmVzdCBvZiB0aGUgcmV2aWV3IGFuZCBjaGFuZ2VkIHRoZSBzdWJqZWN0IGFz IG5vdCB0byBnZXQgaW4gdGhlIHdheSBvZiB0aGUgY3VycmVudCBkaWFsb2cuDQoNClRoYW5rcy4N Cg0KT24gV2VkLCBTZXAgMTAsIDIwMTQgYXQgODo1NyBQTSwgTWlrZSBKb25lcyA8TWljaGFlbC5K b25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PiB3 cm90ZToNCkhpIFN0ZXBoZW4uICBUaGFua3MgZm9yIHlvdXIgZGV0YWlsZWQgYW5kIHVzZWZ1bCBy ZXZpZXcuICBJ4oCZdmUgY2PigJllZCB0aGUgd29ya2luZyBncm91cCBpbiBteSByZXBseSBzbyB0 aGV54oCZcmUgYXdhcmUgb2YgdGhlIGNvbnRlbnRzIG9mIHlvdXIgcmV2aWV3LiAgUmVwbGllcyBh cmUgaW5saW5lIGJlbG934oCmDQoNCkZyb206IFN0ZXBoZW4gS2VudCBbbWFpbHRvOmtlbnRAYmJu LmNvbV0NClNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAwMiwgMjAxNCAxOjA5IFBNDQpUbzogc2Vj ZGlyQGlldGYub3JnPG1haWx0bzpzZWNkaXJAaWV0Zi5vcmc+OyBNaWtlIEpvbmVzOyBqb3NlLWNo YWlyc0B0b29scy5pZXRmLm9yZzxtYWlsdG86am9zZS1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+OyBN b3JpYXJ0eSwgS2F0aGxlZW4NClN1YmplY3Q6IFNFQ0RJUiByZXZpZXcgb2YgZHJhZnQtaWV0Zi1q b3NlLWpzb24td2ViLWtleS0zMQ0KDQpbc25pcF0NCg0KVGhpcyBzZWN0aW9uIGltcG9zZXMgYSBy YXRoZXIgd2ltcHkgY29uc3RyYWludCBvbiBwYXJhbWV0ZXIgbmFtZXM6DQoNCg0KDQogICBUaGUg bWVtYmVyIG5hbWVzIHdpdGhpbiBhIEpXSyBNVVNUIGJlIHVuaXF1ZTsgcmVjaXBpZW50cyBNVVNU IGVpdGhlcg0KDQogICByZWplY3QgSldLcyB3aXRoIGR1cGxpY2F0ZSBtZW1iZXIgbmFtZXMgb3Ig dXNlIGEgSlNPTiBwYXJzZXIgdGhhdA0KDQogICByZXR1cm5zIG9ubHkgdGhlIGxleGljYWxseSBs YXN0IGR1cGxpY2F0ZSBtZW1iZXIgbmFtZSwgYXMgc3BlY2lmaWVkDQoNCiAgIGluIFNlY3Rpb24g MTUuMTIgKFRoZSBKU09OIE9iamVjdCkgb2YgRUNNQVNjcmlwdCA1LjEgW0VDTUFTY3JpcHRdLg0K DQoNClRoaXMgdGV4dCBzYXlzIHRoYXQgbWVtYmVyIG5hbWVzIE1VU1QgYmUgdW5pcXVlLCBidXQg aWYgdGhleSBhcmUgbm90LCB0aGF04oCZcyBPSyB0b287IGp1c3QgdXNlIHRoZSBsYXN0IGluc3Rh bmNlIG9mIGEgbWVtYmVyIHdpdGggYSBkdXBsaWNhdGUgbmFtZS4gVGhpcyBzZWVtcyBsaWtlIGEg dGVycmlibGUgZGVzaWduIHByaW5jaXBsZS4gSXQgaW1wb3NlcyB3aGF0IGFwcGVhcnMgdG8gYmUg YSByZXF1aXJlbWVudCwgdGhlbiBzYXlzIGhvdyB0byBhY2NvbW1vZGF0ZSBkYXRhIHN0cnVjdHVy ZXMgdGhhdCBmYWlsIHRvIG1lZXQgdGhlIHJlcXVpcmVtZW50LiBUaGlzIHdvdWxkIHNlZW0gdG8g ZW5jb3VyYWdlIHNsb3BweSBpbXBsZW1lbnRhdGlvbnMgKGZvciBKV0sgZ2VuZXJhdGlvbikuIEni gJlkIGxpa2UgdG8gc2VlIHRoZSByYXRpb25hbGUgZm9yIHRoaXMuDQoNCg0KDQoNCg0KVW5mb3J0 dW5hdGVseSwgdGhlIGludGVudGlvbmFsIGxheG5lc3MgaW4gdGhlIHNwZWMgaW4gdGhpcyByZWdh cmQgaXMgYSByZWZsZWN0aW9uIG9mIHRoZSBzZW1hbnRpY3Mgb2YgdGhlIGFjdHVhbCBKU09OIHNw ZWNpZmljYXRpb25zIGFuZCBpbXBsZW1lbnRhdGlvbnMuICBGb3IgaW5zdGFuY2UsIGh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL3JmYzcxNTkjc2VjdGlvbi00IHNheXM6DQoNCg0KICAgQW4gb2Jq ZWN0IHdob3NlIG5hbWVzIGFyZSBhbGwgdW5pcXVlIGlzIGludGVyb3BlcmFibGUgaW4gdGhlIHNl bnNlDQogICB0aGF0IGFsbCBzb2Z0d2FyZSBpbXBsZW1lbnRhdGlvbnMgcmVjZWl2aW5nIHRoYXQg b2JqZWN0IHdpbGwgYWdyZWUgb24NCiAgIHRoZSBuYW1lLXZhbHVlIG1hcHBpbmdzLiAgV2hlbiB0 aGUgbmFtZXMgd2l0aGluIGFuIG9iamVjdCBhcmUgbm90DQogICB1bmlxdWUsIHRoZSBiZWhhdmlv ciBvZiBzb2Z0d2FyZSB0aGF0IHJlY2VpdmVzIHN1Y2ggYW4gb2JqZWN0IGlzDQogICB1bnByZWRp Y3RhYmxlLiAgTWFueSBpbXBsZW1lbnRhdGlvbnMgcmVwb3J0IHRoZSBsYXN0IG5hbWUvdmFsdWUg cGFpcg0KICAgb25seS4gIE90aGVyIGltcGxlbWVudGF0aW9ucyByZXBvcnQgYW4gZXJyb3Igb3Ig ZmFpbCB0byBwYXJzZSB0aGUNCiAgIG9iamVjdCwgYW5kIHNvbWUgaW1wbGVtZW50YXRpb25zIHJl cG9ydCBhbGwgb2YgdGhlIG5hbWUvdmFsdWUgcGFpcnMsDQogICBpbmNsdWRpbmcgZHVwbGljYXRl cy4NCg0KDQoNClRoaXMgdG9waWMgaGFzIGJlZW4gaGVhdmlseSBkaXNjdXNzZWQgYnkgdGhlIHdv cmtpbmcgZ3JvdXAsIGFuZCB3aGlsZSB0aGUgc3BlY3MgdXNlZCB0byBqdXN0IHNheSB0aGF0IG9i amVjdHMgd2l0aCBkdXBsaWNhdGUgbWVtYmVyIG5hbWVzIE1VU1QgYmUgcmVqZWN0ZWQsIHdvcmtp bmcgZ3JvdXAgbWVtYmVycywgaW5jbHVkaW5nIFRpbSBCcmF5ICh0aGUgZWRpdG9yIG9mIHRoZSBK U09OIHNwZWMpLCBwcmV2YWlsZWQgb24gdXMgdG8gd2Vha2VuIHRoaXMgc28gdGhhdCBwYXJzZXJz IHRoYXQgaW1wbGVtZW50IHRoZSBFQ01Bc2NyaXB0IGJlaGF2aW9yIG9mIHJldHVybmluZyBvbmx5 IHRoZSBsYXN0IG1lbWJlciBuYW1lIG1heSBiZSBsZWdhbGx5IHVzZWQuICAoVGhlIGFyZ3VtZW50 IHdhcyBtYWRlIHRoYXQgdGhlcmUgd2FzIG1vcmUgc2VjdXJpdHkgZG93bnNpZGUgaW4gZWZmZWN0 aXZlbHkgcmVxdWlyaW5nIHBlb3BsZSB0byB3cml0ZSBhbmQgZGVidWcgdGhlaXIgb3duIHN0cmlj dCBwYXJzZXJzIHRoYW4gaW4gdXNpbmcgbGF4ZXIsIGJ1dCB3ZWxsLXN1cHBvcnRlZCBhbmQgZGVi dWdnZWQgcGFyc2Vycy4pDQoNCg0KDQpIb3dldmVyLCB3ZSBhbHNvIGludGVudGlvbmFsbHkgcmVx dWlyZSB0aGF0IHByb2R1Y2VycyB1c2Ugb25seSBvbmUgaW5zdGFuY2Ugb2YgZWFjaCBtZW1iZXIg bmFtZSwgc28gdGhhdCBsZWdhbGx5IHByb2R1Y2VkIG9iamVjdHMgd2lsbCBuZXZlciBleGVyY2lz ZSB0aGUgYW1iaWd1aXRpZXMgdGhhdCBhcmUgcHJlc2VudCBpbiByZWFsIEpTT04gcGFyc2Vycy4g IFRoYXQgc2VlbWVkIHRvIGJlIHRoZSBtb3N0IHByYWN0aWNhbCBzb2x1dGlvbiB0byB0aGUgd29y a2luZyBncm91cC4NCg0KDQpbc25pcF0NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRoYW5rcyBhZ2FpbiwgU3RlcGhlbiwNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0t IE1pa2UNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0Kam9zZSBtYWlsaW5nIGxpc3QNCmpvc2VAaWV0Zi5vcmc8bWFpbHRvOmpvc2VAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2pvc2UNCg0KDQoNCi0tDQoN CkJlc3QgcmVnYXJkcywNCkthdGhsZWVuDQoNCg0KDQotLQ0KDQpCZXN0IHJlZ2FyZHMsDQpLYXRo bGVlbg0K --_000_4E1F6AAD24975D4BA5B16804296739439AEC00DBTK5EX14MBXC292r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIgMiA1IDIgNCA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIg NCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToy IDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K cA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJ bWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4t bGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRh dGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRl eHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLmhv ZW56Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlN1cmUuJm5ic3A7IEhlcmXigJlzIGFuIGFuYWx5 c2lzIG9mIHRoZSByZXF1aXJlbWVudHMgYWJvdXQgZHVwbGljYXRlIG1lbWJlciBuYW1lcy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPlRoZXJlIGNvdWxkIGJlIHR3byB2ZXJ5IGRpZmZlcmVudCBraW5kcyBvZiBvYmplY3Rp b25zIHRvIHRoZSBwcmVzZW50IHRleHQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkEu Jm5ic3A7IFBlb3BsZSB0aGluayB3ZSBoYXZlIHRoZSBzZW1hbnRpY3MgZm9yIGR1cGxpY2F0ZSBp ZGVudGlmaWVycyB3cm9uZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Qi4mbmJzcDsg UGVvcGxlIHRoaW5rIHdlIHNob3VsZCBleHBsYWluIHRoZSBjdXJyZW50IHNlbWFudGljcyBmb3Ig ZHVwbGljYXRlIGlkZW50aWZpZXJzIG1vcmUgY2xlYXJseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgc3VyZSBob3Bl IHRoYXQgd2XigJlyZSBkZWFsaW5nIHdpdGggQiBhbmQgbm90IEEuJm5ic3A7IFN0ZXBoZW4sIHdo aWNoIGlzIHRoZSBuYXR1cmUgb2YgeW91ciBjcml0aXF1ZSBvZiB0aGlzIHRleHQ/PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5JZiB3ZeKAmXJlIGluIHRoZSByZWFsbSBvZiBBLCBJIHRoaW5rIHRoZXJlIGFyZSB0aHJlZSBw b3NzaWJpbGl0aWVzIGZvciB0aGUgc2VtYW50aWNzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+MS4mbmJzcDsgUmVxdWly ZSBwcm9kdWNlcnMgbm90IHVzZSBkdXBsaWNhdGUgbWVtYmVycyBhbmQgcmVxdWlyZSBjb25zdW1l cnMgdG8gcmVqZWN0IGlucHV0cyB3aXRoIGR1cGxpY2F0ZSBtZW1iZXIgbmFtZXMuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlByb3M6Jm5ic3A7IFRoaXMgaXMgdGhlIG1vc3QgbG9ja2Vk LWRvd24sIGNvbnNpc3RlbnQsIGFuZCBhbHRlcm5hdGl2ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Q29uczombmJzcDsgUmVhbCBKU09OIHBhcnNlcnMgZG9u4oCZdCBhbGwgcmVqZWN0 IGR1cGxpY2F0ZSBpbnB1dHMuJm5ic3A7IElmIHdlIGZvcmNlIHBlb3BsZSB0byB3cml0ZSBjdXN0 b20gcGFyc2VycywgdGhpcyB3aWxsIHJlc3VsdCBpbiBleHBsb2l0YWJsZSBidWdzIChhbmQgc29t ZSBqdXN0DQogd29u4oCZdCBkbyBpdCBhbmQgd29u4oCZdCBiZSBjb25mb3JtYW50KS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjIuJm5ic3A7IFJlcXVpcmUgcHJvZHVjZXJzIG5vdCB0byB1c2UgZHVwbGljYXRlIG1lbWJl cnMgYnV0IGFsbG93IGNvbnN1bWVycyB0byBhY2NlcHQgaW5wdXRzIHdpdGggZHVwbGljYXRlIG1l bWJlciBuYW1lcyBpbiB0aGUgbWFubmVyIGRlZmluZWQgaW4gRUNNQXNjcmlwdC4mbmJzcDsgKFRo aXMNCiBpcyB0aGUgY3VycmVudCBjaG9pY2UuKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5Qcm9zOiZuYnNwOyBQZW9wbGUgY2FuIHVzZSBhbGwgc3RhbmRhcmQgSlNPTiBwYXJzZXJzLiZu YnNwOyBQcm9kdWNlcnMgYXJlIHN0aWxsIHJlcXVpcmVkIHRvIHByb2R1Y2Ugd2VsbC1mb3JtZWQg ZGF0YSBzdHJ1Y3R1cmVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Db25zOiZuYnNw OyBUaGUgcmVxdWlyZW1lbnRzIG9uIHByb2R1Y2VycyBhcmUgc3RyaWN0ZXIgdGhhbiB0aG9zZSBv biBjb25zdW1lcnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4zLiZuYnNwOyBBbGxvdyBib3RoIHByb2R1Y2VycyBhbmQg Y29uc3VtZXJzIHRvIHVzZSBkdXBsaWNhdGUgbWVtYmVycywgd2l0aCBkdXBsaWNhdGUgbWVtYmVy IG5hbWVzIGhhbmRsZWQgaW4gdGhlIG1hbm5lciBkZWZpbmVkIGluIEVDTUFzY3JpcHQuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlByb3M6Jm5ic3A7IFBlb3BsZSBjYW4gdXNlIEVDTUFz Y3JpcHQgcGFyc2VycyAod2hpY2ggYXJlIG1vcmUgbGliZXJhbCB0aGFuIHNvbWUgSlNPTiBwYXJz ZXJzKS4mbmJzcDsgVGhlIHJlcXVpcmVtZW50cyBvbiBwcm9kdWNlcnMgYW5kIGNvbnN1bWVycyBh cmUgdGhlIHNhbWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNvbnM6Jm5ic3A7IEhp ZGRlbiBjb250ZW50IGNhbiBiZSBpbnNlcnRlZCBpbnRvIGR1cGxpY2F0ZSBtZW1iZXIgbmFtZXMu Jm5ic3A7IFRoaXMgY291bGQgZ2l2ZSBhdHRhY2tlcnMgYSB3YXkgdG8gbWFuaXB1bGF0ZSB0aGUg aW5wdXRzIHRvIGNyeXB0byBvcGVyYXRpb25zLiZuYnNwOyBTdHJpY3QgSlNPTg0KIHBhcnNlcnMg KHRoYXQgcmVqZWN0IGlucHV0cyB3aXRoIGR1cGxpY2F0ZSBtZW1iZXJzKSBjYW7igJl0IGJlIHVz ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5QcmFjdGljYWxseSwgSSB0aGluayB3ZXJlIHdlIHByZXNlbnRseSBhcmUg KDIpIGlzIHRoZSBiZXN0IGNvbXByb21pc2UgYmV0d2VlbiBpbXBsZW1lbnRhYmlsaXR5LCBjb25z aXN0ZW5jeSwgYW5kIHNlY3VyaXR5LiZuYnNwOyBUaGUgd29ya2luZyBncm91cCBwdXQgYSBsb3Qg b2YgZGlzY3Vzc2lvbg0KIGludG8gdGhpcywgaW5jbHVkaW5nIGNoYW5naW5nIGZyb20gKDEpIHRv ICgyKSBhbmQgaXTigJlzIG15IHNlbnNlIHRoYXQgbW9zdCBhZ3JlZSB3ZeKAmXZlIGxhbmRlZCBp biB0aGUgcmlnaHQgcGxhY2UuJm5ic3A7IEZyb20gYSBzZWN1cml0eSBwZXJzcGVjdGl2ZSwgSSBk b27igJl0IHRoaW5rIHRoYXQgKDMpIGlzIGEgdmlhYmxlIG9wdGlvbi48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklmIHBl b3BsZSB0aGluayB0aGF0IHRoZSBjdXJyZW50IHNlbWFudGljcyBhcmUgcmlnaHQgYnV0IGFyZSBu b3Qgc3VmZmljaWVudGx5IGNsZWFybHkgZXhwbGFpbmVkIG9yIG1vdGl2YXRlZCwgSeKAmWQgY2Vy dGFpbmx5IHdlbGNvbWUgcHJvcG9zZWQgdGV4dCB0byBjbGFyaWZ5DQogdGhlIGV4cGxhbmF0aW9u LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+IEthdGhsZWVuIE1vcmlhcnR5IFttYWlsdG86a2F0aGxlZW4ubW9y aWFydHkuaWV0ZkBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBTZXB0ZW1i ZXIgMTIsIDIwMTQgNTowMCBBTTxicj4NCjxiPlRvOjwvYj4gam9zZUBpZXRmLm9yZzsgam9zZS1j aGFpcnNAdG9vbHMuaWV0Zi5vcmc7IGRyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1rZXkuYWxsQHRv b2xzLmlldGYub3JnOyBzZWNkaXJAaWV0Zi5vcmc7IFN0ZXBoZW4gS2VudDsgTWlrZSBKb25lczxi cj4NCjxiPlN1YmplY3Q6PC9iPiBKV0sgbWVtYmVyIG5hbWVzLCB3YXM6IFtqb3NlXSBTRUNESVIg cmV2aWV3IG9mIGRyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1rZXktMzE8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIE1pa2UsPG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgdGV4dCBTdGV2ZSBjYWxsZWQg b3V0IGJlbG93IGhhcyBiZWVuIHZlcnkgcHJvYmxlbWF0aWMgYXMgeW91IGtub3cuICZuYnNwO0Nv dWxkIHlvdSBjYWxsIG91dCBzb21lIG9wdGlvbnMgaGVyZSBhcyB0aGUgbGFzdCB0aW1lIHRoaXMg Y2FtZSB1cCwgd2UgZGlkbid0IHJlc29sdmUgaXQuICZuYnNwO1RoZSB3b3JraW5nIGdyb3VwIHdh cyBhc2tlZCBmb3Igc3VnZ2VzdGlvbnMsIGJ1dCBub25lIGNhbWUgdGhyb3VnaC4gJm5ic3A7SWYg eW91DQogY291bGQgcHJvdmlkZSBzb21lIG9wdGlvbnMgYW5kIHRoZW4gaGF2ZSB0aGUgd29ya2lu ZyBncm91cCB3ZWlnaCBpbiwgSSB0aGluayB0aGF0IHdvdWxkIGJlIGdvb2QuJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgc25pcHBl ZCBhd2F5IHRoZSByZXN0IG9mIHRoZSByZXZpZXcgYW5kIGNoYW5nZWQgdGhlIHN1YmplY3QgYXMg bm90IHRvIGdldCBpbiB0aGUgd2F5IG9mIHRoZSBjdXJyZW50IGRpYWxvZy4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgU2VwIDEwLCAyMDE0 IGF0IDg6NTcgUE0sIE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVz QG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwNzBDMCI+ SGkgU3RlcGhlbi4mbmJzcDsgVGhhbmtzIGZvciB5b3VyIGRldGFpbGVkIGFuZCB1c2VmdWwgcmV2 aWV3LiZuYnNwOyBJ4oCZdmUgY2PigJllZCB0aGUgd29ya2luZyBncm91cCBpbiBteSByZXBseQ0K IHNvIHRoZXnigJlyZSBhd2FyZSBvZiB0aGUgY29udGVudHMgb2YgeW91ciByZXZpZXcuJm5ic3A7 IFJlcGxpZXMgYXJlIGlubGluZSBiZWxvd+KApjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDcw QzAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBTdGVw aGVuIEtlbnQgWzwvc3Bhbj48YSBocmVmPSJtYWlsdG86a2VudEBiYm4uY29tIiB0YXJnZXQ9Il9i bGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPm1haWx0bzprZW50QGJibi5jb208L3Nw YW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5dDQo8YnI+DQo8Yj5TZW50OjwvYj4g VHVlc2RheSwgU2VwdGVtYmVyIDAyLCAyMDE0IDE6MDkgUE08YnI+DQo8Yj5Ubzo8L2I+IDwvc3Bh bj48YSBocmVmPSJtYWlsdG86c2VjZGlyQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPnNlY2RpckBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPjsgTWlrZSBKb25lczsNCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86 am9zZS1jaGFpcnNAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+am9zZS1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij47IE1vcmlhcnR5LCBLYXRobGVlbjxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBTRUNESVIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1rZXktMzE8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+W3NuaXBdJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OkNvdXJpZXIiPlRoaXMgc2VjdGlvbiBpbXBvc2VzIGEgcmF0aGVyIHdpbXB5IGNvbnN0cmFpbnQg b24gcGFyYW1ldGVyIG5hbWVzOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHA+Jm5ic3A7Jm5ic3A7IFRoZSBtZW1iZXIgbmFtZXMgd2l0aGluIGEgSldL IE1VU1QgYmUgdW5pcXVlOyByZWNpcGllbnRzIE1VU1QgZWl0aGVyPG86cD48L286cD48L3A+DQo8 cD4mbmJzcDsmbmJzcDsgcmVqZWN0IEpXS3Mgd2l0aCBkdXBsaWNhdGUgbWVtYmVyIG5hbWVzIG9y IHVzZSBhIEpTT04gcGFyc2VyIHRoYXQ8bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOyZuYnNwOyBy ZXR1cm5zIG9ubHkgdGhlIGxleGljYWxseSBsYXN0IGR1cGxpY2F0ZSBtZW1iZXIgbmFtZSwgYXMg c3BlY2lmaWVkPG86cD48L286cD48L3A+DQo8cD4mbmJzcDsmbmJzcDsgaW4gU2VjdGlvbiAxNS4x MiAoVGhlIEpTT04gT2JqZWN0KSBvZiBFQ01BU2NyaXB0IDUuMSBbRUNNQVNjcmlwdF0uPG86cD48 L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIiPlRoaXMgdGV4dCBzYXlzIHRoYXQg bWVtYmVyIG5hbWVzIE1VU1QgYmUgdW5pcXVlLCBidXQgaWYgdGhleSBhcmUgbm90LCB0aGF04oCZ cyBPSyB0b287IGp1c3QgdXNlIHRoZSBsYXN0IGluc3RhbmNlIG9mIGEgbWVtYmVyIHdpdGggYSBk dXBsaWNhdGUgbmFtZS4NCiBUaGlzIHNlZW1zIGxpa2UgYSB0ZXJyaWJsZSBkZXNpZ24gcHJpbmNp cGxlLiBJdCBpbXBvc2VzIHdoYXQgYXBwZWFycyB0byBiZSBhIHJlcXVpcmVtZW50LCB0aGVuIHNh eXMgaG93IHRvIGFjY29tbW9kYXRlIGRhdGEgc3RydWN0dXJlcyB0aGF0IGZhaWwgdG8gbWVldCB0 aGUgcmVxdWlyZW1lbnQuIFRoaXMgd291bGQgc2VlbSB0byBlbmNvdXJhZ2Ugc2xvcHB5IGltcGxl bWVudGF0aW9ucyAoZm9yIEpXSyBnZW5lcmF0aW9uKS4gSeKAmWQgbGlrZSB0bw0KIHNlZSB0aGUg cmF0aW9uYWxlIGZvciB0aGlzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBz dHlsZT0iY29sb3I6IzAwNzBDMCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDcwQzAiPlVuZm9ydHVuYXRlbHksIHRo ZSBpbnRlbnRpb25hbCBsYXhuZXNzIGluIHRoZSBzcGVjIGluIHRoaXMgcmVnYXJkIGlzIGEgcmVm bGVjdGlvbiBvZiB0aGUgc2VtYW50aWNzIG9mIHRoZSBhY3R1YWwgSlNPTiBzcGVjaWZpY2F0aW9u cyBhbmQgaW1wbGVtZW50YXRpb25zLiZuYnNwOyBGb3IgaW5zdGFuY2UsDQo8L3NwYW4+PGEgaHJl Zj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzE1OSNzZWN0aW9uLTQiIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL3JmYzcxNTkjc2VjdGlvbi00PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzAwNzBDMCI+DQogc2F5czo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48 c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgQW4gb2JqZWN0IHdob3NlIG5h bWVzIGFyZSBhbGwgdW5pcXVlIGlzIGludGVyb3BlcmFibGUgaW4gdGhlIHNlbnNlPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTiIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgdGhh dCBhbGwgc29mdHdhcmUgaW1wbGVtZW50YXRpb25zIHJlY2VpdmluZyB0aGF0IG9iamVjdCB3aWxs IGFncmVlIG9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsgdGhlIG5hbWUtdmFsdWUgbWFwcGluZ3MuJm5ic3A7IFdoZW4gdGhlIG5h bWVzIHdpdGhpbiBhbiBvYmplY3QgYXJlIG5vdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHVuaXF1ZSwgdGhlIGJlaGF2aW9yIG9m IHNvZnR3YXJlIHRoYXQgcmVjZWl2ZXMgc3VjaCBhbiBvYmplY3QgaXM8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB1bnByZWRpY3Rh YmxlLiZuYnNwOyBNYW55IGltcGxlbWVudGF0aW9ucyByZXBvcnQgdGhlIGxhc3QgbmFtZS92YWx1 ZSBwYWlyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsmbmJzcDsgb25seS4mbmJzcDsgT3RoZXIgaW1wbGVtZW50YXRpb25zIHJlcG9ydCBhbiBl cnJvciBvciBmYWlsIHRvIHBhcnNlIHRoZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IG9iamVjdCwgYW5kIHNvbWUgaW1wbGVtZW50 YXRpb25zIHJlcG9ydCBhbGwgb2YgdGhlIG5hbWUvdmFsdWUgcGFpcnMsPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgaW5jbHVkaW5n IGR1cGxpY2F0ZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMwMDcwQzAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3MEMwIj5UaGlzIHRvcGljIGhh cyBiZWVuIGhlYXZpbHkgZGlzY3Vzc2VkIGJ5IHRoZSB3b3JraW5nIGdyb3VwLCBhbmQgd2hpbGUg dGhlIHNwZWNzIHVzZWQgdG8ganVzdCBzYXkgdGhhdCBvYmplY3RzIHdpdGggZHVwbGljYXRlIG1l bWJlciBuYW1lcyBNVVNUIGJlIHJlamVjdGVkLCB3b3JraW5nIGdyb3VwIG1lbWJlcnMsDQogaW5j bHVkaW5nIFRpbSBCcmF5ICh0aGUgZWRpdG9yIG9mIHRoZSBKU09OIHNwZWMpLCBwcmV2YWlsZWQg b24gdXMgdG8gd2Vha2VuIHRoaXMgc28gdGhhdCBwYXJzZXJzIHRoYXQgaW1wbGVtZW50IHRoZSBF Q01Bc2NyaXB0IGJlaGF2aW9yIG9mIHJldHVybmluZyBvbmx5IHRoZSBsYXN0IG1lbWJlciBuYW1l IG1heSBiZSBsZWdhbGx5IHVzZWQuJm5ic3A7IChUaGUgYXJndW1lbnQgd2FzIG1hZGUgdGhhdCB0 aGVyZSB3YXMgbW9yZSBzZWN1cml0eSBkb3duc2lkZQ0KIGluIGVmZmVjdGl2ZWx5IHJlcXVpcmlu ZyBwZW9wbGUgdG8gd3JpdGUgYW5kIGRlYnVnIHRoZWlyIG93biBzdHJpY3QgcGFyc2VycyB0aGFu IGluIHVzaW5nIGxheGVyLCBidXQgd2VsbC1zdXBwb3J0ZWQgYW5kIGRlYnVnZ2VkIHBhcnNlcnMu KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMDA3MEMwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwNzBDMCI+SG93ZXZlciwgd2UgYWxzbyBpbnRlbnRp b25hbGx5IHJlcXVpcmUgdGhhdCBwcm9kdWNlcnMgdXNlIG9ubHkgb25lIGluc3RhbmNlIG9mIGVh Y2ggbWVtYmVyIG5hbWUsIHNvIHRoYXQgbGVnYWxseSBwcm9kdWNlZCBvYmplY3RzIHdpbGwgbmV2 ZXIgZXhlcmNpc2UgdGhlIGFtYmlndWl0aWVzIHRoYXQgYXJlDQogcHJlc2VudCBpbiByZWFsIEpT T04gcGFyc2Vycy4mbmJzcDsgVGhhdCBzZWVtZWQgdG8gYmUgdGhlIG1vc3QgcHJhY3RpY2FsIHNv bHV0aW9uIHRvIHRoZSB3b3JraW5nIGdyb3VwLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTpDb3VyaWVyIj5bc25pcF08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3MEMwIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgVGhhbmtzIGFnYWluLCBTdGVwaGVuLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMw MDcwQzAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwNzBD MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpqb3NlIG1haWxpbmcg bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpqb3NlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ am9zZUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2pvc2UiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2pvc2U8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48 YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj48bzpwPjwvbzpwPjwv c3Bhbj48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iaG9l bnpiIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+LS0gPC9zcGFuPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4 OCI+QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij5LYXRobGVlbjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiciBjbGVhcj0iYWxsIj4N CjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5LYXRobGVlbjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4E1F6AAD24975D4BA5B16804296739439AEC00DBTK5EX14MBXC292r_-- From nobody Fri Sep 12 09:20:49 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76F651A6F81; Fri, 12 Sep 2014 09:20:42 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 DSN-TeVnsqf9; Fri, 12 Sep 2014 09:20:36 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0144.outbound.protection.outlook.com [207.46.100.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A2811A0704; Fri, 12 Sep 2014 09:20:34 -0700 (PDT) Received: from BN3PR0301CA0063.namprd03.prod.outlook.com (25.160.152.159) by BL2PR03MB605.namprd03.prod.outlook.com (10.255.109.39) with Microsoft SMTP Server (TLS) id 15.0.1029.13; Fri, 12 Sep 2014 16:20:32 +0000 Received: from BY2FFO11FD028.protection.gbl (2a01:111:f400:7c0c::190) by BN3PR0301CA0063.outlook.office365.com (2a01:111:e400:401e::31) with Microsoft SMTP Server (TLS) id 15.0.1029.13 via Frontend Transport; Fri, 12 Sep 2014 16:20:32 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD028.mail.protection.outlook.com (10.1.15.217) with Microsoft SMTP Server (TLS) id 15.0.1019.14 via Frontend Transport; Fri, 12 Sep 2014 16:20:32 +0000 Received: from TK5EX14MBXC292.redmond.corp.microsoft.com ([169.254.1.60]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.03.0195.002; Fri, 12 Sep 2014 16:20:17 +0000 From: Mike Jones To: Tim Bray Thread-Topic: [jose] JWK member names, was: SECDIR review of draft-ietf-jose-json-web-key-31 Thread-Index: AQHPzqIHj1de3PnVVUOZ99QaOQrAZJv9q2Yg Date: Fri, 12 Sep 2014 16:20:15 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439AEC0929@TK5EX14MBXC292.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739439AEC00DB@TK5EX14MBXC292.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439AEC0929TK5EX14MBXC292r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(438002)(24454002)(377454003)(189002)(43784003)(51444003)(199003)(15975445006)(87936001)(95666004)(92566001)(85306004)(2656002)(92726001)(230783001)(83072002)(85852003)(104016003)(6806004)(80022001)(85806002)(84676001)(83322001)(19580405001)(69596002)(44976005)(68736004)(20776003)(66066001)(19580395003)(15202345003)(19300405004)(71186001)(64706001)(106116001)(90102001)(4396001)(81342001)(110136001)(106466001)(81156004)(107046002)(74502001)(74662001)(16236675004)(33656002)(31966008)(19625215002)(26826002)(50986999)(76176999)(54356999)(99396002)(77096002)(512874002)(21056001)(81542001)(97736003)(86612001)(19617315012)(84326002)(86362001)(79102001)(77982001)(76482001)(46102001)(55846006); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB605; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0332AACBC3 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/claRRPzwgs-5WbQtxvnfgbxaL28 Cc: "jose-chairs@tools.ietf.org" , "secdir@ietf.org" , "draft-ietf-jose-json-web-key.all@tools.ietf.org" , Kathleen Moriarty , "jose@ietf.org" Subject: Re: [secdir] [jose] JWK member names, was: SECDIR review of draft-ietf-jose-json-web-key-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 16:20:42 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439AEC0929TK5EX14MBXC292r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB1bmRlcnN0YW5kIHRoYXQgdGhhdOKAmXMgYW4gaWRlYWwgbG9uZy10ZXJtIHNvbHV0aW9uLCBv bmNlIEktSlNPTiBwYXJzZXJzIGFyZSBjb21tb24vdWJpcXVpdG91cywgYnV0IEkgZG9u4oCZdCBl eHBlY3QgdGhhdCB0byBiZSB0aGUgY2FzZSBmb3IgYSBudW1iZXIgb2YgeWVhcnMgYW5kIHBlb3Bs ZSBhcmUgdXNpbmcgSk9TRSBub3cuICBUaW0sIHlvdSB3ZXJlIG9uZSBvZiB0aGUgcHJpbWFyeSBh ZHZvY2F0ZXMgZm9yIHRoZSBwb3NpdGlvbiB0aGF0IGltcGxlbWVudGVycyBuZWVkIHRvIGJlIGFi bGUgdG8gdXNlIEpTT04gcGFyc2VycyBhcyB0aGV5IGFjdHVhbGx5IGV4aXN0IOKAkyBoZW5jZSB0 aGUgY2hhbmdlIGZyb20gKDEpIHRvICgyKSBpbiBkcmFmdCAtMTIgaW4gSnVseSAyMDEzIGFmdGVy IGV4dGVuc2l2ZSB3b3JraW5nIGdyb3VwIGRpc2N1c3Npb24gb24gdGhlIHRvcGljLg0KDQpVbmxl c3MgeW914oCZdmUgY2hhbmdlZCB5b3VyIHR1bmUsIEkgZG91YnQgdGhhdCB5b3XigJlyZSBhY3R1 YWxseSBzYXlpbmcgdGhhdCB3ZSBzaG91bGQgbW92ZSBiYWNrIHRvICgxKSBub3csIHdoaWNoIHdv dWxkIG1lYW4gdGhhdCBwZW9wbGUgdXNpbmcgdG9kYXnigJlzIEpTT04gcGFyc2VycyB3b3VsZCBi ZSBub25jb25mb3JtYW50Pw0KDQpPbmNlIEktSlNPTiBpcyB1YmlxdWl0b3VzLCBJ4oCZZCBiZSBm aW5lIGRvaW5nIGJpcyB2ZXJzaW9ucyBvZiB0aGUgc3BlY3MgdG8gdGlnaHRlbiB0aGUgcmVxdWly ZW1lbnQgaW4gYSBmZXcgeWVhcnMuICBCdXQgdW50aWwgdGhlbiwga2VlcGluZyB0aGUgcmVxdWly ZW1lbnQgdGhhdCBwcm9kdWNlcnMgbXVzdCBub3QgdXNlIGR1cGxpY2F0ZSBtZW1iZXIgbmFtZXMg d291bGQgbWVhbiB0aGF0IGlmIHdlIGRvIHVwZGF0ZSB0byB1c2UgSS1KU09OIGluIHRoZSBmdXR1 cmUsIG5vdGhpbmcgd291bGQgdGhlbiBicmVhay4NCg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBUaW0g QnJheSBbbWFpbHRvOnRicmF5QHRleHR1YWxpdHkuY29tXQ0KU2VudDogRnJpZGF5LCBTZXB0ZW1i ZXIgMTIsIDIwMTQgODo1NSBBTQ0KVG86IE1pa2UgSm9uZXMNCkNjOiBLYXRobGVlbiBNb3JpYXJ0 eTsgam9zZUBpZXRmLm9yZzsgam9zZS1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IGRyYWZ0LWlldGYt am9zZS1qc29uLXdlYi1rZXkuYWxsQHRvb2xzLmlldGYub3JnOyBzZWNkaXJAaWV0Zi5vcmc7IFN0 ZXBoZW4gS2VudA0KU3ViamVjdDogUmU6IFtqb3NlXSBKV0sgbWVtYmVyIG5hbWVzLCB3YXM6IFNF Q0RJUiByZXZpZXcgb2YgZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWtleS0zMQ0KDQpJ4oCZbSBw cmV0dHkgc3VyZSB0aGF0IGF0IHNvbWUgcG9pbnQgYmVmb3JlIHRoZSBlbmQgb2YgdGhlIHllYXIg dGhlIElFVEYgd2lsbCBwdWJsaXNoIEktSlNPTiAoc2VlIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWlldGYtanNvbi1pLWpzb24vKSB3aGljaCBzaW1wbHkgc3BlY2lmaWVz IHRoYXQgdGhlcmUgTVVTVCBOT1QgYmUgZHVwZSBrZXlzLiAgRGVwZW5kaW5nIG9uIHRoZSB0aW1l ZnJhbWUsIHJlZmVycmluZyB0byB0aGlzIG1pZ2h0IGJlIGEgZ29vZCBzb2x1dGlvbi4NCg0KT24g RnJpLCBTZXAgMTIsIDIwMTQgYXQgODoxOCBBTSwgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0Bt aWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PiB3cm90ZToN ClN1cmUuICBIZXJl4oCZcyBhbiBhbmFseXNpcyBvZiB0aGUgcmVxdWlyZW1lbnRzIGFib3V0IGR1 cGxpY2F0ZSBtZW1iZXIgbmFtZXMuDQoNClRoZXJlIGNvdWxkIGJlIHR3byB2ZXJ5IGRpZmZlcmVu dCBraW5kcyBvZiBvYmplY3Rpb25zIHRvIHRoZSBwcmVzZW50IHRleHQ6DQpBLiAgUGVvcGxlIHRo aW5rIHdlIGhhdmUgdGhlIHNlbWFudGljcyBmb3IgZHVwbGljYXRlIGlkZW50aWZpZXJzIHdyb25n Lg0KQi4gIFBlb3BsZSB0aGluayB3ZSBzaG91bGQgZXhwbGFpbiB0aGUgY3VycmVudCBzZW1hbnRp Y3MgZm9yIGR1cGxpY2F0ZSBpZGVudGlmaWVycyBtb3JlIGNsZWFybHkuDQoNCkkgc3VyZSBob3Bl IHRoYXQgd2XigJlyZSBkZWFsaW5nIHdpdGggQiBhbmQgbm90IEEuICBTdGVwaGVuLCB3aGljaCBp cyB0aGUgbmF0dXJlIG9mIHlvdXIgY3JpdGlxdWUgb2YgdGhpcyB0ZXh0Pw0KDQpJZiB3ZeKAmXJl IGluIHRoZSByZWFsbSBvZiBBLCBJIHRoaW5rIHRoZXJlIGFyZSB0aHJlZSBwb3NzaWJpbGl0aWVz IGZvciB0aGUgc2VtYW50aWNzOg0KDQoxLiAgUmVxdWlyZSBwcm9kdWNlcnMgbm90IHVzZSBkdXBs aWNhdGUgbWVtYmVycyBhbmQgcmVxdWlyZSBjb25zdW1lcnMgdG8gcmVqZWN0IGlucHV0cyB3aXRo IGR1cGxpY2F0ZSBtZW1iZXIgbmFtZXMuDQpQcm9zOiAgVGhpcyBpcyB0aGUgbW9zdCBsb2NrZWQt ZG93biwgY29uc2lzdGVudCwgYW5kIGFsdGVybmF0aXZlLg0KQ29uczogIFJlYWwgSlNPTiBwYXJz ZXJzIGRvbuKAmXQgYWxsIHJlamVjdCBkdXBsaWNhdGUgaW5wdXRzLiAgSWYgd2UgZm9yY2UgcGVv cGxlIHRvIHdyaXRlIGN1c3RvbSBwYXJzZXJzLCB0aGlzIHdpbGwgcmVzdWx0IGluIGV4cGxvaXRh YmxlIGJ1Z3MgKGFuZCBzb21lIGp1c3Qgd29u4oCZdCBkbyBpdCBhbmQgd29u4oCZdCBiZSBjb25m b3JtYW50KS4NCg0KMi4gIFJlcXVpcmUgcHJvZHVjZXJzIG5vdCB0byB1c2UgZHVwbGljYXRlIG1l bWJlcnMgYnV0IGFsbG93IGNvbnN1bWVycyB0byBhY2NlcHQgaW5wdXRzIHdpdGggZHVwbGljYXRl IG1lbWJlciBuYW1lcyBpbiB0aGUgbWFubmVyIGRlZmluZWQgaW4gRUNNQXNjcmlwdC4gIChUaGlz IGlzIHRoZSBjdXJyZW50IGNob2ljZS4pDQpQcm9zOiAgUGVvcGxlIGNhbiB1c2UgYWxsIHN0YW5k YXJkIEpTT04gcGFyc2Vycy4gIFByb2R1Y2VycyBhcmUgc3RpbGwgcmVxdWlyZWQgdG8gcHJvZHVj ZSB3ZWxsLWZvcm1lZCBkYXRhIHN0cnVjdHVyZXMuDQpDb25zOiAgVGhlIHJlcXVpcmVtZW50cyBv biBwcm9kdWNlcnMgYXJlIHN0cmljdGVyIHRoYW4gdGhvc2Ugb24gY29uc3VtZXJzLg0KDQozLiAg QWxsb3cgYm90aCBwcm9kdWNlcnMgYW5kIGNvbnN1bWVycyB0byB1c2UgZHVwbGljYXRlIG1lbWJl cnMsIHdpdGggZHVwbGljYXRlIG1lbWJlciBuYW1lcyBoYW5kbGVkIGluIHRoZSBtYW5uZXIgZGVm aW5lZCBpbiBFQ01Bc2NyaXB0Lg0KUHJvczogIFBlb3BsZSBjYW4gdXNlIEVDTUFzY3JpcHQgcGFy c2VycyAod2hpY2ggYXJlIG1vcmUgbGliZXJhbCB0aGFuIHNvbWUgSlNPTiBwYXJzZXJzKS4gIFRo ZSByZXF1aXJlbWVudHMgb24gcHJvZHVjZXJzIGFuZCBjb25zdW1lcnMgYXJlIHRoZSBzYW1lLg0K Q29uczogIEhpZGRlbiBjb250ZW50IGNhbiBiZSBpbnNlcnRlZCBpbnRvIGR1cGxpY2F0ZSBtZW1i ZXIgbmFtZXMuICBUaGlzIGNvdWxkIGdpdmUgYXR0YWNrZXJzIGEgd2F5IHRvIG1hbmlwdWxhdGUg dGhlIGlucHV0cyB0byBjcnlwdG8gb3BlcmF0aW9ucy4gIFN0cmljdCBKU09OIHBhcnNlcnMgKHRo YXQgcmVqZWN0IGlucHV0cyB3aXRoIGR1cGxpY2F0ZSBtZW1iZXJzKSBjYW7igJl0IGJlIHVzZWQu DQoNClByYWN0aWNhbGx5LCBJIHRoaW5rIHdlcmUgd2UgcHJlc2VudGx5IGFyZSAoMikgaXMgdGhl IGJlc3QgY29tcHJvbWlzZSBiZXR3ZWVuIGltcGxlbWVudGFiaWxpdHksIGNvbnNpc3RlbmN5LCBh bmQgc2VjdXJpdHkuICBUaGUgd29ya2luZyBncm91cCBwdXQgYSBsb3Qgb2YgZGlzY3Vzc2lvbiBp bnRvIHRoaXMsIGluY2x1ZGluZyBjaGFuZ2luZyBmcm9tICgxKSB0byAoMikgYW5kIGl04oCZcyBt eSBzZW5zZSB0aGF0IG1vc3QgYWdyZWUgd2XigJl2ZSBsYW5kZWQgaW4gdGhlIHJpZ2h0IHBsYWNl LiAgRnJvbSBhIHNlY3VyaXR5IHBlcnNwZWN0aXZlLCBJIGRvbuKAmXQgdGhpbmsgdGhhdCAoMykg aXMgYSB2aWFibGUgb3B0aW9uLg0KDQpJZiBwZW9wbGUgdGhpbmsgdGhhdCB0aGUgY3VycmVudCBz ZW1hbnRpY3MgYXJlIHJpZ2h0IGJ1dCBhcmUgbm90IHN1ZmZpY2llbnRseSBjbGVhcmx5IGV4cGxh aW5lZCBvciBtb3RpdmF0ZWQsIEnigJlkIGNlcnRhaW5seSB3ZWxjb21lIHByb3Bvc2VkIHRleHQg dG8gY2xhcmlmeSB0aGUgZXhwbGFuYXRpb24uDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogS2F0aGxl ZW4gTW9yaWFydHkgW21haWx0bzprYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbTxtYWls dG86a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb20+XQ0KU2VudDogRnJpZGF5LCBTZXB0 ZW1iZXIgMTIsIDIwMTQgNTowMCBBTQ0KVG86IGpvc2VAaWV0Zi5vcmc8bWFpbHRvOmpvc2VAaWV0 Zi5vcmc+OyBqb3NlLWNoYWlyc0B0b29scy5pZXRmLm9yZzxtYWlsdG86am9zZS1jaGFpcnNAdG9v bHMuaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLWpvc2UtanNvbi13ZWIta2V5LmFsbEB0b29scy5pZXRm Lm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWtleS5hbGxAdG9vbHMuaWV0Zi5v cmc+OyBzZWNkaXJAaWV0Zi5vcmc8bWFpbHRvOnNlY2RpckBpZXRmLm9yZz47IFN0ZXBoZW4gS2Vu dDsgTWlrZSBKb25lcw0KU3ViamVjdDogSldLIG1lbWJlciBuYW1lcywgd2FzOiBbam9zZV0gU0VD RElSIHJldmlldyBvZiBkcmFmdC1pZXRmLWpvc2UtanNvbi13ZWIta2V5LTMxDQoNCkhpIE1pa2Us DQoNClRoZSB0ZXh0IFN0ZXZlIGNhbGxlZCBvdXQgYmVsb3cgaGFzIGJlZW4gdmVyeSBwcm9ibGVt YXRpYyBhcyB5b3Uga25vdy4gIENvdWxkIHlvdSBjYWxsIG91dCBzb21lIG9wdGlvbnMgaGVyZSBh cyB0aGUgbGFzdCB0aW1lIHRoaXMgY2FtZSB1cCwgd2UgZGlkbid0IHJlc29sdmUgaXQuICBUaGUg d29ya2luZyBncm91cCB3YXMgYXNrZWQgZm9yIHN1Z2dlc3Rpb25zLCBidXQgbm9uZSBjYW1lIHRo cm91Z2guICBJZiB5b3UgY291bGQgcHJvdmlkZSBzb21lIG9wdGlvbnMgYW5kIHRoZW4gaGF2ZSB0 aGUgd29ya2luZyBncm91cCB3ZWlnaCBpbiwgSSB0aGluayB0aGF0IHdvdWxkIGJlIGdvb2QuDQoN Ckkgc25pcHBlZCBhd2F5IHRoZSByZXN0IG9mIHRoZSByZXZpZXcgYW5kIGNoYW5nZWQgdGhlIHN1 YmplY3QgYXMgbm90IHRvIGdldCBpbiB0aGUgd2F5IG9mIHRoZSBjdXJyZW50IGRpYWxvZy4NCg0K VGhhbmtzLg0KDQpPbiBXZWQsIFNlcCAxMCwgMjAxNCBhdCA4OjU3IFBNLCBNaWtlIEpvbmVzIDxN aWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0 LmNvbT4+IHdyb3RlOg0KSGkgU3RlcGhlbi4gIFRoYW5rcyBmb3IgeW91ciBkZXRhaWxlZCBhbmQg dXNlZnVsIHJldmlldy4gIEnigJl2ZSBjY+KAmWVkIHRoZSB3b3JraW5nIGdyb3VwIGluIG15IHJl cGx5IHNvIHRoZXnigJlyZSBhd2FyZSBvZiB0aGUgY29udGVudHMgb2YgeW91ciByZXZpZXcuICBS ZXBsaWVzIGFyZSBpbmxpbmUgYmVsb3figKYNCg0KRnJvbTogU3RlcGhlbiBLZW50IFttYWlsdG86 a2VudEBiYm4uY29tXQ0KU2VudDogVHVlc2RheSwgU2VwdGVtYmVyIDAyLCAyMDE0IDE6MDkgUE0N ClRvOiBzZWNkaXJAaWV0Zi5vcmc8bWFpbHRvOnNlY2RpckBpZXRmLm9yZz47IE1pa2UgSm9uZXM7 IGpvc2UtY2hhaXJzQHRvb2xzLmlldGYub3JnPG1haWx0bzpqb3NlLWNoYWlyc0B0b29scy5pZXRm Lm9yZz47IE1vcmlhcnR5LCBLYXRobGVlbg0KU3ViamVjdDogU0VDRElSIHJldmlldyBvZiBkcmFm dC1pZXRmLWpvc2UtanNvbi13ZWIta2V5LTMxDQoNCltzbmlwXQ0KDQpUaGlzIHNlY3Rpb24gaW1w b3NlcyBhIHJhdGhlciB3aW1weSBjb25zdHJhaW50IG9uIHBhcmFtZXRlciBuYW1lczoNCg0KDQoN CiAgIFRoZSBtZW1iZXIgbmFtZXMgd2l0aGluIGEgSldLIE1VU1QgYmUgdW5pcXVlOyByZWNpcGll bnRzIE1VU1QgZWl0aGVyDQoNCiAgIHJlamVjdCBKV0tzIHdpdGggZHVwbGljYXRlIG1lbWJlciBu YW1lcyBvciB1c2UgYSBKU09OIHBhcnNlciB0aGF0DQoNCiAgIHJldHVybnMgb25seSB0aGUgbGV4 aWNhbGx5IGxhc3QgZHVwbGljYXRlIG1lbWJlciBuYW1lLCBhcyBzcGVjaWZpZWQNCg0KICAgaW4g U2VjdGlvbiAxNS4xMiAoVGhlIEpTT04gT2JqZWN0KSBvZiBFQ01BU2NyaXB0IDUuMSBbRUNNQVNj cmlwdF0uDQoNCg0KVGhpcyB0ZXh0IHNheXMgdGhhdCBtZW1iZXIgbmFtZXMgTVVTVCBiZSB1bmlx dWUsIGJ1dCBpZiB0aGV5IGFyZSBub3QsIHRoYXTigJlzIE9LIHRvbzsganVzdCB1c2UgdGhlIGxh c3QgaW5zdGFuY2Ugb2YgYSBtZW1iZXIgd2l0aCBhIGR1cGxpY2F0ZSBuYW1lLiBUaGlzIHNlZW1z IGxpa2UgYSB0ZXJyaWJsZSBkZXNpZ24gcHJpbmNpcGxlLiBJdCBpbXBvc2VzIHdoYXQgYXBwZWFy cyB0byBiZSBhIHJlcXVpcmVtZW50LCB0aGVuIHNheXMgaG93IHRvIGFjY29tbW9kYXRlIGRhdGEg c3RydWN0dXJlcyB0aGF0IGZhaWwgdG8gbWVldCB0aGUgcmVxdWlyZW1lbnQuIFRoaXMgd291bGQg c2VlbSB0byBlbmNvdXJhZ2Ugc2xvcHB5IGltcGxlbWVudGF0aW9ucyAoZm9yIEpXSyBnZW5lcmF0 aW9uKS4gSeKAmWQgbGlrZSB0byBzZWUgdGhlIHJhdGlvbmFsZSBmb3IgdGhpcy4NCg0KDQoNCg0K DQpVbmZvcnR1bmF0ZWx5LCB0aGUgaW50ZW50aW9uYWwgbGF4bmVzcyBpbiB0aGUgc3BlYyBpbiB0 aGlzIHJlZ2FyZCBpcyBhIHJlZmxlY3Rpb24gb2YgdGhlIHNlbWFudGljcyBvZiB0aGUgYWN0dWFs IEpTT04gc3BlY2lmaWNhdGlvbnMgYW5kIGltcGxlbWVudGF0aW9ucy4gIEZvciBpbnN0YW5jZSwg aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzE1OSNzZWN0aW9uLTQgc2F5czoNCg0KDQog ICBBbiBvYmplY3Qgd2hvc2UgbmFtZXMgYXJlIGFsbCB1bmlxdWUgaXMgaW50ZXJvcGVyYWJsZSBp biB0aGUgc2Vuc2UNCiAgIHRoYXQgYWxsIHNvZnR3YXJlIGltcGxlbWVudGF0aW9ucyByZWNlaXZp bmcgdGhhdCBvYmplY3Qgd2lsbCBhZ3JlZSBvbg0KICAgdGhlIG5hbWUtdmFsdWUgbWFwcGluZ3Mu ICBXaGVuIHRoZSBuYW1lcyB3aXRoaW4gYW4gb2JqZWN0IGFyZSBub3QNCiAgIHVuaXF1ZSwgdGhl IGJlaGF2aW9yIG9mIHNvZnR3YXJlIHRoYXQgcmVjZWl2ZXMgc3VjaCBhbiBvYmplY3QgaXMNCiAg IHVucHJlZGljdGFibGUuICBNYW55IGltcGxlbWVudGF0aW9ucyByZXBvcnQgdGhlIGxhc3QgbmFt ZS92YWx1ZSBwYWlyDQogICBvbmx5LiAgT3RoZXIgaW1wbGVtZW50YXRpb25zIHJlcG9ydCBhbiBl cnJvciBvciBmYWlsIHRvIHBhcnNlIHRoZQ0KICAgb2JqZWN0LCBhbmQgc29tZSBpbXBsZW1lbnRh dGlvbnMgcmVwb3J0IGFsbCBvZiB0aGUgbmFtZS92YWx1ZSBwYWlycywNCiAgIGluY2x1ZGluZyBk dXBsaWNhdGVzLg0KDQoNCg0KVGhpcyB0b3BpYyBoYXMgYmVlbiBoZWF2aWx5IGRpc2N1c3NlZCBi eSB0aGUgd29ya2luZyBncm91cCwgYW5kIHdoaWxlIHRoZSBzcGVjcyB1c2VkIHRvIGp1c3Qgc2F5 IHRoYXQgb2JqZWN0cyB3aXRoIGR1cGxpY2F0ZSBtZW1iZXIgbmFtZXMgTVVTVCBiZSByZWplY3Rl ZCwgd29ya2luZyBncm91cCBtZW1iZXJzLCBpbmNsdWRpbmcgVGltIEJyYXkgKHRoZSBlZGl0b3Ig b2YgdGhlIEpTT04gc3BlYyksIHByZXZhaWxlZCBvbiB1cyB0byB3ZWFrZW4gdGhpcyBzbyB0aGF0 IHBhcnNlcnMgdGhhdCBpbXBsZW1lbnQgdGhlIEVDTUFzY3JpcHQgYmVoYXZpb3Igb2YgcmV0dXJu aW5nIG9ubHkgdGhlIGxhc3QgbWVtYmVyIG5hbWUgbWF5IGJlIGxlZ2FsbHkgdXNlZC4gIChUaGUg YXJndW1lbnQgd2FzIG1hZGUgdGhhdCB0aGVyZSB3YXMgbW9yZSBzZWN1cml0eSBkb3duc2lkZSBp biBlZmZlY3RpdmVseSByZXF1aXJpbmcgcGVvcGxlIHRvIHdyaXRlIGFuZCBkZWJ1ZyB0aGVpciBv d24gc3RyaWN0IHBhcnNlcnMgdGhhbiBpbiB1c2luZyBsYXhlciwgYnV0IHdlbGwtc3VwcG9ydGVk IGFuZCBkZWJ1Z2dlZCBwYXJzZXJzLikNCg0KDQoNCkhvd2V2ZXIsIHdlIGFsc28gaW50ZW50aW9u YWxseSByZXF1aXJlIHRoYXQgcHJvZHVjZXJzIHVzZSBvbmx5IG9uZSBpbnN0YW5jZSBvZiBlYWNo IG1lbWJlciBuYW1lLCBzbyB0aGF0IGxlZ2FsbHkgcHJvZHVjZWQgb2JqZWN0cyB3aWxsIG5ldmVy IGV4ZXJjaXNlIHRoZSBhbWJpZ3VpdGllcyB0aGF0IGFyZSBwcmVzZW50IGluIHJlYWwgSlNPTiBw YXJzZXJzLiAgVGhhdCBzZWVtZWQgdG8gYmUgdGhlIG1vc3QgcHJhY3RpY2FsIHNvbHV0aW9uIHRv IHRoZSB3b3JraW5nIGdyb3VwLg0KDQoNCltzbmlwXQ0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVGhhbmtzIGFnYWluLCBTdGVwaGVu LA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgLS0gTWlrZQ0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpqb3NlIG1haWxpbmcgbGlzdA0Kam9zZUBpZXRmLm9yZzxtYWlsdG86am9zZUBp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vam9zZQ0KDQoN Cg0KLS0NCg0KQmVzdCByZWdhcmRzLA0KS2F0aGxlZW4NCg0KDQoNCi0tDQoNCkJlc3QgcmVnYXJk cywNCkthdGhsZWVuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpqb3NlIG1haWxpbmcgbGlzdA0Kam9zZUBpZXRmLm9yZzxtYWlsdG86am9zZUBpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vam9zZQ0KDQoNCg0K LS0NCi0gVGltIEJyYXkgKElmIHlvdeKAmWQgbGlrZSB0byBzZW5kIG1lIGEgcHJpdmF0ZSBtZXNz YWdlLCBzZWUgaHR0cHM6Ly9rZXliYXNlLmlvL3RpbWJyYXkpDQo= --_000_4E1F6AAD24975D4BA5B16804296739439AEC0929TK5EX14MBXC292r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIgMiA1IDIgNCA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIg NCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToy IDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K cA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJ bWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4t bGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRh dGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRl eHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVt YWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29u VGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1m YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB1bmRlcnN0YW5k IHRoYXQgdGhhdOKAmXMgYW4gaWRlYWwgbG9uZy10ZXJtIHNvbHV0aW9uLCBvbmNlIEktSlNPTiBw YXJzZXJzIGFyZSBjb21tb24vdWJpcXVpdG91cywgYnV0IEkgZG9u4oCZdCBleHBlY3QgdGhhdCB0 byBiZSB0aGUgY2FzZSBmb3IgYSBudW1iZXIgb2YgeWVhcnMNCiBhbmQgcGVvcGxlIGFyZSB1c2lu ZyBKT1NFIG5vdy4mbmJzcDsgVGltLCB5b3Ugd2VyZSBvbmUgb2YgdGhlIHByaW1hcnkgYWR2b2Nh dGVzIGZvciB0aGUgcG9zaXRpb24gdGhhdCBpbXBsZW1lbnRlcnMgbmVlZCB0byBiZSBhYmxlIHRv IHVzZSBKU09OIHBhcnNlcnMgYXMgdGhleSBhY3R1YWxseSBleGlzdCDigJMgaGVuY2UgdGhlIGNo YW5nZSBmcm9tICgxKSB0byAoMikgaW4gZHJhZnQgLTEyIGluIEp1bHkgMjAxMyBhZnRlciBleHRl bnNpdmUgd29ya2luZyBncm91cA0KIGRpc2N1c3Npb24gb24gdGhlIHRvcGljLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ VW5sZXNzIHlvdeKAmXZlIGNoYW5nZWQgeW91ciB0dW5lLCBJIGRvdWJ0IHRoYXQgeW914oCZcmUg YWN0dWFsbHkgc2F5aW5nIHRoYXQgd2Ugc2hvdWxkIG1vdmUgYmFjayB0byAoMSkgbm93LCB3aGlj aCB3b3VsZCBtZWFuIHRoYXQgcGVvcGxlIHVzaW5nIHRvZGF54oCZcyBKU09OIHBhcnNlcnMNCiB3 b3VsZCBiZSBub25jb25mb3JtYW50PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T25jZSBJLUpTT04gaXMgdWJpcXVpdG91 cywgSeKAmWQgYmUgZmluZSBkb2luZyBiaXMgdmVyc2lvbnMgb2YgdGhlIHNwZWNzIHRvIHRpZ2h0 ZW4gdGhlIHJlcXVpcmVtZW50IGluIGEgZmV3IHllYXJzLiZuYnNwOyBCdXQgdW50aWwgdGhlbiwg a2VlcGluZyB0aGUgcmVxdWlyZW1lbnQgdGhhdA0KIHByb2R1Y2VycyBtdXN0IG5vdCB1c2UgZHVw bGljYXRlIG1lbWJlciBuYW1lcyB3b3VsZCBtZWFuIHRoYXQgaWYgd2UgZG8gdXBkYXRlIHRvIHVz ZSBJLUpTT04gaW4gdGhlIGZ1dHVyZSwgbm90aGluZyB3b3VsZCB0aGVuIGJyZWFrLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+IFRpbSBCcmF5IFttYWlsdG86dGJyYXlAdGV4dHVhbGl0eS5jb21dDQo8YnI+DQo8 Yj5TZW50OjwvYj4gRnJpZGF5LCBTZXB0ZW1iZXIgMTIsIDIwMTQgODo1NSBBTTxicj4NCjxiPlRv OjwvYj4gTWlrZSBKb25lczxicj4NCjxiPkNjOjwvYj4gS2F0aGxlZW4gTW9yaWFydHk7IGpvc2VA aWV0Zi5vcmc7IGpvc2UtY2hhaXJzQHRvb2xzLmlldGYub3JnOyBkcmFmdC1pZXRmLWpvc2UtanNv bi13ZWIta2V5LmFsbEB0b29scy5pZXRmLm9yZzsgc2VjZGlyQGlldGYub3JnOyBTdGVwaGVuIEtl bnQ8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtqb3NlXSBKV0sgbWVtYmVyIG5hbWVzLCB3YXM6 IFNFQ0RJUiByZXZpZXcgb2YgZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWtleS0zMTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J4oCZbSBwcmV0dHkgc3VyZSB0 aGF0IGF0IHNvbWUgcG9pbnQgYmVmb3JlIHRoZSBlbmQgb2YgdGhlIHllYXIgdGhlIElFVEYgd2ls bCBwdWJsaXNoIEktSlNPTiAoc2VlJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1qc29uLWktanNvbi8iPmh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtanNvbi1pLWpzb24vPC9hPikgd2hpY2ggc2ltcGx5DQog c3BlY2lmaWVzIHRoYXQgdGhlcmUgTVVTVCBOT1QgYmUgZHVwZSBrZXlzLiAmbmJzcDtEZXBlbmRp bmcgb24gdGhlIHRpbWVmcmFtZSwgcmVmZXJyaW5nIHRvIHRoaXMgbWlnaHQgYmUgYSBnb29kIHNv bHV0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBGcmksIFNlcCAxMiwgMjAxNCBhdCA4OjE4IEFNLCBNaWtlIEpvbmVzICZsdDs8YSBo cmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+ TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlN1cmUuJm5ic3A7IEhlcmXigJlzIGFuIGFuYWx5c2lz IG9mIHRoZSByZXF1aXJlbWVudHMgYWJvdXQgZHVwbGljYXRlIG1lbWJlciBuYW1lcy48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5UaGVyZSBjb3VsZCBiZSB0d28gdmVyeSBkaWZmZXJlbnQga2luZHMgb2Ygb2JqZWN0 aW9ucyB0byB0aGUgcHJlc2VudCB0ZXh0Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkEuJm5ic3A7IFBlb3BsZSB0aGluayB3ZSBoYXZlIHRoZSBzZW1hbnRpY3MgZm9yIGR1cGxpY2F0 ZSBpZGVudGlmaWVycyB3cm9uZy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CLiZu YnNwOyBQZW9wbGUgdGhpbmsgd2Ugc2hvdWxkIGV4cGxhaW4gdGhlIGN1cnJlbnQgc2VtYW50aWNz IGZvciBkdXBsaWNhdGUgaWRlbnRpZmllcnMgbW9yZSBjbGVhcmx5Ljwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkg c3VyZSBob3BlIHRoYXQgd2XigJlyZSBkZWFsaW5nIHdpdGggQiBhbmQgbm90IEEuJm5ic3A7IFN0 ZXBoZW4sIHdoaWNoIGlzIHRoZSBuYXR1cmUgb2YgeW91ciBjcml0aXF1ZSBvZg0KIHRoaXMgdGV4 dD88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5JZiB3ZeKAmXJlIGluIHRoZSByZWFsbSBvZiBBLCBJIHRoaW5rIHRo ZXJlIGFyZSB0aHJlZSBwb3NzaWJpbGl0aWVzIGZvciB0aGUgc2VtYW50aWNzOjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjEuJm5ic3A7IFJlcXVpcmUgcHJvZHVjZXJzIG5vdCB1c2UgZHVwbGljYXRlIG1lbWJlcnMg YW5kIHJlcXVpcmUgY29uc3VtZXJzIHRvIHJlamVjdCBpbnB1dHMgd2l0aCBkdXBsaWNhdGUNCiBt ZW1iZXIgbmFtZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UHJvczombmJzcDsg VGhpcyBpcyB0aGUgbW9zdCBsb2NrZWQtZG93biwgY29uc2lzdGVudCwgYW5kIGFsdGVybmF0aXZl Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNvbnM6Jm5ic3A7IFJlYWwgSlNPTiBw YXJzZXJzIGRvbuKAmXQgYWxsIHJlamVjdCBkdXBsaWNhdGUgaW5wdXRzLiZuYnNwOyBJZiB3ZSBm b3JjZSBwZW9wbGUgdG8gd3JpdGUgY3VzdG9tIHBhcnNlcnMsDQogdGhpcyB3aWxsIHJlc3VsdCBp biBleHBsb2l0YWJsZSBidWdzIChhbmQgc29tZSBqdXN0IHdvbuKAmXQgZG8gaXQgYW5kIHdvbuKA mXQgYmUgY29uZm9ybWFudCkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Mi4mbmJzcDsgUmVxdWlyZSBwcm9kdWNl cnMgbm90IHRvIHVzZSBkdXBsaWNhdGUgbWVtYmVycyBidXQgYWxsb3cgY29uc3VtZXJzIHRvIGFj Y2VwdCBpbnB1dHMgd2l0aCBkdXBsaWNhdGUNCiBtZW1iZXIgbmFtZXMgaW4gdGhlIG1hbm5lciBk ZWZpbmVkIGluIEVDTUFzY3JpcHQuJm5ic3A7IChUaGlzIGlzIHRoZSBjdXJyZW50IGNob2ljZS4p PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UHJvczombmJzcDsgUGVvcGxlIGNhbiB1 c2UgYWxsIHN0YW5kYXJkIEpTT04gcGFyc2Vycy4mbmJzcDsgUHJvZHVjZXJzIGFyZSBzdGlsbCBy ZXF1aXJlZCB0byBwcm9kdWNlIHdlbGwtZm9ybWVkDQogZGF0YSBzdHJ1Y3R1cmVzLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNvbnM6Jm5ic3A7IFRoZSByZXF1aXJlbWVudHMgb24g cHJvZHVjZXJzIGFyZSBzdHJpY3RlciB0aGFuIHRob3NlIG9uIGNvbnN1bWVycy48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4zLiZuYnNwOyBBbGxvdyBib3RoIHByb2R1Y2VycyBhbmQgY29uc3VtZXJzIHRvIHVzZSBk dXBsaWNhdGUgbWVtYmVycywgd2l0aCBkdXBsaWNhdGUgbWVtYmVyIG5hbWVzIGhhbmRsZWQNCiBp biB0aGUgbWFubmVyIGRlZmluZWQgaW4gRUNNQXNjcmlwdC48L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5Qcm9zOiZuYnNwOyBQZW9wbGUgY2FuIHVzZSBFQ01Bc2NyaXB0IHBhcnNlcnMg KHdoaWNoIGFyZSBtb3JlIGxpYmVyYWwgdGhhbiBzb21lIEpTT04gcGFyc2VycykuJm5ic3A7IFRo ZSByZXF1aXJlbWVudHMNCiBvbiBwcm9kdWNlcnMgYW5kIGNvbnN1bWVycyBhcmUgdGhlIHNhbWUu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q29uczombmJzcDsgSGlkZGVuIGNvbnRl bnQgY2FuIGJlIGluc2VydGVkIGludG8gZHVwbGljYXRlIG1lbWJlciBuYW1lcy4mbmJzcDsgVGhp cyBjb3VsZCBnaXZlIGF0dGFja2VycyBhIHdheQ0KIHRvIG1hbmlwdWxhdGUgdGhlIGlucHV0cyB0 byBjcnlwdG8gb3BlcmF0aW9ucy4mbmJzcDsgU3RyaWN0IEpTT04gcGFyc2VycyAodGhhdCByZWpl Y3QgaW5wdXRzIHdpdGggZHVwbGljYXRlIG1lbWJlcnMpIGNhbuKAmXQgYmUgdXNlZC48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5QcmFjdGljYWxseSwgSSB0aGluayB3ZXJlIHdlIHByZXNlbnRseSBhcmUgKDIpIGlz IHRoZSBiZXN0IGNvbXByb21pc2UgYmV0d2VlbiBpbXBsZW1lbnRhYmlsaXR5LCBjb25zaXN0ZW5j eSwNCiBhbmQgc2VjdXJpdHkuJm5ic3A7IFRoZSB3b3JraW5nIGdyb3VwIHB1dCBhIGxvdCBvZiBk aXNjdXNzaW9uIGludG8gdGhpcywgaW5jbHVkaW5nIGNoYW5naW5nIGZyb20gKDEpIHRvICgyKSBh bmQgaXTigJlzIG15IHNlbnNlIHRoYXQgbW9zdCBhZ3JlZSB3ZeKAmXZlIGxhbmRlZCBpbiB0aGUg cmlnaHQgcGxhY2UuJm5ic3A7IEZyb20gYSBzZWN1cml0eSBwZXJzcGVjdGl2ZSwgSSBkb27igJl0 IHRoaW5rIHRoYXQgKDMpIGlzIGEgdmlhYmxlIG9wdGlvbi48L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JZiBwZW9w bGUgdGhpbmsgdGhhdCB0aGUgY3VycmVudCBzZW1hbnRpY3MgYXJlIHJpZ2h0IGJ1dCBhcmUgbm90 IHN1ZmZpY2llbnRseSBjbGVhcmx5IGV4cGxhaW5lZCBvcg0KIG1vdGl2YXRlZCwgSeKAmWQgY2Vy dGFpbmx5IHdlbGNvbWUgcHJvcG9zZWQgdGV4dCB0byBjbGFyaWZ5IHRoZSBleHBsYW5hdGlvbi48 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEthdGhsZWVuIE1vcmlhcnR5IFttYWlsdG86PGEgaHJl Zj0ibWFpbHRvOmthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFu ayI+a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8 L2I+IEZyaWRheSwgU2VwdGVtYmVyIDEyLCAyMDE0IDU6MDAgQU08YnI+DQo8Yj5Ubzo8L2I+IDxh IGhyZWY9Im1haWx0bzpqb3NlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+am9zZUBpZXRmLm9y ZzwvYT47IDxhIGhyZWY9Im1haWx0bzpqb3NlLWNoYWlyc0B0b29scy5pZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPg0Kam9zZS1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWls dG86ZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWtleS5hbGxAdG9vbHMuaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj4NCmRyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1rZXkuYWxsQHRvb2xzLmlldGYu b3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnNlY2RpckBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi Pg0Kc2VjZGlyQGlldGYub3JnPC9hPjsgU3RlcGhlbiBLZW50OyBNaWtlIEpvbmVzPGJyPg0KPGI+ U3ViamVjdDo8L2I+IEpXSyBtZW1iZXIgbmFtZXMsIHdhczogW2pvc2VdIFNFQ0RJUiByZXZpZXcg b2YgZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWtleS0zMTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhpIE1pa2UsPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIHRleHQgU3RldmUgY2FsbGVk IG91dCBiZWxvdyBoYXMgYmVlbiB2ZXJ5IHByb2JsZW1hdGljIGFzIHlvdSBrbm93LiAmbmJzcDtD b3VsZCB5b3UgY2FsbCBvdXQgc29tZSBvcHRpb25zIGhlcmUgYXMgdGhlIGxhc3QgdGltZSB0aGlz IGNhbWUgdXAsIHdlIGRpZG4ndCByZXNvbHZlIGl0LiAmbmJzcDtUaGUgd29ya2luZyBncm91cA0K IHdhcyBhc2tlZCBmb3Igc3VnZ2VzdGlvbnMsIGJ1dCBub25lIGNhbWUgdGhyb3VnaC4gJm5ic3A7 SWYgeW91IGNvdWxkIHByb3ZpZGUgc29tZSBvcHRpb25zIGFuZCB0aGVuIGhhdmUgdGhlIHdvcmtp bmcgZ3JvdXAgd2VpZ2ggaW4sIEkgdGhpbmsgdGhhdCB3b3VsZCBiZSBnb29kLiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBz bmlwcGVkIGF3YXkgdGhlIHJlc3Qgb2YgdGhlIHJldmlldyBhbmQgY2hhbmdlZCB0aGUgc3ViamVj dCBhcyBub3QgdG8gZ2V0IGluIHRoZSB3YXkgb2YgdGhlIGN1cnJlbnQgZGlhbG9nLiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ VGhhbmtzLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBXZWQs IFNlcCAxMCwgMjAxNCBhdCA4OjU3IFBNLCBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86 TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5Kb25l c0BtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMwMDcwQzAiPkhpIFN0ZXBoZW4uJm5ic3A7IFRoYW5rcyBmb3IgeW91ciBkZXRhaWxlZCBh bmQgdXNlZnVsIHJldmlldy4mbmJzcDsgSeKAmXZlIGNj4oCZZWQgdGhlIHdvcmtpbmcgZ3JvdXAg aW4gbXkgcmVwbHkNCiBzbyB0aGV54oCZcmUgYXdhcmUgb2YgdGhlIGNvbnRlbnRzIG9mIHlvdXIg cmV2aWV3LiZuYnNwOyBSZXBsaWVzIGFyZSBpbmxpbmUgYmVsb3figKY8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMDA3MEMwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4gU3RlcGhlbiBLZW50IFs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmtlbnRAYmJuLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5tYWlsdG86a2Vu dEBiYm4uY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+XQ0KPGJyPg0K PGI+U2VudDo8L2I+IFR1ZXNkYXksIFNlcHRlbWJlciAwMiwgMjAxNCAxOjA5IFBNPGJyPg0KPGI+ VG86PC9iPiA8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnNlY2RpckBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5zZWNkaXJAaWV0Zi5vcmc8L3NwYW4+ PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij47IE1pa2UgSm9uZXM7DQo8L3NwYW4+PGEg aHJlZj0ibWFpbHRvOmpvc2UtY2hhaXJzQHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmpvc2UtY2hhaXJzQHRvb2xzLmlldGYub3JnPC9z cGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+OyBNb3JpYXJ0eSwgS2F0aGxlZW48 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gU0VDRElSIHJldmlldyBvZiBkcmFmdC1pZXRmLWpvc2UtanNv bi13ZWIta2V5LTMxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+W3NuaXBdJm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3Vy aWVyIj5UaGlzIHNlY3Rpb24gaW1wb3NlcyBhIHJhdGhlciB3aW1weSBjb25zdHJhaW50IG9uIHBh cmFtZXRlciBuYW1lczo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwPiZuYnNwOyZuYnNwOyBUaGUgbWVtYmVyIG5hbWVzIHdpdGhpbiBhIEpXSyBNVVNU IGJlIHVuaXF1ZTsgcmVjaXBpZW50cyBNVVNUIGVpdGhlcjxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5i c3A7Jm5ic3A7IHJlamVjdCBKV0tzIHdpdGggZHVwbGljYXRlIG1lbWJlciBuYW1lcyBvciB1c2Ug YSBKU09OIHBhcnNlciB0aGF0PG86cD48L286cD48L3A+DQo8cD4mbmJzcDsmbmJzcDsgcmV0dXJu cyBvbmx5IHRoZSBsZXhpY2FsbHkgbGFzdCBkdXBsaWNhdGUgbWVtYmVyIG5hbWUsIGFzIHNwZWNp ZmllZDxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7Jm5ic3A7IGluIFNlY3Rpb24gMTUuMTIgKFRo ZSBKU09OIE9iamVjdCkgb2YgRUNNQVNjcmlwdCA1LjEgW0VDTUFTY3JpcHRdLjxvOnA+PC9vOnA+ PC9wPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyIj5UaGlzIHRleHQgc2F5cyB0aGF0IG1lbWJl ciBuYW1lcyBNVVNUIGJlIHVuaXF1ZSwgYnV0IGlmIHRoZXkgYXJlIG5vdCwgdGhhdOKAmXMgT0sg dG9vOyBqdXN0IHVzZSB0aGUgbGFzdCBpbnN0YW5jZSBvZiBhIG1lbWJlciB3aXRoIGEgZHVwbGlj YXRlIG5hbWUuDQogVGhpcyBzZWVtcyBsaWtlIGEgdGVycmlibGUgZGVzaWduIHByaW5jaXBsZS4g SXQgaW1wb3NlcyB3aGF0IGFwcGVhcnMgdG8gYmUgYSByZXF1aXJlbWVudCwgdGhlbiBzYXlzIGhv dyB0byBhY2NvbW1vZGF0ZSBkYXRhIHN0cnVjdHVyZXMgdGhhdCBmYWlsIHRvIG1lZXQgdGhlIHJl cXVpcmVtZW50LiBUaGlzIHdvdWxkIHNlZW0gdG8gZW5jb3VyYWdlIHNsb3BweSBpbXBsZW1lbnRh dGlvbnMgKGZvciBKV0sgZ2VuZXJhdGlvbikuIEnigJlkIGxpa2UgdG8NCiBzZWUgdGhlIHJhdGlv bmFsZSBmb3IgdGhpcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9 ImNvbG9yOiMwMDcwQzAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3MEMwIj5VbmZvcnR1bmF0ZWx5LCB0aGUgaW50 ZW50aW9uYWwgbGF4bmVzcyBpbiB0aGUgc3BlYyBpbiB0aGlzIHJlZ2FyZCBpcyBhIHJlZmxlY3Rp b24gb2YgdGhlIHNlbWFudGljcyBvZiB0aGUgYWN0dWFsIEpTT04gc3BlY2lmaWNhdGlvbnMgYW5k IGltcGxlbWVudGF0aW9ucy4mbmJzcDsgRm9yIGluc3RhbmNlLA0KPC9zcGFuPjxhIGhyZWY9Imh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcxNTkjc2VjdGlvbi00IiB0YXJnZXQ9Il9ibGFu ayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9yZmM3MTU5I3NlY3Rpb24tNDwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMwMDcwQzAiPg0KIHNheXM6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4g c3R5bGU9ImNvbG9yOiMwMDcwQzAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IEFuIG9iamVjdCB3aG9zZSBuYW1lcyBh cmUgYWxsIHVuaXF1ZSBpcyBpbnRlcm9wZXJhYmxlIGluIHRoZSBzZW5zZTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHRoYXQgYWxs IHNvZnR3YXJlIGltcGxlbWVudGF0aW9ucyByZWNlaXZpbmcgdGhhdCBvYmplY3Qgd2lsbCBhZ3Jl ZSBvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7Jm5ic3A7IHRoZSBuYW1lLXZhbHVlIG1hcHBpbmdzLiZuYnNwOyBXaGVuIHRoZSBuYW1lcyB3 aXRoaW4gYW4gb2JqZWN0IGFyZSBub3Q8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB1bmlxdWUsIHRoZSBiZWhhdmlvciBvZiBzb2Z0 d2FyZSB0aGF0IHJlY2VpdmVzIHN1Y2ggYW4gb2JqZWN0IGlzPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgdW5wcmVkaWN0YWJsZS4m bmJzcDsgTWFueSBpbXBsZW1lbnRhdGlvbnMgcmVwb3J0IHRoZSBsYXN0IG5hbWUvdmFsdWUgcGFp cjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 Jm5ic3A7IG9ubHkuJm5ic3A7IE90aGVyIGltcGxlbWVudGF0aW9ucyByZXBvcnQgYW4gZXJyb3Ig b3IgZmFpbCB0byBwYXJzZSB0aGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBvYmplY3QsIGFuZCBzb21lIGltcGxlbWVudGF0aW9u cyByZXBvcnQgYWxsIG9mIHRoZSBuYW1lL3ZhbHVlIHBhaXJzLDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGluY2x1ZGluZyBkdXBs aWNhdGVzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMDA3MEMwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwNzBDMCI+VGhpcyB0b3BpYyBoYXMgYmVl biBoZWF2aWx5IGRpc2N1c3NlZCBieSB0aGUgd29ya2luZyBncm91cCwgYW5kIHdoaWxlIHRoZSBz cGVjcyB1c2VkIHRvIGp1c3Qgc2F5IHRoYXQgb2JqZWN0cyB3aXRoIGR1cGxpY2F0ZSBtZW1iZXIg bmFtZXMgTVVTVCBiZSByZWplY3RlZCwgd29ya2luZyBncm91cCBtZW1iZXJzLA0KIGluY2x1ZGlu ZyBUaW0gQnJheSAodGhlIGVkaXRvciBvZiB0aGUgSlNPTiBzcGVjKSwgcHJldmFpbGVkIG9uIHVz IHRvIHdlYWtlbiB0aGlzIHNvIHRoYXQgcGFyc2VycyB0aGF0IGltcGxlbWVudCB0aGUgRUNNQXNj cmlwdCBiZWhhdmlvciBvZiByZXR1cm5pbmcgb25seSB0aGUgbGFzdCBtZW1iZXIgbmFtZSBtYXkg YmUgbGVnYWxseSB1c2VkLiZuYnNwOyAoVGhlIGFyZ3VtZW50IHdhcyBtYWRlIHRoYXQgdGhlcmUg d2FzIG1vcmUgc2VjdXJpdHkgZG93bnNpZGUNCiBpbiBlZmZlY3RpdmVseSByZXF1aXJpbmcgcGVv cGxlIHRvIHdyaXRlIGFuZCBkZWJ1ZyB0aGVpciBvd24gc3RyaWN0IHBhcnNlcnMgdGhhbiBpbiB1 c2luZyBsYXhlciwgYnV0IHdlbGwtc3VwcG9ydGVkIGFuZCBkZWJ1Z2dlZCBwYXJzZXJzLik8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzAwNzBDMCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDcwQzAiPkhvd2V2ZXIsIHdlIGFsc28gaW50ZW50aW9uYWxs eSByZXF1aXJlIHRoYXQgcHJvZHVjZXJzIHVzZSBvbmx5IG9uZSBpbnN0YW5jZSBvZiBlYWNoIG1l bWJlciBuYW1lLCBzbyB0aGF0IGxlZ2FsbHkgcHJvZHVjZWQgb2JqZWN0cyB3aWxsIG5ldmVyIGV4 ZXJjaXNlIHRoZSBhbWJpZ3VpdGllcyB0aGF0IGFyZQ0KIHByZXNlbnQgaW4gcmVhbCBKU09OIHBh cnNlcnMuJm5ic3A7IFRoYXQgc2VlbWVkIHRvIGJlIHRoZSBtb3N0IHByYWN0aWNhbCBzb2x1dGlv biB0byB0aGUgd29ya2luZyBncm91cC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 Q291cmllciI+W3NuaXBdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwNzBDMCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IFRoYW5rcyBhZ2FpbiwgU3RlcGhlbiw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3MEMw Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgLS0gTWlrZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDcwQzAiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4w cHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0Kam9zZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86am9zZUBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPmpvc2VAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qb3NlIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qb3NlPC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJjb2xvcjojODg4ODg4Ij48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8L3NwYW4+PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6 Izg4ODg4OCI+LS0NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPkJlc3QgcmVnYXJkcyw8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJjb2xvcjojODg4ODg4Ij5LYXRobGVlbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4tLQ0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+S2F0aGxlZW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0Kam9zZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVm PSJtYWlsdG86am9zZUBpZXRmLm9yZyI+am9zZUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2pvc2UiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2pvc2U8L2E+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiciBjbGVhcj0iYWxs Ij4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBUaW0gQnJheSAoSWYg eW914oCZZCBsaWtlIHRvIHNlbmQgbWUgYSBwcml2YXRlIG1lc3NhZ2UsIHNlZSA8YSBocmVmPSJo dHRwczovL2tleWJhc2UuaW8vdGltYnJheSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9rZXli YXNlLmlvL3RpbWJyYXk8L2E+KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4E1F6AAD24975D4BA5B16804296739439AEC0929TK5EX14MBXC292r_-- From nobody Fri Sep 12 12:05:38 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E47D81A0382 for ; Fri, 12 Sep 2014 08:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 4EmKOWddJh7x for ; Fri, 12 Sep 2014 08:55:48 -0700 (PDT) Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65B901A02EF for ; Fri, 12 Sep 2014 08:55:48 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id ij19so878326vcb.40 for ; Fri, 12 Sep 2014 08:55:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=z3rTfKAw9o0ZH8RBKOM7K1sUcCgsDYOYQ0XTxEyO7EQ=; b=dNpWW55aEEmRwpNchJNR3LsaOehMuco4bsNZimSzbic56FV9KweJUC3mJQgSb9RlPO mENmw4kskWD0Inw2oGV0q8cr3208/6FeHPSNnULHZ4RzvUtlD+nngqR2Nea7KjVuRAx1 fpn8H22aISE5dBRlxCpJJ54YZJGYVG2KdpM4fUFkeOJ0LiEAiPBKhS6SyqaKUwYJWi+u TIdg8Treg05gkgabnaxDrmcBeZYC5KblOOMSUVidPmi1+AMXzINkpwUx5E4zipNtJbyC HmPDVZR7gA2acCk5AjmkDXO5XVLWnUu1H7PeXJ+3Vi67QR7ASuo/SC7Tq5EEw3UlexNh wqdw== X-Gm-Message-State: ALoCoQk/t5LKwjQdmb4E0dw/2VUHt6+wAeTZIy7lv7311xleNDerPxG76qImY2PhTdGkmlc2+WqS X-Received: by 10.220.17.145 with SMTP id s17mr2007124vca.77.1410537347312; Fri, 12 Sep 2014 08:55:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.214.4 with HTTP; Fri, 12 Sep 2014 08:55:27 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439AEC00DB@TK5EX14MBXC292.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739439AEC00DB@TK5EX14MBXC292.redmond.corp.microsoft.com> From: Tim Bray Date: Fri, 12 Sep 2014 08:55:27 -0700 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=001a11c3bfb28784c20502e051ac Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Z3Y-132Ey7jnngsT8rAFVqrKmvM X-Mailman-Approved-At: Fri, 12 Sep 2014 12:05:27 -0700 Cc: "jose-chairs@tools.ietf.org" , "secdir@ietf.org" , "draft-ietf-jose-json-web-key.all@tools.ietf.org" , Kathleen Moriarty , "jose@ietf.org" Subject: Re: [secdir] [jose] JWK member names, was: SECDIR review of draft-ietf-jose-json-web-key-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 15:55:52 -0000 --001a11c3bfb28784c20502e051ac Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I=E2=80=99m pretty sure that at some point before the end of the year the I= ETF will publish I-JSON (see https://datatracker.ietf.org/doc/draft-ietf-json-i-json= /) which simply specifies that there MUST NOT be dupe keys. Depending on the timeframe, referring to this might be a good solution. On Fri, Sep 12, 2014 at 8:18 AM, Mike Jones wrote: > Sure. Here=E2=80=99s an analysis of the requirements about duplicate me= mber > names. > > > > There could be two very different kinds of objections to the present text= : > > A. People think we have the semantics for duplicate identifiers wrong. > > B. People think we should explain the current semantics for duplicate > identifiers more clearly. > > > > I sure hope that we=E2=80=99re dealing with B and not A. Stephen, which = is the > nature of your critique of this text? > > > > If we=E2=80=99re in the realm of A, I think there are three possibilities= for the > semantics: > > > > 1. Require producers not use duplicate members and require consumers to > reject inputs with duplicate member names. > > Pros: This is the most locked-down, consistent, and alternative. > > Cons: Real JSON parsers don=E2=80=99t all reject duplicate inputs. If w= e force > people to write custom parsers, this will result in exploitable bugs (and > some just won=E2=80=99t do it and won=E2=80=99t be conformant). > > > > 2. Require producers not to use duplicate members but allow consumers to > accept inputs with duplicate member names in the manner defined in > ECMAscript. (This is the current choice.) > > Pros: People can use all standard JSON parsers. Producers are still > required to produce well-formed data structures. > > Cons: The requirements on producers are stricter than those on consumers= . > > > > 3. Allow both producers and consumers to use duplicate members, with > duplicate member names handled in the manner defined in ECMAscript. > > Pros: People can use ECMAscript parsers (which are more liberal than som= e > JSON parsers). The requirements on producers and consumers are the same. > > Cons: Hidden content can be inserted into duplicate member names. This > could give attackers a way to manipulate the inputs to crypto operations. > Strict JSON parsers (that reject inputs with duplicate members) can=E2=80= =99t be > used. > > > > Practically, I think were we presently are (2) is the best compromise > between implementability, consistency, and security. The working group p= ut > a lot of discussion into this, including changing from (1) to (2) and it= =E2=80=99s > my sense that most agree we=E2=80=99ve landed in the right place. From a= security > perspective, I don=E2=80=99t think that (3) is a viable option. > > > > If people think that the current semantics are right but are not > sufficiently clearly explained or motivated, I=E2=80=99d certainly welcom= e proposed > text to clarify the explanation. > > > > -- Mike > > > > *From:* Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] > *Sent:* Friday, September 12, 2014 5:00 AM > *To:* jose@ietf.org; jose-chairs@tools.ietf.org; > draft-ietf-jose-json-web-key.all@tools.ietf.org; secdir@ietf.org; Stephen > Kent; Mike Jones > *Subject:* JWK member names, was: [jose] SECDIR review of > draft-ietf-jose-json-web-key-31 > > > > Hi Mike, > > > > The text Steve called out below has been very problematic as you know. > Could you call out some options here as the last time this came up, we > didn't resolve it. The working group was asked for suggestions, but none > came through. If you could provide some options and then have the workin= g > group weigh in, I think that would be good. > > > > I snipped away the rest of the review and changed the subject as not to > get in the way of the current dialog. > > > > Thanks. > > > > On Wed, Sep 10, 2014 at 8:57 PM, Mike Jones > wrote: > > Hi Stephen. Thanks for your detailed and useful review. I=E2=80=99ve cc= =E2=80=99ed the > working group in my reply so they=E2=80=99re aware of the contents of you= r review. > Replies are inline below=E2=80=A6 > > > > *From:* Stephen Kent [mailto:kent@bbn.com ] > *Sent:* Tuesday, September 02, 2014 1:09 PM > *To:* secdir@ietf.org; Mike Jones; jose-chairs@tools.ietf.org; Moriarty, > Kathleen > *Subject:* SECDIR review of draft-ietf-jose-json-web-key-31 > > > > [snip] > > > > This section imposes a rather wimpy constraint on parameter names: > > > > The member names within a JWK MUST be unique; recipients MUST either > > reject JWKs with duplicate member names or use a JSON parser that > > returns only the lexically last duplicate member name, as specified > > in Section 15.12 (The JSON Object) of ECMAScript 5.1 [ECMAScript]. > > > > This text says that member names MUST be unique, but if they are not, > that=E2=80=99s OK too; just use the last instance of a member with a dupl= icate > name. This seems like a terrible design principle. It imposes what appear= s > to be a requirement, then says how to accommodate data structures that fa= il > to meet the requirement. This would seem to encourage sloppy > implementations (for JWK generation). I=E2=80=99d like to see the rationa= le for > this. > > > > > > Unfortunately, the intentional laxness in the spec in this regard is a > reflection of the semantics of the actual JSON specifications and > implementations. For instance, > http://tools.ietf.org/html/rfc7159#section-4 says: > > > > An object whose names are all unique is interoperable in the sense > > that all software implementations receiving that object will agree on > > the name-value mappings. When the names within an object are not > > unique, the behavior of software that receives such an object is > > unpredictable. Many implementations report the last name/value pair > > only. Other implementations report an error or fail to parse the > > object, and some implementations report all of the name/value pairs, > > including duplicates. > > > > This topic has been heavily discussed by the working group, and while the > specs used to just say that objects with duplicate member names MUST be > rejected, working group members, including Tim Bray (the editor of the JS= ON > spec), prevailed on us to weaken this so that parsers that implement the > ECMAscript behavior of returning only the last member name may be legally > used. (The argument was made that there was more security downside in > effectively requiring people to write and debug their own strict parsers > than in using laxer, but well-supported and debugged parsers.) > > > > However, we also intentionally require that producers use only one > instance of each member name, so that legally produced objects will never > exercise the ambiguities that are present in real JSON parsers. That > seemed to be the most practical solution to the working group. > > > > [snip] > > Thanks again, > Stephen, > > -- Mike > > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > > > > > -- > > > > Best regards, > > Kathleen > > > > > > -- > > > > Best regards, > > Kathleen > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --001a11c3bfb28784c20502e051ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I= =E2=80=99m pretty sure that at some point before the end of the year the IE= TF will publish I-JSON (see=C2=A0https://datatracker.ietf.org/doc/draft-ietf-json= -i-json/) which simply specifies that there MUST NOT be dupe keys. =C2= =A0Depending on the timeframe, referring to this might be a good solution.<= /div>

On Fri= , Sep 12, 2014 at 8:18 AM, Mike Jones <Michael.Jones@microsoft.c= om> wrote:

Sure.=C2=A0 Here=E2=80=99= s an analysis of the requirements about duplicate member names.

=C2=A0

There could be two very d= ifferent kinds of objections to the present text:

A.=C2=A0 People think we = have the semantics for duplicate identifiers wrong.
B.=C2=A0 People think we = should explain the current semantics for duplicate identifiers more clearly= .

=C2=A0

I sure hope that we=E2=80= =99re dealing with B and not A.=C2=A0 Stephen, which is the nature of your = critique of this text?

=C2=A0

If we=E2=80=99re in the r= ealm of A, I think there are three possibilities for the semantics:<= u>

=C2=A0

1.=C2=A0 Require producer= s not use duplicate members and require consumers to reject inputs with dup= licate member names.

Pros:=C2=A0 This is the m= ost locked-down, consistent, and alternative.

Cons:=C2=A0 Real JSON par= sers don=E2=80=99t all reject duplicate inputs.=C2=A0 If we force people to= write custom parsers, this will result in exploitable bugs (and some just won=E2=80=99t do it and won=E2=80=99t be conformant).=

=C2=A0

2.=C2=A0 Require producer= s not to use duplicate members but allow consumers to accept inputs with du= plicate member names in the manner defined in ECMAscript.=C2=A0 (This is the current choice.)

Pros:=C2=A0 People can us= e all standard JSON parsers.=C2=A0 Producers are still required to produce = well-formed data structures.

Cons:=C2=A0 The requireme= nts on producers are stricter than those on consumers.=

=C2=A0

3.=C2=A0 Allow both produ= cers and consumers to use duplicate members, with duplicate member names ha= ndled in the manner defined in ECMAscript.

Pros:=C2=A0 People can us= e ECMAscript parsers (which are more liberal than some JSON parsers).=C2=A0= The requirements on producers and consumers are the same.

Cons:=C2=A0 Hidden conten= t can be inserted into duplicate member names.=C2=A0 This could give attack= ers a way to manipulate the inputs to crypto operations.=C2=A0 Strict JSON parsers (that reject inputs with duplicate members) can=E2=80=99t be used.=

=C2=A0

Practically, I think were= we presently are (2) is the best compromise between implementability, cons= istency, and security.=C2=A0 The working group put a lot of discussion into this, including changing from (1) to (2) and it=E2=80=99s my sense th= at most agree we=E2=80=99ve landed in the right place.=C2=A0 From a securit= y perspective, I don=E2=80=99t think that (3) is a viable option.=

=C2=A0

If people think that the = current semantics are right but are not sufficiently clearly explained or m= otivated, I=E2=80=99d certainly welcome proposed text to clarify the explanation.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike

=C2=A0

From: Kathleen= Moriarty [mailto:kathleen.moriarty.ietf@gmail.com]
Sent: Friday, September 12, 2014 5:00 AM
To: jose@ietf.org= ; jose-= chairs@tools.ietf.org; draft-ietf-jose-json-web-key.all@tools= .ietf.org; secdir@= ietf.org; Stephen Kent; Mike Jones
Subject: JWK member names, was: [jose] SECDIR review of draft-ietf-j= ose-json-web-key-31

=C2=A0

Hi Mike,

=C2=A0

The text Steve called out below has been very proble= matic as you know. =C2=A0Could you call out some options here as the last t= ime this came up, we didn't resolve it. =C2=A0The working group was ask= ed for suggestions, but none came through. =C2=A0If you could provide some options and then have the working group weigh in, I thi= nk that would be good.=C2=A0

=C2=A0

I snipped away the rest of the review and changed th= e subject as not to get in the way of the current dialog.=C2=A0

=C2=A0

Thanks.

=C2=A0

On Wed, Sep 10, 2014 at 8:57 PM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

Hi Stephen.=C2=A0 Thanks = for your detailed and useful review.=C2=A0 I=E2=80=99ve cc=E2=80=99ed the w= orking group in my reply so they=E2=80=99re aware of the contents of your review.=C2=A0 Replies are= inline below=E2=80=A6

=C2=A0

From: Stephen = Kent [mailto:kent@bbn.com]
Sent: Tuesday, September 02, 2014 1:09 PM
To: secdir@ietf.org; Mike Jones; jose-chairs@tools.ietf.org; Moriarty, Kathle= en
Subject: SECDIR review of draft-ietf-jose-json-web-key-31<= /u>

=C2=A0

[snip]=C2=A0

=C2=A0=C2=A0

This section imp= oses a rather wimpy constraint on parameter names:

=C2=A0

=C2=A0=C2=A0 The member names within a JWK MUST be unique; recipients MU= ST either

=C2=A0=C2=A0 reject JWKs with duplicate member names or use a JSON parse= r that

=C2=A0=C2=A0 returns only the lexically last duplicate member name, as s= pecified

=C2=A0=C2=A0 in Section 15.12 (The JSON Object) of ECMAScript 5.1 [ECMAS= cript].

=C2=A0

This text says t= hat member names MUST be unique, but if they are not, that=E2=80=99s OK too= ; just use the last instance of a member with a duplicate name. This seems like a terrible design principle. It imposes what appears to be= a requirement, then says how to accommodate data structures that fail to m= eet the requirement. This would seem to encourage sloppy implementations (f= or JWK generation). I=E2=80=99d like to see the rationale for this.

=C2=A0

=C2=A0

Unfortunately, the intentional laxness in the= spec in this regard is a reflection of the semantics of the actual JSON sp= ecifications and implementations.=C2=A0 For instance, http://tools.ietf.org/html/rfc7159#section-4= says:

=C2=A0

=C2=A0=C2=A0 An object whose names are all unique is interopera= ble in the sense

=C2=A0=C2=A0 that all software implementations receiving that o= bject will agree on

=C2=A0=C2=A0 the name-value mappings.=C2=A0 When the names with= in an object are not

=C2=A0=C2=A0 unique, the behavior of software that receives suc= h an object is

=C2=A0=C2=A0 unpredictable.=C2=A0 Many implementations report t= he last name/value pair

=C2=A0=C2=A0 only.=C2=A0 Other implementations report an error = or fail to parse the

=C2=A0=C2=A0 object, and some implementations report all of the= name/value pairs,

=C2=A0=C2=A0 including duplicates.

=C2=A0

This topic has been heavily discussed by the = working group, and while the specs used to just say that objects with dupli= cate member names MUST be rejected, working group members, including Tim Bray (the editor of the JSON spec), prevailed on us to weake= n this so that parsers that implement the ECMAscript behavior of returning = only the last member name may be legally used.=C2=A0 (The argument was made= that there was more security downside in effectively requiring people to write and debug their own strict parser= s than in using laxer, but well-supported and debugged parsers.)<= /u>

=C2=A0

However, we also intentionally require that p= roducers use only one instance of each member name, so that legally produce= d objects will never exercise the ambiguities that are present in real JSON parsers.=C2=A0 That seemed to be the most practical s= olution to the working group.

=C2=A0

[snip]=

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thanks again, Stephen,<= /p>
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike

=C2=A0

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

=C2=A0

--

=C2=A0

Best regards,

Kathleen=

=C2=A0

--

=C2=A0

Best regards,

Kathleen

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

- Tim Bray (If you=E2=80=99d like to send me a private messag= e, see https://key= base.io/timbray)

--001a11c3bfb28784c20502e051ac-- From nobody Fri Sep 12 12:05:45 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A381A797C for ; Fri, 12 Sep 2014 10:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 3X6U_JE10E8c for ; Fri, 12 Sep 2014 10:29:57 -0700 (PDT) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E97921A7D81 for ; Fri, 12 Sep 2014 10:29:52 -0700 (PDT) Received: by mail-vc0-f178.google.com with SMTP id hy4so1038347vcb.9 for ; Fri, 12 Sep 2014 10:29:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=4E43L8nXDzbbe0qG5YbNT7o5F0FxYgud5BDxwMzzZGI=; b=ZcGejXtHbBwThMhO15HRvw9yIaOurVKgLhohKTWXQIziQRlqjCOSadpHLNIVJRIlHP x0YexGLn3pZpRbiiO9kLUZ5wv9AEdZJXE2QTxCZrA3wGd0wViRTbLVoLCHyE1OmSTQ8w EBiXBd5NNA0YCGD5cIv+9ZSoZsAsSUAQicsgSBHI4LZzt4ZzS9Kc1K9qSq4/2iBnjizl ppJOBC8fS+YHJzuAoBbcuDS62yoF7IjTxr8EJMB92AnIoELq2ROPoEQCT+i1sk6naHBK vXSYwxjl8HaeQOggmEjTDT7Pj3gadd6N8w2qERr/MjFEW9ibJty5MG1rXvAGsgeyv5i1 AZSg== X-Gm-Message-State: ALoCoQnm9t6uI+sJR2l9ud5cQDVUgVI90bHD/BylJkwnRz3jn/K7ymQoy06H6R2Ey8H+SBtttD0D X-Received: by 10.220.77.65 with SMTP id f1mr4484726vck.48.1410542991593; Fri, 12 Sep 2014 10:29:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.214.4 with HTTP; Fri, 12 Sep 2014 10:29:30 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439AEC0929@TK5EX14MBXC292.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739439AEC00DB@TK5EX14MBXC292.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439AEC0929@TK5EX14MBXC292.redmond.corp.microsoft.com> From: Tim Bray Date: Fri, 12 Sep 2014 10:29:30 -0700 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=001a11c1e54af4bc930502e1a1fe Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/fqEdk99pMPV6qblhvlyH53lJdBo X-Mailman-Approved-At: Fri, 12 Sep 2014 12:05:28 -0700 Cc: "jose-chairs@tools.ietf.org" , "secdir@ietf.org" , "draft-ietf-jose-json-web-key.all@tools.ietf.org" , Kathleen Moriarty , "jose@ietf.org" Subject: Re: [secdir] [jose] JWK member names, was: SECDIR review of draft-ietf-jose-json-web-key-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 17:29:59 -0000 --001a11c1e54af4bc930502e1a1fe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Well, quoting from your option (2): =E2=80=9C2. Require producers not to use duplicate members =E2=80=9D Another way to express this would be to require that producers emit I-JSON. This would also have benefits such as forbidding malformed Unicode, forbidding dependency on object member ordering, and staying within the bounds of IEEE double precision. I agree that at this point in time, REQUIRING consumers to reject data with dupes is problematic, but as long as they=E2=80=99re allowed to do so, that means they can deploy I-JSON pars= ers when such things arrive. If the goal is to allow the use of off-the-shelf parsers, there=E2=80=99s r= eally not much you can say about what consumers should do about dupe keys, because the behavior of such parsers is inconsistent in practice. In any practical programming scenario, what the recipient wants is to take the JSON and stuff objects into hashes or dicts or whatever so they can pull out fields by name. They=E2=80=99d really rather avoid thinking about= dealing with malformed messages - and I claim that any message with dupe keys is malformed. The one way to be sure that consumers don=E2=80=99t have to dea= l with this crap is to require that producers don=E2=80=99t emit broken messages. = I-JSON messages have way less scope for breakage. On Fri, Sep 12, 2014 at 9:20 AM, Mike Jones wrote: > I understand that that=E2=80=99s an ideal long-term solution, once I-JSO= N > parsers are common/ubiquitous, but I don=E2=80=99t expect that to be the = case for a > number of years and people are using JOSE now. Tim, you were one of the > primary advocates for the position that implementers need to be able to u= se > JSON parsers as they actually exist =E2=80=93 hence the change from (1) t= o (2) in > draft -12 in July 2013 after extensive working group discussion on the > topic. > > > > Unless you=E2=80=99ve changed your tune, I doubt that you=E2=80=99re actu= ally saying that > we should move back to (1) now, which would mean that people using today= =E2=80=99s > JSON parsers would be nonconformant? > > > > Once I-JSON is ubiquitous, I=E2=80=99d be fine doing bis versions of the = specs to > tighten the requirement in a few years. But until then, keeping the > requirement that producers must not use duplicate member names would mean > that if we do update to use I-JSON in the future, nothing would then brea= k. > > > > -- Mike > > > > *From:* Tim Bray [mailto:tbray@textuality.com] > *Sent:* Friday, September 12, 2014 8:55 AM > *To:* Mike Jones > *Cc:* Kathleen Moriarty; jose@ietf.org; jose-chairs@tools.ietf.org; > draft-ietf-jose-json-web-key.all@tools.ietf.org; secdir@ietf.org; Stephen > Kent > *Subject:* Re: [jose] JWK member names, was: SECDIR review of > draft-ietf-jose-json-web-key-31 > > > > I=E2=80=99m pretty sure that at some point before the end of the year the= IETF > will publish I-JSON (see > https://datatracker.ietf.org/doc/draft-ietf-json-i-json/) which simply > specifies that there MUST NOT be dupe keys. Depending on the timeframe, > referring to this might be a good solution. > > > > On Fri, Sep 12, 2014 at 8:18 AM, Mike Jones > wrote: > > Sure. Here=E2=80=99s an analysis of the requirements about duplicate mem= ber names. > > > > There could be two very different kinds of objections to the present text= : > > A. People think we have the semantics for duplicate identifiers wrong. > > B. People think we should explain the current semantics for duplicate > identifiers more clearly. > > > > I sure hope that we=E2=80=99re dealing with B and not A. Stephen, which = is the > nature of your critique of this text? > > > > If we=E2=80=99re in the realm of A, I think there are three possibilities= for the > semantics: > > > > 1. Require producers not use duplicate members and require consumers to > reject inputs with duplicate member names. > > Pros: This is the most locked-down, consistent, and alternative. > > Cons: Real JSON parsers don=E2=80=99t all reject duplicate inputs. If w= e force > people to write custom parsers, this will result in exploitable bugs (and > some just won=E2=80=99t do it and won=E2=80=99t be conformant). > > > > 2. Require producers not to use duplicate members but allow consumers to > accept inputs with duplicate member names in the manner defined in > ECMAscript. (This is the current choice.) > > Pros: People can use all standard JSON parsers. Producers are still > required to produce well-formed data structures. > > Cons: The requirements on producers are stricter than those on consumers= . > > > > 3. Allow both producers and consumers to use duplicate members, with > duplicate member names handled in the manner defined in ECMAscript. > > Pros: People can use ECMAscript parsers (which are more liberal than som= e > JSON parsers). The requirements on producers and consumers are the same. > > Cons: Hidden content can be inserted into duplicate member names. This > could give attackers a way to manipulate the inputs to crypto operations. > Strict JSON parsers (that reject inputs with duplicate members) can=E2=80= =99t be > used. > > > > Practically, I think were we presently are (2) is the best compromise > between implementability, consistency, and security. The working group p= ut > a lot of discussion into this, including changing from (1) to (2) and it= =E2=80=99s > my sense that most agree we=E2=80=99ve landed in the right place. From a= security > perspective, I don=E2=80=99t think that (3) is a viable option. > > > > If people think that the current semantics are right but are not > sufficiently clearly explained or motivated, I=E2=80=99d certainly welcom= e proposed > text to clarify the explanation. > > > > -- Mike > > > > *From:* Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] > *Sent:* Friday, September 12, 2014 5:00 AM > *To:* jose@ietf.org; jose-chairs@tools.ietf.org; > draft-ietf-jose-json-web-key.all@tools.ietf.org; secdir@ietf.org; Stephen > Kent; Mike Jones > *Subject:* JWK member names, was: [jose] SECDIR review of > draft-ietf-jose-json-web-key-31 > > > > Hi Mike, > > > > The text Steve called out below has been very problematic as you know. > Could you call out some options here as the last time this came up, we > didn't resolve it. The working group was asked for suggestions, but none > came through. If you could provide some options and then have the workin= g > group weigh in, I think that would be good. > > > > I snipped away the rest of the review and changed the subject as not to > get in the way of the current dialog. > > > > Thanks. > > > > On Wed, Sep 10, 2014 at 8:57 PM, Mike Jones > wrote: > > Hi Stephen. Thanks for your detailed and useful review. I=E2=80=99ve cc= =E2=80=99ed the > working group in my reply so they=E2=80=99re aware of the contents of you= r review. > Replies are inline below=E2=80=A6 > > > > *From:* Stephen Kent [mailto:kent@bbn.com ] > *Sent:* Tuesday, September 02, 2014 1:09 PM > *To:* secdir@ietf.org; Mike Jones; jose-chairs@tools.ietf.org; Moriarty, > Kathleen > *Subject:* SECDIR review of draft-ietf-jose-json-web-key-31 > > > > [snip] > > > > This section imposes a rather wimpy constraint on parameter names: > > > > The member names within a JWK MUST be unique; recipients MUST either > > reject JWKs with duplicate member names or use a JSON parser that > > returns only the lexically last duplicate member name, as specified > > in Section 15.12 (The JSON Object) of ECMAScript 5.1 [ECMAScript]. > > > > This text says that member names MUST be unique, but if they are not, > that=E2=80=99s OK too; just use the last instance of a member with a dupl= icate > name. This seems like a terrible design principle. It imposes what appear= s > to be a requirement, then says how to accommodate data structures that fa= il > to meet the requirement. This would seem to encourage sloppy > implementations (for JWK generation). I=E2=80=99d like to see the rationa= le for > this. > > > > > > Unfortunately, the intentional laxness in the spec in this regard is a > reflection of the semantics of the actual JSON specifications and > implementations. For instance, > http://tools.ietf.org/html/rfc7159#section-4 says: > > > > An object whose names are all unique is interoperable in the sense > > that all software implementations receiving that object will agree on > > the name-value mappings. When the names within an object are not > > unique, the behavior of software that receives such an object is > > unpredictable. Many implementations report the last name/value pair > > only. Other implementations report an error or fail to parse the > > object, and some implementations report all of the name/value pairs, > > including duplicates. > > > > This topic has been heavily discussed by the working group, and while the > specs used to just say that objects with duplicate member names MUST be > rejected, working group members, including Tim Bray (the editor of the JS= ON > spec), prevailed on us to weaken this so that parsers that implement the > ECMAscript behavior of returning only the last member name may be legally > used. (The argument was made that there was more security downside in > effectively requiring people to write and debug their own strict parsers > than in using laxer, but well-supported and debugged parsers.) > > > > However, we also intentionally require that producers use only one > instance of each member name, so that legally produced objects will never > exercise the ambiguities that are present in real JSON parsers. That > seemed to be the most practical solution to the working group. > > > > [snip] > > Thanks again, > Stephen, > > -- Mike > > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > > > > > -- > > > > Best regards, > > Kathleen > > > > > > -- > > > > Best regards, > > Kathleen > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > > > > > -- > > - Tim Bray (If you=E2=80=99d like to send me a private message, see > https://keybase.io/timbray) > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --001a11c1e54af4bc930502e1a1fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Wel= l, quoting from your option (2):=C2=A0

=E2=80=9C2.=C2=A0 Require producers not to use duplic= ate members=C2=A0=E2=80=9D

Another way to express this would be to require tha= t producers emit I-JSON. =C2=A0This would also have benefits such as forbid= ding malformed Unicode, forbidding dependency on object member ordering, an= d staying within the bounds of IEEE double precision. =C2=A0I agree that at= this point in time, REQUIRING consumers to reject data with dupes is probl= ematic, but as long as they=E2=80=99re allowed to do so, that means they ca= n deploy I-JSON parsers when such things arrive.

If the goal is to allow the use of off-the-shelf pa= rsers, there=E2=80=99s really not much you can say about what consumers sho= uld do about dupe keys, because the behavior of such parsers is inconsisten= t in practice. =C2=A0

In = any practical programming scenario, what the recipient wants is to take the= JSON and stuff objects into hashes or dicts or whatever so they can pull o= ut fields by name. =C2=A0They=E2=80=99d really rather avoid thinking about = dealing with malformed messages - and I claim that any message with dupe ke= ys is malformed. =C2=A0The one way to be sure that consumers don=E2=80=99t = have to deal with this crap is to require that producers don=E2=80=99t emit= broken messages. =C2=A0I-JSON messages have way less scope for breakage.

On Fri,= Sep 12, 2014 at 9:20 AM, Mike Jones <Michael.Jones@microsoft.co= m> wrote:

I understand that that=E2= =80=99s an ideal long-term solution, once I-JSON parsers are common/ubiquit= ous, but I don=E2=80=99t expect that to be the case for a number of years and people are using JOSE now.=C2=A0 Tim, you were one of the primary advo= cates for the position that implementers need to be able to use JSON parser= s as they actually exist =E2=80=93 hence the change from (1) to (2) in draf= t -12 in July 2013 after extensive working group discussion on the topic.

=C2=A0

Unless you=E2=80=99ve cha= nged your tune, I doubt that you=E2=80=99re actually saying that we should = move back to (1) now, which would mean that people using today=E2=80=99s JS= ON parsers would be nonconformant?

=C2=A0

Once I-JSON is ubiquitous= , I=E2=80=99d be fine doing bis versions of the specs to tighten the requir= ement in a few years.=C2=A0 But until then, keeping the requirement that producers must not use duplicate member names would mean that if we do upd= ate to use I-JSON in the future, nothing would then break.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike

=C2=A0

From: Tim Bray= [mailto:tbray@te= xtuality.com]
Sent: Friday, September 12, 2014 8:55 AM
To: Mike Jones
Cc: Kathleen Moriarty; jose@ietf.org; jose-chairs@tools.ietf.org; draft-ietf-jose-jso= n-web-key.all@tools.ietf.org; secdir@ietf.org; Stephen Kent
Subject: Re: [jose] JWK member names, was: SECDIR review of draft-ie= tf-jose-json-web-key-31

=C2=A0

I=E2=80=99m pretty sure that at some point before th= e end of the year the IETF will publish I-JSON (see=C2=A0https:= //datatracker.ietf.org/doc/draft-ietf-json-i-json/) which simply specifies that there MUST NOT be dupe keys. =C2=A0Depending on the timefra= me, referring to this might be a good solution.

=C2=A0

On Fri, Sep 12, 2014 at 8:18 AM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

Sure.=C2=A0 Here=E2=80=99= s an analysis of the requirements about duplicate member names.

=C2=A0

There could be two very d= ifferent kinds of objections to the present text:

A.=C2=A0 People think we = have the semantics for duplicate identifiers wrong.
B.=C2=A0 People think we = should explain the current semantics for duplicate identifiers more clearly= .

=C2=A0

I sure hope that we=E2=80= =99re dealing with B and not A.=C2=A0 Stephen, which is the nature of your = critique of this text?

=C2=A0

If we=E2=80=99re in the r= ealm of A, I think there are three possibilities for the semantics:<= u>

=C2=A0

1.=C2=A0 Require producer= s not use duplicate members and require consumers to reject inputs with dup= licate member names.

Pros:=C2=A0 This is the m= ost locked-down, consistent, and alternative.

Cons:=C2=A0 Real JSON par= sers don=E2=80=99t all reject duplicate inputs.=C2=A0 If we force people to= write custom parsers, this will result in exploitable bugs (and some just won=E2=80=99t do it an= d won=E2=80=99t be conformant).

=C2=A0

2.=C2=A0 Require producer= s not to use duplicate members but allow consumers to accept inputs with du= plicate member names in the manner defined in ECMAscript.=C2=A0 (This is the curre= nt choice.)

Pros:=C2=A0 People can us= e all standard JSON parsers.=C2=A0 Producers are still required to produce = well-formed data structures.

Cons:=C2=A0 The requireme= nts on producers are stricter than those on consumers.=

=C2=A0

3.=C2=A0 Allow both produ= cers and consumers to use duplicate members, with duplicate member names ha= ndled in the manner defined in ECMAscript.

Pros:=C2=A0 People can us= e ECMAscript parsers (which are more liberal than some JSON parsers).=C2=A0= The requirements on producers and consumers are the same.

Cons:=C2=A0 Hidden conten= t can be inserted into duplicate member names.=C2=A0 This could give attack= ers a way to manipulate the inputs to crypto operations.=C2=A0 Strict JSON parsers (= that reject inputs with duplicate members) can=E2=80=99t be used.=

=C2=A0

Practically, I think were= we presently are (2) is the best compromise between implementability, cons= istency, and security.=C2=A0 The working group put a lot of discussion into this, i= ncluding changing from (1) to (2) and it=E2=80=99s my sense that most agree= we=E2=80=99ve landed in the right place.=C2=A0 From a security perspective= , I don=E2=80=99t think that (3) is a viable option.
=C2=A0

If people think that the = current semantics are right but are not sufficiently clearly explained or motivated, I=E2=80=99d certainly welcome proposed text to clarify the expl= anation.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike

=C2=A0

From: Kathleen= Moriarty [mailto:kathleen.moriarty.ietf@gmail.com]
Sent: Friday, September 12, 2014 5:00 AM
To: jose@ietf.org= ; jose-chairs@tools.ietf.org; draft-ietf-jose-json-web-key.all@tools.ietf.org; secdir@ietf.org; Stephen Kent; Mike Jones
Subject: JWK member names, was: [jose] SECDIR review of draft-ietf-j= ose-json-web-key-31

=C2=A0

Hi Mike,

=C2=A0

The text Steve called out below has been very proble= matic as you know. =C2=A0Could you call out some options here as the last t= ime this came up, we didn't resolve it. =C2=A0The working group was asked for suggestions, but none came through. =C2=A0If you could provi= de some options and then have the working group weigh in, I think that woul= d be good.=C2=A0

=C2=A0

I snipped away the rest of the review and changed th= e subject as not to get in the way of the current dialog.=C2=A0

=C2=A0

Thanks.

=C2=A0

On Wed, Sep 10, 2014 at 8:57 PM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

Hi Stephen.=C2=A0 Thanks = for your detailed and useful review.=C2=A0 I=E2=80=99ve cc=E2=80=99ed the w= orking group in my reply so they=E2=80=99re aware of the contents of your review.=C2=A0 Replies are= inline below=E2=80=A6

=C2=A0

From: Stephen = Kent [mailto:kent@bbn.com]
Sent: Tuesday, September 02, 2014 1:09 PM
To: secdir@ietf.org; Mike Jones; jose-chairs@tools.ietf.org; Moriarty, Kathle= en
Subject: SECDIR review of draft-ietf-jose-json-web-key-31<= /u>

=C2=A0

[snip]=C2=A0

=C2=A0=C2=A0

This section imp= oses a rather wimpy constraint on parameter names:

=C2=A0

=C2=A0=C2=A0 The member names within a JWK MUST be unique; recipients MU= ST either

=C2=A0=C2=A0 reject JWKs with duplicate member names or use a JSON parse= r that

=C2=A0=C2=A0 returns only the lexically last duplicate member name, as s= pecified

=C2=A0=C2=A0 in Section 15.12 (The JSON Object) of ECMAScript 5.1 [ECMAS= cript].

=C2=A0

This text says t= hat member names MUST be unique, but if they are not, that=E2=80=99s OK too= ; just use the last instance of a member with a duplicate name. This seems like a terrible design principle. It imposes what appears to be= a requirement, then says how to accommodate data structures that fail to m= eet the requirement. This would seem to encourage sloppy implementations (f= or JWK generation). I=E2=80=99d like to see the rationale for this.

=C2=A0

=C2=A0

Unfortunately, the intentional laxness in the= spec in this regard is a reflection of the semantics of the actual JSON sp= ecifications and implementations.=C2=A0 For instance, http://tools.ietf.org/html/rfc7159#section-4= says:

=C2=A0

=C2=A0=C2=A0 An object whose names are all unique is interopera= ble in the sense

=C2=A0=C2=A0 that all software implementations receiving that o= bject will agree on

=C2=A0=C2=A0 the name-value mappings.=C2=A0 When the names with= in an object are not

=C2=A0=C2=A0 unique, the behavior of software that receives suc= h an object is

=C2=A0=C2=A0 unpredictable.=C2=A0 Many implementations report t= he last name/value pair

=C2=A0=C2=A0 only.=C2=A0 Other implementations report an error = or fail to parse the

=C2=A0=C2=A0 object, and some implementations report all of the= name/value pairs,

=C2=A0=C2=A0 including duplicates.

=C2=A0

This topic has been heavily discussed by the = working group, and while the specs used to just say that objects with dupli= cate member names MUST be rejected, working group members, including Tim Bray (the editor of the JSON spec), prevailed on us to weake= n this so that parsers that implement the ECMAscript behavior of returning = only the last member name may be legally used.=C2=A0 (The argument was made= that there was more security downside in effectively requiring people to write and debug their own strict parser= s than in using laxer, but well-supported and debugged parsers.)<= /u>

=C2=A0

However, we also intentionally require that p= roducers use only one instance of each member name, so that legally produce= d objects will never exercise the ambiguities that are present in real JSON parsers.=C2=A0 That seemed to be the most practical s= olution to the working group.

=C2=A0

[snip]=

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thanks again, Stephen,<= /p>
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike

=C2=A0

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

=C2=A0

--

=C2=A0

Best regards,

Kathleen=

=C2=A0

--

=C2=A0

Best regards,

Kathleen

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

=C2=A0

--

- Tim Bray (If you=E2=80=99d like to send me a priva= te message, see https://keybase.io/timbray)

- Tim Bray (If you=E2=80=99d like to send me a private message, s= ee https://keybase= .io/timbray)

--001a11c1e54af4bc930502e1a1fe-- From nobody Fri Sep 12 12:05:48 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A263B1A802C for ; Fri, 12 Sep 2014 10:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 vfrSBx9yqMq6 for ; Fri, 12 Sep 2014 10:48:45 -0700 (PDT) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C10D1A6F66 for ; Fri, 12 Sep 2014 10:48:42 -0700 (PDT) Received: by mail-vc0-f178.google.com with SMTP id hy4so1063797vcb.9 for ; Fri, 12 Sep 2014 10:48:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=KRUzFZV0CpU6KfBQ6uljjcIkDnecTABfknW/1xUXGWo=; b=GUeiOMDKjRJ+CrDApSOHyYnHtdkQYigoJM2QG8JYEQCqd8CBqy3iND5Tn/nsiLChs3 IKE7CHjjbRUqRKA3D2o+4rZE0wTWxC2EwdPV6iP3IZdXnuKPqJBgeKtk2wxXI4k1H5FK cV28bKJTBSY0+WUJyAqy0O8zxh/sZQjps2d5K2blyVNJ0S9mdR50oTZVDdubokUqKgK5 c31lOYEdNFys/9d8rA7FnwUO+cdDTXifAStXDHllyg+PGvMbuiWacU8LlvwP0iQXy6CC j8my2rNoMJtTWZdctQm+il0JYht3zzQ+DSFxnYE+Wk24AH91dghN4FVAJ3J0f1LmlC8K H5Og== X-Gm-Message-State: ALoCoQmjE8FoD/7nXq7WWudShzdqgyuVbtcCwIWmCNx20JgbES4Uphqs0d9/0w8Za4K4U2C5ye41 X-Received: by 10.52.38.134 with SMTP id g6mr6867708vdk.34.1410544121242; Fri, 12 Sep 2014 10:48:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.214.4 with HTTP; Fri, 12 Sep 2014 10:48:21 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: References: <4E1F6AAD24975D4BA5B16804296739439AEC00DB@TK5EX14MBXC292.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439AEC0929@TK5EX14MBXC292.redmond.corp.microsoft.com> From: Tim Bray Date: Fri, 12 Sep 2014 10:48:21 -0700 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=bcaec51d282a4981cc0502e1e54c Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/TUAOv7XYK1BKzvKPCa3r9o6o3FU X-Mailman-Approved-At: Fri, 12 Sep 2014 12:05:30 -0700 Cc: "jose-chairs@tools.ietf.org" , "secdir@ietf.org" , "draft-ietf-jose-json-web-key.all@tools.ietf.org" , Kathleen Moriarty , "jose@ietf.org" Subject: Re: [secdir] [jose] JWK member names, was: SECDIR review of draft-ietf-jose-json-web-key-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 17:48:48 -0000 --bcaec51d282a4981cc0502e1e54c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It also seems that the Security Considerations should call out malformed messages, specifically including dupe keys, as an attack vector. The best defense against such attacks is for clients to reject malformed messages. On Fri, Sep 12, 2014 at 10:29 AM, Tim Bray wrote: > Well, quoting from your option (2): > > =E2=80=9C2. Require producers not to use duplicate members =E2=80=9D > > Another way to express this would be to require that producers emit > I-JSON. This would also have benefits such as forbidding malformed > Unicode, forbidding dependency on object member ordering, and staying > within the bounds of IEEE double precision. I agree that at this point i= n > time, REQUIRING consumers to reject data with dupes is problematic, but a= s > long as they=E2=80=99re allowed to do so, that means they can deploy I-JS= ON parsers > when such things arrive. > > If the goal is to allow the use of off-the-shelf parsers, there=E2=80=99s= really > not much you can say about what consumers should do about dupe keys, > because the behavior of such parsers is inconsistent in practice. > > In any practical programming scenario, what the recipient wants is to tak= e > the JSON and stuff objects into hashes or dicts or whatever so they can > pull out fields by name. They=E2=80=99d really rather avoid thinking abo= ut dealing > with malformed messages - and I claim that any message with dupe keys is > malformed. The one way to be sure that consumers don=E2=80=99t have to d= eal with > this crap is to require that producers don=E2=80=99t emit broken messages= . I-JSON > messages have way less scope for breakage. > > On Fri, Sep 12, 2014 at 9:20 AM, Mike Jones > wrote: > >> I understand that that=E2=80=99s an ideal long-term solution, once I-JS= ON >> parsers are common/ubiquitous, but I don=E2=80=99t expect that to be the= case for a >> number of years and people are using JOSE now. Tim, you were one of the >> primary advocates for the position that implementers need to be able to = use >> JSON parsers as they actually exist =E2=80=93 hence the change from (1) = to (2) in >> draft -12 in July 2013 after extensive working group discussion on the >> topic. >> >> >> >> Unless you=E2=80=99ve changed your tune, I doubt that you=E2=80=99re act= ually saying that >> we should move back to (1) now, which would mean that people using today= =E2=80=99s >> JSON parsers would be nonconformant? >> >> >> >> Once I-JSON is ubiquitous, I=E2=80=99d be fine doing bis versions of the= specs to >> tighten the requirement in a few years. But until then, keeping the >> requirement that producers must not use duplicate member names would mea= n >> that if we do update to use I-JSON in the future, nothing would then bre= ak. >> >> >> >> -- Mike >> >> >> >> *From:* Tim Bray [mailto:tbray@textuality.com] >> *Sent:* Friday, September 12, 2014 8:55 AM >> *To:* Mike Jones >> *Cc:* Kathleen Moriarty; jose@ietf.org; jose-chairs@tools.ietf.org; >> draft-ietf-jose-json-web-key.all@tools.ietf.org; secdir@ietf.org; >> Stephen Kent >> *Subject:* Re: [jose] JWK member names, was: SECDIR review of >> draft-ietf-jose-json-web-key-31 >> >> >> >> I=E2=80=99m pretty sure that at some point before the end of the year th= e IETF >> will publish I-JSON (see >> https://datatracker.ietf.org/doc/draft-ietf-json-i-json/) which simply >> specifies that there MUST NOT be dupe keys. Depending on the timeframe, >> referring to this might be a good solution. >> >> >> >> On Fri, Sep 12, 2014 at 8:18 AM, Mike Jones >> wrote: >> >> Sure. Here=E2=80=99s an analysis of the requirements about duplicate me= mber >> names. >> >> >> >> There could be two very different kinds of objections to the present tex= t: >> >> A. People think we have the semantics for duplicate identifiers wrong. >> >> B. People think we should explain the current semantics for duplicate >> identifiers more clearly. >> >> >> >> I sure hope that we=E2=80=99re dealing with B and not A. Stephen, which= is the >> nature of your critique of this text? >> >> >> >> If we=E2=80=99re in the realm of A, I think there are three possibilitie= s for the >> semantics: >> >> >> >> 1. Require producers not use duplicate members and require consumers to >> reject inputs with duplicate member names. >> >> Pros: This is the most locked-down, consistent, and alternative. >> >> Cons: Real JSON parsers don=E2=80=99t all reject duplicate inputs. If = we force >> people to write custom parsers, this will result in exploitable bugs (an= d >> some just won=E2=80=99t do it and won=E2=80=99t be conformant). >> >> >> >> 2. Require producers not to use duplicate members but allow consumers t= o >> accept inputs with duplicate member names in the manner defined in >> ECMAscript. (This is the current choice.) >> >> Pros: People can use all standard JSON parsers. Producers are still >> required to produce well-formed data structures. >> >> Cons: The requirements on producers are stricter than those on consumer= s. >> >> >> >> 3. Allow both producers and consumers to use duplicate members, with >> duplicate member names handled in the manner defined in ECMAscript. >> >> Pros: People can use ECMAscript parsers (which are more liberal than >> some JSON parsers). The requirements on producers and consumers are the >> same. >> >> Cons: Hidden content can be inserted into duplicate member names. This >> could give attackers a way to manipulate the inputs to crypto operations= . >> Strict JSON parsers (that reject inputs with duplicate members) can=E2= =80=99t be >> used. >> >> >> >> Practically, I think were we presently are (2) is the best compromise >> between implementability, consistency, and security. The working group = put >> a lot of discussion into this, including changing from (1) to (2) and it= =E2=80=99s >> my sense that most agree we=E2=80=99ve landed in the right place. From = a security >> perspective, I don=E2=80=99t think that (3) is a viable option. >> >> >> >> If people think that the current semantics are right but are not >> sufficiently clearly explained or motivated, I=E2=80=99d certainly welco= me proposed >> text to clarify the explanation. >> >> >> >> -- Mike >> >> >> >> *From:* Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] >> *Sent:* Friday, September 12, 2014 5:00 AM >> *To:* jose@ietf.org; jose-chairs@tools.ietf.org; >> draft-ietf-jose-json-web-key.all@tools.ietf.org; secdir@ietf.org; >> Stephen Kent; Mike Jones >> *Subject:* JWK member names, was: [jose] SECDIR review of >> draft-ietf-jose-json-web-key-31 >> >> >> >> Hi Mike, >> >> >> >> The text Steve called out below has been very problematic as you know. >> Could you call out some options here as the last time this came up, we >> didn't resolve it. The working group was asked for suggestions, but non= e >> came through. If you could provide some options and then have the worki= ng >> group weigh in, I think that would be good. >> >> >> >> I snipped away the rest of the review and changed the subject as not to >> get in the way of the current dialog. >> >> >> >> Thanks. >> >> >> >> On Wed, Sep 10, 2014 at 8:57 PM, Mike Jones >> wrote: >> >> Hi Stephen. Thanks for your detailed and useful review. I=E2=80=99ve c= c=E2=80=99ed the >> working group in my reply so they=E2=80=99re aware of the contents of yo= ur review. >> Replies are inline below=E2=80=A6 >> >> >> >> *From:* Stephen Kent [mailto:kent@bbn.com ] >> *Sent:* Tuesday, September 02, 2014 1:09 PM >> *To:* secdir@ietf.org; Mike Jones; jose-chairs@tools.ietf.org; Moriarty, >> Kathleen >> *Subject:* SECDIR review of draft-ietf-jose-json-web-key-31 >> >> >> >> [snip] >> >> >> >> This section imposes a rather wimpy constraint on parameter names: >> >> >> >> The member names within a JWK MUST be unique; recipients MUST either >> >> reject JWKs with duplicate member names or use a JSON parser that >> >> returns only the lexically last duplicate member name, as specified >> >> in Section 15.12 (The JSON Object) of ECMAScript 5.1 [ECMAScript]. >> >> >> >> This text says that member names MUST be unique, but if they are not, >> that=E2=80=99s OK too; just use the last instance of a member with a dup= licate >> name. This seems like a terrible design principle. It imposes what appea= rs >> to be a requirement, then says how to accommodate data structures that f= ail >> to meet the requirement. This would seem to encourage sloppy >> implementations (for JWK generation). I=E2=80=99d like to see the ration= ale for >> this. >> >> >> >> >> >> Unfortunately, the intentional laxness in the spec in this regard is a >> reflection of the semantics of the actual JSON specifications and >> implementations. For instance, >> http://tools.ietf.org/html/rfc7159#section-4 says: >> >> >> >> An object whose names are all unique is interoperable in the sense >> >> that all software implementations receiving that object will agree on >> >> the name-value mappings. When the names within an object are not >> >> unique, the behavior of software that receives such an object is >> >> unpredictable. Many implementations report the last name/value pair >> >> only. Other implementations report an error or fail to parse the >> >> object, and some implementations report all of the name/value pairs, >> >> including duplicates. >> >> >> >> This topic has been heavily discussed by the working group, and while th= e >> specs used to just say that objects with duplicate member names MUST be >> rejected, working group members, including Tim Bray (the editor of the J= SON >> spec), prevailed on us to weaken this so that parsers that implement the >> ECMAscript behavior of returning only the last member name may be legall= y >> used. (The argument was made that there was more security downside in >> effectively requiring people to write and debug their own strict parsers >> than in using laxer, but well-supported and debugged parsers.) >> >> >> >> However, we also intentionally require that producers use only one >> instance of each member name, so that legally produced objects will neve= r >> exercise the ambiguities that are present in real JSON parsers. That >> seemed to be the most practical solution to the working group. >> >> >> >> [snip] >> >> Thanks again= , >> Stephen, >> >> -- Mike >> >> >> >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >> >> >> >> >> >> -- >> >> >> >> Best regards, >> >> Kathleen >> >> >> >> >> >> -- >> >> >> >> Best regards, >> >> Kathleen >> >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >> >> >> >> >> >> -- >> >> - Tim Bray (If you=E2=80=99d like to send me a private message, see >> https://keybase.io/timbray) >> > > > > -- > - Tim Bray (If you=E2=80=99d like to send me a private message, see > https://keybase.io/timbray) > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --bcaec51d282a4981cc0502e1e54c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

It = also seems that the Security Considerations should call out malformed messa= ges, specifically including dupe keys, as an attack vector. =C2=A0The best = defense against such attacks is for clients to reject malformed messages.

On Fri,= Sep 12, 2014 at 10:29 AM, Tim Bray <tbray@textuality.com> wrote:

Well, quoting from your option (2):= =C2=A0

=E2=80=9C2= .=C2=A0 Require producers not to use duplicate members=C2=A0= =E2=80=9D

Another = way to express this would be to require that producers emit I-JSON. =C2=A0T= his would also have benefits such as forbidding malformed Unicode, forbiddi= ng dependency on object member ordering, and staying within the bounds of I= EEE double precision. =C2=A0I agree that at this point in time, REQUIRING c= onsumers to reject data with dupes is problematic, but as long as they=E2= =80=99re allowed to do so, that means they can deploy I-JSON parsers when s= uch things arrive.

If the= goal is to allow the use of off-the-shelf parsers, there=E2=80=99s really = not much you can say about what consumers should do about dupe keys, becaus= e the behavior of such parsers is inconsistent in practice. =C2=A0

In any practical programming scen= ario, what the recipient wants is to take the JSON and stuff objects into h= ashes or dicts or whatever so they can pull out fields by name. =C2=A0They= =E2=80=99d really rather avoid thinking about dealing with malformed messag= es - and I claim that any message with dupe keys is malformed. =C2=A0The on= e way to be sure that consumers don=E2=80=99t have to deal with this crap i= s to require that producers don=E2=80=99t emit broken messages. =C2=A0I-JSO= N messages have way less scope for breakage.

On Fri, Sep 12, 2014 at 9:20 AM, Mike Jones <Michael.Jones@m= icrosoft.com> wrote:

I understand that that=E2= =80=99s an ideal long-term solution, once I-JSON parsers are common/ubiquit= ous, but I don=E2=80=99t expect that to be the case for a number of years and people are using JOSE now.=C2=A0 Tim, you were one of the primary advo= cates for the position that implementers need to be able to use JSON parser= s as they actually exist =E2=80=93 hence the change from (1) to (2) in draf= t -12 in July 2013 after extensive working group discussion on the topic.

=C2=A0

Unless you=E2=80=99ve cha= nged your tune, I doubt that you=E2=80=99re actually saying that we should = move back to (1) now, which would mean that people using today=E2=80=99s JS= ON parsers would be nonconformant?

=C2=A0

Once I-JSON is ubiquitous= , I=E2=80=99d be fine doing bis versions of the specs to tighten the requir= ement in a few years.=C2=A0 But until then, keeping the requirement that producers must not use duplicate member names would mean that if we do upd= ate to use I-JSON in the future, nothing would then break.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike

=C2=A0

From: Tim Bray= [mailto:tbray@te= xtuality.com]
Sent: Friday, September 12, 2014 8:55 AM
To: Mike Jones
Cc: Kathleen Moriarty; jose@ietf.org; jose-chairs@tools.ietf.org; draft-ietf-jose-jso= n-web-key.all@tools.ietf.org; secdir@ietf.org; Stephen Kent
Subject: Re: [jose] JWK member names, was: SECDIR review of draft-ie= tf-jose-json-web-key-31

=C2=A0

I=E2=80=99m pretty sure that at some point before th= e end of the year the IETF will publish I-JSON (see=C2=A0https:= //datatracker.ietf.org/doc/draft-ietf-json-i-json/) which simply specifies that there MUST NOT be dupe keys. =C2=A0Depending on the timefra= me, referring to this might be a good solution.

=C2=A0

On Fri, Sep 12, 2014 at 8:18 AM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

Sure.=C2=A0 Here=E2=80=99= s an analysis of the requirements about duplicate member names.

=C2=A0

There could be two very d= ifferent kinds of objections to the present text:

A.=C2=A0 People think we = have the semantics for duplicate identifiers wrong.
B.=C2=A0 People think we = should explain the current semantics for duplicate identifiers more clearly= .

=C2=A0

I sure hope that we=E2=80= =99re dealing with B and not A.=C2=A0 Stephen, which is the nature of your = critique of this text?

=C2=A0

If we=E2=80=99re in the r= ealm of A, I think there are three possibilities for the semantics:<= u>

=C2=A0

1.=C2=A0 Require producer= s not use duplicate members and require consumers to reject inputs with dup= licate member names.

Pros:=C2=A0 This is the m= ost locked-down, consistent, and alternative.

Cons:=C2=A0 Real JSON par= sers don=E2=80=99t all reject duplicate inputs.=C2=A0 If we force people to= write custom parsers, this will result in exploitable bugs (and some just won=E2=80=99t do it an= d won=E2=80=99t be conformant).

=C2=A0

2.=C2=A0 Require producer= s not to use duplicate members but allow consumers to accept inputs with du= plicate member names in the manner defined in ECMAscript.=C2=A0 (This is the curre= nt choice.)

Pros:=C2=A0 People can us= e all standard JSON parsers.=C2=A0 Producers are still required to produce = well-formed data structures.

Cons:=C2=A0 The requireme= nts on producers are stricter than those on consumers.=

=C2=A0

3.=C2=A0 Allow both produ= cers and consumers to use duplicate members, with duplicate member names ha= ndled in the manner defined in ECMAscript.

Pros:=C2=A0 People can us= e ECMAscript parsers (which are more liberal than some JSON parsers).=C2=A0= The requirements on producers and consumers are the same.

Cons:=C2=A0 Hidden conten= t can be inserted into duplicate member names.=C2=A0 This could give attack= ers a way to manipulate the inputs to crypto operations.=C2=A0 Strict JSON parsers (= that reject inputs with duplicate members) can=E2=80=99t be used.=

=C2=A0

Practically, I think were= we presently are (2) is the best compromise between implementability, cons= istency, and security.=C2=A0 The working group put a lot of discussion into this, i= ncluding changing from (1) to (2) and it=E2=80=99s my sense that most agree= we=E2=80=99ve landed in the right place.=C2=A0 From a security perspective= , I don=E2=80=99t think that (3) is a viable option.
=C2=A0

If people think that the = current semantics are right but are not sufficiently clearly explained or motivated, I=E2=80=99d certainly welcome proposed text to clarify the expl= anation.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike

=C2=A0

From: Kathleen= Moriarty [mailto:kathleen.moriarty.ietf@gmail.com]
Sent: Friday, September 12, 2014 5:00 AM
To: jose@ietf.org= ; jose-chairs@tools.ietf.org; draft-ietf-jose-json-web-key.all@tools.ietf.org; secdir@ietf.org; Stephen Kent; Mike Jones
Subject: JWK member names, was: [jose] SECDIR review of draft-ietf-j= ose-json-web-key-31

=C2=A0

Hi Mike,

=C2=A0

The text Steve called out below has been very proble= matic as you know. =C2=A0Could you call out some options here as the last t= ime this came up, we didn't resolve it. =C2=A0The working group was asked for suggestions, but none came through. =C2=A0If you could provi= de some options and then have the working group weigh in, I think that woul= d be good.=C2=A0

=C2=A0

I snipped away the rest of the review and changed th= e subject as not to get in the way of the current dialog.=C2=A0

=C2=A0

Thanks.

=C2=A0

On Wed, Sep 10, 2014 at 8:57 PM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

Hi Stephen.=C2=A0 Thanks = for your detailed and useful review.=C2=A0 I=E2=80=99ve cc=E2=80=99ed the w= orking group in my reply so they=E2=80=99re aware of the contents of your review.=C2=A0 Replies are= inline below=E2=80=A6

=C2=A0

From: Stephen = Kent [mailto:kent@bbn.com]
Sent: Tuesday, September 02, 2014 1:09 PM
To: secdir@ietf.org; Mike Jones; jose-chairs@tools.ietf.org; Moriarty, Kathle= en
Subject: SECDIR review of draft-ietf-jose-json-web-key-31<= /u>

=C2=A0

[snip]=C2=A0

=C2=A0=C2=A0

This section imp= oses a rather wimpy constraint on parameter names:

=C2=A0

=C2=A0=C2=A0 The member names within a JWK MUST be unique; recipients MU= ST either

=C2=A0=C2=A0 reject JWKs with duplicate member names or use a JSON parse= r that

=C2=A0=C2=A0 returns only the lexically last duplicate member name, as s= pecified

=C2=A0=C2=A0 in Section 15.12 (The JSON Object) of ECMAScript 5.1 [ECMAS= cript].

=C2=A0

This text says t= hat member names MUST be unique, but if they are not, that=E2=80=99s OK too= ; just use the last instance of a member with a duplicate name. This seems like a terrible design principle. It imposes what appears to be= a requirement, then says how to accommodate data structures that fail to m= eet the requirement. This would seem to encourage sloppy implementations (f= or JWK generation). I=E2=80=99d like to see the rationale for this.

=C2=A0

=C2=A0

Unfortunately, the intentional laxness in the= spec in this regard is a reflection of the semantics of the actual JSON sp= ecifications and implementations.=C2=A0 For instance, http://tools.ietf.org/html/rfc7159#section-4= says:

=C2=A0

=C2=A0=C2=A0 An object whose names are all unique is interopera= ble in the sense

=C2=A0=C2=A0 that all software implementations receiving that o= bject will agree on

=C2=A0=C2=A0 the name-value mappings.=C2=A0 When the names with= in an object are not

=C2=A0=C2=A0 unique, the behavior of software that receives suc= h an object is

=C2=A0=C2=A0 unpredictable.=C2=A0 Many implementations report t= he last name/value pair

=C2=A0=C2=A0 only.=C2=A0 Other implementations report an error = or fail to parse the

=C2=A0=C2=A0 object, and some implementations report all of the= name/value pairs,

=C2=A0=C2=A0 including duplicates.

=C2=A0

This topic has been heavily discussed by the = working group, and while the specs used to just say that objects with dupli= cate member names MUST be rejected, working group members, including Tim Bray (the editor of the JSON spec), prevailed on us to weake= n this so that parsers that implement the ECMAscript behavior of returning = only the last member name may be legally used.=C2=A0 (The argument was made= that there was more security downside in effectively requiring people to write and debug their own strict parser= s than in using laxer, but well-supported and debugged parsers.)<= /u>

=C2=A0

However, we also intentionally require that p= roducers use only one instance of each member name, so that legally produce= d objects will never exercise the ambiguities that are present in real JSON parsers.=C2=A0 That seemed to be the most practical s= olution to the working group.

=C2=A0

[snip]=

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thanks again, Stephen,<= /p>
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike

=C2=A0

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

=C2=A0

--

=C2=A0

Best regards,

Kathleen=

=C2=A0

--

=C2=A0

Best regards,

Kathleen

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

=C2=A0

--

- Tim Bray (If you=E2=80=99d like to send me a priva= te message, see https://keybase.io/timbray)

--
- Tim Bray (If you=E2=80=99d like to send me a private message, s= ee https://keybase= .io/timbray)

--
=

- Tim Bray (If you=E2=80=99d like to send me a privat= e message, see htt= ps://keybase.io/timbray)

--bcaec51d282a4981cc0502e1e54c-- From nobody Fri Sep 12 14:51:28 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 853B51A010F for ; Fri, 12 Sep 2014 14:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 SzJIrvccU9eX for ; Fri, 12 Sep 2014 14:51:22 -0700 (PDT) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC8401A00F0 for ; Fri, 12 Sep 2014 14:51:20 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id 10so1708188lbg.30 for ; Fri, 12 Sep 2014 14:51:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=grfJkGKJsHYDbQ9yihBjigcFrGpHwerdbWSq2PjzV3Q=; b=LY9dlKZfrzrVjFbb8gbGN/TEQ+EaD+1iN7Dmcg+e1JStEdlqKlEGy/0qRhUmlKbH/d +A26jpvM/ox6QZ47/3yYcb1SBZbuS0l0DtuuFbD7ED0RFei6RUa8xszLo1MZ4NTo+j+W LHLAycGpCdTdOX4oPCUk6TrzEYLg0ngZEB7sRJOyvtyUmMA3nDUPRPnduphXZdK+Lqv1 eoyhxGwPLfBhqifieUGCfh9NIjNgRQOfYgiuVwZmE4aohPO9n0fpj3l6ZkfShvL9GwXg pHjCP26AKrTmrPZhblyVj4uiVK2x+JdOv5Kbz2sGUlTnVDOrtcR6mt6VfEa1UxM9VLD7 Jr3g== X-Gm-Message-State: ALoCoQkaWOGio5x5JHul1Oi50Lr9XeHYE8LVps4zjyQ1AchpxyZKIgTR7hsB5a6XfNLsifxiZ91/ MIME-Version: 1.0 X-Received: by 10.112.53.199 with SMTP id d7mr6356580lbp.106.1410558679025; Fri, 12 Sep 2014 14:51:19 -0700 (PDT) Received: by 10.25.159.84 with HTTP; Fri, 12 Sep 2014 14:51:18 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439AE9DD47@TK5EX14MBXC292.redmond.corp.microsoft.com> References: <21512.21725.209461.976375@fireball.kivinen.iki.fi> <4E1F6AAD24975D4BA5B16804296739439AE9DD47@TK5EX14MBXC292.redmond.corp.microsoft.com> Date: Fri, 12 Sep 2014 17:51:18 -0400 Message-ID: From: Richard Barnes To: Mike Jones Content-Type: multipart/alternative; boundary=001a1133d09eff9f140502e548e3 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/vunaLEaR3o0bFddk1EitCN6wf-A Cc: "ietf@ietf.org" , "secdir@ietf.org" , "iesg@ietf.org" , "jose@ietf.org" , "draft-ietf-jose-json-web-signature.all@tools.ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-jose-json-web-signature-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 21:51:25 -0000 --001a1133d09eff9f140502e548e3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Sep 5, 2014 at 8:56 PM, Mike Jones wrote: > Thanks for the useful review, Tero. I=E2=80=99ve cc=E2=80=99ed the work= ing group to > make them aware of the contents of your review. Also, Richard Barnes, > please see a request for a reply from you on one issue below. Replies ar= e > inline below=E2=80=A6 > > > > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@iki.fi] > Sent: Thursday, September 04, 2014 5:03 AM > To: iesg@ietf.org; secdir@ietf.org; ietf@ietf.org; > draft-ietf-jose-json-web-signature.all@tools.ietf.org > Subject: Secdir review of draft-ietf-jose-json-web-signature-31 > > > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security are= a > directors. Document editors and WG chairs should treat these comments ju= st > like any other last call comments. > > > > Summary: This document has issues. > > > > This document is part of the jose-json document set, and describres the > JSON Web Signatures. > > > > The security considerations section includes text which says: > > > > The entire list of security considerations is beyond the scope of > > this document, but some significant considerations are listed here. > > > > > > but also lists quite a lot of security considerations. I think the > security considerations covering this document should be in scope with th= e > document. Of course there are generic security considerations which might > be outside the scope of this document, but I do not think we need to > explictly mention those. > > > > Several reviewers have objected to this sentence. Its removal is planned= . > > > > Also, additional security considerations will be described in the process > of resolving Russ Housley=E2=80=99s gen-art review comments. > > > > I have following issues about the draft: > > > > 1) "alg" and Protected Header > > > > 2) Hash inside "alg" and inside the signature > > > > 3) There is no explict warning about the "alg" "none". > > > > 4) Thumbprint formats > > > > There is also following nit: > > > > 5) Terminology ordering. > > > > ---------------------------------------------------------------------- > > > > 1) "alg" and Protected Header > > > > Question: Shouldn't the "alg" header parameter be protected by the > signature, i.e. wouldn't it make sense to say MUST be in the "Protected > Header"? > > > > If it is part of the "Unprotected Header" and is not protected by the > signature, that would allow all kind of attacks, i.e. changing the "alg" = to > be "none" or changing the hash algorithm of the signature. > > > > If it should be part of the "Protected Header" then that would mean that > "Proteced Header" cannot be empty, as "alg" is mandatory header parameter= , > and MUST be present. > > > > There are several cases where the text indicates that "Protected Header" > could be empty, which would mean that "alg" could be part of the > "Unprotected Header". (Section 5.1, 4. bullet; section 7.2, "protected" > element and other places in same section). In all examples the "alg" is > always in the "Proteced Header". > > > > I think the draft needs text saying something about the situation where > "alg" is not in "Protected Header" in the security sections section. I.e. > either say, that it has been analyzed that there is no problem even when > the "alg" is not protected, and reference to such analysis, or otherwise > add text/warning that it MUST/SHOULD be in the "Protected Header". I do n= ot > know enough about the proposed signature algorithms to know which one is > true, especially as there might be new algorithms in the future. > > > > Richard Barnes, do you want to answer this one? You were the primary > advocate for allowing the algorithm to be unprotected in the JSON > Serialization. > > > > As I recall, the motivation had to do with the fact that, by default, CMS > does not protect the algorithm (although it was later extended to enable = it > to be protected). Some others in the working group thought that having > unprotected algorithms was a bad idea, in line with your comment above. > The only need for protection of the "alg" value is to prevent algorithm substitution attacks, as discussed in RFC 6211. https://tools.ietf.org/html/rfc6211 These attacks are fairly limited in their applicability, since they require that: * The attacker is able to compute an input that is valid for the signature using a different, weaker algorithm * The attacker's input is valid according to whatever application rules are being applied * A relying party will accept the weaker algorithm Given all those criteria, it seems reasonable that some signers might regard algorithm substitution attacks as an acceptable risk. For example, in an application that set explicit minimum algorithm requirements (e.g., SHA-3 only!), there may be no risk of a relying party accepting the weaker algorithm. Or the application payload might have low enough entropy that it's impossible to find a valid forged input. And if an application is concerned about algorithm substitution attacks, it can protect itself by including the algorithm in the payload, as X.509 does= . I would be happy to have some advisory text in the security considerations, but I don't think this rises to the level of SHOULD/MUST. --Richard > > > -- > > > > 2) Hash inside "alg" and inside the signature > > > > Also in some cases the signature itself has the hash function stored > internally, i.e. RSASSA-PKCS1-V1_5 contains the hash function oid inside > the signature, so what should the implementation do if the "alg" paramete= r > outside the signature does not match the oid inside the signature? I.e th= e > signature using "alg" of "RS256", but inside the signature the oid is usi= ng > the "SHA1". Most crypto libraries will just take the oid from the > signature, and use that to verify the message. Adding some description wh= at > to do in such situation would be needed. > > > > I think there=E2=80=99s some confusion here, since the JWS spec does not = use any > OIDs or ASN.1 for signatures. Rather, the cryptographic operations to be > performed are fully specified by the =E2=80=9Calg=E2=80=9D value and the = signatures are > represented as base64url encoded octet sequences representing the signatu= re > values produced by the signature algorithms. > > > > -- > > > > 3) There is no explict warning about the "alg" "none". > > > > In the section 5.2 it says that "at least one signature ... MUST > successfully validate", but that does not limit alg "none" out from it. > I.e. if the application policy is to "one signature needs to validate", a= nd > it gets JWS that has "none" as one of the algorithms, then it will accept > it. > > > > I think there should be warning here or in the security considerations > section about the "none" algorithm, especially as the algorithm itself is > defined in the different draft (perhaps just reference to the section 8.5 > of the [JWA] draft). > > > > This warning is present in the spec where the algorithm is defined =E2=80= =93 > specifically > http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-31#section= -8.5. > (Note that the working group decided to define algorithms in a separate > spec than the ones in which they are used.) > > > > Also note that it is up to applications which algorithms are acceptable i= n > a given context =E2=80=93 not just =E2=80=9Cnone=E2=80=9D but also other = algorithms that might be > deprecated or inappropriate for some other reason. Unless the signature > algorithm used is acceptable to the application, it should not accept the > JWT. > > > > -- > > > > 4) Thumbprint formats > > > > Section 4.1.7 and 4.1.8 defines a x5t and x5t#S256 thumbprints, but those > are over the whole certificate. > > > > With the thumbprints, it has been noted lately, that quite often it is > more useful to use the hash of the SubjectPublicKeyInfo object of the > > X.509 certificate, than the full X.509 certificate. This method has been > used in the raw public key methods (draft-ietf-tls-oob-pubkey, > draft-kivinen-ipsecme-oob-pubkey), and also in the DANE (it has two optio= ns > one for the full certificate and another for the SubjectPublicKeyInfo > object of the certificate). > > > > Using hash of the SubjectPublicKeyInfo object allows changing the > certificate without invalidiating the certificates, i.e. when changing CA= s, > or switching from SHA1 to SHA2 in certificates, or just renewing the > certificate. It also allows using raw public keys which do not have defin= ed > X.509 certificate format, but which can be converted to the > SubjectPublicKeyInfo object when calculating the thumbprints. This is ver= y > important in the Internet of Things type of things, which might not be > using the full X.509 certificates. > > > > This thumbprint definition matches existing practice in commonly used > software packages. For instance, both openssl and Windows use certificat= e > thumbprints of this kind. > > > > That being said, there=E2=80=99s nothing preventing another specification= from > defining a different thumbprint calculation over the SPKI information and= a > header parameter used to represent it. The header parameters are > extensible via a registry. > > > > -- > > > > 5) Terminology ordering. > > > > Terminology is not in any order. It would be useful to have it either in > logical order (i.e. define terms before they are used), or in alphabetica= l > order. > > > > Now for example the "JWS Protected Header" is used before it is defined i= n > the "JWS Signature", and "Header Paramater" is between "JWS Signature" an= d > "JWS Protected Header", also "JWS Signature" uses both "JWS Payload" and > "JWS Protected Header", and one of those is defined before and one after > the "JWS Signature". > > > > The terms are listed in top-down order, with related terms grouped > together. Thus =E2=80=9CJSON Web Signature=E2=80=9D is first, the member= s that make up a > JWS object are listed together in the order that they appear in a JWS, > etc. That being said, I=E2=80=99ll plan to review the orderings and make= sure that > they consistently follow those ordering rules. > > > > -- > > kivinen@iki.fi > > > > Thanks > again, > > -- Mike > > > --001a1133d09eff9f140502e548e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Sep 5, 2014 at 8:56 PM, Mike Jones <Michael.Jone= s@microsoft.com> wrote:

Thanks for the useful review, Tero.= =C2=A0 I=E2=80=99ve cc=E2=80=99ed the working group to make them aware of t= he contents of your review.=C2=A0 Also, Ri= chard Barnes, please see a request for a reply from you on one issue below.=C2=A0 Replie= s are inline below=E2=80=A6

=C2=A0

-----Original Message-----
From: Tero Kivinen [mailto:kivinen@iki.fi]
Sent: Thursday, September 04, 2014 5:03 AM
To: iesg@ietf.org; <= a href=3D"mailto:secdir@ietf.org" target=3D"_blank">secdir@ietf.org; ietf@ietf.org; draft-ietf-jose-json-web-signature.all@tools.ietf.org
Subject: Secdir review of draft-ietf-jose-json-web-signature-31

=C2=A0

I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG.=C2= =A0 These comments were written primarily for the benefit of the security a= rea directors.=C2=A0 Document editors and WG chairs should treat these comments just like any other last= call comments.

=C2=A0

Summary: This document has issues.

=C2=A0

This document is part of the jose-json document set, and describres the = JSON Web Signatures.

=C2=A0

The security considerations section includes text which says:<= /u>

=C2=A0

=C2=A0=C2=A0 The entire list of security considerations is beyond the sc= ope of

=C2=A0=C2=A0 this document, but some significant considerations are list= ed here.

=C2=A0

=C2=A0

but also lists quite a lot of security considerations. I think the secur= ity considerations covering this document should be in scope with the docum= ent. Of course there are generic security considerations which might be out= side the scope of this document, but I do not think we need to explictly mention those.

=C2=A0

Several reviewers have objec= ted to this sentence.=C2=A0 Its removal is planned.
=C2=A0

Also, additional security considera= tions will be described in the process of resolving Russ Housley=E2=80=99s = gen-art review comments.

=C2=A0

I have following issues about the draft:

=C2=A0

=C2=A0=C2=A0 1) "alg" and Protected Header

=C2=A0

=C2=A0=C2=A0 2) Hash inside "alg" and inside the signature<= /u>

=C2=A0

=C2=A0=C2=A0 3) There is no explict warning about the "alg" &q= uot;none".

=C2=A0

=C2=A0=C2=A0 4) Thumbprint formats

=C2=A0

There is also following nit:

=C2=A0

=C2=A0=C2=A0 5) Terminology ordering.

=C2=A0

----------------------------------------------------------------------

=C2=A0

1) "alg" and Protected Header

=C2=A0

Question: Shouldn't the "alg" header parameter be protecte= d by the signature, i.e. wouldn't it make sense to say MUST be in the &= quot;Protected Header"?

=C2=A0

If it is part of the "Unprotected Header" and is not protected= by the signature, that would allow all kind of attacks, i.e. changing the = "alg" to be "none" or changing the hash algorithm of th= e signature.

=C2=A0

If it should be part of the "Protected Header" then that would= mean that "Proteced Header" cannot be empty, as "alg" = is mandatory header parameter, and MUST be present.

=C2=A0

There are several cases where the text indicates that "Protected He= ader" could be empty, which would mean that "alg" could be p= art of the "Unprotected Header". (Section 5.1, 4. bullet; section= 7.2, "protected" element and other places in same section). In all examples the "alg" is always in the &qu= ot;Proteced Header".

=C2=A0

I think the draft needs text saying something about the situation where = "alg" is not in "Protected Header" in the security sect= ions section. I.e. either say, that it has been analyzed that there is no p= roblem even when the "alg" is not protected, and reference to such analysis, or otherwise add text/warning t= hat it MUST/SHOULD be in the "Protected Header". I do not know en= ough about the proposed signature algorithms to know which one is true, esp= ecially as there might be new algorithms in the future.

=C2=A0

Richard Barnes, do you want to answer this one?=C2=A0 You were the pri= mary advocate for allowing the algorithm to be unprotected in the JSON Seri= alization.

=C2=A0

As I recall, the motivation had to = do with the fact that, by default, CMS does not protect the algorithm (alth= ough it was later extended to enable it to be protected).=C2=A0 Some others= in the working group thought that having unprotected algorithms was a bad idea, in line with your comme= nt above.

The only need for protect= ion of the "alg" value is to prevent algorithm substitution attac= ks, as discussed in RFC 6211.
https://tools.ietf.org/html/rfc6211

= These attacks are fairly limited in their applicability, since they require= that:
=C2=A0* The attacker is able to compute an input that is valid fo= r the signature using a different, weaker algorithm
=C2=A0* The attacker= 's input is valid according to whatever application rules are being app= lied

=C2=A0* A relying party will accept the weaker algorithm
=
Given all those criteria, it seems reasonable that some signers might r= egard algorithm substitution attacks as an acceptable risk.=C2=A0 For examp= le, in an application that set explicit minimum algorithm requirements (e.g= ., SHA-3 only!), there may be no risk of a relying party accepting the weak= er algorithm.=C2=A0 Or the application payload might have low enough entrop= y that it's impossible to find a valid forged input.

= And if an application is concerned about algorithm substitution attacks, it= can protect itself by including the algorithm in the payload, as X.509 doe= s.

I would be happy to have some advisory text in the sec= urity considerations, but I don't think this rises to the level of SHOU= LD/MUST.

--Richard

=C2=A0

2) Hash inside "alg" and inside the signature

=C2=A0

Also in some cases the signature itself has the hash function stored int= ernally, i.e. RSASSA-PKCS1-V1_5 contains the hash function oid inside the s= ignature, so what should the implementation do if the "alg" param= eter outside the signature does not match the oid inside the signature? I.e the signature using "= ;alg" of "RS256", but inside the signature the oid is using = the "SHA1". Most crypto libraries will just take the oid from the= signature, and use that to verify the message. Adding some description what to do in such situation would be needed.

=C2=A0

I think there=E2=80=99s some= confusion here, since the JWS spec does not use any OIDs or ASN.1 for sign= atures.=C2=A0 Rather, the cryptographic operations to be performed are full= y specified by the =E2=80=9Calg=E2=80=9D value and the signatures are represented as base64url encoded octet sequences representing the sign= ature values produced by the signature algorithms.

=C2=A0

3) There is no explict warning about the "alg" "none"= ;.

=C2=A0

In the section 5.2 it says that "at least one signature ... MUST su= ccessfully validate", but that does not limit alg "none" out= from it. I.e. if the application policy is to "one signature needs to= validate", and it gets JWS that has "none" as one of the algorithms, then it will accept it.<= u>

=C2=A0

I think there should be warning here or in the security considerations s= ection about the "none" algorithm, especially as the algorithm it= self is defined in the different draft (perhaps just reference to the secti= on 8.5 of the [JWA] draft).

=C2=A0

This warning is present in t= he spec where the algorithm is defined =E2=80=93 specifically http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-31#section-8= .5.=C2=A0 (Note that the working group decided to define algorithms in = a separate spec than the ones in which they are used.)=

=C2=A0

Also note that it is up to applicat= ions which algorithms are acceptable in a given context =E2=80=93 not just = =E2=80=9Cnone=E2=80=9D but also other algorithms that might be deprecated o= r inappropriate for some other reason.=C2=A0 Unless the signature algorithm used is acceptable to the application, it should n= ot accept the JWT.

=C2=A0

4) Thumbprint formats

=C2=A0

Section 4.1.7 and 4.1.8 defines a x5t and x5t#S256 thumbprints, but thos= e are over the whole certificate.

=C2=A0

With the thumbprints, it has been noted lately, that quite often it is m= ore useful to use the hash of the SubjectPublicKeyInfo object of the=

X.509 certificate, than the full X.509 certificate. This method has been= used in the raw public key methods (draft-ietf-tls-oob-pubkey, draft-kivin= en-ipsecme-oob-pubkey), and also in the DANE (it has two options one for th= e full certificate and another for the SubjectPublicKeyInfo object of the certificate).

=C2=A0

Using hash of the SubjectPublicKeyInfo object allows changing the certif= icate without invalidiating the certificates, i.e. when changing CAs, or sw= itching from SHA1 to SHA2 in certificates, or just renewing the certificate= . It also allows using raw public keys which do not have defined X.509 certificate format, = but which can be converted to the SubjectPublicKeyInfo object when calculat= ing the thumbprints. This is very important in the Internet of Things type = of things, which might not be using the full X.509 certificates.

=C2=A0

This thumbprint definition m= atches existing practice in commonly used software packages.=C2=A0 For inst= ance, both openssl and Windows use certificate thumbprints of this kind.=

=C2=A0

That being said, there=E2=80=99s no= thing preventing another specification from defining a different thumbprint= calculation over the SPKI information and a header parameter used to repre= sent it.=C2=A0 The header parameters are extensible via a registry.

=C2=A0

5) Terminology ordering.

=C2=A0

Terminology is not in any order. It would be useful to have it either in= logical order (i.e. define terms before they are used), or in alphabetical= order.

=C2=A0

Now for example the "JWS Protected Header" is used before it i= s defined in the "JWS Signature", and "Header Paramater"= ; is between "JWS Signature" and "JWS Protected Header"= , also "JWS Signature" uses both "JWS Payload" and &quo= t;JWS Protected Header", and one of those is defined before and one after the "J= WS Signature".

=C2=A0

The terms are listed in top-= down order, with related terms grouped together.=C2=A0 Thus =E2=80=9CJSON W= eb Signature=E2=80=9D is first, the members that make up a JWS object are l= isted together in the order that they appear in a JWS, etc.=C2=A0 That being said, I=E2=80=99ll plan to review the orderin= gs and make sure that they consistently follow those ordering rules.=

=C2=A0

kivinen@iki.fi

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thanks again,

=C2=A0

--001a1133d09eff9f140502e548e3-- From nobody Mon Sep 15 07:56:29 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D66C71A036A; Mon, 15 Sep 2014 07:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.852 X-Spam-Level: X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham 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 5vJKKtsEEasL; Mon, 15 Sep 2014 07:56:24 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DE9A1A0363; Mon, 15 Sep 2014 07:56:22 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:33013 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XTXhR-000GDl-Ea; Mon, 15 Sep 2014 10:56:17 -0400 Message-ID: <5416FE10.3060608@bbn.com> Date: Mon, 15 Sep 2014 10:56:16 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Mike Jones , Kathleen Moriarty , "jose@ietf.org" , "jose-chairs@tools.ietf.org" , "draft-ietf-jose-json-web-key.all@tools.ietf.org" , "secdir@ietf.org" References: <4E1F6AAD24975D4BA5B16804296739439AEC00DB@TK5EX14MBXC292.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439AEC00DB@TK5EX14MBXC292.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary="------------050408030108070408080803" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/ao7rRkotzjSyOh7Aor1_fEdpNjI Subject: Re: [secdir] JWK member names, was: [jose] SECDIR review of draft-ietf-jose-json-web-key-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 14:56:26 -0000 This is a multi-part message in MIME format. --------------050408030108070408080803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mike, > Sure. Here's an analysis of the requirements about duplicate member names. > > There could be two very different kinds of objections to the present text: > > A. People think we have the semantics for duplicate identifiers wrong. > > B. People think we should explain the current semantics for duplicate > identifiers more clearly. > > I sure hope that we're dealing with B and not A. Stephen, which is > the nature of your critique of this text? > C- don't accept duplicate IDs, is what I was hoping for. I noted why allowing a recipient to accept a dup name, and use just the last instance, will likely lead to such behavior being perpetuated, based on PKIX experience. Also, in a reply to Tim, I think you argued that people have already implemented JOSE and so we ought not make any changes at this late stage. If that's what you said, I disagree emphatically. The IETF always warns implementers that specs may change until an RFC is published, and thus one implements a pre-RFC spec at risk. Steve --------------050408030108070408080803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mike,

Sure. Here’s an analysis of the requirements about duplicate member names.

There could be two very different kinds of objections to the present text:

A. People think we have the semantics for duplicate identifiers wrong.

B. People think we should explain the current semantics for duplicate identifiers more clearly.

I sure hope that we’re dealing with B and not A. Stephen, which is the nature of your critique of this text?

C- don't accept duplicate IDs, is what I was hoping for.

I noted why allowing a recipient to accept a dup name, and use just the last instance, will
likely lead to such behavior being perpetuated, based on PKIX experience.

Also, in a reply to Tim, I think you argued that people have already implemented JOSE and so
we ought not make any changes at this late stage. If that's what you said, I disagree emphatically.
The IETF always warns implementers that specs may change until an RFC is published, and thus
one implements a pre-RFC spec at risk.

Steve
--------------050408030108070408080803-- From nobody Mon Sep 15 09:51:12 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3E81A8727 for ; Mon, 15 Sep 2014 09:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 nISgTbcVJ2qb for ; Mon, 15 Sep 2014 09:48:04 -0700 (PDT) Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F22D1A8725 for ; Mon, 15 Sep 2014 09:13:34 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id hy10so3657366vcb.33 for ; Mon, 15 Sep 2014 09:13:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=apONAkUtMrdm/3ZShR+XOgbqwCqx9VqOdn1V7ixJBGU=; b=IfdqQBbWNGZwvG1oyFxpCzHajSfulb6QxlZpNWmOlKT01HfYuDip6QzZvmcOEAWwrZ m0jV96n5kS8Vs5EBjlh+a7GrBDvtOsc7SXFoG62c4HCcAUdtQ21z1FIlJblhQdySw9kc /lQmlKxPAhR5vBhzl3+js9+0ZwWnbcrnfjzpqvFiIf4vaNaZT6dSnH+D7A71SGuW8iAL jsJ9o4Hj2mXkzB9M934zFXCLQmoykF2CqbB7lDPonVF7g8kmQQP8Of6JALRRYVVVLDis odBz4HdojKqOnhrIWqOIlljbENDZE6/S49gaqqcxbOB6Sh5IzcOuSKN83yyLrOH4NRE/ UZCQ== X-Gm-Message-State: ALoCoQnhZSXJxXP5Fk/yWlyWREy78q432OG/N499lSHF/JxOCy+dgP2gOb1sQo6bdA9SPD+Aiv3U X-Received: by 10.52.183.136 with SMTP id em8mr1829418vdc.76.1410797613274; Mon, 15 Sep 2014 09:13:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.214.4 with HTTP; Mon, 15 Sep 2014 09:13:13 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <5416FE10.3060608@bbn.com> References: <4E1F6AAD24975D4BA5B16804296739439AEC00DB@TK5EX14MBXC292.redmond.corp.microsoft.com> <5416FE10.3060608@bbn.com> From: Tim Bray Date: Mon, 15 Sep 2014 09:13:13 -0700 Message-ID: To: Stephen Kent Content-Type: multipart/alternative; boundary=bcaec5489e4396f24905031ceac1 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/YkX1UWCh4rCmuQLgQaeDVRvkL3Q X-Mailman-Approved-At: Mon, 15 Sep 2014 09:51:11 -0700 Cc: "jose-chairs@tools.ietf.org" , "secdir@ietf.org" , "draft-ietf-jose-json-web-key.all@tools.ietf.org" , Kathleen Moriarty , Mike Jones , "jose@ietf.org" Subject: Re: [secdir] [jose] JWK member names, was: SECDIR review of draft-ietf-jose-json-web-key-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 16:48:08 -0000 --bcaec5489e4396f24905031ceac1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Sep 15, 2014 at 7:56 AM, Stephen Kent wrote: > Also, in a reply to Tim, I think you argued that people have already > implemented JOSE and so > we ought not make any changes at this late stage. If that's what you said= , > I disagree emphatically. > The IETF always warns implementers that specs may change until an RFC is > published, and thus > one implements a pre-RFC spec at risk. > =E2=80=8BNo; In theory I would entirely support requiring receivers of malf= ormed messages to reject them. In practice, it=E2=80=99s problematic to say that the format is JSON, and t= hen to require any particular policy concerning duplicate keys, because existing software generally doesn=E2=80=99t handle them in a consistent manner, and = in particular may not even inform receiving software that dupes existed. > > Steve > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --bcaec5489e4396f24905031ceac1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On = Mon, Sep 15, 2014 at 7:56 AM, Stephen Kent <kent@bbn.com> wrote:<= br>

=C2=A0<= /div>

Also, in a reply to Tim, I think you argued that people have already implemented JOSE and so
we ought not make any changes at this late stage. If that's what yo= u said, I disagree emphatically.
The IETF always warns implementers that specs may change until an RFC is published, and thus
one implements a pre-RFC spec at risk.

<= /div>

=E2=80=8BN= o; In theory I would entirely support requiring receivers of malformed mess= ages to reject them.

In p= ractice, it=E2=80=99s problematic to say that the format is JSON, and then = to require any particular policy concerning duplicate keys, because existin= g software generally doesn=E2=80=99t handle them in a consistent manner, an= d in particular may not even inform receiving software that dupes existed.<= /div>

=C2=A0

Steve

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

- Tim Bray (If you=E2=80=99d like to send me a private messag= e, see https://key= base.io/timbray)

--bcaec5489e4396f24905031ceac1-- From nobody Mon Sep 15 09:51:41 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C941B1ACD2A; Mon, 15 Sep 2014 09:51:38 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 Hk4eY2MO0JqU; Mon, 15 Sep 2014 09:51:35 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0103.outbound.protection.outlook.com [207.46.100.103]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 100CE1A03A9; Mon, 15 Sep 2014 09:17:48 -0700 (PDT) Received: from BN3PR0301CA0084.namprd03.prod.outlook.com (25.160.152.180) by BY1PR0301MB0837.namprd03.prod.outlook.com (25.160.193.143) with Microsoft SMTP Server (TLS) id 15.0.1029.13; Mon, 15 Sep 2014 16:17:47 +0000 Received: from BN1AFFO11FD043.protection.gbl (2a01:111:f400:7c10::153) by BN3PR0301CA0084.outlook.office365.com (2a01:111:e400:401e::52) with Microsoft SMTP Server (TLS) id 15.0.1029.13 via Frontend Transport; Mon, 15 Sep 2014 16:17:47 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD043.mail.protection.outlook.com (10.58.52.190) with Microsoft SMTP Server (TLS) id 15.0.1019.14 via Frontend Transport; Mon, 15 Sep 2014 16:17:46 +0000 Received: from TK5EX14MBXC292.redmond.corp.microsoft.com ([169.254.1.60]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.03.0195.002; Mon, 15 Sep 2014 16:17:38 +0000 From: Mike Jones To: Stephen Kent , Kathleen Moriarty , "jose@ietf.org" , "jose-chairs@tools.ietf.org" , "draft-ietf-jose-json-web-key.all@tools.ietf.org" , "secdir@ietf.org" Thread-Topic: JWK member names, was: [jose] SECDIR review of draft-ietf-jose-json-web-key-31 Thread-Index: AQHPzoESD2WvkanDakGRB2XPz/nr6pv9mXgQgASz7ACAABG9IA== Date: Mon, 15 Sep 2014 16:17:37 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439AECCC93@TK5EX14MBXC292.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739439AEC00DB@TK5EX14MBXC292.redmond.corp.microsoft.com> <5416FE10.3060608@bbn.com> In-Reply-To: <5416FE10.3060608@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439AECCC93TK5EX14MBXC292r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(189002)(377454003)(199003)(84326002)(84676001)(83322001)(85806002)(15975445006)(44976005)(512954002)(86612001)(6806004)(77096002)(19300405004)(87936001)(16236675004)(2656002)(33656002)(31966008)(74662001)(19625215002)(26826002)(15202345003)(86362001)(76482001)(81342001)(81542001)(71186001)(46102001)(54356999)(99396002)(76176999)(50986999)(85852003)(83072002)(79102001)(55846006)(92566001)(92726001)(2201001)(77982001)(104016003)(107046002)(107886001)(2501002)(69596002)(19580395003)(19580405001)(68736004)(64706001)(97736003)(20776003)(80022001)(66066001)(90102001)(230783001)(85306004)(21056001)(74502001)(4396001)(106466001)(95666004)(81156004)(106116001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0301MB0837; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 03355EE97E Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/qlH_SB11j4RJ-S-fiFPMllqXxp8 Subject: Re: [secdir] JWK member names, was: [jose] SECDIR review of draft-ietf-jose-json-web-key-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 16:51:39 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439AECCC93TK5EX14MBXC292r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Replies inline below... From: Stephen Kent [mailto:kent@bbn.com] Sent: Monday, September 15, 2014 7:56 AM To: Mike Jones; Kathleen Moriarty; jose@ietf.org; jose-chairs@tools.ietf.or= g; draft-ietf-jose-json-web-key.all@tools.ietf.org; secdir@ietf.org Subject: Re: JWK member names, was: [jose] SECDIR review of draft-ietf-jose= -json-web-key-31 Mike, Sure. Here's an analysis of the requirements about duplicate member names. There could be two very different kinds of objections to the present text: A. People think we have the semantics for duplicate identifiers wrong. B. People think we should explain the current semantics for duplicate iden= tifiers more clearly. I sure hope that we're dealing with B and not A. Stephen, which is the nat= ure of your critique of this text? C- don't accept duplicate IDs, is what I was hoping for. I noted why allowing a recipient to accept a dup name, and use just the las= t instance, will likely lead to such behavior being perpetuated, based on PKIX experience. So you're advocating this alternative from the analysis, correct? 1. Require producers not use duplicate members and require consumers to re= ject inputs with duplicate member names. Pros: This is the most locked-down, consistent, and alternative. Cons: Real JSON parsers don't all reject duplicate inputs. If we force pe= ople to write custom parsers, this will result in exploitable bugs (and som= e just won't do it and won't be conformant). The primary reason that the working group changed from this alternative in = draft -12 in July 2013 to the present one is that it allows JSON parsers as= actually deployed and supported to be used. The argument made then was th= at forcing people to write a custom parser to reject duplicate member names= is likely to create security bugs, since insufficiently locked down parser= s are a fertile area for security vulnerabilities. It was thought that it = was better to have people using well-maintained, standard parsers and count= on producers to not emit duplicate member names in the first place. Is th= ere some aspect of this reasoning that doesn't seem convincing to you, Step= hen? As for perpetuating the behavior, it's not clear to me that the behavior wi= ll ever start, since producers can't use duplicate member names and consume= rs are allowed to reject them. Thus, producers can't count on consumers ac= cepting the illegal inputs, and so have a strong disincentive against ever = producing them. Is there something I'm missing here? Also, in a reply to Tim, I think you argued that people have already implem= ented JOSE and so we ought not make any changes at this late stage. If that's what you said, = I disagree emphatically. The IETF always warns implementers that specs may change until an RFC is pu= blished, and thus one implements a pre-RFC spec at risk. You apparently misunderstood the point of my reply to Tim. I wasn't saying= that changes aren't possible. I was saying that we want JOSE to be usable= by people now - not just several years in the future when parsers for a mo= re locked-down JSON dialect may become available. Steve -- Mike --_000_4E1F6AAD24975D4BA5B16804296739439AECCC93TK5EX14MBXC292r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Replies inline below̷= 0;

<= /p>

From: Stephen Kent [mailto:kent@bbn.com]
Sent: Monday, September 15, 2014 7:56 AM
To: Mike Jones; Kathleen Moriarty; jose@ietf.org; jose-chairs@tools.= ietf.org; draft-ietf-jose-json-web-key.all@tools.ietf.org; secdir@ietf.org<= br> Subject: Re: JWK member names, was: [jose] SECDIR review of draft-ie= tf-jose-json-web-key-31

Mike,

Sure. Here’s = an analysis of the requirements about duplicate member names.

<= /p>
There could be two very d= ifferent kinds of objections to the present text:

A. People think we = have the semantics for duplicate identifiers wrong.

B. People think we = should explain the current semantics for duplicate identifiers more clearly= .

<= /p>
I sure hope that we’= ;re dealing with B and not A. Stephen, which is the nature of your cr= itique of this text?

C- don't accept duplicate IDs, is what I was hoping = for.

I noted why allowing a recipient to accept a dup nam= e, and use just the last instance, will
likely lead to such behavior being perpetuated, based on PKIX experience.

So you’re advocatin= g this alternative from the analysis, correct?

The primary reason that the working group= changed from this alternative in draft -12 in July 2013 to the present one is that i= t allows JSON parsers as actually deployed and supported to be used. = The argument made then was that forcing people to write a custom parser to reject duplicate member names is likely to create security bugs,= since insufficiently locked down parsers are a fertile area for security v= ulnerabilities. It was thought that it was better to have people usin= g well-maintained, standard parsers and count on producers to not emit duplicate member names in the first place.&= nbsp; Is there some aspect of this reasoning that doesn’t seem convin= cing to you, Stephen?

<= /p>

As for perpetuating the b= ehavior, it’s not clear to me that the behavior will ever start, sinc= e producers can’t use duplicate member names and consumers are allowed to reject them. Thus, producers can’t count on consume= rs accepting the illegal inputs, and so have a strong disincentive against = ever producing them. Is there something I’m missing here?

Also, in a reply to Tim, I think you argued that people have already= implemented JOSE and so
we ought not make any changes at this late stage. If that's what you said, = I disagree emphatically.
The IETF always warns implementers that specs may change until an RFC is pu= blished, and thus
one implements a pre-RFC spec at risk.

You apparently misunderst= ood the point of my reply to Tim. I wasn’t saying that changes = aren’t possible. I was saying that we want JOSE to be usable by= people now – not just several years in the future when parsers for a more l= ocked-down JSON dialect may become available.

Steve

<= /p>

&= nbsp; &nbs= p; &= nbsp; &nbs= p; &= nbsp; -- Mike

<= /p>

--_000_4E1F6AAD24975D4BA5B16804296739439AECCC93TK5EX14MBXC292r_-- From nobody Mon Sep 15 09:54:40 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 602E01A03A0; Mon, 15 Sep 2014 09:54: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, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 3OlNx5-yPdQn; Mon, 15 Sep 2014 09:54:36 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0797.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::797]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F55F1A878D; Mon, 15 Sep 2014 09:21:20 -0700 (PDT) Received: from BY2PR03CA065.namprd03.prod.outlook.com (10.141.249.38) by BY2PR03MB157.namprd03.prod.outlook.com (10.242.36.12) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Mon, 15 Sep 2014 16:20:57 +0000 Received: from BL2FFO11FD016.protection.gbl (2a01:111:f400:7c09::139) by BY2PR03CA065.outlook.office365.com (2a01:111:e400:2c5d::38) with Microsoft SMTP Server (TLS) id 15.0.1029.13 via Frontend Transport; Mon, 15 Sep 2014 16:20:57 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD016.mail.protection.outlook.com (10.173.160.224) with Microsoft SMTP Server (TLS) id 15.0.1019.14 via Frontend Transport; Mon, 15 Sep 2014 16:20:56 +0000 Received: from TK5EX14MBXC292.redmond.corp.microsoft.com ([169.254.1.60]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.193]) with mapi id 14.03.0195.002; Mon, 15 Sep 2014 16:20:04 +0000 From: Mike Jones To: Tim Bray , Stephen Kent Thread-Topic: [jose] JWK member names, was: SECDIR review of draft-ietf-jose-json-web-key-31 Thread-Index: AQHP0QAJrqBafxnciEq+15U92qOPJ5wCX4gg Date: Mon, 15 Sep 2014 16:20:03 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439AECCCDD@TK5EX14MBXC292.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739439AEC00DB@TK5EX14MBXC292.redmond.corp.microsoft.com> <5416FE10.3060608@bbn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439AECCCDDTK5EX14MBXC292r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(438002)(377454003)(24454002)(189002)(199003)(33656002)(87936001)(81156004)(106466001)(19617315012)(85806002)(90102001)(26826002)(104016003)(19625215002)(68736004)(106116001)(46102001)(2656002)(107046002)(76482001)(16236675004)(69596002)(512874002)(15202345003)(15975445006)(50986999)(92566001)(71186001)(86362001)(54356999)(76176999)(92726001)(81342001)(81542001)(6806004)(99396002)(64706001)(44976005)(55846006)(19580405001)(79102001)(85852003)(83072002)(83322001)(19580395003)(19300405004)(20776003)(66066001)(4396001)(80022001)(77982001)(95666004)(230783001)(97736003)(74662001)(93886004)(84326002)(85306004)(86612001)(84676001)(31966008)(74502001)(77096002)(21056001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB157; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 03355EE97E Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/nSZMrdGseISAE-xK7hgWIop65E0 Cc: "draft-ietf-jose-json-web-key.all@tools.ietf.org" , Kathleen Moriarty , "jose-chairs@tools.ietf.org" , "jose@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] [jose] JWK member names, was: SECDIR review of draft-ietf-jose-json-web-key-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 16:54:39 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439AECCCDDTK5EX14MBXC292r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIFRpbSDigJMgdGhhdCB3YXMgZXhhY3RseSB0aGUgcG9pbnQgdGhhdCBjYXVzZWQgdGhl IHdvcmtpbmcgZ3JvdXAgdG8gY2hhbmdlIHRvIHRoZSBjdXJyZW50IGJlaGF2aW9yLg0KDQpGcm9t OiBUaW0gQnJheSBbbWFpbHRvOnRicmF5QHRleHR1YWxpdHkuY29tXQ0KU2VudDogTW9uZGF5LCBT ZXB0ZW1iZXIgMTUsIDIwMTQgOToxMyBBTQ0KVG86IFN0ZXBoZW4gS2VudA0KQ2M6IE1pa2UgSm9u ZXM7IEthdGhsZWVuIE1vcmlhcnR5OyBqb3NlQGlldGYub3JnOyBqb3NlLWNoYWlyc0B0b29scy5p ZXRmLm9yZzsgZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWtleS5hbGxAdG9vbHMuaWV0Zi5vcmc7 IHNlY2RpckBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtqb3NlXSBKV0sgbWVtYmVyIG5hbWVzLCB3 YXM6IFNFQ0RJUiByZXZpZXcgb2YgZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWtleS0zMQ0KDQpP biBNb24sIFNlcCAxNSwgMjAxNCBhdCA3OjU2IEFNLCBTdGVwaGVuIEtlbnQgPGtlbnRAYmJuLmNv bTxtYWlsdG86a2VudEBiYm4uY29tPj4gd3JvdGU6DQoNCkFsc28sIGluIGEgcmVwbHkgdG8gVGlt LCBJIHRoaW5rIHlvdSBhcmd1ZWQgdGhhdCBwZW9wbGUgaGF2ZSBhbHJlYWR5IGltcGxlbWVudGVk IEpPU0UgYW5kIHNvDQp3ZSBvdWdodCBub3QgbWFrZSBhbnkgY2hhbmdlcyBhdCB0aGlzIGxhdGUg c3RhZ2UuIElmIHRoYXQncyB3aGF0IHlvdSBzYWlkLCBJIGRpc2FncmVlIGVtcGhhdGljYWxseS4N ClRoZSBJRVRGIGFsd2F5cyB3YXJucyBpbXBsZW1lbnRlcnMgdGhhdCBzcGVjcyBtYXkgY2hhbmdl IHVudGlsIGFuIFJGQyBpcyBwdWJsaXNoZWQsIGFuZCB0aHVzDQpvbmUgaW1wbGVtZW50cyBhIHBy ZS1SRkMgc3BlYyBhdCByaXNrLg0KDQrigItObzsgSW4gdGhlb3J5IEkgd291bGQgZW50aXJlbHkg c3VwcG9ydCByZXF1aXJpbmcgcmVjZWl2ZXJzIG9mIG1hbGZvcm1lZCBtZXNzYWdlcyB0byByZWpl Y3QgdGhlbS4NCg0KSW4gcHJhY3RpY2UsIGl04oCZcyBwcm9ibGVtYXRpYyB0byBzYXkgdGhhdCB0 aGUgZm9ybWF0IGlzIEpTT04sIGFuZCB0aGVuIHRvIHJlcXVpcmUgYW55IHBhcnRpY3VsYXIgcG9s aWN5IGNvbmNlcm5pbmcgZHVwbGljYXRlIGtleXMsIGJlY2F1c2UgZXhpc3Rpbmcgc29mdHdhcmUg Z2VuZXJhbGx5IGRvZXNu4oCZdCBoYW5kbGUgdGhlbSBpbiBhIGNvbnNpc3RlbnQgbWFubmVyLCBh bmQgaW4gcGFydGljdWxhciBtYXkgbm90IGV2ZW4gaW5mb3JtIHJlY2VpdmluZyBzb2Z0d2FyZSB0 aGF0IGR1cGVzIGV4aXN0ZWQuDQoNCg0KDQoNClN0ZXZlDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpqb3NlIG1haWxpbmcgbGlzdA0Kam9zZUBpZXRm Lm9yZzxtYWlsdG86am9zZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vam9zZQ0KDQoNCg0KLS0NCi0gVGltIEJyYXkgKElmIHlvdeKAmWQgbGlrZSB0byBz ZW5kIG1lIGEgcHJpdmF0ZSBtZXNzYWdlLCBzZWUgaHR0cHM6Ly9rZXliYXNlLmlvL3RpbWJyYXkp DQo= --_000_4E1F6AAD24975D4BA5B16804296739439AECCCDDTK5EX14MBXC292r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIFRpbSDigJMg dGhhdCB3YXMgZXhhY3RseSB0aGUgcG9pbnQgdGhhdCBjYXVzZWQgdGhlIHdvcmtpbmcgZ3JvdXAg dG8gY2hhbmdlIHRvIHRoZSBjdXJyZW50IGJlaGF2aW9yLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4gVGltIEJyYXkgW21haWx0bzp0YnJheUB0ZXh0dWFsaXR5LmNv bV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIFNlcHRlbWJlciAxNSwgMjAxNCA5OjEzIEFN PGJyPg0KPGI+VG86PC9iPiBTdGVwaGVuIEtlbnQ8YnI+DQo8Yj5DYzo8L2I+IE1pa2UgSm9uZXM7 IEthdGhsZWVuIE1vcmlhcnR5OyBqb3NlQGlldGYub3JnOyBqb3NlLWNoYWlyc0B0b29scy5pZXRm Lm9yZzsgZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWtleS5hbGxAdG9vbHMuaWV0Zi5vcmc7IHNl Y2RpckBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2pvc2VdIEpXSyBtZW1iZXIg bmFtZXMsIHdhczogU0VDRElSIHJldmlldyBvZiBkcmFmdC1pZXRmLWpvc2UtanNvbi13ZWIta2V5 LTMxPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwg U2VwIDE1LCAyMDE0IGF0IDc6NTYgQU0sIFN0ZXBoZW4gS2VudCAmbHQ7PGEgaHJlZj0ibWFpbHRv OmtlbnRAYmJuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmtlbnRAYmJuLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbHNvLCBpbiBhIHJlcGx5IHRvIFRpbSwgSSB0aGlu ayB5b3UgYXJndWVkIHRoYXQgcGVvcGxlIGhhdmUgYWxyZWFkeSBpbXBsZW1lbnRlZCBKT1NFIGFu ZCBzbzxicj4NCndlIG91Z2h0IG5vdCBtYWtlIGFueSBjaGFuZ2VzIGF0IHRoaXMgbGF0ZSBzdGFn ZS4gSWYgdGhhdCdzIHdoYXQgeW91IHNhaWQsIEkgZGlzYWdyZWUgZW1waGF0aWNhbGx5Ljxicj4N ClRoZSBJRVRGIGFsd2F5cyB3YXJucyBpbXBsZW1lbnRlcnMgdGhhdCBzcGVjcyBtYXkgY2hhbmdl IHVudGlsIGFuIFJGQyBpcyBwdWJsaXNoZWQsIGFuZCB0aHVzPGJyPg0Kb25lIGltcGxlbWVudHMg YSBwcmUtUkZDIHNwZWMgYXQgcmlzay48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAi05vOyBJbiB0aGVv cnkgSSB3b3VsZCBlbnRpcmVseSBzdXBwb3J0IHJlcXVpcmluZyByZWNlaXZlcnMgb2YgbWFsZm9y bWVkIG1lc3NhZ2VzIHRvIHJlamVjdCB0aGVtLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBwcmFjdGljZSwgaXTigJlzIHByb2JsZW1hdGlj IHRvIHNheSB0aGF0IHRoZSBmb3JtYXQgaXMgSlNPTiwgYW5kIHRoZW4gdG8gcmVxdWlyZSBhbnkg cGFydGljdWxhciBwb2xpY3kgY29uY2VybmluZyBkdXBsaWNhdGUga2V5cywgYmVjYXVzZSBleGlz dGluZyBzb2Z0d2FyZSBnZW5lcmFsbHkgZG9lc27igJl0IGhhbmRsZSB0aGVtIGluIGEgY29uc2lz dGVudCBtYW5uZXIsIGFuZCBpbiBwYXJ0aWN1bGFyIG1heSBub3QNCiBldmVuIGluZm9ybSByZWNl aXZpbmcgc29mdHdhcmUgdGhhdCBkdXBlcyBleGlzdGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KU3RldmU8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCmpvc2UgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmpv c2VAaWV0Zi5vcmciPmpvc2VAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qb3NlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qb3NlPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnIgY2xlYXI9 ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gVGltIEJyYXkg KElmIHlvdeKAmWQgbGlrZSB0byBzZW5kIG1lIGEgcHJpdmF0ZSBtZXNzYWdlLCBzZWUgPGEgaHJl Zj0iaHR0cHM6Ly9rZXliYXNlLmlvL3RpbWJyYXkiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8v a2V5YmFzZS5pby90aW1icmF5PC9hPik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4E1F6AAD24975D4BA5B16804296739439AECCCDDTK5EX14MBXC292r_-- From nobody Mon Sep 15 11:39:13 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69CFF1A87E3 for ; Mon, 15 Sep 2014 11:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.031 X-Spam-Level: X-Spam-Status: No, score=-3.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=unavailable 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 k2-sm5-LAa2c for ; Mon, 15 Sep 2014 11:39:11 -0700 (PDT) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71BB91A8991 for ; Mon, 15 Sep 2014 11:12:03 -0700 (PDT) Received: by mail-qc0-f177.google.com with SMTP id o8so4246272qcw.22 for ; Mon, 15 Sep 2014 11:12:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=DJXh3W07zYF5kmiBYhNYsR9jF9Xx4aMEgYJcc30/c8Y=; b=IW7eLVgFHTPZ3bgVRibyb98jZVA3qM8AaAYZ15McRL37uL7nXfhUISUPEAVZZ5A/FK 6vJax0FzQtQpdtshNA0coupxo66XHNSaJbx23G3cFnwy2ZZskbKLjLDGFCWKdxI0m2WP A4IFZ6Zx3XVLV18ZyeHm9GHTmIxxMq771DA0cZe/pQFoBj4U3kU5hgNm91gM2BRMNiPH IgnTRzok2I6cZzlc6DZa92HDSo6NIGaMjUVON0WLazdlL+UPOYYd6OaoHGHAVFjRGeuy C9fshwErn1bJoEzoh5LyKF2FPDqq14PjcNOJwuwlIoTXp41QkM/ojl/AAK+itHs7TNId 6seQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=DJXh3W07zYF5kmiBYhNYsR9jF9Xx4aMEgYJcc30/c8Y=; b=KqBQMLFkUwb+J8LutnzhuRdmIaZle6e91Q6bcTVn24kf9KfvaI3zJcYjQGbSIsu74d Mp1AgGSJ8hpF6g3W98V4fNyfSvJTDWUPsxULRZbTMXD7gh/LCEi28EVzV15+exkf7RWF ZxjRKZoTTdiuMZlJa9yhajafE4wtFsvGZHl2ScoLhd5h1fqjfqNSBgHlVhAvrV7x78JJ juwPecWCeDe9VgxZYva1LHknZuy14lrtCgTy+05hUm9htp1KY92hlXDgP3Yk/gBPc4lw EX9XNwX/toICtLicuQa9CP2uV1Z9d1B/biMqDOvA9GBK7kJ4ljuiEQgx+76W+gNnizEI u1cg== X-Gm-Message-State: ALoCoQlqgu6SXTuMWEtmrVBvosyLb5BRAOWxS9ASORabFrgDGJKbQQrmXOO5fIFBrj/G/51do/DU MIME-Version: 1.0 X-Received: by 10.140.23.17 with SMTP id 17mr5046109qgo.30.1410804720253; Mon, 15 Sep 2014 11:12:00 -0700 (PDT) Received: by 10.229.247.198 with HTTP; Mon, 15 Sep 2014 11:12:00 -0700 (PDT) Date: Mon, 15 Sep 2014 19:12:00 +0100 Message-ID: From: Ben Laurie To: The IESG , "secdir@ietf.org" , draft-ietf-avtcore-aria-srtp.all@tools.ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/gg_NnFaTTRVfSEXF02nu9GHzEmY Subject: [secdir] draft-ietf-avtcore-aria-srtp-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 18:39:12 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: ready with issues, or maybe not ready (AD's choice!) Firstly, I'm not generally keen on RFCs for "vanity" ciphers - or, indeed, any cipher that's been as lightly reviewed as ARIA has. The Security ADs may feel differently, so I defer to them. Secondly, ARIA-CTR and ARIA-GCM both use SHA-1 as a hash function, and I believe we are trying to deprecate that practice. Thirdly, I am not familiar enough with SRTP to understand why short authentication tags are needed, but in general its a bad idea, so I feel the Security Considerations should explain more fully than "Ciphersuites with short tag length may be considered for specific application environments stated in 7.5 of [RFC3711], but the risk of weak authentication described in Section 9.5.1 of [RFC3711] should be taken into account." How would I take this risk into account? Finally, given that short tags are a risk, why are there no modes with full-length tags? From nobody Mon Sep 15 12:01:35 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2FD91A8723; Mon, 15 Sep 2014 12:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.852 X-Spam-Level: X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham 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 F9HGX_A_QKfH; Mon, 15 Sep 2014 12:01:21 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62CDC1A6FCE; Mon, 15 Sep 2014 11:51:23 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:33094 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XTbN2-000PNE-K8; Mon, 15 Sep 2014 14:51:28 -0400 Message-ID: <5417351F.3050706@bbn.com> Date: Mon, 15 Sep 2014 14:51:11 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Mike Jones , Kathleen Moriarty , "jose@ietf.org" , "jose-chairs@tools.ietf.org" , "draft-ietf-jose-json-web-key.all@tools.ietf.org" , "secdir@ietf.org" References: <4E1F6AAD24975D4BA5B16804296739439AEC00DB@TK5EX14MBXC292.redmond.corp.microsoft.com> <5416FE10.3060608@bbn.com> <4E1F6AAD24975D4BA5B16804296739439AECCC93@TK5EX14MBXC292.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439AECCC93@TK5EX14MBXC292.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary="------------090207070302040409080400" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/WYzrrj46ASILbcL60r20DQl8NQA Subject: Re: [secdir] JWK member names, was: [jose] SECDIR review of draft-ietf-jose-json-web-key-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 19:01:26 -0000 This is a multi-part message in MIME format. --------------090207070302040409080400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mike, > ... > > > So you're advocating this alternative from the analysis, correct? > > 1. Require producers not use duplicate members and require consumers > to reject inputs with duplicate member names. > > Pros: This is the most locked-down, consistent, and alternative. > > Cons: Real JSON parsers don't all reject duplicate inputs. If we > force people to write custom parsers, this will result in exploitable > bugs (and some just won't do it and won't be conformant). > > > The primary reason that the working group changed from this > alternative in draft -12 in July 2013 to the present one is that it > allows JSON parsers as actually deployed and supported to be used. > The argument made then was that forcing people to write a custom > parser to reject duplicate member names is likely to create security > bugs, since insufficiently locked down parsers are a fertile area for > security vulnerabilities. It was thought that it was better to have > people using well-maintained, standard parsers and count on producers > to not emit duplicate member names in the first place. Is there some > aspect of this reasoning that doesn't seem convincing to you, Stephen? > I read the rationale. Is there a good baseline of experience showing that JSON parsers are not very exploitable today? We have seen problems with ASN.1 parsers, problems that have taken years to surface, despite extensive use of ASN.1 in both certs and in SNMP. I suggest, without substantiation, that bugs in ASN.1 parsers were not exploited in the SNMP context because there was little to gain. Use of ASN.1 for certs, where there can be financial incentives for exploiting flaws, motivated more analysis by attackers. If JOSE represents an initial step into an arena where crypto is to be applied to JSON in a widespread fashion, it also may represent a new motivation for attackers to try to exploit any bugs in parsers. If so, then the lack of identified vulnerabilities in JSON parsers so far may not be indicative of their security. > ... > > > You apparently misunderstood the point of my reply to Tim. I wasn't > saying that changes aren't possible. I was saying that we want JOSE > to be usable by people now -- not just several years in the future > when parsers for a more locked-down JSON dialect may become available. I did misunderstand your point, perhaps because you said: "I understand that that's an ideal long-term solution, once I-JSON parsers are common/ubiquitous, but I don't expect that to be the case for a number of years and _*people are using JOSE now.*_" Steve --------------090207070302040409080400 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mike,

...

So you’re advocating this alternative from the analysis, correct?

1. Require producers not use duplicate members and require consumers to reject inputs with duplicate member names.

Pros: This is the most locked-down, consistent, and alternative.

Cons: Real JSON parsers don’t all reject duplicate inputs. If we force people to write custom parsers, this will result in exploitable bugs (and some just won’t do it and won’t be conformant).

The primary reason that the working group changed from this alternative in draft -12 in July 2013 to the present one is that it allows JSON parsers as actually deployed and supported to be used. The argument made then was that forcing people to write a custom parser to reject duplicate member names is likely to create security bugs, since insufficiently locked down parsers are a fertile area for security vulnerabilities. It was thought that it was better to have people using well-maintained, standard parsers and count on producers to not emit duplicate member names in the first place. Is there some aspect of this reasoning that doesn’t seem convincing to you, Stephen?

I read the rationale. Is there a good baseline of experience showing that JSON parsers are
not very exploitable today? We have seen problems with ASN.1 parsers, problems that have
taken years to surface, despite extensive use of ASN.1 in both certs and in SNMP. I suggest,
without substantiation, that bugs in ASN.1 parsers were not exploited in the SNMP context
because there was little to gain. Use of ASN.1 for certs, where there can be financial incentives
for exploiting flaws, motivated more analysis by attackers. If JOSE represents an initial
step into an arena where crypto is to be applied to JSON in a widespread fashion, it also
may represent a new motivation for attackers to try to exploit any bugs in parsers. If so, then
the lack of identified vulnerabilities in JSON parsers so far may not be indicative of their
security.

...

You apparently misunderstood the point of my reply to Tim. I wasn’t saying that changes aren’t possible. I was saying that we want JOSE to be usable by people now – not just several years in the future when parsers for a more locked-down JSON dialect may become available.

I did misunderstand your point, perhaps because you said:

"I understand that that’s an ideal long-term solution, once I-JSON parsers are common/ubiquitous, but I don’t expect that to be the case for a number of years and people are using JOSE now."

Steve
--------------090207070302040409080400-- From nobody Mon Sep 15 12:02:25 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69EFB1A7009; Mon, 15 Sep 2014 12:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham 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 YFO_IaAE7O4B; Mon, 15 Sep 2014 12:02:15 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FD111A7014; Mon, 15 Sep 2014 11:51:57 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:33096 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XTbNe-000PNW-Rh; Mon, 15 Sep 2014 14:52:07 -0400 Message-ID: <54173546.5000400@bbn.com> Date: Mon, 15 Sep 2014 14:51:50 -0400 From: Stephen Kent

--001a11c3dbe45d8b7905031f2baf-- From nobody Mon Sep 15 13:41:56 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 685371A002F for ; Mon, 15 Sep 2014 12:19:10 -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 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 hTuvOY4NaAg4 for ; Mon, 15 Sep 2014 12:19:08 -0700 (PDT) Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5281B1A0026 for ; Mon, 15 Sep 2014 12:19:08 -0700 (PDT) Received: by mail-qg0-f47.google.com with SMTP id i50so4336576qgf.20 for ; Mon, 15 Sep 2014 12:19:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=8uygKMleTb5hoRj0JsxlFdMYie8QtNNb7VSTfSqs+vY=; b=BW3ICHdkTOAuCf0gBSC6poUFFEsBwGXwvRW3zkYCffuG3ePlz+7ObKSnI/06AurFS8 68UnkL7n/pXjPAdBDN7g/qkdatuDS9txR61ieJHzn6EnjkU1zRVqkmb6sbWIQdjhKq8M WP3VrK0H7vQQRdzNATeWUkAEs+mzp3I+o753PS4zS38xmhO0IqIX20JhD6+IE8U1psAJ vamZyHyvbznUuhWYv0GZp53WKXuR22xZlj8Elc4EE99fDGHePuK9sz2mxle1awmu7kzd yzJODjXOAtvTg+8Kcm3wbwe/9XcIQqQSe2MaiKNZEaRQ3vZf3KzcK5Q7hSuZ7XOkWEdw tUCQ== X-Gm-Message-State: ALoCoQl5pth7lT6ceqGyULu0Y/lB5oUZv1nHxz+9CvOSHFI7TDi57MQ6TGLM2eDr3DzkmUtONjew X-Received: by 10.224.80.65 with SMTP id s1mr38084147qak.41.1410808745300; Mon, 15 Sep 2014 12:19:05 -0700 (PDT) Received: from [192.168.1.38] (186-106-144-90.baf.movistar.cl. [186.106.144.90]) by mx.google.com with ESMTPSA id g52sm10142250qgg.17.2014.09.15.12.19.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Sep 2014 12:19:04 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_6237CE3F-B6C0-4323-AE32-1BCBFF7C40C9"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 $1878.6$) From: John Bradley In-Reply-To: Date: Mon, 15 Sep 2014 16:18:59 -0300 Message-Id: References: <4E1F6AAD24975D4BA5B16804296739439AEC00DB@TK5EX14MBXC292.redmond.corp.microsoft.com> <5416FE10.3060608@bbn.com> <4E1F6AAD24975D4BA5B16804296739439AECCCDD@TK5EX14MBXC292.redmond.corp.microsoft.com> <54173546.5000400@bbn.com> To: Tim Bray X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/hFxSWfDDtfOvqO7W6by7AEo3mag X-Mailman-Approved-At: Mon, 15 Sep 2014 13:41:52 -0700 Cc: "jose-chairs@tools.ietf.org" , "secdir@ietf.org" , "draft-ietf-jose-json-web-key.all@tools.ietf.org" , Kathleen Moriarty , Michael Jones , "jose@ietf.org" Subject: Re: [secdir] [jose] JWK member names, was: SECDIR review of draft-ietf-jose-json-web-key-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 19:19:10 -0000 --Apple-Mail=_6237CE3F-B6C0-4323-AE32-1BCBFF7C40C9 Content-Type: multipart/alternative; boundary="Apple-Mail=_DC02E50F-C40A-4D30-8118-DA009E054012" --Apple-Mail=_DC02E50F-C40A-4D30-8118-DA009E054012 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Tim, To clarify. Are you recommending that: That receivers MUST reject JOSE objects with duplicate keys. =20 This would require compliant implementations to write there own parsers = (perhaps not a good idea), or wait for I-JSON parsers (perhaps sometime = soonish) Or that JOSE require producers not to send dup keys, and receivers = SHOULD reject them if possible based on the parser. For JWE and JWS the header is integrity protected so we are talking = about duplicate keys inserted by a bad producer rather than an attacker = modifying the message after signing.. The concern is if something at the application layer is tricked into = inserting a parameter with a duplicate name or one that otherwise = changes the message verification. I suspect the important issue is taking care that when producing a = JWE/JWS you are not accepting arbitrary elements for the header without = verifying that they are not JOSE parameters. John B. On Sep 15, 2014, at 3:54 PM, Tim Bray wrote: > =E2=80=8BWhen I talk about existing software I=E2=80=99m referring to = generic JSON parsers such as are included in the basic library set of = every programming language now, and which are unfortunately = idiosyncratic and inconsistent in their handling of dupe keys, but in = almost no cases actually inform the calling software whether or not dupe = keys were encountered. >=20 > On Mon, Sep 15, 2014 at 11:51 AM, Stephen Kent wrote: > OK, I'm a bit confused. >=20 > I thought the JOSE specs were intended to create standards for = transport of keys, and for sigs, > MACs, and encryption of JSON objects. >=20 > What is the existing software to which you and Tim refer, when = referring to keys (vs. > JSON parsing in general)? >=20 > Steve >=20 >=20 >=20 >=20 > --=20 > - Tim Bray (If you=E2=80=99d like to send me a private message, see = https://keybase.io/timbray) > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_DC02E50F-C40A-4D30-8118-DA009E054012 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Tim,

To = clarify.

Are you recommending = that:

That receivers MUST reject JOSE objects with duplicate = keys.

This would require compliant = implementations to write there own parsers (perhaps not a good idea), or = wait for I-JSON parsers (perhaps sometime = soonish)

Or that JOSE require producers not to = send dup keys, and receivers SHOULD reject them if possible based on the = parser.

For JWE and JWS the header is integrity = protected so we are talking about duplicate keys inserted by a bad = producer rather than an attacker modifying the message after = signing..

The concern is if something at the = application layer is tricked into inserting a parameter with a duplicate = name or one that otherwise changes the message = verification.

I suspect the important issue is = taking care that when producing a JWE/JWS you are not accepting = arbitrary elements for the header without verifying that they are not = JOSE parameters.

John = B.

On Sep 15, 2014, at = 3:54 PM, Tim Bray <tbray@textuality.com> = wrote:

=E2=80=8BWhen I talk about existing software = I=E2=80=99m referring to generic JSON parsers such as are included in = the basic library set of every programming language now, and which are = unfortunately idiosyncratic and inconsistent in their handling of dupe = keys, but in almost no cases actually inform the calling software = whether or not dupe keys were encountered.

On Mon, Sep 15, = 2014 at 11:51 AM, Stephen Kent <kent@bbn.com>= wrote:
OK, I'm a bit = confused.

I thought the JOSE specs were intended to create standards for transport = of keys, and for sigs,
MACs, and encryption of JSON objects.

What is the existing software to which you and Tim refer, when referring = to keys (vs.
JSON parsing in general)?

Steve

--
- Tim Bray (If you=E2=80=99d like to send me a private = message, see https://keybase.io/timbray)

_______________________________________________
jose mailing = list
jose@ietf.org
https://www.ietf.org/ma= ilman/listinfo/jose

= --Apple-Mail=_DC02E50F-C40A-4D30-8118-DA009E054012-- --Apple-Mail=_6237CE3F-B6C0-4323-AE32-1BCBFF7C40C9 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNDA5MTUxOTE4NjBaMCMGCSqGSIb3DQEJBDEWBBTXoc5mvd37JvtbQhFCN2Qh o1i8qTCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQCSkaq51e7/SstyRkbC2qP99TQ/JEsij9FcArvlc5jQSzxUwtWWk8r5 LVD48n+bioxEwC32VvyJWCk1iXnEre9yhtOUrfjx8ACTQ/wxV7Oc9yOdzDOmL8AmU05OTt6PLsM6 RM0gFEfbPAVqGa7oLgaR9tOj+qAcfG8sOF8sbFlv2UIfkaANubh5o8tMcv1dZwqb/UHdEuERw9// fdGREahU4D4PK0Id+qelAJuaRI2HhQ829iWe8rIUuVbA3AQEAau8dl6WgSllMRK5lrj8CESTY0NT sLK+ygFhkKQ96HBih/++Eou7cUDVD78prastOSL1jOZkgJHNGUkx8wHHlvpkAAAAAAAA --Apple-Mail=_6237CE3F-B6C0-4323-AE32-1BCBFF7C40C9-- From nobody Mon Sep 15 13:49:16 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8E51A875C; Mon, 15 Sep 2014 13:49:15 -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, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 sgXnOBAovjzu; Mon, 15 Sep 2014 13:49:13 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0727.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:727]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6D2D1A6F7F; Mon, 15 Sep 2014 13:48:48 -0700 (PDT) Received: from BN3PR0301CA0014.namprd03.prod.outlook.com (25.160.180.152) by BN3PR0301MB0836.namprd03.prod.outlook.com (25.160.154.146) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Mon, 15 Sep 2014 20:48:25 +0000 Received: from BY2FFO11FD032.protection.gbl (2a01:111:f400:7c0c::193) by BN3PR0301CA0014.outlook.office365.com (2a01:111:e400:4000::24) with Microsoft SMTP Server (TLS) id 15.0.1029.13 via Frontend Transport; Mon, 15 Sep 2014 20:48:25 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD032.mail.protection.outlook.com (10.1.14.210) with Microsoft SMTP Server (TLS) id 15.0.1019.14 via Frontend Transport; Mon, 15 Sep 2014 20:48:24 +0000 Received: from TK5EX14MBXC292.redmond.corp.microsoft.com ([169.254.1.60]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.03.0195.002; Mon, 15 Sep 2014 20:47:44 +0000 From: Mike Jones To: Tim Bray , Stephen Kent Thread-Topic: [jose] JWK member names, was: SECDIR review of draft-ietf-jose-json-web-key-31 Thread-Index: AQHP0QAJrqBafxnciEq+15U92qOPJ5wCX4gggAAqrwCAAAC8AIAAFg3w Date: Mon, 15 Sep 2014 20:47:43 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439AECE40B@TK5EX14MBXC292.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739439AEC00DB@TK5EX14MBXC292.redmond.corp.microsoft.com> <5416FE10.3060608@bbn.com> <4E1F6AAD24975D4BA5B16804296739439AECCCDD@TK5EX14MBXC292.redmond.corp.microsoft.com> <54173546.5000400@bbn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.20] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439AECE40BTK5EX14MBXC292r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(438002)(189002)(377454003)(24454002)(199003)(99396002)(15975445006)(6806004)(46102001)(83322001)(20776003)(92566001)(16236675004)(69596002)(86612001)(230783001)(85306004)(55846006)(74502001)(106466001)(80022001)(44976005)(107046002)(84326002)(74662001)(93886004)(68736004)(85806002)(87936001)(19580405001)(106116001)(26826002)(86362001)(54356999)(64706001)(71186001)(15202345003)(19300405004)(66066001)(4396001)(97736003)(31966008)(95666004)(15395725005)(85852003)(16297215004)(76482001)(77982001)(79102001)(81156004)(76176999)(92726001)(19625215002)(19580395003)(77096002)(512874002)(19617315012)(33656002)(2656002)(21056001)(81542001)(90102001)(83072002)(50986999)(84676001)(81342001)(104016003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB0836; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 03355EE97E Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/xf8PLxMWt5mLRbA2TwHdcvLs0QM Cc: "draft-ietf-jose-json-web-key.all@tools.ietf.org" , Kathleen Moriarty , "jose-chairs@tools.ietf.org" , "jose@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] [jose] JWK member names, was: SECDIR review of draft-ietf-jose-json-web-key-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 20:49:15 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439AECE40BTK5EX14MBXC292r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmVwbGllcyBpbmxpbmUgYmVsb3figKYNCg0KRnJvbTogVGltIEJyYXkgW21haWx0bzp0YnJheUB0 ZXh0dWFsaXR5LmNvbV0NClNlbnQ6IE1vbmRheSwgU2VwdGVtYmVyIDE1LCAyMDE0IDExOjU0IEFN DQpUbzogU3RlcGhlbiBLZW50DQpDYzogTWlrZSBKb25lczsgS2F0aGxlZW4gTW9yaWFydHk7IGpv c2VAaWV0Zi5vcmc7IGpvc2UtY2hhaXJzQHRvb2xzLmlldGYub3JnOyBkcmFmdC1pZXRmLWpvc2Ut anNvbi13ZWIta2V5LmFsbEB0b29scy5pZXRmLm9yZzsgc2VjZGlyQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW2pvc2VdIEpXSyBtZW1iZXIgbmFtZXMsIHdhczogU0VDRElSIHJldmlldyBvZiBkcmFm dC1pZXRmLWpvc2UtanNvbi13ZWIta2V5LTMxDQoNCuKAi1doZW4gSSB0YWxrIGFib3V0IGV4aXN0 aW5nIHNvZnR3YXJlIEnigJltIHJlZmVycmluZyB0byBnZW5lcmljIEpTT04gcGFyc2VycyBzdWNo IGFzIGFyZSBpbmNsdWRlZCBpbiB0aGUgYmFzaWMgbGlicmFyeSBzZXQgb2YgZXZlcnkgcHJvZ3Jh bW1pbmcgbGFuZ3VhZ2Ugbm93LCBhbmQgd2hpY2ggYXJlIHVuZm9ydHVuYXRlbHkgaWRpb3N5bmNy YXRpYyBhbmQgaW5jb25zaXN0ZW50IGluIHRoZWlyIGhhbmRsaW5nIG9mIGR1cGUga2V5cywgYnV0 IGluIGFsbW9zdCBubyBjYXNlcyBhY3R1YWxseSBpbmZvcm0gdGhlIGNhbGxpbmcgc29mdHdhcmUg d2hldGhlciBvciBub3QgZHVwZSBrZXlzIHdlcmUgZW5jb3VudGVyZWQuDQoNCk9uIE1vbiwgU2Vw IDE1LCAyMDE0IGF0IDExOjUxIEFNLCBTdGVwaGVuIEtlbnQgPGtlbnRAYmJuLmNvbTxtYWlsdG86 a2VudEBiYm4uY29tPj4gd3JvdGU6DQpPSywgSSdtIGEgYml0IGNvbmZ1c2VkLg0KDQpJIHRob3Vn aHQgdGhlIEpPU0Ugc3BlY3Mgd2VyZSBpbnRlbmRlZCB0byBjcmVhdGUgc3RhbmRhcmRzIGZvciB0 cmFuc3BvcnQgb2Yga2V5cywgYW5kIGZvciBzaWdzLA0KTUFDcywgYW5kIGVuY3J5cHRpb24gb2Yg SlNPTiBvYmplY3RzLg0KDQpBY3R1YWxseSwgdGhlIHBheWxvYWRzIG9mIEpXUyBhbmQgSldFIG9i amVjdHMgY2FuIGJlIGFueSBvY3RldCBzZXF1ZW5jZSDigJMgbm90IGp1c3QgdGhvc2UgcmVwcmVz ZW50aW5nIEpTT04gb2JqZWN0cy4NCg0KV2hhdCBpcyB0aGUgZXhpc3Rpbmcgc29mdHdhcmUgdG8g d2hpY2ggeW91IGFuZCBUaW0gcmVmZXIsIHdoZW4gcmVmZXJyaW5nIHRvIGtleXMgKHZzLg0KSlNP TiBwYXJzaW5nIGluIGdlbmVyYWwpPw0KDQpKV0sgb2JqZWN0cyBhcmUgYWxyZWFkeSB1c2VkIGlu IHByb2R1Y3Rpb24gdG8gZGlzdHJpYnV0ZSBwdWJsaWMga2V5cy4gIEZvciBpbnN0YW5jZSwgdGhl IGtleXMgZm9yIFNhbGVzZm9yY2XigJlzIGlkZW50aXR5IHNlcnZpY2VzIGFyZSBpbiBKV0sgZm9y bWF0IGF0IGh0dHBzOi8vbG9naW4uc2FsZXNmb3JjZS5jb20vaWQva2V5cy4gIChOb3RlIHRoYXQg SeKAmW0gbm90IHNheWluZyB0aGF0IGp1c3QgYmVjYXVzZSB0aGUgY3VycmVudCBzcGVjcyBhcmUg aW4gdXNlLCB0aGF0IG5vIGNoYW5nZXMgYXJlIHBvc3NpYmxlLikNClRoZSBleGlzdGluZyBKU09O IHBhcnNlcnMgaW5jbHVkZSBldmVyeSBleGlzdGluZyBKYXZhU2NyaXB0IGltcGxlbWVudGF0aW9u LCBmb3Igc3RhcnRlcnMsIHBsdXMgdGhlIEpTT04gaW1wbGVtZW50YXRpb25zIGluIEphdmEsIFBI UCwgUnVieSwgUHl0aG9uLCBQZXJsLCAuTkVULCBPYmplY3RpdmUgQywgU2NhbGEsIGV0Yy4gIFRo ZXJl4oCZcyBhIHByZXR0eSBsYXJnZSBsaXN0IGF0IGh0dHA6Ly9qc29uLm9yZy8uICBBbnkgb2Yg dGhlc2UgY291bGQgYmUgdXNlZCB0byBjb25zdW1lIHRoZXNlIGtleXMuDQoNClN0ZXZlDQoNCi0t DQotIFRpbSBCcmF5IChJZiB5b3XigJlkIGxpa2UgdG8gc2VuZCBtZSBhIHByaXZhdGUgbWVzc2Fn ZSwgc2VlIGh0dHBzOi8va2V5YmFzZS5pby90aW1icmF5KQ0KDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCg== --_000_4E1F6AAD24975D4BA5B16804296739439AECE40BTK5EX14MBXC292r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDcw QzAiPlJlcGxpZXMgaW5saW5lIGJlbG934oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDcwQzAi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiBUaW0gQnJheSBbbWFpbHRvOnRicmF5QHRleHR1YWxpdHkuY29tXQ0KPGJy Pg0KPGI+U2VudDo8L2I+IE1vbmRheSwgU2VwdGVtYmVyIDE1LCAyMDE0IDExOjU0IEFNPGJyPg0K PGI+VG86PC9iPiBTdGVwaGVuIEtlbnQ8YnI+DQo8Yj5DYzo8L2I+IE1pa2UgSm9uZXM7IEthdGhs ZWVuIE1vcmlhcnR5OyBqb3NlQGlldGYub3JnOyBqb3NlLWNoYWlyc0B0b29scy5pZXRmLm9yZzsg ZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWtleS5hbGxAdG9vbHMuaWV0Zi5vcmc7IHNlY2RpckBp ZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2pvc2VdIEpXSyBtZW1iZXIgbmFtZXMs IHdhczogU0VDRElSIHJldmlldyBvZiBkcmFmdC1pZXRmLWpvc2UtanNvbi13ZWIta2V5LTMxPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAi1doZW4gSSB0YWxr IGFib3V0IGV4aXN0aW5nIHNvZnR3YXJlIEnigJltIHJlZmVycmluZyB0byBnZW5lcmljIEpTT04g cGFyc2VycyBzdWNoIGFzIGFyZSBpbmNsdWRlZCBpbiB0aGUgYmFzaWMgbGlicmFyeSBzZXQgb2Yg ZXZlcnkgcHJvZ3JhbW1pbmcgbGFuZ3VhZ2Ugbm93LCBhbmQgd2hpY2ggYXJlIHVuZm9ydHVuYXRl bHkgaWRpb3N5bmNyYXRpYyBhbmQgaW5jb25zaXN0ZW50IGluIHRoZWlyIGhhbmRsaW5nIG9mDQog ZHVwZSBrZXlzLCBidXQgaW4gYWxtb3N0IG5vIGNhc2VzIGFjdHVhbGx5IGluZm9ybSB0aGUgY2Fs bGluZyBzb2Z0d2FyZSB3aGV0aGVyIG9yIG5vdCBkdXBlIGtleXMgd2VyZSBlbmNvdW50ZXJlZC48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIFNl cCAxNSwgMjAxNCBhdCAxMTo1MSBBTSwgU3RlcGhlbiBLZW50ICZsdDs8YSBocmVmPSJtYWlsdG86 a2VudEBiYm4uY29tIiB0YXJnZXQ9Il9ibGFuayI+a2VudEBiYm4uY29tPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PSywgSSdtIGEgYml0IGNvbmZ1 c2VkLjxicj4NCjxicj4NCkkgdGhvdWdodCB0aGUgSk9TRSBzcGVjcyB3ZXJlIGludGVuZGVkIHRv IGNyZWF0ZSBzdGFuZGFyZHMgZm9yIHRyYW5zcG9ydCBvZiBrZXlzLCBhbmQgZm9yIHNpZ3MsPGJy Pg0KTUFDcywgYW5kIGVuY3J5cHRpb24gb2YgSlNPTiBvYmplY3RzLjxicj4NCjxicj4NCjxzcGFu IHN0eWxlPSJjb2xvcjojMDA3MEMwIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwNzBDMCI+QWN0 dWFsbHksIHRoZSBwYXlsb2FkcyBvZiBKV1MgYW5kIEpXRSBvYmplY3RzIGNhbiBiZSBhbnkgb2N0 ZXQgc2VxdWVuY2Ug4oCTIG5vdCBqdXN0IHRob3NlIHJlcHJlc2VudGluZyBKU09OIG9iamVjdHMu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMwMDcwQzAiPjxicj4NCjwvc3Bhbj5XaGF0IGlzIHRoZSBleGlzdGluZyBzb2Z0d2Fy ZSB0byB3aGljaCB5b3UgYW5kIFRpbSByZWZlciwgd2hlbiByZWZlcnJpbmcgdG8ga2V5cyAodnMu PGJyPg0KSlNPTiBwYXJzaW5nIGluIGdlbmVyYWwpPzxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwNzBDMCI+SldLIG9iamVjdHMg YXJlIGFscmVhZHkgdXNlZCBpbiBwcm9kdWN0aW9uIHRvIGRpc3RyaWJ1dGUgcHVibGljIGtleXMu Jm5ic3A7IEZvciBpbnN0YW5jZSwgdGhlIGtleXMgZm9yIFNhbGVzZm9yY2XigJlzIGlkZW50aXR5 IHNlcnZpY2VzIGFyZSBpbiBKV0sgZm9ybWF0IGF0DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQVUi PjxhIGhyZWY9Imh0dHBzOi8vbG9naW4uc2FsZXNmb3JjZS5jb20vaWQva2V5cyIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vbG9naW4uc2FsZXNmb3JjZS5jb20vaWQva2V5czwvYT48L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDcwQzAiPi4mbmJzcDsgKE5vdGUgdGhh dCBJ4oCZbSBub3Qgc2F5aW5nIHRoYXQganVzdCBiZWNhdXNlDQogdGhlIGN1cnJlbnQgc3BlY3Mg YXJlIGluIHVzZSwgdGhhdCBubyBjaGFuZ2VzIGFyZSBwb3NzaWJsZS4pPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3MEMwIj5UaGUgZXhpc3RpbmcgSlNPTiBwYXJzZXJz IGluY2x1ZGUgZXZlcnkgZXhpc3RpbmcgSmF2YVNjcmlwdCBpbXBsZW1lbnRhdGlvbiwgZm9yIHN0 YXJ0ZXJzLCBwbHVzIHRoZSBKU09OIGltcGxlbWVudGF0aW9ucyBpbiBKYXZhLCBQSFAsIFJ1Ynks IFB5dGhvbiwgUGVybCwgLk5FVCwNCiBPYmplY3RpdmUgQywgU2NhbGEsIGV0Yy4mbmJzcDsgVGhl cmXigJlzIGEgcHJldHR5IGxhcmdlIGxpc3QgYXQgPGEgaHJlZj0iaHR0cDovL2pzb24ub3JnLyI+ DQpodHRwOi8vanNvbi5vcmcvPC9hPi4mbmJzcDsgQW55IG9mIHRoZXNlIGNvdWxkIGJlIHVzZWQg dG8gY29uc3VtZSB0aGVzZSBrZXlzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj48YnI+DQo8L3NwYW4+U3RldmU8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBUaW0gQnJheSAo SWYgeW914oCZZCBsaWtlIHRvIHNlbmQgbWUgYSBwcml2YXRlIG1lc3NhZ2UsIHNlZSA8YSBocmVm PSJodHRwczovL2tleWJhc2UuaW8vdGltYnJheSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9r ZXliYXNlLmlvL3RpbWJyYXk8L2E+KTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDcwQzAiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMDA3MEMwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_4E1F6AAD24975D4BA5B16804296739439AECE40BTK5EX14MBXC292r_-- From nobody Mon Sep 15 14:22:14 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF95F1A878E for ; Mon, 15 Sep 2014 14:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 KtUuyUBzv7j9 for ; Mon, 15 Sep 2014 14:21:48 -0700 (PDT) Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CA901A0299 for ; Mon, 15 Sep 2014 14:21:45 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id ij19so3993492vcb.26 for ; Mon, 15 Sep 2014 14:21:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=kSXwnjBkmaOy3HTt4yCWMrHQxUU9g8xuhSb4WMyBkGU=; b=INrj+zj66lb+eoqxCnfxxstfIBj3C0T+Eu+EvT9wltA3YmsgMeFhPKr2FR+Bypc++F DG+dtkBt0CTeiHwQg2oFcX1CtJuMNEeqos/AGQrWxItdFPjlXEZy/46ulBZ+eROY13pj TTGBYs0ox/gQ5I+U5Lm8162IPaeUXCFIYBSo9GMO6FlTAJibg5rTWzayKDwWwdtCwNLh YGHsIzBhhBbj9jJ6a8d4SqQ7PWFVtR8rIEWlOS3W/mJ/WRYio8ILCVJaugyJ2BfXN0wb wMlYkZzeb+RFhswW/VguWZYSF2FDEjpqaYLlVupHn+Z75NNPmbVcOnWG2dzQVeMrjOaN e+DA== X-Gm-Message-State: ALoCoQkTMqG7EQSOg1CdjccREzVb6efMtAExQljWQn8z26J6reoBb+NhOg4LbNskb1E5A+/oKywJ X-Received: by 10.52.185.168 with SMTP id fd8mr18318643vdc.58.1410816104519; Mon, 15 Sep 2014 14:21:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.214.4 with HTTP; Mon, 15 Sep 2014 14:21:24 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: References: <4E1F6AAD24975D4BA5B16804296739439AEC00DB@TK5EX14MBXC292.redmond.corp.microsoft.com> <5416FE10.3060608@bbn.com> <4E1F6AAD24975D4BA5B16804296739439AECCCDD@TK5EX14MBXC292.redmond.corp.microsoft.com> <54173546.5000400@bbn.com>

From: Tim Bray Date: Mon, 15 Sep 2014 14:21:24 -0700 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=bcaec5485a24c0f05b05032138cd Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/ki8OH16N7cIaEGMCxLV62T7usoE Cc: "jose-chairs@tools.ietf.org" , "secdir@ietf.org" , "draft-ietf-jose-json-web-key.all@tools.ietf.org" , Kathleen Moriarty , Michael Jones , "jose@ietf.org" Subject: Re: [secdir] [jose] JWK member names, was: SECDIR review of draft-ietf-jose-json-web-key-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe:

--bcaec5485a24c0f05b05032138cd-- From nobody Mon Sep 15 14:27:32 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE681A87C0 for ; Mon, 15 Sep 2014 14:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 YnGl7pXpmiTK for ; Mon, 15 Sep 2014 14:27:05 -0700 (PDT) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54A081A87CA for ; Mon, 15 Sep 2014 14:26:16 -0700 (PDT) Received: by mail-vc0-f178.google.com with SMTP id hy4so4054480vcb.37 for ; Mon, 15 Sep 2014 14:26:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=+oOlHJPo7Oe3B+5Ntx1KeS1LroL7umWS7sZXweVwRuw=; b=Lc18TDnZVQk6R6wR9p1p6OyJ61cNYjTGyWTX/rf0QJJX1UB3HTVCvIcIxTfIOxW+RZ 0i9p+fQwgjscSME+rjBwl3ZPpoUHGTHGh6NT1fc0kmVTwTtiFjPpr91exZ2hhonRdCC9 jq9uTO/1rXhCd/hSsw0M548QoiYfPNcVwZ5NrtWJ09X9NbqhLua1hXxUTgO9pqfI5end 889JB7RmwecrKSrL4SIMCkXJVo7x/hHbTplaEwO7AsWqUwRgbipDcbQ5oCP3dAPfrzET 7nkWBCYbScxO7iAED9NL/yr6n4q5V4fg94CJaOuLB4cY+6/ZMOg49oIamywrqIbCFsKk OYtQ== X-Gm-Message-State: ALoCoQm685GCcC9Xt6PfnTXVF9dSG2qPpoGyI4GHlCNqgnQciWVXUTKrtXy2Ozoserrw8N2PoznF X-Received: by 10.220.59.138 with SMTP id l10mr4203597vch.59.1410816375558; Mon, 15 Sep 2014 14:26:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.214.4 with HTTP; Mon, 15 Sep 2014 14:25:55 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <5417351F.3050706@bbn.com> References: <4E1F6AAD24975D4BA5B16804296739439AEC00DB@TK5EX14MBXC292.redmond.corp.microsoft.com> <5416FE10.3060608@bbn.com> <4E1F6AAD24975D4BA5B16804296739439AECCC93@TK5EX14MBXC292.redmond.corp.microsoft.com> <5417351F.3050706@bbn.com> From: Tim Bray Date: Mon, 15 Sep 2014 14:25:55 -0700 Message-ID: To: Stephen Kent Content-Type: multipart/alternative; boundary=001a11c25182e8a3a10503214846 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/tsTUTsT21SG8dQSnxRA3aMTJQuU Cc: "jose-chairs@tools.ietf.org" , "secdir@ietf.org" , "draft-ietf-jose-json-web-key.all@tools.ietf.org" , Kathleen Moriarty , Mike Jones , "jose@ietf.org" Subject: Re: [secdir] [jose] JWK member names, was: SECDIR review of draft-ietf-jose-json-web-key-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 21:27:08 -0000 --001a11c25182e8a3a10503214846 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Sep 15, 2014 at 11:51 AM, Stephen Kent wrote: I read the rationale. Is there a good baseline of experience showing that > JSON parsers are > not very exploitable today? > =E2=80=8BWell, increasingly, more or less every Internet facing API is JSON-over-HTTP; the amount of JSON in circulation is huge. So, nothing in the world is 100% debugged, but production JSON parsers are among the better-tested software suites in the world. It also helps that the JSON format is very stripped-down and doesn=E2=80=99t provide a very rich attack surface.=E2=80=8B --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --001a11c25182e8a3a10503214846 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On = Mon, Sep 15, 2014 at 11:51 AM, Stephen Kent <kent@bbn.com> wrot= e:

=20 =20 =20
I read the rationale. Is there = a good baseline of experience showing that JSON parsers are
not very exploitable today?

=E2=80=8BWell, increasin= gly, more or less every Internet facing API is JSON-over-HTTP; the amount o= f JSON in circulation is huge. So, nothing in the world is 100% debugged, b= ut production JSON parsers are among the better-tested software suites in t= he world. =C2=A0It also helps that the JSON format is very stripped-down an= d doesn=E2=80=99t provide a very rich attack surface.=E2=80=8B

<= /div>

- Tim Bray (If you=E2=80= =99d like to send me a private message, see https://keybase.io/timbray)

--001a11c25182e8a3a10503214846-- From nobody Mon Sep 15 14:36:37 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5158E1A8784 for ; Mon, 15 Sep 2014 14:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham 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 N6wx7zuZAe3y for ; Mon, 15 Sep 2014 14:36:33 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BEC81A8748 for ; Mon, 15 Sep 2014 14:36:33 -0700 (PDT) X-AuditID: 1209190c-f795e6d000006c66-07-54175be085ee Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id CF.95.27750.0EB57145; Mon, 15 Sep 2014 17:36:32 -0400 (EDT) Received: from outgoing-exchange-3.mit.edu (outgoing-exchange-3.mit.edu [18.9.28.13]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s8FLaVuE011960; Mon, 15 Sep 2014 17:36:32 -0400 Received: from W92EXEDGE5.EXCHANGE.MIT.EDU (w92exedge5.exchange.mit.edu [18.7.73.22]) by outgoing-exchange-3.mit.edu (8.13.8/8.12.4) with ESMTP id s8FLaTj4002218; Mon, 15 Sep 2014 17:36:31 -0400 Received: from W92EXHUB11.exchange.mit.edu (18.7.73.20) by W92EXEDGE5.EXCHANGE.MIT.EDU (18.7.73.22) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 15 Sep 2014 17:35:47 -0400 Received: from OC11EXPO28.exchange.mit.edu ([169.254.1.211]) by W92EXHUB11.exchange.mit.edu ([18.7.73.20]) with mapi id 14.03.0158.001; Mon, 15 Sep 2014 17:36:29 -0400 From: Uri Blumenthal To: Ben Laurie , "secdir@ietf.org" , "draft-ietf-avtcore-aria-srtp.all@tools.ietf.org" Thread-Topic: [secdir] draft-ietf-avtcore-aria-srtp-06 Thread-Index: AQHP0RRbFKfP74bOH0qsxsJ3nE4kHpwCtdlE Date: Mon, 15 Sep 2014 21:36:29 +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: [129.55.200.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrAKsWRmVeSWpSXmKPExsUixCmqrPsgWjzEoGuHmMWGz9fYLHY13Gex +LDwIYsDs8eCTaUeS5b8ZPL4cvkzWwBzFJdNSmpOZllqkb5dAlfGvks32AuaxCqOP//B1sC4 XqiLkZNDQsBEYu3dTewQtpjEhXvr2boYuTiEBGYzSWz+uYcFwjnAKHFx/RV2COcYo8SEaW8Y IZztjBLfd/dDOasZJd5ebWQDGcYmoCTx4dEmsH4Rga2MEp3rroNtERYwlTh1/TGYLSJgJjH7 3HpWCNtIYn/rQ0YQm0VAVWL95VlMIDavQJDEpZc/wGqEBAIkds9eBNbLKRAosXDHTRYQmxHo 8u+n1oDVMwuIS9x6Mp8J4iNBiUWz9zDDfPdv10Og4ziAbEWJOat9Icp1JBbs/sQGYWtLLFv4 mhliraDEyZlPWCYwSsxCMnUWkpZZSFpmIWlZwMiyilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdQ LzezRC81pXQTIzgyJXl2ML45qHSIUYCDUYmHt6BPLESINbGsuDL3EKMkB5OSKK+ht3iIEF9S fkplRmJxRnxRaU5q8SFGCQ5mJRHe/T5AOd6UxMqq1KJ8mJQ0B4uSOO+mH3whQgLpiSWp2amp BalFMFkZDg4lCd6TUUCNgkWp6akVaZk5JQhpJg5OkOE8QMMFQWp4iwsSc4sz0yHypxh1OdZ1 futnEmLJy89LlRLnPQNSJABSlFGaBzcHllBfMYoDvSXM+wykigeYjOEmvQJawgS05GyPGMiS kkSElFQDY9d5kfK9r29+t/EIu5lW0Zy4+8QWHoZjoi3fXl6RMf2fGWf0yCLpz6v44HbDwwEr FtUZxR9q3W94xz7ST+X2JY/Fl9nXH1Krbv/4ap+g8omNFxh8nFfZpv7w3pfl89XOc4XFBSPV nTb+1UvkJOxPVEzNiG57ZfxSfNrmhtS/fDP6s/YebFAMU2Ipzkg01GIuKk4EAMhXFbeDAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/f9s0S4Yg26kuvtUi1nSEeMZtDw4 Subject: Re: [secdir] draft-ietf-avtcore-aria-srtp-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 21:36:36 -0000 My assumption would be that the main use case for SRTP is streaming video. = For streaming video the main threat is theft of service - aka unauthorized = reception. The sender usually doesn't care if some packets don't make it th= rough, which includes being accidentally or maliciously corrupted.=0A= =0A= Compounded by the performance requirements (and if my assumption is correct= ), I can understand why the idea of adding a full authentication tag for ev= ery packet is repulsive to SRTP crowd. =0A= =0A= I agree that for SRTP in the above context full-length authentication tags = would be highly undesirable, and short tags are all that's needed.=0A= =0A= Having said that, I share Ben's concern wrt. "vanity ciphers", and think th= at it is a bad idea, to be avoided if possible - and fully justified if not= . =0A= =0A= TNX!=0A= =0A= ________________________________________=0A= From: secdir [secdir-bounces@ietf.org] on behalf of Ben Laurie [benl@google= .com]=0A= Sent: Monday, September 15, 2014 14:12=0A= To: The IESG; secdir@ietf.org; draft-ietf-avtcore-aria-srtp.all@tools.ietf.= org=0A= Subject: [secdir] draft-ietf-avtcore-aria-srtp-06=0A= =0A= I have reviewed this document as part of the security directorate's=0A= ongoing effort to review all IETF documents being processed by the=0A= IESG. These comments were written primarily for the benefit of the=0A= security area directors. Document editors and WG chairs should treat=0A= these comments just like any other last call comments.=0A= =0A= Summary: ready with issues, or maybe not ready (AD's choice!)=0A= =0A= Firstly, I'm not generally keen on RFCs for "vanity" ciphers - or,=0A= indeed, any cipher that's been as lightly reviewed as ARIA has. The=0A= Security ADs may feel differently, so I defer to them.=0A= =0A= Secondly, ARIA-CTR and ARIA-GCM both use SHA-1 as a hash function, and=0A= I believe we are trying to deprecate that practice.=0A= =0A= Thirdly, I am not familiar enough with SRTP to understand why short=0A= authentication tags are needed, but in general its a bad idea, so I=0A= feel the Security Considerations should explain more fully than=0A= "Ciphersuites with short tag length may be=0A= considered for specific application environments stated in 7.5 of=0A= [RFC3711], but the risk of weak authentication described in=0A= Section 9.5.1 of [RFC3711] should be taken into account."=0A= =0A= How would I take this risk into account?=0A= =0A= Finally, given that short tags are a risk, why are there no modes with=0A= full-length tags?=0A= =0A= _______________________________________________=0A= secdir mailing list=0A= secdir@ietf.org=0A= https://www.ietf.org/mailman/listinfo/secdir=0A= wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview=0A= From nobody Mon Sep 15 14:41:11 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFF0E1A8784 for ; Mon, 15 Sep 2014 14:41:08 -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 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 hNXhj5yW_FIR for ; Mon, 15 Sep 2014 14:41:05 -0700 (PDT) Received: from mail-qg0-f42.google.com (mail-qg0-f42.google.com [209.85.192.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27A9D1A877E for ; Mon, 15 Sep 2014 14:41:05 -0700 (PDT) Received: by mail-qg0-f42.google.com with SMTP id q107so4766166qgd.1 for ; Mon, 15 Sep 2014 14:41:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=1m+Z6Y359ifdQnxuGxTn/ejYwoQbTOTrRIt4++G1WRA=; b=D0mTRRIbJ+duDcsYojc9xrupiWQi5vfRqgD0aDtB1REZV4qU/K0j8j/AqLweUXxAiE nZw9Rl8BY0GOSLG1KZ9Z85A+tIbqBoQJUdZmQpd/AjCPJaMYa6GBcbMRdyIyiDNFC2SR amBvAhp1r1GRsG7WBpPsc5ktaOEEetHHTj9OtaA2j1MYjT1Hv1QzD2IpltSdzx7+BzLB czVLe/8aU9YMcMTI5F7ree1jNG+FEz8VV4qEZARMJ/Gv1UFig8QG7rbcgDYDkZJ+0r1p 1EUzqHGajNfbVjEDavbz728f6q+XQrRDMOaqPdN76QmP51b7/MSYzMEtNpri/JKyBv1Y mgJg== X-Gm-Message-State: ALoCoQmsvlIR6lHIuusCBIXHuGLbK8PA9AbQh2HKChOcqiYguimaTo74MGjCpGWZrBvKyYduLb28 X-Received: by 10.140.89.179 with SMTP id v48mr9385485qgd.65.1410817263890; Mon, 15 Sep 2014 14:41:03 -0700 (PDT) Received: from [192.168.0.90] ([186.67.38.12]) by mx.google.com with ESMTPSA id e5sm10482227qaa.33.2014.09.15.14.41.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Sep 2014 14:41:02 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_EE04313C-AA47-48DF-9A63-C4950A25C8F4"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 $1878.6$) From: John Bradley In-Reply-To: Date: Mon, 15 Sep 2014 18:40:58 -0300 Message-Id: References: <4E1F6AAD24975D4BA5B16804296739439AEC00DB@TK5EX14MBXC292.redmond.corp.microsoft.com> <5416FE10.3060608@bbn.com> <4E1F6AAD24975D4BA5B16804296739439AECCCDD@TK5EX14MBXC292.redmond.corp.microsoft.com> <54173546.5000400@bbn.com>

To: Tim Bray X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/PP7JeUR4ZzwDTp_VJIjFlmZm1to Cc: "jose-chairs@tools.ietf.org" , "secdir@ietf.org" , "draft-ietf-jose-json-web-key.all@tools.ietf.org" , Kathleen Moriarty , Michael Jones , "jose@ietf.org" Subject: Re: [secdir] [jose] JWK member names, was: SECDIR review of draft-ietf-jose-json-web-key-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 21:41:09 -0000 --Apple-Mail=_EE04313C-AA47-48DF-9A63-C4950A25C8F4 Content-Type: multipart/alternative; boundary="Apple-Mail=_4C32D4F4-C864-4BFF-BDF6-0840F106C03F" --Apple-Mail=_4C32D4F4-C864-4BFF-BDF6-0840F106C03F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Inline On Sep 15, 2014, at 6:21 PM, Tim Bray wrote: > On Mon, Sep 15, 2014 at 12:18 PM, John Bradley = wrote: > Are you recommending that: > That receivers MUST reject JOSE objects with duplicate keys. =20 >=20 > This would require compliant implementations to write there own = parsers (perhaps not a good idea), or wait for I-JSON parsers (perhaps = sometime soonish) >=20 > =E2=80=8BAgree, sigh.=E2=80=8B >=20 >=20 > Or that JOSE require producers not to send dup keys, and receivers = SHOULD reject them if possible based on the parser. >=20 > =E2=80=8BYeah=E2=80=A6 MUST NOT send malformed JSON (I argue that an = economical way to do that would be to reference I-JSON if the schedule = works). As for the receiver, I like SHOULD reject, but I=E2=80=99m = wondering if we can get away with that given that a high proportion of = receiving software will have no way to detect the error.=E2=80=8B >=20 >=20 > For JWE and JWS the header is integrity protected so we are talking = about duplicate keys inserted by a bad producer rather than an attacker = modifying the message after signing.. >=20 > =E2=80=8BWhatever. If you get a busted message, something is wrong = somewhere upstream.=E2=80=8B >=20 >=20 > I suspect the important issue is taking care that when producing a = JWE/JWS you are not accepting arbitrary elements for the header without = verifying that they are not JOSE parameters. >=20 > =E2=80=8BHm, for ID Tokens, didn=E2=80=99t we do exactly the opposite, = and end up with a Must-Ignore policy?=E2=80=8B Yes the receiver ignores unknown elements in the body of the JWT. =20 I think that is different than a JWS/JWE library accepting additional = parameters from a calling application to go into the envelope. In that = case the sender lib may want to check that they are not JW* reserved = names that might cause some interoperability problems. The lib producing the JWE/S is probably not going to normally duplicate = elements on it's own. Where I see it perhaps going bas is if someone is counting on the = receiver taking the last one of a duplicate element and trying to = override some header parameter by inserting a duplicate after the lib = generated one. This would work sometime and fail others depending on = the receivers parser. We probably want to be clear that anything extra going into an envelope = needs to be checked to avoid reserved elements. John B. >=20 >=20 > =20 >=20 > John B. >=20 >=20 > On Sep 15, 2014, at 3:54 PM, Tim Bray wrote: >=20 >> =E2=80=8BWhen I talk about existing software I=E2=80=99m referring to = generic JSON parsers such as are included in the basic library set of = every programming language now, and which are unfortunately = idiosyncratic and inconsistent in their handling of dupe keys, but in = almost no cases actually inform the calling software whether or not dupe = keys were encountered. >>=20 >> On Mon, Sep 15, 2014 at 11:51 AM, Stephen Kent wrote: >> OK, I'm a bit confused. >>=20 >> I thought the JOSE specs were intended to create standards for = transport of keys, and for sigs, >> MACs, and encryption of JSON objects. >>=20 >> What is the existing software to which you and Tim refer, when = referring to keys (vs. >> JSON parsing in general)? >>=20 >> Steve >>=20 >>=20 >>=20 >>=20 >> --=20 >> - Tim Bray (If you=E2=80=99d like to send me a private message, see = https://keybase.io/timbray) >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 >=20 >=20 >=20 > --=20 > - Tim Bray (If you=E2=80=99d like to send me a private message, see = https://keybase.io/timbray) --Apple-Mail=_4C32D4F4-C864-4BFF-BDF6-0840F106C03F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Inline

= --Apple-Mail=_4C32D4F4-C864-4BFF-BDF6-0840F106C03F-- --Apple-Mail=_EE04313C-AA47-48DF-9A63-C4950A25C8F4 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNDA5MTUyMTQwNTlaMCMGCSqGSIb3DQEJBDEWBBRLktizZRn9Rd3ntcU61dbO unuzsTCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQBtlq17JNCQmYYtkKF0qBL8mPajopRP7oRZLtc4+IkQ+jTcHdqP8X/+ HSAIJRmERCLpWgJR8wGCdVGcrGkEoASmrRx50JsfNW69vv2BtbtkrciskTrxQfO0egoXlJLtgbH4 T5p38de9pxFenIsmqI+gaLtccZXJ/nc0Fcs7Fpk0MJAsx1tvqABsAlnpSVSWt+yF/iRpS+tl56kK Q9NU8HyN8T2xCNO7tjdYUnlI90DesbZeb/l+P6XWChnlLE1INU8nJiQqPACF3hILlXRe94E2mxxv jBxbhjikg75j9zfhvAPo9KHsvWQC65AYfXiNu17SJOyn6JLg9LQONdc2ADb7AAAAAAAA --Apple-Mail=_EE04313C-AA47-48DF-9A63-C4950A25C8F4-- From nobody Mon Sep 15 15:51:17 2014 Return-Path:

--bcaec5489e431a37b40503459099-- From nobody Wed Sep 17 09:52:51 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF541A06B4 for ; Wed, 17 Sep 2014 09:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 FUewTyiqSRoP for ; Wed, 17 Sep 2014 09:52:44 -0700 (PDT) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B4341A06BD for ; Wed, 17 Sep 2014 09:52:43 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id w7so2218642lbi.32 for ; Wed, 17 Sep 2014 09:52:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=P6gFYXyO6C8WRiFGAhX5qtD9re6V014jQJuyVuddsJw=; b=H8f3UIWBhrqwuIc40/w4lxDOInLwizEH3mmzLSYnQeJFJVjsOeYBQvFCfUvd1Yfnac 0VOSUVhcDbh39oXvMs0ib0EJP6/NxF45DGKw8VKbtpa1KjyzOsvqYf+I45ASpseDDciY Bp1Tnp4lFvNLzeTZs/vU1ulpz2UGbZrbPzDHVrM423Er6fagJ5Cd2H50r3hEF9Nn4sTq zrXImVCfacdNjKCcBGtUl0ARQYOcQUBxtWBkGvL8Yf7W7V12VKsWt7bF1Eq8uTTpTGWq p/+CgoNXylBKCOCqzmkpjSMX9Tbz+Ab/eel+cv2kA5KzwY2OS2sziy4BcmU4cNPJr53F RPRw== X-Gm-Message-State: ALoCoQnQSWl2reZm4Oc4usTx/uh207vAfhP9ghWuCIfuZryB4U0rzMky0fpFabv9Y9MGkN9EbXZ4 MIME-Version: 1.0 X-Received: by 10.152.234.76 with SMTP id uc12mr46079292lac.50.1410972761622; Wed, 17 Sep 2014 09:52:41 -0700 (PDT) Received: by 10.25.159.84 with HTTP; Wed, 17 Sep 2014 09:52:41 -0700 (PDT) In-Reply-To: References: <4E1F6AAD24975D4BA5B16804296739439AEC00DB@TK5EX14MBXC292.redmond.corp.microsoft.com> <5416FE10.3060608@bbn.com> <4E1F6AAD24975D4BA5B16804296739439AECCCDD@TK5EX14MBXC292.redmond.corp.microsoft.com> <54173546.5000400@bbn.com> <4E1F6AAD24975D4BA5B16804296739439AECE40B@TK5EX14MBXC292.redmond.corp.microsoft.com> <54184EBA.3010109@bbn.com> <4E1F6AAD24975D4BA5B16804296739439AED1727@TK5EX14MBXC292.redmond.corp.microsoft.com> <5418987E.1060307@bbn.com> <54199E11.1000809@bbn.com> Date: Wed, 17 Sep 2014 12:52:41 -0400 Message-ID: From: Richard Barnes To: Tim Bray Content-Type: multipart/alternative; boundary=001a11340f123e9b22050345b214 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/7rH7Lyep3BYQQE0DB3QMgZ4BCYE Cc: "jose-chairs@tools.ietf.org" , "secdir@ietf.org" , "draft-ietf-jose-json-web-key.all@tools.ietf.org" , Kathleen Moriarty , Michael Jones , "jose@ietf.org" , John Bradley Subject: Re: [secdir] [jose] JWK member names, was: SECDIR review of draft-ietf-jose-json-web-key-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 16:52:47 -0000 --001a11340f123e9b22050345b214 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable People are going to use off-the-shelf JSON parsers because they're the obvious tool for the job. It seems like a general maxim that if we prohibit using the obvious tools without a really good reason (which I don't really see here), people are just going to ignore the prohibition. --Richard On Wed, Sep 17, 2014 at 12:42 PM, Tim Bray wrote: > The chance of the JOSE working group moving the vast world of deployed > JSON infrastructure round to 0.00. Thus putting a MUST reject in here > would essentially say you can=E2=80=99t use well-debugged production soft= ware, and > would be a really bad idea. > > On the other hand, if JOSE specified that producers=E2=80=99 messages MUS= T conform > to I-JSON, and a couple other WGs climbed on that bandwagon, and the word > started to get around, I wouldn=E2=80=99t be surprised if a few of the po= pular JSON > implementations added an I-JSON mode. That would be a good thing and > lessen the attack surface of all JSON-based protocols (which these days, = is > a whole lot of them). > > > > On Wed, Sep 17, 2014 at 7:43 AM, Stephen Kent wrote: > >> OK, now I have a clear answer to the question I posed earlier, i.e., thi= s >> is a JSON parser problem, not specific to the JOSE-defined formats. >> >> I still believe it makes sense for the RFC(s) to mandate rejection of >> duplicates, >> as a way to "encourage" transition to better parsers, as others have >> noted. And >> I rely on Tero's judgement that the required changes are not onerous. >> >> Steve >> > > > > -- > - Tim Bray (If you=E2=80=99d like to send me a private message, see > https://keybase.io/timbray) > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --001a11340f123e9b22050345b214 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

People are going to use off-the-shelf JSON parsers be= cause they're the obvious tool for the job.=C2=A0 It seems like a gener= al maxim that if we prohibit using the obvious tools without a really good = reason (which I don't really see here), people are just going to ignore= the prohibition.

--Richard

On Wed, Sep 17, 2014 at 12:42 PM, Tim Bray= <tbray@textuality.com> wrote:

The chance =C2=A0of the JOSE working group moving the vast world of de= ployed JSON infrastructure round to 0.00. =C2=A0 Thus putting a MUST reject= in here would essentially say you can=E2=80=99t use well-debugged producti= on software, and would be a really bad idea.

On the other hand, if JOSE specified that producers=E2= =80=99 messages MUST conform to I-JSON, and a couple other WGs climbed on t= hat bandwagon, and the word started to get around, I wouldn=E2=80=99t be su= rprised if a few of the popular JSON implementations added an I-JSON mode. = =C2=A0That would be a good thing and lessen the attack surface of all JSON-= based protocols (which these days, is a whole lot of them).

On Wed, Sep 17, 2014 at = 7:43 AM, Stephen Kent <kent@bbn.com> wrote:
OK, now I have a clear answer to the question I posed earlier= , i.e., this
is a JSON parser problem, not specific to the JOSE-defined formats.

I still believe it makes sense for the RFC(s) to mandate rejection of dupli= cates,
as a way to "encourage" transition to better parsers, as others h= ave noted. And
I rely on Tero's judgement that the required changes are not onerous.
Steve

--
- Tim Bray (If you=E2=80=99d like to sen= d me a private message, see https://keybase.io/timbray)

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

--001a11340f123e9b22050345b214-- From nobody Wed Sep 17 10:58:22 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF8FF1A03AC; Wed, 17 Sep 2014 10:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.852 X-Spam-Level: X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham 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_fQLANfKjxy; Wed, 17 Sep 2014 10:58:16 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5C051A06E1; Wed, 17 Sep 2014 10:58:15 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:53340 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XUJUW-0008qX-RF; Wed, 17 Sep 2014 13:58:08 -0400 Message-ID: <5419CBA9.8020807@bbn.com> Date: Wed, 17 Sep 2014 13:58:01 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tim Bray References: <4E1F6AAD24975D4BA5B16804296739439AEC00DB@TK5EX14MBXC292.redmond.corp.microsoft.com> <5416FE10.3060608@bbn.com> <4E1F6AAD24975D4BA5B16804296739439AECCCDD@TK5EX14MBXC292.redmond.corp.microsoft.com> <54173546.5000400@bbn.com> <4E1F6AAD24975D4BA5B16804296739439AECE40B@TK5EX14MBXC292.redmond.corp.microsoft.com> <54184EBA.3010109@bbn.com> <4E1F6AAD24975D4BA5B16804296739439AED1727@TK5EX14MBXC292.redmond.corp.microsoft.com> <5418987E.1060307@bbn.com> <54199E11.1000809@bbn.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090903060607040800070505" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/tOKUrQ2noLcVySulZXiktFs1trA Cc: "jose-chairs@tools.ietf.org" , "secdir@ietf.org" , "draft-ietf-jose-json-web-key.all@tools.ietf.org" , Kathleen Moriarty , Michael Jones , "jose@ietf.org" , John Bradley Subject: Re: [secdir] [jose] JWK member names, was: SECDIR review of draft-ietf-jose-json-web-key-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive:

"""
#= Signature Algorithm Protection

In some usages of JWS, there i= s a risk of algorithm substitution attacks, in which an attacker can use an= existing signature value with a different signature algorithm to make it a= ppear that a signer has signed something that he actually has not.=C2=A0 Th= ese attacks have been discussed in detail in the context of CMS {{RFC 6211}= }.=C2=A0 The risk arises when all of the following are true:

*= Verifiers of a signature support multiple algorithms of different strength= s

* Given an existing signature, an attacker can find another payl= oad that produces the same signature value with a weaker algorithm
* In particular, the payload crafted by the attacker is valid in a given a= pplication-layer context

For example, suppose a verifier is wi= lling to accept both "PS1" and "PS256" as "alg&quo= t; values, and a signer creates a signature using "PS256".=C2=A0 = If the attacker can craft a payload that has the same SHA-1 digest has as t= he SHA-256 digest of the legitimate payload, then the "PS1" signa= ture over the bogus payload will be the same as the "PS256" signa= ture over the legitimate payload.

There are several way= s for an application using JOSE to mitigate algorithm substitution attacks:=

* Don't accept signatures using vulnerable algorithm= s: Algorithm substitution attacks do not arise for all signature algorithms= .=C2=A0
=C2=A0 * Signatures using RSA PKCS#1 v1.5 ("RS1", &qu= ot;RS256", etc.) are not subject to substitution attacks because the s= ignature value itself encodes the hash function used.=C2=A0
=C2=A0 * Si= gnatures with HMAC algorithms ("HS1", "HS256", etc.) ca= nnot be substituted because the signature values have different lengths=C2= =A0 Likewise for signatures with ECDSA algorithms ("ES256", "= ;ES384", etc.).

=C2=A0 * The only algorithms defined in = JWA {{I-D.ietf-jose-json-web-algorithms}} that is vulnerable to algorithm s= ubstitution attacks is RSA-PSS ("PS1", "PS256", etc.).= =C2=A0 An implementation that does not support RSA-PSS is not vulnerable to= algorithm substitution attacks.

* Require that th= e "alg" parameter be carried in the protected header.=C2=A0 (This= is the approach taken by RFC 6211.)

* Include a field re= flecting the algorithm in the application payload, and require that it be m= atched with the "alg" parameter during verification (This is the = approach taken by PKIX {{RFC5280}}.)

Of these mitig= ations, the only sure solution is the first.=C2=A0 Signing over the "a= lg" parameter (directly or indirectly) only makes the attacker's w= ork more difficult, by requiring that the bogus payload also contain bogus = information about the signing algorithm.=C2=A0 They do not prevent attack b= y a sufficiently powerful attacker.

<= div>

"""

On Fri, Sep 19, 2014 at 2:49 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

I would appreciate it if = you would write a draft of the proposed security considerations text, Richa= rd.=C2=A0 Perhaps title the section =E2=80=9CUnsecured Algorithm Values=E2= =80=9D.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thanks!

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike

=C2=A0

From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Wednesday, September 17, 2014 6:24 AM
To: Tero Kivinen
Cc: Mike Jones; i= esg@ietf.org; secd= ir@ietf.org; ietf@ie= tf.org; draft-ietf-jose-json-web-signature.all@tools.ie= tf.org; jose@ietf.or= g
Subject: Re: Secdir review of draft-ietf-jose-json-web-signature-31<= u>

=C2=A0

On Wednesday, September 17, 2014, Tero Kivinen <kivinen@iki.fi> wrote:

Richard Barnes writes:
>=C2=A0 =C2=A0 =C2=A0Perhaps, but is there benefits for leaving the alg = without protection?
>
> Simplicity (if you omit protected headers altogether), and
> compatibility with other signed things.=C2=A0 In the sense that you co= uld
> transform one of them into a JWS without re-signing.=C2=A0 This would<= br> > apply, for example, to an X.509 certificate -- just parse the outer > SEQUENCE, and re-assemble into a JWS with the tbsCertificate as
> payload.=C2=A0 Same security properties that X.509 already has.

Ok, having this kind of information somewhere in the draft would help
to understand the reason. Also having text explaining that is
possible, and that the security properties of this option (i.e. no
problem with PKCS#1, etc... the text you had in the other email).

> It's also completely unnecessary for PKCS#1 signatures, which are<= br> > the dominant use case today.

I agree.

> In general, I'm opposed to protocols baking in more
> application-specific logic than they need to.=C2=A0 The point of JOSE = is
> to describe the cryptographic operation that was performed, and
> carry the relevant bits around.=C2=A0 Its job is not to fix all the > weaknesses that every algorithm has.=C2=A0

Yes, but this property might have security issues, so they should be
covered by the security considerations section.

=C2=A0

I'm perfectly happy to have it documented in the= Security Considerations.=C2=A0

=C2=A0

Mike: Should I generate some text, or do you want to= take a stab?

=C2=A0

--
kivinen@iki.fi

--089e0149338c408e92050371d62b-- From nobody Fri Sep 19 15:30:33 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C29F31A88E0; Fri, 19 Sep 2014 15:30:15 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 NNEnCXvVpiVb; Fri, 19 Sep 2014 15:30:11 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0135.outbound.protection.outlook.com [207.46.100.135]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E00A1A88A9; Fri, 19 Sep 2014 15:30:11 -0700 (PDT) Received: from BY2PR03CA040.namprd03.prod.outlook.com (10.141.249.13) by BLUPR03MB392.namprd03.prod.outlook.com (10.141.78.28) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Fri, 19 Sep 2014 22:30:09 +0000 Received: from BL2FFO11FD047.protection.gbl (2a01:111:f400:7c09::160) by BY2PR03CA040.outlook.office365.com (2a01:111:e400:2c5d::13) with Microsoft SMTP Server (TLS) id 15.0.1034.13 via Frontend Transport; Fri, 19 Sep 2014 22:30:08 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD047.mail.protection.outlook.com (10.173.161.209) with Microsoft SMTP Server (TLS) id 15.0.1029.15 via Frontend Transport; Fri, 19 Sep 2014 22:30:08 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.23]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.03.0195.002; Fri, 19 Sep 2014 22:29:36 +0000 From: Mike Jones To: Richard Barnes Thread-Topic: Secdir review of draft-ietf-jose-json-web-signature-31 Thread-Index: AQHPyDgrWdMUgOdf8EqNa4N9Ytbe4ZvzQwoggArT4gCABW9RgIABPl2AgABFmwCAAFrAgIADfttQgAAuJgCAAA+iQA== Date: Fri, 19 Sep 2014 22:29:35 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BA5B7B6@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <21512.21725.209461.976375@fireball.kivinen.iki.fi> <4E1F6AAD24975D4BA5B16804296739439AE9DD47@TK5EX14MBXC292.redmond.corp.microsoft.com> <21527.63989.999440.801542@fireball.kivinen.iki.fi> <21529.16232.880915.215045@fireball.kivinen.iki.fi> <4E1F6AAD24975D4BA5B16804296739439BA59EB7@TK5EX14MBXC286.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439BA5B7B6TK5EX14MBXC286r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(438002)(24454002)(43784003)(41574002)(52544003)(199003)(51704005)(189002)(377454003)(81342003)(106116001)(77982003)(97736003)(46102003)(4396001)(79102003)(64706001)(74662003)(80022003)(74502003)(77096002)(81542003)(66066001)(512874002)(76482002)(93886004)(85306004)(90102001)(110136001)(230783001)(106466001)(95666004)(15975445006)(104016003)(107046002)(81156004)(85852003)(83072002)(54356999)(92726001)(16236675004)(92566001)(6806004)(86362001)(44976005)(19300405004)(55846006)(86612001)(76176999)(33656002)(31966008)(69596002)(19580405001)(19580395003)(83322001)(68736004)(84676001)(20776003)(26826002)(21056001)(50986999)(71186001)(15202345003)(2656002)(84326002)(87936001)(19625215002)(99396002)(85806002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB392; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB392; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0339F89554 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/MyH6iEWxAnNI1em1ZvBO6bWzre8 Cc: "ietf@ietf.org" , "secdir@ietf.org" , "iesg@ietf.org" , "jose@ietf.org" , "draft-ietf-jose-json-web-signature.all@tools.ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-jose-json-web-signature-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 22:30:16 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439BA5B7B6TK5EX14MBXC286r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIFJpY2hhcmQuICBZb3VyIHByb3Bvc2VkIHRleHQgdXNlcyB0aGUg4oCcUlMx4oCdIGFu ZCDigJxQUzHigJ0gYWxnb3JpdGhtcywgd2hpY2ggV2ViQ3J5cHRvIGhhcyBidXQgSk9TRSBkb2Vz buKAmXQuICBDYW4geW91IHJldmlzZSB0aGUgZXhhbXBsZXMgdG8gbWFrZSB0aGUgc2FtZSBwb2lu dHMgdXNpbmcgb25seSBhbGdvcml0aG1zIGluIEpXQT8NCg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRoYW5rcyBhZ2FpbiwN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAtLSBNaWtlDQoNCkZyb206IFJpY2hhcmQgQmFybmVzIFttYWlsdG86cmxiQGlwdi5z eF0NClNlbnQ6IEZyaWRheSwgU2VwdGVtYmVyIDE5LCAyMDE0IDI6MzIgUE0NClRvOiBNaWtlIEpv bmVzDQpDYzogVGVybyBLaXZpbmVuOyBpZXNnQGlldGYub3JnOyBzZWNkaXJAaWV0Zi5vcmc7IGll dGZAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1zaWduYXR1cmUuYWxsQHRvb2xz LmlldGYub3JnOyBqb3NlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogU2VjZGlyIHJldmlldyBvZiBk cmFmdC1pZXRmLWpvc2UtanNvbi13ZWItc2lnbmF0dXJlLTMxDQoNCiIiIg0KIyBTaWduYXR1cmUg QWxnb3JpdGhtIFByb3RlY3Rpb24NCkluIHNvbWUgdXNhZ2VzIG9mIEpXUywgdGhlcmUgaXMgYSBy aXNrIG9mIGFsZ29yaXRobSBzdWJzdGl0dXRpb24gYXR0YWNrcywgaW4gd2hpY2ggYW4gYXR0YWNr ZXIgY2FuIHVzZSBhbiBleGlzdGluZyBzaWduYXR1cmUgdmFsdWUgd2l0aCBhIGRpZmZlcmVudCBz aWduYXR1cmUgYWxnb3JpdGhtIHRvIG1ha2UgaXQgYXBwZWFyIHRoYXQgYSBzaWduZXIgaGFzIHNp Z25lZCBzb21ldGhpbmcgdGhhdCBoZSBhY3R1YWxseSBoYXMgbm90LiAgVGhlc2UgYXR0YWNrcyBo YXZlIGJlZW4gZGlzY3Vzc2VkIGluIGRldGFpbCBpbiB0aGUgY29udGV4dCBvZiBDTVMge3tSRkMg NjIxMX19LiAgVGhlIHJpc2sgYXJpc2VzIHdoZW4gYWxsIG9mIHRoZSBmb2xsb3dpbmcgYXJlIHRy dWU6DQoNCiogVmVyaWZpZXJzIG9mIGEgc2lnbmF0dXJlIHN1cHBvcnQgbXVsdGlwbGUgYWxnb3Jp dGhtcyBvZiBkaWZmZXJlbnQgc3RyZW5ndGhzDQoqIEdpdmVuIGFuIGV4aXN0aW5nIHNpZ25hdHVy ZSwgYW4gYXR0YWNrZXIgY2FuIGZpbmQgYW5vdGhlciBwYXlsb2FkIHRoYXQgcHJvZHVjZXMgdGhl IHNhbWUgc2lnbmF0dXJlIHZhbHVlIHdpdGggYSB3ZWFrZXIgYWxnb3JpdGhtDQoqIEluIHBhcnRp Y3VsYXIsIHRoZSBwYXlsb2FkIGNyYWZ0ZWQgYnkgdGhlIGF0dGFja2VyIGlzIHZhbGlkIGluIGEg Z2l2ZW4gYXBwbGljYXRpb24tbGF5ZXIgY29udGV4dA0KRm9yIGV4YW1wbGUsIHN1cHBvc2UgYSB2 ZXJpZmllciBpcyB3aWxsaW5nIHRvIGFjY2VwdCBib3RoICJQUzEiIGFuZCAiUFMyNTYiIGFzICJh bGciIHZhbHVlcywgYW5kIGEgc2lnbmVyIGNyZWF0ZXMgYSBzaWduYXR1cmUgdXNpbmcgIlBTMjU2 Ii4gIElmIHRoZSBhdHRhY2tlciBjYW4gY3JhZnQgYSBwYXlsb2FkIHRoYXQgaGFzIHRoZSBzYW1l IFNIQS0xIGRpZ2VzdCBoYXMgYXMgdGhlIFNIQS0yNTYgZGlnZXN0IG9mIHRoZSBsZWdpdGltYXRl IHBheWxvYWQsIHRoZW4gdGhlICJQUzEiIHNpZ25hdHVyZSBvdmVyIHRoZSBib2d1cyBwYXlsb2Fk IHdpbGwgYmUgdGhlIHNhbWUgYXMgdGhlICJQUzI1NiIgc2lnbmF0dXJlIG92ZXIgdGhlIGxlZ2l0 aW1hdGUgcGF5bG9hZC4NCg0KVGhlcmUgYXJlIHNldmVyYWwgd2F5cyBmb3IgYW4gYXBwbGljYXRp b24gdXNpbmcgSk9TRSB0byBtaXRpZ2F0ZSBhbGdvcml0aG0gc3Vic3RpdHV0aW9uIGF0dGFja3M6 DQoqIERvbid0IGFjY2VwdCBzaWduYXR1cmVzIHVzaW5nIHZ1bG5lcmFibGUgYWxnb3JpdGhtczog QWxnb3JpdGhtIHN1YnN0aXR1dGlvbiBhdHRhY2tzIGRvIG5vdCBhcmlzZSBmb3IgYWxsIHNpZ25h dHVyZSBhbGdvcml0aG1zLg0KICAqIFNpZ25hdHVyZXMgdXNpbmcgUlNBIFBLQ1MjMSB2MS41ICgi UlMxIiwgIlJTMjU2IiwgZXRjLikgYXJlIG5vdCBzdWJqZWN0IHRvIHN1YnN0aXR1dGlvbiBhdHRh Y2tzIGJlY2F1c2UgdGhlIHNpZ25hdHVyZSB2YWx1ZSBpdHNlbGYgZW5jb2RlcyB0aGUgaGFzaCBm dW5jdGlvbiB1c2VkLg0KICAqIFNpZ25hdHVyZXMgd2l0aCBITUFDIGFsZ29yaXRobXMgKCJIUzEi LCAiSFMyNTYiLCBldGMuKSBjYW5ub3QgYmUgc3Vic3RpdHV0ZWQgYmVjYXVzZSB0aGUgc2lnbmF0 dXJlIHZhbHVlcyBoYXZlIGRpZmZlcmVudCBsZW5ndGhzICBMaWtld2lzZSBmb3Igc2lnbmF0dXJl cyB3aXRoIEVDRFNBIGFsZ29yaXRobXMgKCJFUzI1NiIsICJFUzM4NCIsIGV0Yy4pLg0KICAqIFRo ZSBvbmx5IGFsZ29yaXRobXMgZGVmaW5lZCBpbiBKV0Ege3tJLUQuaWV0Zi1qb3NlLWpzb24td2Vi LWFsZ29yaXRobXN9fSB0aGF0IGlzIHZ1bG5lcmFibGUgdG8gYWxnb3JpdGhtIHN1YnN0aXR1dGlv biBhdHRhY2tzIGlzIFJTQS1QU1MgKCJQUzEiLCAiUFMyNTYiLCBldGMuKS4gIEFuIGltcGxlbWVu dGF0aW9uIHRoYXQgZG9lcyBub3Qgc3VwcG9ydCBSU0EtUFNTIGlzIG5vdCB2dWxuZXJhYmxlIHRv IGFsZ29yaXRobSBzdWJzdGl0dXRpb24gYXR0YWNrcy4NCg0KKiBSZXF1aXJlIHRoYXQgdGhlICJh bGciIHBhcmFtZXRlciBiZSBjYXJyaWVkIGluIHRoZSBwcm90ZWN0ZWQgaGVhZGVyLiAgKFRoaXMg aXMgdGhlIGFwcHJvYWNoIHRha2VuIGJ5IFJGQyA2MjExLikNCiogSW5jbHVkZSBhIGZpZWxkIHJl ZmxlY3RpbmcgdGhlIGFsZ29yaXRobSBpbiB0aGUgYXBwbGljYXRpb24gcGF5bG9hZCwgYW5kIHJl cXVpcmUgdGhhdCBpdCBiZSBtYXRjaGVkIHdpdGggdGhlICJhbGciIHBhcmFtZXRlciBkdXJpbmcg dmVyaWZpY2F0aW9uIChUaGlzIGlzIHRoZSBhcHByb2FjaCB0YWtlbiBieSBQS0lYIHt7UkZDNTI4 MH19LikNCg0KT2YgdGhlc2UgbWl0aWdhdGlvbnMsIHRoZSBvbmx5IHN1cmUgc29sdXRpb24gaXMg dGhlIGZpcnN0LiAgU2lnbmluZyBvdmVyIHRoZSAiYWxnIiBwYXJhbWV0ZXIgKGRpcmVjdGx5IG9y IGluZGlyZWN0bHkpIG9ubHkgbWFrZXMgdGhlIGF0dGFja2VyJ3Mgd29yayBtb3JlIGRpZmZpY3Vs dCwgYnkgcmVxdWlyaW5nIHRoYXQgdGhlIGJvZ3VzIHBheWxvYWQgYWxzbyBjb250YWluIGJvZ3Vz IGluZm9ybWF0aW9uIGFib3V0IHRoZSBzaWduaW5nIGFsZ29yaXRobS4gIFRoZXkgZG8gbm90IHBy ZXZlbnQgYXR0YWNrIGJ5IGEgc3VmZmljaWVudGx5IHBvd2VyZnVsIGF0dGFja2VyLg0KIiIiDQoN Ck9uIEZyaSwgU2VwIDE5LCAyMDE0IGF0IDI6NDkgUE0sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9u ZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4gd3Jv dGU6DQpJIHdvdWxkIGFwcHJlY2lhdGUgaXQgaWYgeW91IHdvdWxkIHdyaXRlIGEgZHJhZnQgb2Yg dGhlIHByb3Bvc2VkIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHRleHQsIFJpY2hhcmQuICBQZXJo YXBzIHRpdGxlIHRoZSBzZWN0aW9uIOKAnFVuc2VjdXJlZCBBbGdvcml0aG0gVmFsdWVz4oCdLg0K DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBUaGFua3MhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IFJpY2hhcmQgQmFybmVzIFttYWlsdG86 cmxiQGlwdi5zeDxtYWlsdG86cmxiQGlwdi5zeD5dDQpTZW50OiBXZWRuZXNkYXksIFNlcHRlbWJl ciAxNywgMjAxNCA2OjI0IEFNDQpUbzogVGVybyBLaXZpbmVuDQpDYzogTWlrZSBKb25lczsgaWVz Z0BpZXRmLm9yZzxtYWlsdG86aWVzZ0BpZXRmLm9yZz47IHNlY2RpckBpZXRmLm9yZzxtYWlsdG86 c2VjZGlyQGlldGYub3JnPjsgaWV0ZkBpZXRmLm9yZzxtYWlsdG86aWV0ZkBpZXRmLm9yZz47IGRy YWZ0LWlldGYtam9zZS1qc29uLXdlYi1zaWduYXR1cmUuYWxsQHRvb2xzLmlldGYub3JnPG1haWx0 bzpkcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItc2lnbmF0dXJlLmFsbEB0b29scy5pZXRmLm9yZz47 IGpvc2VAaWV0Zi5vcmc8bWFpbHRvOmpvc2VAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogU2VjZGly IHJldmlldyBvZiBkcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItc2lnbmF0dXJlLTMxDQoNCg0KDQpP biBXZWRuZXNkYXksIFNlcHRlbWJlciAxNywgMjAxNCwgVGVybyBLaXZpbmVuIDxraXZpbmVuQGlr aS5maTxtYWlsdG86a2l2aW5lbkBpa2kuZmk+PiB3cm90ZToNClJpY2hhcmQgQmFybmVzIHdyaXRl czoNCj4gICAgIFBlcmhhcHMsIGJ1dCBpcyB0aGVyZSBiZW5lZml0cyBmb3IgbGVhdmluZyB0aGUg YWxnIHdpdGhvdXQgcHJvdGVjdGlvbj8NCj4NCj4gU2ltcGxpY2l0eSAoaWYgeW91IG9taXQgcHJv dGVjdGVkIGhlYWRlcnMgYWx0b2dldGhlciksIGFuZA0KPiBjb21wYXRpYmlsaXR5IHdpdGggb3Ro ZXIgc2lnbmVkIHRoaW5ncy4gIEluIHRoZSBzZW5zZSB0aGF0IHlvdSBjb3VsZA0KPiB0cmFuc2Zv cm0gb25lIG9mIHRoZW0gaW50byBhIEpXUyB3aXRob3V0IHJlLXNpZ25pbmcuICBUaGlzIHdvdWxk DQo+IGFwcGx5LCBmb3IgZXhhbXBsZSwgdG8gYW4gWC41MDkgY2VydGlmaWNhdGUgLS0ganVzdCBw YXJzZSB0aGUgb3V0ZXINCj4gU0VRVUVOQ0UsIGFuZCByZS1hc3NlbWJsZSBpbnRvIGEgSldTIHdp dGggdGhlIHRic0NlcnRpZmljYXRlIGFzDQo+IHBheWxvYWQuICBTYW1lIHNlY3VyaXR5IHByb3Bl cnRpZXMgdGhhdCBYLjUwOSBhbHJlYWR5IGhhcy4NCg0KT2ssIGhhdmluZyB0aGlzIGtpbmQgb2Yg aW5mb3JtYXRpb24gc29tZXdoZXJlIGluIHRoZSBkcmFmdCB3b3VsZCBoZWxwDQp0byB1bmRlcnN0 YW5kIHRoZSByZWFzb24uIEFsc28gaGF2aW5nIHRleHQgZXhwbGFpbmluZyB0aGF0IGlzDQpwb3Nz aWJsZSwgYW5kIHRoYXQgdGhlIHNlY3VyaXR5IHByb3BlcnRpZXMgb2YgdGhpcyBvcHRpb24gKGku ZS4gbm8NCnByb2JsZW0gd2l0aCBQS0NTIzEsIGV0Yy4uLiB0aGUgdGV4dCB5b3UgaGFkIGluIHRo ZSBvdGhlciBlbWFpbCkuDQoNCj4gSXQncyBhbHNvIGNvbXBsZXRlbHkgdW5uZWNlc3NhcnkgZm9y IFBLQ1MjMSBzaWduYXR1cmVzLCB3aGljaCBhcmUNCj4gdGhlIGRvbWluYW50IHVzZSBjYXNlIHRv ZGF5Lg0KDQpJIGFncmVlLg0KDQo+IEluIGdlbmVyYWwsIEknbSBvcHBvc2VkIHRvIHByb3RvY29s cyBiYWtpbmcgaW4gbW9yZQ0KPiBhcHBsaWNhdGlvbi1zcGVjaWZpYyBsb2dpYyB0aGFuIHRoZXkg bmVlZCB0by4gIFRoZSBwb2ludCBvZiBKT1NFIGlzDQo+IHRvIGRlc2NyaWJlIHRoZSBjcnlwdG9n cmFwaGljIG9wZXJhdGlvbiB0aGF0IHdhcyBwZXJmb3JtZWQsIGFuZA0KPiBjYXJyeSB0aGUgcmVs ZXZhbnQgYml0cyBhcm91bmQuICBJdHMgam9iIGlzIG5vdCB0byBmaXggYWxsIHRoZQ0KPiB3ZWFr bmVzc2VzIHRoYXQgZXZlcnkgYWxnb3JpdGhtIGhhcy4NCg0KWWVzLCBidXQgdGhpcyBwcm9wZXJ0 eSBtaWdodCBoYXZlIHNlY3VyaXR5IGlzc3Vlcywgc28gdGhleSBzaG91bGQgYmUNCmNvdmVyZWQg YnkgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24uDQoNCkknbSBwZXJmZWN0bHkg aGFwcHkgdG8gaGF2ZSBpdCBkb2N1bWVudGVkIGluIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9u cy4NCg0KTWlrZTogU2hvdWxkIEkgZ2VuZXJhdGUgc29tZSB0ZXh0LCBvciBkbyB5b3Ugd2FudCB0 byB0YWtlIGEgc3RhYj8NCg0KLS0NCmtpdmluZW5AaWtpLmZpPG1haWx0bzpraXZpbmVuQGlraS5m aT4NCg0K --_000_4E1F6AAD24975D4BA5B16804296739439BA5B7B6TK5EX14MBXC286r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0 IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5UaGFua3MgUmljaGFyZC4mbmJzcDsgWW91ciBwcm9wb3NlZCB0ZXh0IHVzZXMgdGhlIOKA nFJTMeKAnSBhbmQg4oCcUFMx4oCdIGFsZ29yaXRobXMsIHdoaWNoIFdlYkNyeXB0byBoYXMgYnV0 IEpPU0UgZG9lc27igJl0LiZuYnNwOyBDYW4geW91IHJldmlzZSB0aGUgZXhhbXBsZXMgdG8gbWFr ZSB0aGUgc2FtZQ0KIHBvaW50cyB1c2luZyBvbmx5IGFsZ29yaXRobXMgaW4gSldBPzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoYW5rcyBhZ2Fpbiw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IFJpY2hhcmQgQmFybmVzIFttYWlsdG86cmxiQGlwdi5zeF0NCjxicj4NCjxiPlNlbnQ6PC9iPiBG cmlkYXksIFNlcHRlbWJlciAxOSwgMjAxNCAyOjMyIFBNPGJyPg0KPGI+VG86PC9iPiBNaWtlIEpv bmVzPGJyPg0KPGI+Q2M6PC9iPiBUZXJvIEtpdmluZW47IGllc2dAaWV0Zi5vcmc7IHNlY2RpckBp ZXRmLm9yZzsgaWV0ZkBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLXNpZ25hdHVy ZS5hbGxAdG9vbHMuaWV0Zi5vcmc7IGpvc2VAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFNlY2RpciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLXNpZ25hdHVyZS0z MTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPiZxdW90OyZxdW90OyZxdW90Ozxicj4NCiMgU2lnbmF0dXJlIEFsZ29yaXRobSBQcm90ZWN0 aW9uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIHNvbWUg dXNhZ2VzIG9mIEpXUywgdGhlcmUgaXMgYSByaXNrIG9mIGFsZ29yaXRobSBzdWJzdGl0dXRpb24g YXR0YWNrcywgaW4gd2hpY2ggYW4gYXR0YWNrZXIgY2FuIHVzZSBhbiBleGlzdGluZyBzaWduYXR1 cmUgdmFsdWUgd2l0aCBhIGRpZmZlcmVudCBzaWduYXR1cmUgYWxnb3JpdGhtIHRvIG1ha2UgaXQg YXBwZWFyIHRoYXQgYSBzaWduZXIgaGFzIHNpZ25lZCBzb21ldGhpbmcgdGhhdCBoZSBhY3R1YWxs eQ0KIGhhcyBub3QuJm5ic3A7IFRoZXNlIGF0dGFja3MgaGF2ZSBiZWVuIGRpc2N1c3NlZCBpbiBk ZXRhaWwgaW4gdGhlIGNvbnRleHQgb2YgQ01TIHt7UkZDIDYyMTF9fS4mbmJzcDsgVGhlIHJpc2sg YXJpc2VzIHdoZW4gYWxsIG9mIHRoZSBmb2xsb3dpbmcgYXJlIHRydWU6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCiogVmVyaWZpZXJzIG9mIGEgc2ln bmF0dXJlIHN1cHBvcnQgbXVsdGlwbGUgYWxnb3JpdGhtcyBvZiBkaWZmZXJlbnQgc3RyZW5ndGhz PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiogR2l2ZW4gYW4g ZXhpc3Rpbmcgc2lnbmF0dXJlLCBhbiBhdHRhY2tlciBjYW4gZmluZCBhbm90aGVyIHBheWxvYWQg dGhhdCBwcm9kdWNlcyB0aGUgc2FtZSBzaWduYXR1cmUgdmFsdWUgd2l0aCBhIHdlYWtlciBhbGdv cml0aG08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4qIEluIHBhcnRpY3VsYXIsIHRoZSBwYXlsb2FkIGNyYWZ0 ZWQgYnkgdGhlIGF0dGFja2VyIGlzIHZhbGlkIGluIGEgZ2l2ZW4gYXBwbGljYXRpb24tbGF5ZXIg Y29udGV4dDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3Ig ZXhhbXBsZSwgc3VwcG9zZSBhIHZlcmlmaWVyIGlzIHdpbGxpbmcgdG8gYWNjZXB0IGJvdGggJnF1 b3Q7UFMxJnF1b3Q7IGFuZCAmcXVvdDtQUzI1NiZxdW90OyBhcyAmcXVvdDthbGcmcXVvdDsgdmFs dWVzLCBhbmQgYSBzaWduZXIgY3JlYXRlcyBhIHNpZ25hdHVyZSB1c2luZyAmcXVvdDtQUzI1NiZx dW90Oy4mbmJzcDsgSWYgdGhlIGF0dGFja2VyIGNhbiBjcmFmdCBhIHBheWxvYWQgdGhhdCBoYXMg dGhlIHNhbWUgU0hBLTEgZGlnZXN0IGhhcyBhcyB0aGUgU0hBLTI1NiBkaWdlc3Qgb2YNCiB0aGUg bGVnaXRpbWF0ZSBwYXlsb2FkLCB0aGVuIHRoZSAmcXVvdDtQUzEmcXVvdDsgc2lnbmF0dXJlIG92 ZXIgdGhlIGJvZ3VzIHBheWxvYWQgd2lsbCBiZSB0aGUgc2FtZSBhcyB0aGUgJnF1b3Q7UFMyNTYm cXVvdDsgc2lnbmF0dXJlIG92ZXIgdGhlIGxlZ2l0aW1hdGUgcGF5bG9hZC48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPlRoZXJlIGFyZSBzZXZlcmFsIHdheXMgZm9yIGFuIGFwcGxpY2F0aW9uIHVzaW5nIEpP U0UgdG8gbWl0aWdhdGUgYWxnb3JpdGhtIHN1YnN0aXR1dGlvbiBhdHRhY2tzOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KiBEb24ndCBhY2NlcHQg c2lnbmF0dXJlcyB1c2luZyB2dWxuZXJhYmxlIGFsZ29yaXRobXM6IEFsZ29yaXRobSBzdWJzdGl0 dXRpb24gYXR0YWNrcyBkbyBub3QgYXJpc2UgZm9yIGFsbCBzaWduYXR1cmUgYWxnb3JpdGhtcy4m bmJzcDsNCjxicj4NCiZuYnNwOyAqIFNpZ25hdHVyZXMgdXNpbmcgUlNBIFBLQ1MjMSB2MS41ICgm cXVvdDtSUzEmcXVvdDssICZxdW90O1JTMjU2JnF1b3Q7LCBldGMuKSBhcmUgbm90IHN1YmplY3Qg dG8gc3Vic3RpdHV0aW9uIGF0dGFja3MgYmVjYXVzZSB0aGUgc2lnbmF0dXJlIHZhbHVlIGl0c2Vs ZiBlbmNvZGVzIHRoZSBoYXNoIGZ1bmN0aW9uIHVzZWQuJm5ic3A7DQo8YnI+DQombmJzcDsgKiBT aWduYXR1cmVzIHdpdGggSE1BQyBhbGdvcml0aG1zICgmcXVvdDtIUzEmcXVvdDssICZxdW90O0hT MjU2JnF1b3Q7LCBldGMuKSBjYW5ub3QgYmUgc3Vic3RpdHV0ZWQgYmVjYXVzZSB0aGUgc2lnbmF0 dXJlIHZhbHVlcyBoYXZlIGRpZmZlcmVudCBsZW5ndGhzJm5ic3A7IExpa2V3aXNlIGZvciBzaWdu YXR1cmVzIHdpdGggRUNEU0EgYWxnb3JpdGhtcyAoJnF1b3Q7RVMyNTYmcXVvdDssICZxdW90O0VT Mzg0JnF1b3Q7LCBldGMuKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOyAqIFRoZSBvbmx5IGFsZ29yaXRobXMgZGVmaW5lZCBpbiBKV0Eg e3tJLUQuaWV0Zi1qb3NlLWpzb24td2ViLWFsZ29yaXRobXN9fSB0aGF0IGlzIHZ1bG5lcmFibGUg dG8gYWxnb3JpdGhtIHN1YnN0aXR1dGlvbiBhdHRhY2tzIGlzIFJTQS1QU1MgKCZxdW90O1BTMSZx dW90OywgJnF1b3Q7UFMyNTYmcXVvdDssIGV0Yy4pLiZuYnNwOyBBbiBpbXBsZW1lbnRhdGlvbiB0 aGF0IGRvZXMgbm90IHN1cHBvcnQgUlNBLVBTUyBpcyBub3QgdnVsbmVyYWJsZSB0byBhbGdvcml0 aG0NCiBzdWJzdGl0dXRpb24gYXR0YWNrcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4qIFJl cXVpcmUgdGhhdCB0aGUgJnF1b3Q7YWxnJnF1b3Q7IHBhcmFtZXRlciBiZSBjYXJyaWVkIGluIHRo ZSBwcm90ZWN0ZWQgaGVhZGVyLiZuYnNwOyAoVGhpcyBpcyB0aGUgYXBwcm9hY2ggdGFrZW4gYnkg UkZDIDYyMTEuKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+KiBJbmNsdWRlIGEgZmllbGQgcmVmbGVjdGluZyB0aGUgYWxnb3JpdGhtIGluIHRoZSBh cHBsaWNhdGlvbiBwYXlsb2FkLCBhbmQgcmVxdWlyZSB0aGF0IGl0IGJlIG1hdGNoZWQgd2l0aCB0 aGUgJnF1b3Q7YWxnJnF1b3Q7IHBhcmFtZXRlciBkdXJpbmcgdmVyaWZpY2F0aW9uIChUaGlzIGlz IHRoZSBhcHByb2FjaCB0YWtlbiBieSBQS0lYIHt7UkZDNTI4MH19Lik8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PZiB0aGVzZSBtaXRpZ2F0aW9ucywgdGhl IG9ubHkgc3VyZSBzb2x1dGlvbiBpcyB0aGUgZmlyc3QuJm5ic3A7IFNpZ25pbmcgb3ZlciB0aGUg JnF1b3Q7YWxnJnF1b3Q7IHBhcmFtZXRlciAoZGlyZWN0bHkgb3IgaW5kaXJlY3RseSkgb25seSBt YWtlcyB0aGUgYXR0YWNrZXIncyB3b3JrIG1vcmUgZGlmZmljdWx0LCBieSByZXF1aXJpbmcgdGhh dCB0aGUgYm9ndXMgcGF5bG9hZCBhbHNvIGNvbnRhaW4gYm9ndXMgaW5mb3JtYXRpb24gYWJvdXQN CiB0aGUgc2lnbmluZyBhbGdvcml0aG0uJm5ic3A7IFRoZXkgZG8gbm90IHByZXZlbnQgYXR0YWNr IGJ5IGEgc3VmZmljaWVudGx5IHBvd2VyZnVsIGF0dGFja2VyLjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mcXVvdDsmcXVvdDsmcXVvdDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIFNlcCAxOSwgMjAxNCBhdCAyOjQ5IFBNLCBNaWtl IEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0 YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgd291bGQgYXBwcmVjaWF0 ZSBpdCBpZiB5b3Ugd291bGQgd3JpdGUgYSBkcmFmdCBvZiB0aGUgcHJvcG9zZWQgc2VjdXJpdHkg Y29uc2lkZXJhdGlvbnMgdGV4dCwgUmljaGFyZC4mbmJzcDsNCiBQZXJoYXBzIHRpdGxlIHRoZSBz ZWN0aW9uIOKAnFVuc2VjdXJlZCBBbGdvcml0aG0gVmFsdWVz4oCdLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBUaGFua3MhPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IC0tIE1pa2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiBSaWNoYXJkIEJhcm5lcyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpybGJAaXB2LnN4IiB0 YXJnZXQ9Il9ibGFuayI+cmxiQGlwdi5zeDwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVz ZGF5LCBTZXB0ZW1iZXIgMTcsIDIwMTQgNjoyNCBBTTxicj4NCjxiPlRvOjwvYj4gVGVybyBLaXZp bmVuPGJyPg0KPGI+Q2M6PC9iPiBNaWtlIEpvbmVzOyA8YSBocmVmPSJtYWlsdG86aWVzZ0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmllc2dAaWV0Zi5vcmc8L2E+Ow0KPGEgaHJlZj0ibWFpbHRv OnNlY2RpckBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNlY2RpckBpZXRmLm9yZzwvYT47IDxh IGhyZWY9Im1haWx0bzppZXRmQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQppZXRmQGlldGYu b3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1zaWduYXR1 cmUuYWxsQHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpkcmFmdC1pZXRmLWpvc2Ut anNvbi13ZWItc2lnbmF0dXJlLmFsbEB0b29scy5pZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0 bzpqb3NlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpqb3NlQGlldGYub3JnPC9hPjxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogU2VjZGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLWpvc2UtanNv bi13ZWItc2lnbmF0dXJlLTMxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48YnI+DQo8YnI+DQpPbiBXZWRuZXNkYXksIFNlcHRlbWJlciAxNywgMjAxNCwg VGVybyBLaXZpbmVuICZsdDs8YSBocmVmPSJtYWlsdG86a2l2aW5lbkBpa2kuZmkiIHRhcmdldD0i X2JsYW5rIj5raXZpbmVuQGlraS5maTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5SaWNoYXJkIEJhcm5lcyB3cml0ZXM6PGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7UGVyaGFwcywgYnV0IGlzIHRoZXJlIGJlbmVmaXRzIGZvciBsZWF2aW5n IHRoZSBhbGcgd2l0aG91dCBwcm90ZWN0aW9uPzxicj4NCiZndDs8YnI+DQomZ3Q7IFNpbXBsaWNp dHkgKGlmIHlvdSBvbWl0IHByb3RlY3RlZCBoZWFkZXJzIGFsdG9nZXRoZXIpLCBhbmQ8YnI+DQom Z3Q7IGNvbXBhdGliaWxpdHkgd2l0aCBvdGhlciBzaWduZWQgdGhpbmdzLiZuYnNwOyBJbiB0aGUg c2Vuc2UgdGhhdCB5b3UgY291bGQ8YnI+DQomZ3Q7IHRyYW5zZm9ybSBvbmUgb2YgdGhlbSBpbnRv IGEgSldTIHdpdGhvdXQgcmUtc2lnbmluZy4mbmJzcDsgVGhpcyB3b3VsZDxicj4NCiZndDsgYXBw bHksIGZvciBleGFtcGxlLCB0byBhbiBYLjUwOSBjZXJ0aWZpY2F0ZSAtLSBqdXN0IHBhcnNlIHRo ZSBvdXRlcjxicj4NCiZndDsgU0VRVUVOQ0UsIGFuZCByZS1hc3NlbWJsZSBpbnRvIGEgSldTIHdp dGggdGhlIHRic0NlcnRpZmljYXRlIGFzPGJyPg0KJmd0OyBwYXlsb2FkLiZuYnNwOyBTYW1lIHNl Y3VyaXR5IHByb3BlcnRpZXMgdGhhdCBYLjUwOSBhbHJlYWR5IGhhcy48YnI+DQo8YnI+DQpPaywg aGF2aW5nIHRoaXMga2luZCBvZiBpbmZvcm1hdGlvbiBzb21ld2hlcmUgaW4gdGhlIGRyYWZ0IHdv dWxkIGhlbHA8YnI+DQp0byB1bmRlcnN0YW5kIHRoZSByZWFzb24uIEFsc28gaGF2aW5nIHRleHQg ZXhwbGFpbmluZyB0aGF0IGlzPGJyPg0KcG9zc2libGUsIGFuZCB0aGF0IHRoZSBzZWN1cml0eSBw cm9wZXJ0aWVzIG9mIHRoaXMgb3B0aW9uIChpLmUuIG5vPGJyPg0KcHJvYmxlbSB3aXRoIFBLQ1Mj MSwgZXRjLi4uIHRoZSB0ZXh0IHlvdSBoYWQgaW4gdGhlIG90aGVyIGVtYWlsKS48YnI+DQo8YnI+ DQomZ3Q7IEl0J3MgYWxzbyBjb21wbGV0ZWx5IHVubmVjZXNzYXJ5IGZvciBQS0NTIzEgc2lnbmF0 dXJlcywgd2hpY2ggYXJlPGJyPg0KJmd0OyB0aGUgZG9taW5hbnQgdXNlIGNhc2UgdG9kYXkuPGJy Pg0KPGJyPg0KSSBhZ3JlZS48YnI+DQo8YnI+DQomZ3Q7IEluIGdlbmVyYWwsIEknbSBvcHBvc2Vk IHRvIHByb3RvY29scyBiYWtpbmcgaW4gbW9yZTxicj4NCiZndDsgYXBwbGljYXRpb24tc3BlY2lm aWMgbG9naWMgdGhhbiB0aGV5IG5lZWQgdG8uJm5ic3A7IFRoZSBwb2ludCBvZiBKT1NFIGlzPGJy Pg0KJmd0OyB0byBkZXNjcmliZSB0aGUgY3J5cHRvZ3JhcGhpYyBvcGVyYXRpb24gdGhhdCB3YXMg cGVyZm9ybWVkLCBhbmQ8YnI+DQomZ3Q7IGNhcnJ5IHRoZSByZWxldmFudCBiaXRzIGFyb3VuZC4m bmJzcDsgSXRzIGpvYiBpcyBub3QgdG8gZml4IGFsbCB0aGU8YnI+DQomZ3Q7IHdlYWtuZXNzZXMg dGhhdCBldmVyeSBhbGdvcml0aG0gaGFzLiZuYnNwOzxicj4NCjxicj4NClllcywgYnV0IHRoaXMg cHJvcGVydHkgbWlnaHQgaGF2ZSBzZWN1cml0eSBpc3N1ZXMsIHNvIHRoZXkgc2hvdWxkIGJlPGJy Pg0KY292ZXJlZCBieSB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbi48bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JJ20gcGVyZmVjdGx5 IGhhcHB5IHRvIGhhdmUgaXQgZG9jdW1lbnRlZCBpbiB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlv bnMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5NaWtlOiBTaG91bGQgSSBnZW5lcmF0ZSBzb21lIHRleHQsIG9yIGRvIHlvdSB3 YW50IHRvIHRha2UgYSBzdGFiPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPi0tPGJyPg0KPGEgaHJlZj0ibWFpbHRvOmtpdmluZW5AaWtpLmZpIj5raXZpbmVuQGlr aS5maTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4E1F6AAD24975D4BA5B16804296739439BA5B7B6TK5EX14MBXC286r_-- From nobody Fri Sep 19 16:27:56 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 671351A6F91; Fri, 19 Sep 2014 16:27:47 -0700 (PDT) X-Quarantine-ID: <8S0Tvd-KivZu> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains text/plain,.exe X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 8S0Tvd-KivZu; Fri, 19 Sep 2014 16:27:44 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD13F1A03A9; Fri, 19 Sep 2014 16:27:42 -0700 (PDT) Received: from Philemon (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 967672CA4E; Fri, 19 Sep 2014 16:27:41 -0700 (PDT) From: "Jim Schaad" To: "'Richard Barnes'" , "'Mike Jones'" References: <21512.21725.209461.976375@fireball.kivinen.iki.fi> <4E1F6AAD24975D4BA5B16804296739439AE9DD47@TK5EX14MBXC292.redmond.corp.microsoft.com> <21527.63989.999440.801542@fireball.kivinen.iki.fi> <21529.16232.880915.215045@fireball.kivinen.iki.fi> <4E1F6AAD24975D4BA5B16804296739439BA59EB7@TK5EX14MBXC286.redmond.corp.microsoft.com> In-Reply-To: Date: Fri, 19 Sep 2014 16:25:16 -0700 Message-ID: <03a601cfd460$f8d71d70$ea855850$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03A7_01CFD426.4C7CB240" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHuOuT/hh4qDeGZm241cGqvJGlDHQGDSHSvAfo059oBmzmMjgKe6fc2AlAhJ5UBTPVdRAKLDxUuAlnvmcGbSnuscA== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/lGvGr-2rw6zpwOoiKbCE_uZ84cc Cc: ietf@ietf.org, secdir@ietf.org, iesg@ietf.org, jose@ietf.org, draft-ietf-jose-json-web-signature.all@tools.ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-jose-json-web-signature-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 23:27:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03A7_01CFD426.4C7CB240 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Richard Barnes [mailto:rlb@ipv.sx]=20 Sent: Friday, September 19, 2014 2:32 PM To: Mike Jones Cc: Tero Kivinen; iesg@ietf.org; secdir@ietf.org; ietf@ietf.org; = draft-ietf-jose-json-web-signature.all@tools.ietf.org; jose@ietf.org Subject: Re: Secdir review of draft-ietf-jose-json-web-signature-31 =20 """ # Signature Algorithm Protection In some usages of JWS, there is a risk of algorithm substitution = attacks, in which an attacker can use an existing signature value with a = different signature algorithm to make it appear that a signer has signed = something that he actually has not. These attacks have been discussed = in detail in the context of CMS {{RFC 6211}}. The risk arises when all = of the following are true: * Verifiers of a signature support multiple algorithms of different = strengths * Given an existing signature, an attacker can find another payload that = produces the same signature value with a weaker algorithm * In particular, the payload crafted by the attacker is valid in a given = application-layer context For example, suppose a verifier is willing to accept both "PS1" and = "PS256" as "alg" values, and a signer creates a signature using "PS256". = If the attacker can craft a payload that has the same SHA-1 digest has = as the SHA-256 digest of the legitimate payload, then the "PS1" = signature over the bogus payload will be the same as the "PS256" = signature over the legitimate payload. =20 There are several ways for an application using JOSE to mitigate = algorithm substitution attacks: * Don't accept signatures using vulnerable algorithms: Algorithm = substitution attacks do not arise for all signature algorithms. =20 * Signatures using RSA PKCS#1 v1.5 ("RS1", "RS256", etc.) are not = subject to substitution attacks because the signature value itself = encodes the hash function used. =20 * Signatures with HMAC algorithms ("HS1", "HS256", etc.) cannot be = substituted because the signature values have different lengths = Likewise for signatures with ECDSA algorithms ("ES256", "ES384", etc.). =20 [JLS] This is not a true statement. If you support both SHA256 and = SHA512/256 then the signature values have the same length. This will = also be an issue if you support both the SHA2 and the SHA3 algorithm = sets as they have results of the same length. =20 * The only algorithms defined in JWA = {{I-D.ietf-jose-json-web-algorithms}} that is vulnerable to algorithm = substitution attacks is RSA-PSS ("PS1", "PS256", etc.). An = implementation that does not support RSA-PSS is not vulnerable to = algorithm substitution attacks. =20 [JLS] ECDSA is open to this attack if you support both SHA256 and = SHA512/256 the hash lengths are the same. This will also be an issue if = you support both the SHA2 and the SHA3 algorithm sets as they have = results of the same length. =20 * Require that the "alg" parameter be carried in the protected header. = (This is the approach taken by RFC 6211.) * Include a field reflecting the algorithm in the application payload, = and require that it be matched with the "alg" parameter during = verification (This is the approach taken by PKIX {{RFC5280}}.) =20 [JLS] RSA-PKCS#1.5 is open to this attack if the suggestion of Mike in a = message prior to this is put into the text. That is to allow for the = hash inside of the signature and that outside of the signature to differ = in value because you only enforce one of the two values. =20 Of these mitigations, the only sure solution is the first. Signing over = the "alg" parameter (directly or indirectly) only makes the attacker's = work more difficult, by requiring that the bogus payload also contain = bogus information about the signing algorithm. They do not prevent = attack by a sufficiently powerful attacker. """ =20 On Fri, Sep 19, 2014 at 2:49 PM, Mike Jones = wrote: I would appreciate it if you would write a draft of the proposed = security considerations text, Richard. Perhaps title the section = =E2=80=9CUnsecured Algorithm Values=E2=80=9D. =20 Thanks! -- Mike =20 From: Richard Barnes [mailto:rlb@ipv.sx]=20 Sent: Wednesday, September 17, 2014 6:24 AM To: Tero Kivinen Cc: Mike Jones; iesg@ietf.org; secdir@ietf.org; ietf@ietf.org; = draft-ietf-jose-json-web-signature.all@tools.ietf.org; jose@ietf.org Subject: Re: Secdir review of draft-ietf-jose-json-web-signature-31 =20 On Wednesday, September 17, 2014, Tero Kivinen wrote: Richard Barnes writes: > Perhaps, but is there benefits for leaving the alg without = protection? > > Simplicity (if you omit protected headers altogether), and > compatibility with other signed things. In the sense that you could > transform one of them into a JWS without re-signing. This would > apply, for example, to an X.509 certificate -- just parse the outer > SEQUENCE, and re-assemble into a JWS with the tbsCertificate as > payload. Same security properties that X.509 already has. Ok, having this kind of information somewhere in the draft would help to understand the reason. Also having text explaining that is possible, and that the security properties of this option (i.e. no problem with PKCS#1, etc... the text you had in the other email). > It's also completely unnecessary for PKCS#1 signatures, which are > the dominant use case today. I agree. > In general, I'm opposed to protocols baking in more > application-specific logic than they need to. The point of JOSE is > to describe the cryptographic operation that was performed, and > carry the relevant bits around. Its job is not to fix all the > weaknesses that every algorithm has.=20 Yes, but this property might have security issues, so they should be covered by the security considerations section. =20 I'm perfectly happy to have it documented in the Security = Considerations.=20 =20 Mike: Should I generate some text, or do you want to take a stab? =20 -- kivinen@iki.fi =20 ------=_NextPart_000_03A7_01CFD426.4C7CB240 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

From:= = Richard Barnes [mailto:rlb@ipv.sx]
Sent: Friday, September = 19, 2014 2:32 PM
To: Mike Jones
Cc: Tero Kivinen; = iesg@ietf.org; secdir@ietf.org; ietf@ietf.org; = draft-ietf-jose-json-web-signature.all@tools.ietf.org; = jose@ietf.org
Subject: Re: Secdir review of = draft-ietf-jose-json-web-signature-31

"""
# Signature = Algorithm Protection

In some = usages of JWS, there is a risk of algorithm substitution attacks, in = which an attacker can use an existing signature value with a different = signature algorithm to make it appear that a signer has signed something = that he actually has not. These attacks have been discussed in = detail in the context of CMS {{RFC 6211}}. The risk arises when = all of the following are true:

* Verifiers of a signature support multiple = algorithms of different strengths

* Given an existing signature, an attacker can find = another payload that produces the same signature value with a weaker = algorithm

* In particular, the payload crafted by = the attacker is valid in a given application-layer = context

For example, suppose a = verifier is willing to accept both "PS1" and "PS256" = as "alg" values, and a signer creates a signature using = "PS256". If the attacker can craft a payload that has = the same SHA-1 digest has as the SHA-256 digest of the legitimate = payload, then the "PS1" signature over the bogus payload will = be the same as the "PS256" signature over the legitimate = payload.

There are several ways for an application = using JOSE to mitigate algorithm substitution = attacks:

* Don't accept = signatures using vulnerable algorithms: Algorithm substitution attacks = do not arise for all signature algorithms.
* Signatures = using RSA PKCS#1 v1.5 ("RS1", "RS256", etc.) are not = subject to substitution attacks because the signature value itself = encodes the hash function used.
* Signatures with HMAC = algorithms ("HS1", "HS256", etc.) cannot be = substituted because the signature values have different lengths = Likewise for signatures with ECDSA algorithms ("ES256", = "ES384", etc.).

[JLS] This is not a true statement.=C2=A0 If you support both SHA256 = and SHA512/256 then the signature values have the same length.=C2=A0 = This will also be an issue if you support both the SHA2 and the SHA3 = algorithm sets as they have results of the same = length.

* = The only algorithms defined in JWA {{I-D.ietf-jose-json-web-algorithms}} = that is vulnerable to algorithm substitution attacks is RSA-PSS = ("PS1", "PS256", etc.). An implementation that = does not support RSA-PSS is not vulnerable to algorithm substitution = attacks.

[JLS] ECDSA is open to this attack if you support both SHA256 and = SHA512/256 the hash lengths are the same.=C2=A0 This will also be an = issue if you support both the SHA2 and the SHA3 algorithm sets as they = have results of the same length.

* Require that the "alg" = parameter be carried in the protected header. (This is the = approach taken by RFC 6211.)

* Include a field reflecting the algorithm in the = application payload, and require that it be matched with the = "alg" parameter during verification (This is the approach = taken by PKIX {{RFC5280}}.)

[JLS] RSA-PKCS#1.5 is open to this attack if the suggestion of Mike = in a message prior to this is put into the text.=C2=A0 That is to allow = for the hash inside of the signature and that outside of the signature = to differ in value because you only enforce one of the two = values.

Of = these mitigations, the only sure solution is the first. Signing = over the "alg" parameter (directly or indirectly) only makes = the attacker's work more difficult, by requiring that the bogus payload = also contain bogus information about the signing algorithm. They = do not prevent attack by a sufficiently powerful = attacker.

On Fri, = Sep 19, 2014 at 2:49 PM, Mike Jones <Michael.Jones@microsoft.com> = wrote:

I would appreciate it if you would write a draft of the proposed = security considerations text, Richard. Perhaps title the section = =E2=80=9CUnsecured Algorithm Values=E2=80=9D.

&nbs= p; = ; = &= nbsp; = Thanks!

&nbs= p; = ; = &= nbsp; -- = Mike

From:= = Richard Barnes [mailto:rlb@ipv.sx]
Sent: Wednesday, September = 17, 2014 6:24 AM
To: Tero Kivinen
Cc: Mike Jones; iesg@ietf.org; secdir@ietf.org; = ietf@ietf.org; draft-ietf-jose-json-web-signature.all@tools.ietf.org; jose@ietf.org
Subject: Re: Secdir review = of = draft-ietf-jose-json-web-signature-31

<= /o:p>

On = Wednesday, September 17, 2014, Tero Kivinen <kivinen@iki.fi> = wrote:

Richard = Barnes writes:
> Perhaps, but is there benefits = for leaving the alg without protection?
>
> Simplicity (if = you omit protected headers altogether), and
> compatibility with = other signed things. In the sense that you could
> transform = one of them into a JWS without re-signing. This would
> = apply, for example, to an X.509 certificate -- just parse the = outer
> SEQUENCE, and re-assemble into a JWS with the = tbsCertificate as
> payload. Same security properties that = X.509 already has.

Ok, having this kind of information somewhere = in the draft would help
to understand the reason. Also having text = explaining that is
possible, and that the security properties of this = option (i.e. no
problem with PKCS#1, etc... the text you had in the = other email).

> It's also completely unnecessary for PKCS#1 = signatures, which are
> the dominant use case today.

I = agree.

> In general, I'm opposed to protocols baking in = more
> application-specific logic than they need to. The = point of JOSE is
> to describe the cryptographic operation that = was performed, and
> carry the relevant bits around. Its job = is not to fix all the
> weaknesses that every algorithm = has.

Yes, but this property might have security issues, so = they should be
covered by the security considerations = section.

<= /o:p>

I'm = perfectly happy to have it documented in the Security = Considerations.

<= /o:p>

Mike: = Should I generate some text, or do you want to take a = stab?

<= /o:p>

--
kivinen@iki.fi

------=_NextPart_000_03A7_01CFD426.4C7CB240-- From nobody Fri Sep 19 19:17:32 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7F941A891D for ; Fri, 19 Sep 2014 19:17:29 -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 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 TgtT4Mn8d_U2 for ; Fri, 19 Sep 2014 19:17:26 -0700 (PDT) Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BF9B1A8918 for ; Fri, 19 Sep 2014 19:17:25 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id x48so539933wes.21 for ; Fri, 19 Sep 2014 19:17:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=LxQxAVP0m9HMgKs77Q+eFmk8UOv8au7rekWPRI68CBE=; b=fQNiaEWPzG9ElHnbkolS8QEfG1lvNM4uNWIvpiGiIaQMqYcwNZ7OA6IQPRu2EDZ+SC XSQM2KEqMbynw8BuvC7rDnN61x+fd4TthacmqKzPDStj4MtSSIfyxWu3cBkkiuyzo+HW k7Vyc8FE+HYDjmlngBh3mMJZ4iiCNp3Slu1640GhWHsEAorr//Afq3wrYDIfr3VSMdSG eVJugMdFJs5vjyn+54pO3cxIw6beukRhw+xAfiEsWHKjSTwwNvGlsPx0gRUpyJOFVDBn WjLaucaFC8osSq+s4gRaH2l0Z+zzGjc/W49lpsul7g/346RylVzexTonehDSS+ktR/i4 WIog== X-Gm-Message-State: ALoCoQl8EFCqfUYnOCOAgNS7VyCJbtpQaxMYDKcl4KMU8nG4uNb6hymDem+xNc7rwd928wf3hBeq X-Received: by 10.180.182.67 with SMTP id ec3mr632536wic.12.1411179444506; Fri, 19 Sep 2014 19:17:24 -0700 (PDT) Received: from [10.6.0.146] ([95.211.146.166]) by mx.google.com with ESMTPSA id gj3sm3861943wib.15.2014.09.19.19.17.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Sep 2014 19:17:23 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_FCEAC809-B68D-4C9D-9E0B-92138C502043"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 $1878.6$) From: John Bradley In-Reply-To: <03a601cfd460$f8d71d70$ea855850$@augustcellars.com> Date: Fri, 19 Sep 2014 22:17:05 -0400 Message-Id: References: <21512.21725.209461.976375@fireball.kivinen.iki.fi> <4E1F6AAD24975D4BA5B16804296739439AE9DD47@TK5EX14MBXC292.redmond.corp.microsoft.com> <21527.63989.999440.801542@fireball.kivinen.iki.fi> <21529.16232.880915.215045@fireball.kivinen.iki.fi> <4E1F6AAD24975D4BA5B16804296739439BA59EB7@TK5EX14MBXC286.redmond.corp.microsoft.com> <03a601cfd460$f8d71d70$ea855850$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/-MgbCdvVqK7sxXIjMvo4E32MveQ Cc: ietf@ietf.org, secdir@ietf.org, Michael Jones , IESG , jose@ietf.org, draft-ietf-jose-json-web-signature.all@tools.ietf.org Subject: Re: [secdir] [jose] Secdir review of draft-ietf-jose-json-web-signature-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 02:17:30 -0000 --Apple-Mail=_FCEAC809-B68D-4C9D-9E0B-92138C502043 Content-Type: multipart/alternative; boundary="Apple-Mail=_1F640F46-80AF-4EE5-80F5-27330CEAFC41" --Apple-Mail=_1F640F46-80AF-4EE5-80F5-27330CEAFC41 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 For HMAC changing the hash from SHA3 256 to SHA2 256 doesn't really get = the attacker much as they still don't know the key to be able to create = a appropriate fake plaintext. So simply knowing a value that creates a collision is not sufficient for = an attack. I interpreted Mike's comment on PKCS#1 as being that the signature needs = to be verified by the algorithm specified in the "alg" parameter. That = is not to say that if in the case of PKCS#1 padding if the OID is not = consistent with the value of "alg" that wouldn't be an error. I think = that would be a invalid JWS. I do think that should be made clear. =20= With PSS if the key is the same length it is true that you are going to = be vulnerable to collisions over the plaintext based on the weakest hash = you can get the receiver to accept. =20 This is not a issue unique to JOSE in any way. One would be tempted to = rule out SHA1 now but it is differentiated by it's key length, so can't = be downgraded to from SHA2. John B. On Sep 19, 2014, at 7:25 PM, Jim Schaad wrote: > =20 > =20 > From: Richard Barnes [mailto:rlb@ipv.sx]=20 > Sent: Friday, September 19, 2014 2:32 PM > To: Mike Jones > Cc: Tero Kivinen; iesg@ietf.org; secdir@ietf.org; ietf@ietf.org; = draft-ietf-jose-json-web-signature.all@tools.ietf.org;jose@ietf.org > Subject: Re: Secdir review of draft-ietf-jose-json-web-signature-31 > =20 > """ > # Signature Algorithm Protection >=20 > In some usages of JWS, there is a risk of algorithm substitution = attacks, in which an attacker can use an existing signature value with a = different signature algorithm to make it appear that a signer has signed = something that he actually has not. These attacks have been discussed = in detail in the context of CMS {{RFC 6211}}. The risk arises when all = of the following are true: >=20 > * Verifiers of a signature support multiple algorithms of different = strengths > * Given an existing signature, an attacker can find another payload = that produces the same signature value with a weaker algorithm > * In particular, the payload crafted by the attacker is valid in a = given application-layer context >=20 > For example, suppose a verifier is willing to accept both "PS1" and = "PS256" as "alg" values, and a signer creates a signature using "PS256". = If the attacker can craft a payload that has the same SHA-1 digest has = as the SHA-256 digest of the legitimate payload, then the "PS1" = signature over the bogus payload will be the same as the "PS256" = signature over the legitimate payload. > =20 > There are several ways for an application using JOSE to mitigate = algorithm substitution attacks: >=20 > * Don't accept signatures using vulnerable algorithms: Algorithm = substitution attacks do not arise for all signature algorithms. =20 > * Signatures using RSA PKCS#1 v1.5 ("RS1", "RS256", etc.) are not = subject to substitution attacks because the signature value itself = encodes the hash function used. =20 > * Signatures with HMAC algorithms ("HS1", "HS256", etc.) cannot be = substituted because the signature values have different lengths = Likewise for signatures with ECDSA algorithms ("ES256", "ES384", etc.). > =20 > [JLS] This is not a true statement. If you support both SHA256 and = SHA512/256 then the signature values have the same length. This will = also be an issue if you support both the SHA2 and the SHA3 algorithm = sets as they have results of the same length. > =20 > * The only algorithms defined in JWA = {{I-D.ietf-jose-json-web-algorithms}} that is vulnerable to algorithm = substitution attacks is RSA-PSS ("PS1", "PS256", etc.). An = implementation that does not support RSA-PSS is not vulnerable to = algorithm substitution attacks. > =20 > [JLS] ECDSA is open to this attack if you support both SHA256 and = SHA512/256 the hash lengths are the same. This will also be an issue if = you support both the SHA2 and the SHA3 algorithm sets as they have = results of the same length. > =20 > * Require that the "alg" parameter be carried in the protected header. = (This is the approach taken by RFC 6211.) >=20 > * Include a field reflecting the algorithm in the application payload, = and require that it be matched with the "alg" parameter during = verification (This is the approach taken by PKIX {{RFC5280}}.) > =20 > [JLS] RSA-PKCS#1.5 is open to this attack if the suggestion of Mike in = a message prior to this is put into the text. That is to allow for the = hash inside of the signature and that outside of the signature to differ = in value because you only enforce one of the two values. > =20 > Of these mitigations, the only sure solution is the first. Signing = over the "alg" parameter (directly or indirectly) only makes the = attacker's work more difficult, by requiring that the bogus payload also = contain bogus information about the signing algorithm. They do not = prevent attack by a sufficiently powerful attacker. > """ > =20 > On Fri, Sep 19, 2014 at 2:49 PM, Mike Jones = wrote: > I would appreciate it if you would write a draft of the proposed = security considerations text, Richard. Perhaps title the section = =93Unsecured Algorithm Values=94. > =20 > Thanks! > -- Mike > =20 > From: Richard Barnes [mailto:rlb@ipv.sx]=20 > Sent: Wednesday, September 17, 2014 6:24 AM > To: Tero Kivinen > Cc: Mike Jones; iesg@ietf.org; secdir@ietf.org; ietf@ietf.org; = draft-ietf-jose-json-web-signature.all@tools.ietf.org;jose@ietf.org > Subject: Re: Secdir review of draft-ietf-jose-json-web-signature-31 > =20 >=20 >=20 > On Wednesday, September 17, 2014, Tero Kivinen wrote: > Richard Barnes writes: > > Perhaps, but is there benefits for leaving the alg without = protection? > > > > Simplicity (if you omit protected headers altogether), and > > compatibility with other signed things. In the sense that you could > > transform one of them into a JWS without re-signing. This would > > apply, for example, to an X.509 certificate -- just parse the outer > > SEQUENCE, and re-assemble into a JWS with the tbsCertificate as > > payload. Same security properties that X.509 already has. >=20 > Ok, having this kind of information somewhere in the draft would help > to understand the reason. Also having text explaining that is > possible, and that the security properties of this option (i.e. no > problem with PKCS#1, etc... the text you had in the other email). >=20 > > It's also completely unnecessary for PKCS#1 signatures, which are > > the dominant use case today. >=20 > I agree. >=20 > > In general, I'm opposed to protocols baking in more > > application-specific logic than they need to. The point of JOSE is > > to describe the cryptographic operation that was performed, and > > carry the relevant bits around. Its job is not to fix all the > > weaknesses that every algorithm has.=20 >=20 > Yes, but this property might have security issues, so they should be > covered by the security considerations section. > =20 > I'm perfectly happy to have it documented in the Security = Considerations.=20 > =20 > Mike: Should I generate some text, or do you want to take a stab? > =20 > -- > kivinen@iki.fi > =20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_1F640F46-80AF-4EE5-80F5-27330CEAFC41 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 For = HMAC changing the hash from SHA3 256 to SHA2 256 doesn't really = get the attacker much as they still don't know the key to be able to = create a appropriate fake plaintext.

So simply knowing a value that = creates a collision is not sufficient for an = attack.

I interpreted Mike's comment on PKCS#1 = as being that the signature needs to be verified by the algorithm = specified in the "alg" parameter. That is not to say that if in = the case of PKCS#1 padding if the OID is not consistent with the value = of "alg" that wouldn't be an error. I think that would be a = invalid JWS. I do think that should be made clear. =

With PSS if the key is the same length = it is true that you are going to be vulnerable to collisions over the = plaintext based on the weakest hash you can get the receiver to accept. =

This is not a issue unique to JOSE in any way. = One would be tempted to rule out SHA1 now but it is differentiated by = it's key length, so can't be downgraded to from = SHA2.

John = B.

On Sep 19, 2014, at = 7:25 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

From: Richard Barnes [mailto:rlb@ipv.sx]
Sent: Friday, September 19, 2014 = 2:32 PM
To: Mike = Jones
Cc: Tero= Kivinen; iesg@ietf.org; secdir@ietf.org; ietf@ietf.org; draft-ietf-jose-json-web-signature.all@tools.ietf.org;jose@ietf.org
Subject: Re: Secdir review of = draft-ietf-jose-json-web-signature-31

"""
# Signature Algorithm = Protection
In some usages = of JWS, there is a risk of algorithm substitution attacks, in which an = attacker can use an existing signature value with a different signature = algorithm to make it appear that a signer has signed something that he = actually has not. These attacks have been discussed in detail in = the context of CMS {{RFC 6211}}. The risk arises when all of the = following are true:

* = Verifiers of a signature support multiple algorithms of different = strengths
* Given an = existing signature, an attacker can find another payload that produces = the same signature value with a weaker = algorithm
* = In particular, the payload crafted by the attacker is valid in a given = application-layer context
For example, suppose a verifier is willing to accept both "PS1" = and "PS256" as "alg" values, and a signer creates a signature using = "PS256". If the attacker can craft a payload that has the same = SHA-1 digest has as the SHA-256 digest of the legitimate payload, then = the "PS1" signature over the bogus payload will be the same as the = "PS256" signature over the legitimate = payload.

There are several ways for an application using JOSE to = mitigate algorithm substitution attacks:
* Don't accept signatures using vulnerable = algorithms: Algorithm substitution attacks do not arise for all = signature algorithms.
* Signatures = using RSA PKCS#1 v1.5 ("RS1", "RS256", etc.) are not subject to = substitution attacks because the signature value itself encodes the hash = function used.
* Signatures = with HMAC algorithms ("HS1", "HS256", etc.) cannot be substituted = because the signature values have different lengths Likewise for = signatures with ECDSA algorithms ("ES256", "ES384", = etc.).

[JLS] This is not a true statement. If you = support both SHA256 and SHA512/256 then the signature values have the = same length. This will also be an issue if you support both the = SHA2 and the SHA3 algorithm sets as they have results of the same = length.

* The only algorithms defined in JWA = {{I-D.ietf-jose-json-web-algorithms}} that is vulnerable to algorithm = substitution attacks is RSA-PSS ("PS1", "PS256", etc.). An = implementation that does not support RSA-PSS is not vulnerable to = algorithm substitution attacks.

[JLS] ECDSA is open to = this attack if you support both SHA256 and SHA512/256 the hash lengths = are the same. This will also be an issue if you support both the = SHA2 and the SHA3 algorithm sets as they have results of the same = length.

* Require that the "alg" parameter be carried in the = protected header. (This is the approach taken by RFC = 6211.)
* Include a = field reflecting the algorithm in the application payload, and require = that it be matched with the "alg" parameter during verification (This is = the approach taken by PKIX {{RFC5280}}.)

[JLS] RSA-PKCS#1.5 is = open to this attack if the suggestion of Mike in a message prior to this = is put into the text. That is to allow for the hash inside of the = signature and that outside of the signature to differ in value because = you only enforce one of the two = values.

Of = these mitigations, the only sure solution is the first. Signing = over the "alg" parameter (directly or indirectly) only makes the = attacker's work more difficult, by requiring that the bogus payload also = contain bogus information about the signing algorithm. They do not = prevent attack by a sufficiently powerful = attacker.
"""

On = Fri, Sep 19, 2014 at 2:49 PM, Mike Jones <Michael.Jones@microsoft.com> = wrote:
I would appreciate it if you would write a draft of = the proposed security considerations text, Richard. Perhaps title = the section =93Unsecured Algorithm Values=94.

           &= nbsp;           &nb= sp;            = ;            &= nbsp;           = Thanks!
           &= nbsp;           &nb= sp;            = ;            &= nbsp;           -- = Mike

From: Richard Barnes [mailto:rlb@ipv.sx]
Sent: Wednesday, September 17, = 2014 6:24 AM
To: Tero = Kivinen
Cc: Mike Jones; iesg@ietf.org; secdir@ietf.org; ietf@ietf.org; draft-ietf-jose-json-web-signature.all@tools.ietf.org;jose@ietf.org
Subject: Re: Secdir review of = draft-ietf-jose-json-web-signature-31

On Wednesday, September 17, 2014, Tero Kivinen <kivinen@iki.fi> = wrote:
Richard Barnes = writes:
> Perhaps, but is there benefits for = leaving the alg without protection?
>
> Simplicity (if you = omit protected headers altogether), and
> compatibility with other = signed things. In the sense that you could
> transform one = of them into a JWS without re-signing. This would
> apply, = for example, to an X.509 certificate -- just parse the outer
> = SEQUENCE, and re-assemble into a JWS with the tbsCertificate as
> = payload. Same security properties that X.509 already = has.

Ok, having this kind of information somewhere in the draft = would help
to understand the reason. Also having text explaining that = is
possible, and that the security properties of this option (i.e. = no
problem with PKCS#1, etc... the text you had in the other = email).

> It's also completely unnecessary for PKCS#1 = signatures, which are
> the dominant use case today.

I = agree.

> In general, I'm opposed to protocols baking in = more
> application-specific logic than they need to. The = point of JOSE is
> to describe the cryptographic operation that = was performed, and
> carry the relevant bits around. Its job = is not to fix all the
> weaknesses that every algorithm = has.

Yes, but this property might have security issues, so = they should be
covered by the security considerations = section.

I'm = perfectly happy to have it documented in the Security = Considerations.

Mike: = Should I generate some text, or do you want to take a = stab?

--
kivinen@iki.fi

_______________________________= ________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose

= --Apple-Mail=_1F640F46-80AF-4EE5-80F5-27330CEAFC41-- --Apple-Mail=_FCEAC809-B68D-4C9D-9E0B-92138C502043 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNDA5MjAwMjE3MDZaMCMGCSqGSIb3DQEJBDEWBBQY1qv6FZHHhj1eQWP5YNbs cI0CQTCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQBlP+dckhXiJiWElqz7s1Xu4h4ao4xK29yjhMDuL5p/no0qWqr7gKrt gPd8o6Mrvz4OHsPymuvp1nvfK/2ghGXdHLIAKqo1N2FfHMievxF1oJMScu2K0/NOkvfhTs0oKMze l0dwV6iJYZa8RzlgE2ARa9jtA5QNY2u426mTZv9bkoaI4NuzwohsSWAq8PCUFN8zRldZCU05ohPE xJeM3frTS6r9CWE6EiPsOfyrmACeSWRnZKqQAXZXUTvwA5NThi2NraI62uG/zfypcPnAOFJADncM f4TbYyg8Ec4h/3nBIJbtbmcb7aObIDG43jqLxFAmWcay98mTGoaxP0jiGLWzAAAAAAAA --Apple-Mail=_FCEAC809-B68D-4C9D-9E0B-92138C502043-- From nobody Fri Sep 19 19:37:15 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5518C1A0072; Fri, 19 Sep 2014 19:37:12 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 ZvOzNtAY3wnZ; Fri, 19 Sep 2014 19:37:07 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0126.outbound.protection.outlook.com [65.55.169.126]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 771741A005D; Fri, 19 Sep 2014 19:37:06 -0700 (PDT) Received: from BN3PR0301CA0002.namprd03.prod.outlook.com (25.160.180.140) by BY1PR0301MB1206.namprd03.prod.outlook.com (25.161.203.155) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Sat, 20 Sep 2014 02:37:04 +0000 Received: from BY2FFO11FD025.protection.gbl (2a01:111:f400:7c0c::153) by BN3PR0301CA0002.outlook.office365.com (2a01:111:e400:4000::12) with Microsoft SMTP Server (TLS) id 15.0.1034.13 via Frontend Transport; Sat, 20 Sep 2014 02:37:03 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD025.mail.protection.outlook.com (10.1.15.214) with Microsoft SMTP Server (TLS) id 15.0.1029.15 via Frontend Transport; Sat, 20 Sep 2014 02:37:03 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.23]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.03.0195.002; Sat, 20 Sep 2014 02:36:33 +0000 From: Mike Jones To: John Bradley , Jim Schaad Thread-Topic: [jose] Secdir review of draft-ietf-jose-json-web-signature-31 Thread-Index: Ac/Ue6/WWdMUgOdf8EqNa4N9Ytbe4Q== Content-Class: urn:content-classes:message Date: Sat, 20 Sep 2014 02:36:32 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BA5C5C0@TK5EX14MBXC286.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439BA5C5C0TK5EX14MBXC286r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(438002)(189002)(51444003)(24454002)(199003)(52544003)(377454003)(41574002)(51704005)(92566001)(74662003)(83322001)(92726001)(19617315012)(86612001)(31966008)(86362001)(81542003)(33656002)(6806004)(79102003)(16236675004)(19580405001)(69596002)(81342003)(19580395003)(85852003)(77982003)(80022003)(15975445006)(68736004)(46102003)(107046002)(104016003)(74502003)(26826002)(44976005)(83072002)(85306004)(106466001)(55846006)(84676001)(90102001)(87936001)(50986999)(230783001)(64706001)(20776003)(54356999)(77096002)(512874002)(99396002)(2656002)(95666004)(97736003)(84326002)(71186001)(76482002)(21056001)(85806002)(81156004)(4396001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0301MB1206; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0301MB1206; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0340850FCD Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Qyl9QcVUB7kdg-C-KIBjakwbjAM Cc: "ietf@ietf.org" , "secdir@ietf.org" , IESG , "jose@ietf.org" , "draft-ietf-jose-json-web-signature.all@tools.ietf.org" Subject: Re: [secdir] [jose] Secdir review of draft-ietf-jose-json-web-signature-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 02:37:12 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439BA5C5C0TK5EX14MBXC286r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW91ciBpbnRlcnByZXRhdGlvbiBtYXRjaGVzIG15IGludGVudC4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpGcm9tOiBKb2huIEJyYWRsZXk8bWFpbHRvOnZlN2p0YkB2ZTdqdGIu Y29tPg0KU2VudDog4oCOOS/igI4xOS/igI4yMDE0IDc6MTcgUE0NClRvOiBKaW0gU2NoYWFkPG1h aWx0bzppZXRmQGF1Z3VzdGNlbGxhcnMuY29tPg0KQ2M6IFJpY2hhcmQgQmFybmVzPG1haWx0bzpy bGJAaXB2LnN4PjsgTWlrZSBKb25lczxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29t PjsgaWV0ZkBpZXRmLm9yZzxtYWlsdG86aWV0ZkBpZXRmLm9yZz47IHNlY2RpckBpZXRmLm9yZzxt YWlsdG86c2VjZGlyQGlldGYub3JnPjsgVGVybyBLaXZpbmVuPG1haWx0bzpraXZpbmVuQGlraS5m aT47IElFU0c8bWFpbHRvOmllc2dAaWV0Zi5vcmc+OyBqb3NlQGlldGYub3JnPG1haWx0bzpqb3Nl QGlldGYub3JnPjsgZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLXNpZ25hdHVyZS5hbGxAdG9vbHMu aWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1zaWduYXR1cmUuYWxsQHRv b2xzLmlldGYub3JnPg0KU3ViamVjdDogUmU6IFtqb3NlXSBTZWNkaXIgcmV2aWV3IG9mIGRyYWZ0 LWlldGYtam9zZS1qc29uLXdlYi1zaWduYXR1cmUtMzENCg0KRm9yIEhNQUMgY2hhbmdpbmcgdGhl ICBoYXNoIGZyb20gU0hBMyAyNTYgdG8gU0hBMiAyNTYgZG9lc24ndCByZWFsbHkgZ2V0IHRoZSBh dHRhY2tlciBtdWNoIGFzIHRoZXkgc3RpbGwgZG9uJ3Qga25vdyB0aGUga2V5IHRvIGJlIGFibGUg dG8gY3JlYXRlIGEgYXBwcm9wcmlhdGUgZmFrZSBwbGFpbnRleHQuDQpTbyBzaW1wbHkga25vd2lu ZyBhIHZhbHVlIHRoYXQgY3JlYXRlcyBhIGNvbGxpc2lvbiBpcyBub3Qgc3VmZmljaWVudCBmb3Ig YW4gYXR0YWNrLg0KDQpJIGludGVycHJldGVkIE1pa2UncyBjb21tZW50IG9uIFBLQ1MjMSBhcyBi ZWluZyB0aGF0IHRoZSBzaWduYXR1cmUgbmVlZHMgdG8gYmUgdmVyaWZpZWQgYnkgdGhlIGFsZ29y aXRobSBzcGVjaWZpZWQgaW4gdGhlICJhbGciIHBhcmFtZXRlci4gIFRoYXQgaXMgbm90IHRvIHNh eSB0aGF0IGlmIGluIHRoZSBjYXNlIG9mIFBLQ1MjMSBwYWRkaW5nIGlmIHRoZSBPSUQgaXMgbm90 IGNvbnNpc3RlbnQgd2l0aCB0aGUgdmFsdWUgb2YgImFsZyIgdGhhdCB3b3VsZG4ndCBiZSBhbiBl cnJvci4gICBJIHRoaW5rIHRoYXQgd291bGQgYmUgYSBpbnZhbGlkIEpXUy4gICAgIEkgZG8gdGhp bmsgdGhhdCBzaG91bGQgYmUgbWFkZSBjbGVhci4NCg0KV2l0aCBQU1MgaWYgdGhlIGtleSBpcyB0 aGUgc2FtZSBsZW5ndGggaXQgaXMgdHJ1ZSB0aGF0IHlvdSBhcmUgZ29pbmcgdG8gYmUgdnVsbmVy YWJsZSB0byBjb2xsaXNpb25zIG92ZXIgdGhlIHBsYWludGV4dCBiYXNlZCBvbiB0aGUgd2Vha2Vz dCBoYXNoIHlvdSBjYW4gZ2V0IHRoZSByZWNlaXZlciB0byBhY2NlcHQuDQpUaGlzIGlzIG5vdCBh IGlzc3VlIHVuaXF1ZSB0byBKT1NFIGluIGFueSB3YXkuICAgT25lIHdvdWxkIGJlIHRlbXB0ZWQg dG8gcnVsZSBvdXQgU0hBMSBub3cgYnV0IGl0IGlzIGRpZmZlcmVudGlhdGVkIGJ5IGl0J3Mga2V5 IGxlbmd0aCwgc28gY2FuJ3QgYmUgZG93bmdyYWRlZCB0byBmcm9tIFNIQTIuDQoNCkpvaG4gQi4N Cg0KDQpPbiBTZXAgMTksIDIwMTQsIGF0IDc6MjUgUE0sIEppbSBTY2hhYWQgPGlldGZAYXVndXN0 Y2VsbGFycy5jb208bWFpbHRvOmlldGZAYXVndXN0Y2VsbGFycy5jb20+PiB3cm90ZToNCg0KDQoN CkZyb206IFJpY2hhcmQgQmFybmVzIFttYWlsdG86cmxiQGlwdi5zeF0NClNlbnQ6IEZyaWRheSwg U2VwdGVtYmVyIDE5LCAyMDE0IDI6MzIgUE0NClRvOiBNaWtlIEpvbmVzDQpDYzogVGVybyBLaXZp bmVuOyBpZXNnQGlldGYub3JnPG1haWx0bzppZXNnQGlldGYub3JnPjsgc2VjZGlyQGlldGYub3Jn PG1haWx0bzpzZWNkaXJAaWV0Zi5vcmc+OyBpZXRmQGlldGYub3JnPG1haWx0bzppZXRmQGlldGYu b3JnPjsgZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLXNpZ25hdHVyZS5hbGxAdG9vbHMuaWV0Zi5v cmc8bWFpbHRvOmRyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1zaWduYXR1cmUuYWxsQHRvb2xzLmll dGYub3JnPjtqb3NlQGlldGYub3JnPG1haWx0bzpqb3NlQGlldGYub3JnPg0KU3ViamVjdDogUmU6 IFNlY2RpciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLXNpZ25hdHVyZS0zMQ0K DQoiIiINCiMgU2lnbmF0dXJlIEFsZ29yaXRobSBQcm90ZWN0aW9uDQpJbiBzb21lIHVzYWdlcyBv ZiBKV1MsIHRoZXJlIGlzIGEgcmlzayBvZiBhbGdvcml0aG0gc3Vic3RpdHV0aW9uIGF0dGFja3Ms IGluIHdoaWNoIGFuIGF0dGFja2VyIGNhbiB1c2UgYW4gZXhpc3Rpbmcgc2lnbmF0dXJlIHZhbHVl IHdpdGggYSBkaWZmZXJlbnQgc2lnbmF0dXJlIGFsZ29yaXRobSB0byBtYWtlIGl0IGFwcGVhciB0 aGF0IGEgc2lnbmVyIGhhcyBzaWduZWQgc29tZXRoaW5nIHRoYXQgaGUgYWN0dWFsbHkgaGFzIG5v dC4gIFRoZXNlIGF0dGFja3MgaGF2ZSBiZWVuIGRpc2N1c3NlZCBpbiBkZXRhaWwgaW4gdGhlIGNv bnRleHQgb2YgQ01TIHt7UkZDIDYyMTF9fS4gIFRoZSByaXNrIGFyaXNlcyB3aGVuIGFsbCBvZiB0 aGUgZm9sbG93aW5nIGFyZSB0cnVlOg0KDQoqIFZlcmlmaWVycyBvZiBhIHNpZ25hdHVyZSBzdXBw b3J0IG11bHRpcGxlIGFsZ29yaXRobXMgb2YgZGlmZmVyZW50IHN0cmVuZ3Rocw0KKiBHaXZlbiBh biBleGlzdGluZyBzaWduYXR1cmUsIGFuIGF0dGFja2VyIGNhbiBmaW5kIGFub3RoZXIgcGF5bG9h ZCB0aGF0IHByb2R1Y2VzIHRoZSBzYW1lIHNpZ25hdHVyZSB2YWx1ZSB3aXRoIGEgd2Vha2VyIGFs Z29yaXRobQ0KKiBJbiBwYXJ0aWN1bGFyLCB0aGUgcGF5bG9hZCBjcmFmdGVkIGJ5IHRoZSBhdHRh Y2tlciBpcyB2YWxpZCBpbiBhIGdpdmVuIGFwcGxpY2F0aW9uLWxheWVyIGNvbnRleHQNCkZvciBl eGFtcGxlLCBzdXBwb3NlIGEgdmVyaWZpZXIgaXMgd2lsbGluZyB0byBhY2NlcHQgYm90aCAiUFMx IiBhbmQgIlBTMjU2IiBhcyAiYWxnIiB2YWx1ZXMsIGFuZCBhIHNpZ25lciBjcmVhdGVzIGEgc2ln bmF0dXJlIHVzaW5nICJQUzI1NiIuICBJZiB0aGUgYXR0YWNrZXIgY2FuIGNyYWZ0IGEgcGF5bG9h ZCB0aGF0IGhhcyB0aGUgc2FtZSBTSEEtMSBkaWdlc3QgaGFzIGFzIHRoZSBTSEEtMjU2IGRpZ2Vz dCBvZiB0aGUgbGVnaXRpbWF0ZSBwYXlsb2FkLCB0aGVuIHRoZSAiUFMxIiBzaWduYXR1cmUgb3Zl ciB0aGUgYm9ndXMgcGF5bG9hZCB3aWxsIGJlIHRoZSBzYW1lIGFzIHRoZSAiUFMyNTYiIHNpZ25h dHVyZSBvdmVyIHRoZSBsZWdpdGltYXRlIHBheWxvYWQuDQoNClRoZXJlIGFyZSBzZXZlcmFsIHdh eXMgZm9yIGFuIGFwcGxpY2F0aW9uIHVzaW5nIEpPU0UgdG8gbWl0aWdhdGUgYWxnb3JpdGhtIHN1 YnN0aXR1dGlvbiBhdHRhY2tzOg0KKiBEb24ndCBhY2NlcHQgc2lnbmF0dXJlcyB1c2luZyB2dWxu ZXJhYmxlIGFsZ29yaXRobXM6IEFsZ29yaXRobSBzdWJzdGl0dXRpb24gYXR0YWNrcyBkbyBub3Qg YXJpc2UgZm9yIGFsbCBzaWduYXR1cmUgYWxnb3JpdGhtcy4NCiAgKiBTaWduYXR1cmVzIHVzaW5n IFJTQSBQS0NTIzEgdjEuNSAoIlJTMSIsICJSUzI1NiIsIGV0Yy4pIGFyZSBub3Qgc3ViamVjdCB0 byBzdWJzdGl0dXRpb24gYXR0YWNrcyBiZWNhdXNlIHRoZSBzaWduYXR1cmUgdmFsdWUgaXRzZWxm IGVuY29kZXMgdGhlIGhhc2ggZnVuY3Rpb24gdXNlZC4NCiAgKiBTaWduYXR1cmVzIHdpdGggSE1B QyBhbGdvcml0aG1zICgiSFMxIiwgIkhTMjU2IiwgZXRjLikgY2Fubm90IGJlIHN1YnN0aXR1dGVk IGJlY2F1c2UgdGhlIHNpZ25hdHVyZSB2YWx1ZXMgaGF2ZSBkaWZmZXJlbnQgbGVuZ3RocyAgTGlr ZXdpc2UgZm9yIHNpZ25hdHVyZXMgd2l0aCBFQ0RTQSBhbGdvcml0aG1zICgiRVMyNTYiLCAiRVMz ODQiLCBldGMuKS4NCg0KW0pMU10gVGhpcyBpcyBub3QgYSB0cnVlIHN0YXRlbWVudC4gIElmIHlv dSBzdXBwb3J0IGJvdGggU0hBMjU2IGFuZCBTSEE1MTIvMjU2IHRoZW4gdGhlIHNpZ25hdHVyZSB2 YWx1ZXMgaGF2ZSB0aGUgc2FtZSBsZW5ndGguICBUaGlzIHdpbGwgYWxzbyBiZSBhbiBpc3N1ZSBp ZiB5b3Ugc3VwcG9ydCBib3RoIHRoZSBTSEEyIGFuZCB0aGUgU0hBMyBhbGdvcml0aG0gc2V0cyBh cyB0aGV5IGhhdmUgcmVzdWx0cyBvZiB0aGUgc2FtZSBsZW5ndGguDQoNCiAgKiBUaGUgb25seSBh bGdvcml0aG1zIGRlZmluZWQgaW4gSldBIHt7SS1ELmlldGYtam9zZS1qc29uLXdlYi1hbGdvcml0 aG1zfX0gdGhhdCBpcyB2dWxuZXJhYmxlIHRvIGFsZ29yaXRobSBzdWJzdGl0dXRpb24gYXR0YWNr cyBpcyBSU0EtUFNTICgiUFMxIiwgIlBTMjU2IiwgZXRjLikuICBBbiBpbXBsZW1lbnRhdGlvbiB0 aGF0IGRvZXMgbm90IHN1cHBvcnQgUlNBLVBTUyBpcyBub3QgdnVsbmVyYWJsZSB0byBhbGdvcml0 aG0gc3Vic3RpdHV0aW9uIGF0dGFja3MuDQoNCltKTFNdIEVDRFNBIGlzIG9wZW4gdG8gdGhpcyBh dHRhY2sgaWYgeW91IHN1cHBvcnQgYm90aCBTSEEyNTYgYW5kIFNIQTUxMi8yNTYgdGhlIGhhc2gg bGVuZ3RocyBhcmUgdGhlIHNhbWUuICBUaGlzIHdpbGwgYWxzbyBiZSBhbiBpc3N1ZSBpZiB5b3Ug c3VwcG9ydCBib3RoIHRoZSBTSEEyIGFuZCB0aGUgU0hBMyBhbGdvcml0aG0gc2V0cyBhcyB0aGV5 IGhhdmUgcmVzdWx0cyBvZiB0aGUgc2FtZSBsZW5ndGguDQoNCiogUmVxdWlyZSB0aGF0IHRoZSAi YWxnIiBwYXJhbWV0ZXIgYmUgY2FycmllZCBpbiB0aGUgcHJvdGVjdGVkIGhlYWRlci4gIChUaGlz IGlzIHRoZSBhcHByb2FjaCB0YWtlbiBieSBSRkMgNjIxMS4pDQoqIEluY2x1ZGUgYSBmaWVsZCBy ZWZsZWN0aW5nIHRoZSBhbGdvcml0aG0gaW4gdGhlIGFwcGxpY2F0aW9uIHBheWxvYWQsIGFuZCBy ZXF1aXJlIHRoYXQgaXQgYmUgbWF0Y2hlZCB3aXRoIHRoZSAiYWxnIiBwYXJhbWV0ZXIgZHVyaW5n IHZlcmlmaWNhdGlvbiAoVGhpcyBpcyB0aGUgYXBwcm9hY2ggdGFrZW4gYnkgUEtJWCB7e1JGQzUy ODB9fS4pDQoNCltKTFNdIFJTQS1QS0NTIzEuNSBpcyBvcGVuIHRvIHRoaXMgYXR0YWNrIGlmIHRo ZSBzdWdnZXN0aW9uIG9mIE1pa2UgaW4gYSBtZXNzYWdlIHByaW9yIHRvIHRoaXMgaXMgcHV0IGlu dG8gdGhlIHRleHQuICBUaGF0IGlzIHRvIGFsbG93IGZvciB0aGUgaGFzaCBpbnNpZGUgb2YgdGhl IHNpZ25hdHVyZSBhbmQgdGhhdCBvdXRzaWRlIG9mIHRoZSBzaWduYXR1cmUgdG8gZGlmZmVyIGlu IHZhbHVlIGJlY2F1c2UgeW91IG9ubHkgZW5mb3JjZSBvbmUgb2YgdGhlIHR3byB2YWx1ZXMuDQoN Ck9mIHRoZXNlIG1pdGlnYXRpb25zLCB0aGUgb25seSBzdXJlIHNvbHV0aW9uIGlzIHRoZSBmaXJz dC4gIFNpZ25pbmcgb3ZlciB0aGUgImFsZyIgcGFyYW1ldGVyIChkaXJlY3RseSBvciBpbmRpcmVj dGx5KSBvbmx5IG1ha2VzIHRoZSBhdHRhY2tlcidzIHdvcmsgbW9yZSBkaWZmaWN1bHQsIGJ5IHJl cXVpcmluZyB0aGF0IHRoZSBib2d1cyBwYXlsb2FkIGFsc28gY29udGFpbiBib2d1cyBpbmZvcm1h dGlvbiBhYm91dCB0aGUgc2lnbmluZyBhbGdvcml0aG0uICBUaGV5IGRvIG5vdCBwcmV2ZW50IGF0 dGFjayBieSBhIHN1ZmZpY2llbnRseSBwb3dlcmZ1bCBhdHRhY2tlci4NCiIiIg0KDQpPbiBGcmks IFNlcCAxOSwgMjAxNCBhdCAyOjQ5IFBNLCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jv c29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KSSB3 b3VsZCBhcHByZWNpYXRlIGl0IGlmIHlvdSB3b3VsZCB3cml0ZSBhIGRyYWZ0IG9mIHRoZSBwcm9w b3NlZCBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyB0ZXh0LCBSaWNoYXJkLiAgUGVyaGFwcyB0aXRs ZSB0aGUgc2VjdGlvbiDigJxVbnNlY3VyZWQgQWxnb3JpdGhtIFZhbHVlc+KAnS4NCg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVGhh bmtzIQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBSaWNoYXJkIEJhcm5lcyBbbWFpbHRvOnJsYkBpcHYu c3g8bWFpbHRvOnJsYkBpcHYuc3g+XQ0KU2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMTcsIDIw MTQgNjoyNCBBTQ0KVG86IFRlcm8gS2l2aW5lbg0KQ2M6IE1pa2UgSm9uZXM7IGllc2dAaWV0Zi5v cmc8bWFpbHRvOmllc2dAaWV0Zi5vcmc+OyBzZWNkaXJAaWV0Zi5vcmc8bWFpbHRvOnNlY2RpckBp ZXRmLm9yZz47IGlldGZAaWV0Zi5vcmc8bWFpbHRvOmlldGZAaWV0Zi5vcmc+OyBkcmFmdC1pZXRm LWpvc2UtanNvbi13ZWItc2lnbmF0dXJlLmFsbEB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQt aWV0Zi1qb3NlLWpzb24td2ViLXNpZ25hdHVyZS5hbGxAdG9vbHMuaWV0Zi5vcmc+O2pvc2VAaWV0 Zi5vcmc8bWFpbHRvOmpvc2VAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogU2VjZGlyIHJldmlldyBv ZiBkcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItc2lnbmF0dXJlLTMxDQoNCg0KDQpPbiBXZWRuZXNk YXksIFNlcHRlbWJlciAxNywgMjAxNCwgVGVybyBLaXZpbmVuIDxraXZpbmVuQGlraS5maTxtYWls dG86a2l2aW5lbkBpa2kuZmk+PiB3cm90ZToNClJpY2hhcmQgQmFybmVzIHdyaXRlczoNCj4gICAg IFBlcmhhcHMsIGJ1dCBpcyB0aGVyZSBiZW5lZml0cyBmb3IgbGVhdmluZyB0aGUgYWxnIHdpdGhv dXQgcHJvdGVjdGlvbj8NCj4NCj4gU2ltcGxpY2l0eSAoaWYgeW91IG9taXQgcHJvdGVjdGVkIGhl YWRlcnMgYWx0b2dldGhlciksIGFuZA0KPiBjb21wYXRpYmlsaXR5IHdpdGggb3RoZXIgc2lnbmVk IHRoaW5ncy4gIEluIHRoZSBzZW5zZSB0aGF0IHlvdSBjb3VsZA0KPiB0cmFuc2Zvcm0gb25lIG9m IHRoZW0gaW50byBhIEpXUyB3aXRob3V0IHJlLXNpZ25pbmcuICBUaGlzIHdvdWxkDQo+IGFwcGx5 LCBmb3IgZXhhbXBsZSwgdG8gYW4gWC41MDkgY2VydGlmaWNhdGUgLS0ganVzdCBwYXJzZSB0aGUg b3V0ZXINCj4gU0VRVUVOQ0UsIGFuZCByZS1hc3NlbWJsZSBpbnRvIGEgSldTIHdpdGggdGhlIHRi c0NlcnRpZmljYXRlIGFzDQo+IHBheWxvYWQuICBTYW1lIHNlY3VyaXR5IHByb3BlcnRpZXMgdGhh dCBYLjUwOSBhbHJlYWR5IGhhcy4NCg0KT2ssIGhhdmluZyB0aGlzIGtpbmQgb2YgaW5mb3JtYXRp b24gc29tZXdoZXJlIGluIHRoZSBkcmFmdCB3b3VsZCBoZWxwDQp0byB1bmRlcnN0YW5kIHRoZSBy ZWFzb24uIEFsc28gaGF2aW5nIHRleHQgZXhwbGFpbmluZyB0aGF0IGlzDQpwb3NzaWJsZSwgYW5k IHRoYXQgdGhlIHNlY3VyaXR5IHByb3BlcnRpZXMgb2YgdGhpcyBvcHRpb24gKGkuZS4gbm8NCnBy b2JsZW0gd2l0aCBQS0NTIzEsIGV0Yy4uLiB0aGUgdGV4dCB5b3UgaGFkIGluIHRoZSBvdGhlciBl bWFpbCkuDQoNCj4gSXQncyBhbHNvIGNvbXBsZXRlbHkgdW5uZWNlc3NhcnkgZm9yIFBLQ1MjMSBz aWduYXR1cmVzLCB3aGljaCBhcmUNCj4gdGhlIGRvbWluYW50IHVzZSBjYXNlIHRvZGF5Lg0KDQpJ IGFncmVlLg0KDQo+IEluIGdlbmVyYWwsIEknbSBvcHBvc2VkIHRvIHByb3RvY29scyBiYWtpbmcg aW4gbW9yZQ0KPiBhcHBsaWNhdGlvbi1zcGVjaWZpYyBsb2dpYyB0aGFuIHRoZXkgbmVlZCB0by4g IFRoZSBwb2ludCBvZiBKT1NFIGlzDQo+IHRvIGRlc2NyaWJlIHRoZSBjcnlwdG9ncmFwaGljIG9w ZXJhdGlvbiB0aGF0IHdhcyBwZXJmb3JtZWQsIGFuZA0KPiBjYXJyeSB0aGUgcmVsZXZhbnQgYml0 cyBhcm91bmQuICBJdHMgam9iIGlzIG5vdCB0byBmaXggYWxsIHRoZQ0KPiB3ZWFrbmVzc2VzIHRo YXQgZXZlcnkgYWxnb3JpdGhtIGhhcy4NCg0KWWVzLCBidXQgdGhpcyBwcm9wZXJ0eSBtaWdodCBo YXZlIHNlY3VyaXR5IGlzc3Vlcywgc28gdGhleSBzaG91bGQgYmUNCmNvdmVyZWQgYnkgdGhlIHNl Y3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24uDQoNCkknbSBwZXJmZWN0bHkgaGFwcHkgdG8g aGF2ZSBpdCBkb2N1bWVudGVkIGluIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucy4NCg0KTWlr ZTogU2hvdWxkIEkgZ2VuZXJhdGUgc29tZSB0ZXh0LCBvciBkbyB5b3Ugd2FudCB0byB0YWtlIGEg c3RhYj8NCg0KLS0NCmtpdmluZW5AaWtpLmZpPG1haWx0bzpraXZpbmVuQGlraS5maT4NCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmpvc2UgbWFpbGlu ZyBsaXN0DQpqb3NlQGlldGYub3JnPG1haWx0bzpqb3NlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qb3NlDQoNCg== --_000_4E1F6AAD24975D4BA5B16804296739439BA5C5C0TK5EX14MBXC286r_ Content-Type: text/html; charset="utf-8" Content-ID: <58020EF631318545A3899EAC32A91CB0@microsoft.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSItbXMtd29y ZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGlu ZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZh bWlseTogQ2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6IDExcHQ7Ij5Zb3VyIGludGVycHJl dGF0aW9uIG1hdGNoZXMgbXkgaW50ZW50Ljxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGRpcj0i bHRyIj4NCjxocj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSxzYW5zLXNlcmlm OyBmb250LXNpemU6IDExcHQ7IGZvbnQtd2VpZ2h0OiBib2xkOyI+RnJvbToNCjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMXB0 OyI+PGEgaHJlZj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tIj5Kb2huIEJyYWRsZXk8L2E+PC9z cGFuPjxicj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSxzYW5zLXNlcmlmOyBm b250LXNpemU6IDExcHQ7IGZvbnQtd2VpZ2h0OiBib2xkOyI+U2VudDoNCjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMXB0OyI+ 4oCOOS/igI4xOS/igI4yMDE0IDc6MTcgUE08L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiBDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC13ZWlnaHQ6 IGJvbGQ7Ij5UbzoNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksc2Fu cy1zZXJpZjsgZm9udC1zaXplOiAxMXB0OyI+PGEgaHJlZj0ibWFpbHRvOmlldGZAYXVndXN0Y2Vs bGFycy5jb20iPkppbSBTY2hhYWQ8L2E+PC9zcGFuPjxicj4NCjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTogQ2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6IDExcHQ7IGZvbnQtd2VpZ2h0OiBi b2xkOyI+Q2M6DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogMTFwdDsiPjxhIGhyZWY9Im1haWx0bzpybGJAaXB2LnN4Ij5SaWNo YXJkIEJhcm5lczwvYT47DQo8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQu Y29tIj5NaWtlIEpvbmVzPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmlldGZAaWV0Zi5vcmciPg0KaWV0 ZkBpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpzZWNkaXJAaWV0Zi5vcmciPnNlY2RpckBp ZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpraXZpbmVuQGlraS5maSI+DQpUZXJvIEtpdmlu ZW48L2E+OyA8YSBocmVmPSJtYWlsdG86aWVzZ0BpZXRmLm9yZyI+SUVTRzwvYT47IDxhIGhyZWY9 Im1haWx0bzpqb3NlQGlldGYub3JnIj4NCmpvc2VAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWls dG86ZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLXNpZ25hdHVyZS5hbGxAdG9vbHMuaWV0Zi5vcmci Pg0KZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLXNpZ25hdHVyZS5hbGxAdG9vbHMuaWV0Zi5vcmc8 L2E+PC9zcGFuPjxicj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSxzYW5zLXNl cmlmOyBmb250LXNpemU6IDExcHQ7IGZvbnQtd2VpZ2h0OiBib2xkOyI+U3ViamVjdDoNCjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXpl OiAxMXB0OyI+UmU6IFtqb3NlXSBTZWNkaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtam9zZS1qc29u LXdlYi1zaWduYXR1cmUtMzE8L3NwYW4+PGJyPg0KPGJyPg0KPC9kaXY+DQpGb3IgSE1BQyBjaGFu Z2luZyB0aGUgJm5ic3A7aGFzaCBmcm9tIFNIQTMgMjU2IHRvIFNIQTIgMjU2IGRvZXNuJ3QgcmVh bGx5IGdldCB0aGUgYXR0YWNrZXIgbXVjaCBhcyB0aGV5IHN0aWxsIGRvbid0IGtub3cgdGhlIGtl eSB0byBiZSBhYmxlIHRvIGNyZWF0ZSBhIGFwcHJvcHJpYXRlIGZha2UgcGxhaW50ZXh0Lg0KPGRp dj5TbyBzaW1wbHkga25vd2luZyBhIHZhbHVlIHRoYXQgY3JlYXRlcyBhIGNvbGxpc2lvbiBpcyBu b3Qgc3VmZmljaWVudCBmb3IgYW4gYXR0YWNrLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk aXY+SSBpbnRlcnByZXRlZCBNaWtlJ3MgY29tbWVudCBvbiBQS0NTIzEgYXMgYmVpbmcgdGhhdCB0 aGUgc2lnbmF0dXJlIG5lZWRzIHRvIGJlIHZlcmlmaWVkIGJ5IHRoZSBhbGdvcml0aG0gc3BlY2lm aWVkIGluIHRoZSAmcXVvdDthbGcmcXVvdDsgcGFyYW1ldGVyLiAmbmJzcDtUaGF0IGlzIG5vdCB0 byBzYXkgdGhhdCBpZiBpbiB0aGUgY2FzZSBvZiBQS0NTIzEgcGFkZGluZyBpZiB0aGUgT0lEIGlz IG5vdCBjb25zaXN0ZW50IHdpdGggdGhlIHZhbHVlIG9mICZxdW90O2FsZyZxdW90OyB0aGF0DQog d291bGRuJ3QgYmUgYW4gZXJyb3IuICZuYnNwOyBJIHRoaW5rIHRoYXQgd291bGQgYmUgYSBpbnZh bGlkIEpXUy4gJm5ic3A7ICZuYnNwOyBJIGRvIHRoaW5rIHRoYXQgc2hvdWxkIGJlIG1hZGUgY2xl YXIuICZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+V2l0aCBQU1MgaWYgdGhl IGtleSBpcyB0aGUgc2FtZSBsZW5ndGggaXQgaXMgdHJ1ZSB0aGF0IHlvdSBhcmUgZ29pbmcgdG8g YmUgdnVsbmVyYWJsZSB0byBjb2xsaXNpb25zIG92ZXIgdGhlIHBsYWludGV4dCBiYXNlZCBvbiB0 aGUgd2Vha2VzdCBoYXNoIHlvdSBjYW4gZ2V0IHRoZSByZWNlaXZlciB0byBhY2NlcHQuICZuYnNw OzwvZGl2Pg0KPGRpdj5UaGlzIGlzIG5vdCBhIGlzc3VlIHVuaXF1ZSB0byBKT1NFIGluIGFueSB3 YXkuICZuYnNwOyBPbmUgd291bGQgYmUgdGVtcHRlZCB0byBydWxlIG91dCBTSEExIG5vdyBidXQg aXQgaXMgZGlmZmVyZW50aWF0ZWQgYnkgaXQncyBrZXkgbGVuZ3RoLCBzbyBjYW4ndCBiZSBkb3du Z3JhZGVkIHRvIGZyb20gU0hBMi48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkpvaG4g Qi48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pk9uIFNlcCAxOSwgMjAxNCwgYXQgNzoyNSBQTSwgSmltIFNjaGFhZCAmbHQ7PGEg aHJlZj0ibWFpbHRvOmlldGZAYXVndXN0Y2VsbGFycy5jb20iPmlldGZAYXVndXN0Y2VsbGFycy5j b208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3 bGluZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250OiAxMnB4L25vcm1hbCBIZWx2ZXRpY2E7IHRleHQtdHJhbnNmb3JtOiBub25lOyB0ZXh0 LWluZGVudDogMHB4OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgZm9udC1zaXplLWFkanVzdDogbm9uZTsgZm9udC1zdHJldGNo OiBub3JtYWw7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIiBzdHlsZT0icGFnZTogV29y ZFNlY3Rpb24xOyI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMHB0OyBmb250LWZhbWls eTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsgZm9udC1zaXplOiAxMnB0OyI+ DQo8c3BhbiBzdHlsZT0iY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDExcHQ7Ij4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMHB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsgZm9udC1zaXplOiAxMnB0OyI+DQo8c3BhbiBzdHlsZT0i Y29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyBmb250LXNpemU6IDExcHQ7Ij4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBpbiAwaW4gMHB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCBzZXJpZjsgZm9udC1zaXplOiAxMnB0OyI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 IFRhaG9tYSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMHB0OyI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEw cHQ7Ij48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Umlj aGFyZCBCYXJuZXMgWzxhIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVu ZGVybGluZTsiIGhyZWY9Im1haWx0bzpybGJAaXB2LnN4Ij5tYWlsdG86cmxiQGlwdi5zeDwvYT5d PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxi PlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj5GcmlkYXksIFNlcHRlbWJlciAxOSwgMjAxNCAyOjMyIFBNPGJyPg0KPGI+VG86PC9iPjxzcGFu IGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5NaWtlIEpvbmVzPGJy Pg0KPGI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj5UZXJvIEtpdmluZW47PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPjxhIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVy bGluZTsiIGhyZWY9Im1haWx0bzppZXNnQGlldGYub3JnIj5pZXNnQGlldGYub3JnPC9hPjs8c3Bh biBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgc3R5bGU9ImNv bG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgaHJlZj0ibWFpbHRvOnNl Y2RpckBpZXRmLm9yZyI+c2VjZGlyQGlldGYub3JnPC9hPjs8c3BhbiBjbGFzcz0iQXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQt ZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgaHJlZj0ibWFpbHRvOmlldGZAaWV0Zi5vcmciPmlldGZA aWV0Zi5vcmc8L2E+OzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48YSBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7 IiBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLXNpZ25hdHVyZS5hbGxAdG9v bHMuaWV0Zi5vcmciPmRyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1zaWduYXR1cmUuYWxsQHRvb2xz LmlldGYub3JnPC9hPjs8YSBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1 bmRlcmxpbmU7IiBocmVmPSJtYWlsdG86am9zZUBpZXRmLm9yZyI+am9zZUBpZXRmLm9yZzwvYT48 YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+UmU6IFNlY2RpciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1qb3NlLWpzb24td2Vi LXNpZ25hdHVyZS0zMTxvOnA+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwaW4gMGluIDBwdDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywg c2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsiPg0KPG86cD4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAxMnB0OyBmb250LWZhbWlseTog JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsgZm9udC1zaXplOiAxMnB0OyI+DQom cXVvdDsmcXVvdDsmcXVvdDs8YnI+DQojIFNpZ25hdHVyZSBBbGdvcml0aG0gUHJvdGVjdGlvbjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMHB0OyBm b250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsgZm9udC1zaXpl OiAxMnB0OyI+DQpJbiBzb21lIHVzYWdlcyBvZiBKV1MsIHRoZXJlIGlzIGEgcmlzayBvZiBhbGdv cml0aG0gc3Vic3RpdHV0aW9uIGF0dGFja3MsIGluIHdoaWNoIGFuIGF0dGFja2VyIGNhbiB1c2Ug YW4gZXhpc3Rpbmcgc2lnbmF0dXJlIHZhbHVlIHdpdGggYSBkaWZmZXJlbnQgc2lnbmF0dXJlIGFs Z29yaXRobSB0byBtYWtlIGl0IGFwcGVhciB0aGF0IGEgc2lnbmVyIGhhcyBzaWduZWQgc29tZXRo aW5nIHRoYXQgaGUgYWN0dWFsbHkgaGFzIG5vdC4mbmJzcDsgVGhlc2UgYXR0YWNrcw0KIGhhdmUg YmVlbiBkaXNjdXNzZWQgaW4gZGV0YWlsIGluIHRoZSBjb250ZXh0IG9mIENNUyB7e1JGQyA2MjEx fX0uJm5ic3A7IFRoZSByaXNrIGFyaXNlcyB3aGVuIGFsbCBvZiB0aGUgZm9sbG93aW5nIGFyZSB0 cnVlOjxvOnA+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBp biAwcHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssIHNlcmlmOyBm b250LXNpemU6IDEycHQ7Ij4NCjxicj4NCiogVmVyaWZpZXJzIG9mIGEgc2lnbmF0dXJlIHN1cHBv cnQgbXVsdGlwbGUgYWxnb3JpdGhtcyBvZiBkaWZmZXJlbnQgc3RyZW5ndGhzPG86cD48L286cD48 L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDBwdDsgZm9udC1mYW1p bHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsi Pg0KKiBHaXZlbiBhbiBleGlzdGluZyBzaWduYXR1cmUsIGFuIGF0dGFja2VyIGNhbiBmaW5kIGFu b3RoZXIgcGF5bG9hZCB0aGF0IHByb2R1Y2VzIHRoZSBzYW1lIHNpZ25hdHVyZSB2YWx1ZSB3aXRo IGEgd2Vha2VyIGFsZ29yaXRobTxvOnA+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMTJwdDsgZm9udC1mYW1pbHk6ICZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsiPg0KKiBJbiBw YXJ0aWN1bGFyLCB0aGUgcGF5bG9hZCBjcmFmdGVkIGJ5IHRoZSBhdHRhY2tlciBpcyB2YWxpZCBp biBhIGdpdmVuIGFwcGxpY2F0aW9uLWxheWVyIGNvbnRleHQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDBwdDsgZm9udC1mYW1pbHk6ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsiPg0KRm9yIGV4YW1w bGUsIHN1cHBvc2UgYSB2ZXJpZmllciBpcyB3aWxsaW5nIHRvIGFjY2VwdCBib3RoICZxdW90O1BT MSZxdW90OyBhbmQgJnF1b3Q7UFMyNTYmcXVvdDsgYXMgJnF1b3Q7YWxnJnF1b3Q7IHZhbHVlcywg YW5kIGEgc2lnbmVyIGNyZWF0ZXMgYSBzaWduYXR1cmUgdXNpbmcgJnF1b3Q7UFMyNTYmcXVvdDsu Jm5ic3A7IElmIHRoZSBhdHRhY2tlciBjYW4gY3JhZnQgYSBwYXlsb2FkIHRoYXQgaGFzIHRoZSBz YW1lIFNIQS0xIGRpZ2VzdCBoYXMgYXMgdGhlIFNIQS0yNTYgZGlnZXN0IG9mIHRoZSBsZWdpdGlt YXRlIHBheWxvYWQsDQogdGhlbiB0aGUgJnF1b3Q7UFMxJnF1b3Q7IHNpZ25hdHVyZSBvdmVyIHRo ZSBib2d1cyBwYXlsb2FkIHdpbGwgYmUgdGhlIHNhbWUgYXMgdGhlICZxdW90O1BTMjU2JnF1b3Q7 IHNpZ25hdHVyZSBvdmVyIHRoZSBsZWdpdGltYXRlIHBheWxvYWQuPG86cD48L286cD48L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwcHQ7IGZvbnQtZmFt aWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssIHNlcmlmOyBmb250LXNpemU6IDEycHQ7 Ij4NCjxvOnA+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMTJwdDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90Oywgc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsiPg0KVGhlcmUgYXJlIHNldmVy YWwgd2F5cyBmb3IgYW4gYXBwbGljYXRpb24gdXNpbmcgSk9TRSB0byBtaXRpZ2F0ZSBhbGdvcml0 aG0gc3Vic3RpdHV0aW9uIGF0dGFja3M6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMHB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsgZm9udC1zaXplOiAxMnB0OyI+DQoqIERvbid0IGFjY2Vw dCBzaWduYXR1cmVzIHVzaW5nIHZ1bG5lcmFibGUgYWxnb3JpdGhtczogQWxnb3JpdGhtIHN1YnN0 aXR1dGlvbiBhdHRhY2tzIGRvIG5vdCBhcmlzZSBmb3IgYWxsIHNpZ25hdHVyZSBhbGdvcml0aG1z LiZuYnNwOzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 YnI+DQombmJzcDsgKiBTaWduYXR1cmVzIHVzaW5nIFJTQSBQS0NTIzEgdjEuNSAoJnF1b3Q7UlMx JnF1b3Q7LCAmcXVvdDtSUzI1NiZxdW90OywgZXRjLikgYXJlIG5vdCBzdWJqZWN0IHRvIHN1YnN0 aXR1dGlvbiBhdHRhY2tzIGJlY2F1c2UgdGhlIHNpZ25hdHVyZSB2YWx1ZSBpdHNlbGYgZW5jb2Rl cyB0aGUgaGFzaCBmdW5jdGlvbiB1c2VkLiZuYnNwOzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQombmJzcDsgKiBTaWduYXR1cmVzIHdpdGggSE1B QyBhbGdvcml0aG1zICgmcXVvdDtIUzEmcXVvdDssICZxdW90O0hTMjU2JnF1b3Q7LCBldGMuKSBj YW5ub3QgYmUgc3Vic3RpdHV0ZWQgYmVjYXVzZSB0aGUgc2lnbmF0dXJlIHZhbHVlcyBoYXZlIGRp ZmZlcmVudCBsZW5ndGhzJm5ic3A7IExpa2V3aXNlIGZvciBzaWduYXR1cmVzIHdpdGggRUNEU0Eg YWxnb3JpdGhtcyAoJnF1b3Q7RVMyNTYmcXVvdDssICZxdW90O0VTMzg0JnF1b3Q7LCBldGMuKS48 bzpwPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDBwdDsgZm9udC1m YW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IGZvbnQtc2l6ZTogMTJw dDsiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMXB0OyI+Jm5ic3A7PC9zcGFuPjwvZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDBwdDsgZm9udC1mYW1pbHk6ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsiPg0KPHNwYW4gc3R5 bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsgZm9udC1zaXplOiAxMXB0OyI+W0pMU10gVGhpcyBpcyBub3QgYSB0cnVlIHN0YXRlbWVu dC4mbmJzcDsgSWYgeW91IHN1cHBvcnQgYm90aCBTSEEyNTYgYW5kIFNIQTUxMi8yNTYgdGhlbiB0 aGUgc2lnbmF0dXJlIHZhbHVlcyBoYXZlIHRoZSBzYW1lIGxlbmd0aC4mbmJzcDsgVGhpcyB3aWxs IGFsc28gYmUgYW4gaXNzdWUgaWYgeW91IHN1cHBvcnQNCiBib3RoIHRoZSBTSEEyIGFuZCB0aGUg U0hBMyBhbGdvcml0aG0gc2V0cyBhcyB0aGV5IGhhdmUgcmVzdWx0cyBvZiB0aGUgc2FtZSBsZW5n dGguPG86cD48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4g MHB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsgZm9u dC1zaXplOiAxMnB0OyI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDExcHQ7Ij4mbmJzcDs8 L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4g MHB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsgZm9u dC1zaXplOiAxMnB0OyI+DQombmJzcDsgKiBUaGUgb25seSBhbGdvcml0aG1zIGRlZmluZWQgaW4g SldBIHt7SS1ELmlldGYtam9zZS1qc29uLXdlYi1hbGdvcml0aG1zfX0gdGhhdCBpcyB2dWxuZXJh YmxlIHRvIGFsZ29yaXRobSBzdWJzdGl0dXRpb24gYXR0YWNrcyBpcyBSU0EtUFNTICgmcXVvdDtQ UzEmcXVvdDssICZxdW90O1BTMjU2JnF1b3Q7LCBldGMuKS4mbmJzcDsgQW4gaW1wbGVtZW50YXRp b24gdGhhdCBkb2VzIG5vdCBzdXBwb3J0IFJTQS1QU1MgaXMgbm90IHZ1bG5lcmFibGUgdG8gYWxn b3JpdGhtIHN1YnN0aXR1dGlvbg0KIGF0dGFja3MuPG86cD48L286cD48L2Rpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGluIDBpbiAwcHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssIHNlcmlmOyBmb250LXNpemU6IDEycHQ7Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjog cmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQt c2l6ZTogMTFwdDsiPiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGlu IDBpbiAwcHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssIHNlcmlm OyBmb250LXNpemU6IDEycHQ7Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1 KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTFwdDsiPltK TFNdIEVDRFNBIGlzIG9wZW4gdG8gdGhpcyBhdHRhY2sgaWYgeW91IHN1cHBvcnQgYm90aCBTSEEy NTYgYW5kIFNIQTUxMi8yNTYgdGhlIGhhc2ggbGVuZ3RocyBhcmUgdGhlIHNhbWUuJm5ic3A7IFRo aXMgd2lsbCBhbHNvIGJlIGFuIGlzc3VlIGlmIHlvdSBzdXBwb3J0IGJvdGggdGhlIFNIQTIgYW5k DQogdGhlIFNIQTMgYWxnb3JpdGhtIHNldHMgYXMgdGhleSBoYXZlIHJlc3VsdHMgb2YgdGhlIHNh bWUgbGVuZ3RoLjxvOnA+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwaW4gMGluIDBwdDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90Oywgc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsiPg0KPG86cD4mbmJzcDs8L286cD48 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46 IDBpbiAwaW4gMTJwdDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywg c2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsiPg0KKiBSZXF1aXJlIHRoYXQgdGhlICZxdW90O2FsZyZx dW90OyBwYXJhbWV0ZXIgYmUgY2FycmllZCBpbiB0aGUgcHJvdGVjdGVkIGhlYWRlci4mbmJzcDsg KFRoaXMgaXMgdGhlIGFwcHJvYWNoIHRha2VuIGJ5IFJGQyA2MjExLik8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwcHQ7IGZvbnQtZmFt aWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssIHNlcmlmOyBmb250LXNpemU6IDEycHQ7 Ij4NCiogSW5jbHVkZSBhIGZpZWxkIHJlZmxlY3RpbmcgdGhlIGFsZ29yaXRobSBpbiB0aGUgYXBw bGljYXRpb24gcGF5bG9hZCwgYW5kIHJlcXVpcmUgdGhhdCBpdCBiZSBtYXRjaGVkIHdpdGggdGhl ICZxdW90O2FsZyZxdW90OyBwYXJhbWV0ZXIgZHVyaW5nIHZlcmlmaWNhdGlvbiAoVGhpcyBpcyB0 aGUgYXBwcm9hY2ggdGFrZW4gYnkgUEtJWCB7e1JGQzUyODB9fS4pPG86cD48L286cD48L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwcHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssIHNlcmlmOyBmb250LXNpemU6IDEycHQ7Ij4NCjxzcGFuIHN0eWxl PSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IGZvbnQtc2l6ZTogMTFwdDsiPiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMGluIDBpbiAwcHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssIHNlcmlmOyBmb250LXNpemU6IDEycHQ7Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDMx LCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTog MTFwdDsiPltKTFNdIFJTQS1QS0NTIzEuNSBpcyBvcGVuIHRvIHRoaXMgYXR0YWNrIGlmIHRoZSBz dWdnZXN0aW9uIG9mIE1pa2UgaW4gYSBtZXNzYWdlIHByaW9yIHRvIHRoaXMgaXMgcHV0IGludG8g dGhlIHRleHQuJm5ic3A7IFRoYXQgaXMgdG8gYWxsb3cgZm9yIHRoZSBoYXNoIGluc2lkZSBvZiB0 aGUgc2lnbmF0dXJlDQogYW5kIHRoYXQgb3V0c2lkZSBvZiB0aGUgc2lnbmF0dXJlIHRvIGRpZmZl ciBpbiB2YWx1ZSBiZWNhdXNlIHlvdSBvbmx5IGVuZm9yY2Ugb25lIG9mIHRoZSB0d28gdmFsdWVz LjxvOnA+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwaW4gMGluIDBwdDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 Oywgc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsiPg0KPG86cD4mbmJzcDs8L286cD48L2Rpdj4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDBwdDsgZm9udC1mYW1pbHk6ICZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsiPg0KT2YgdGhl c2UgbWl0aWdhdGlvbnMsIHRoZSBvbmx5IHN1cmUgc29sdXRpb24gaXMgdGhlIGZpcnN0LiZuYnNw OyBTaWduaW5nIG92ZXIgdGhlICZxdW90O2FsZyZxdW90OyBwYXJhbWV0ZXIgKGRpcmVjdGx5IG9y IGluZGlyZWN0bHkpIG9ubHkgbWFrZXMgdGhlIGF0dGFja2VyJ3Mgd29yayBtb3JlIGRpZmZpY3Vs dCwgYnkgcmVxdWlyaW5nIHRoYXQgdGhlIGJvZ3VzIHBheWxvYWQgYWxzbyBjb250YWluIGJvZ3Vz IGluZm9ybWF0aW9uIGFib3V0IHRoZSBzaWduaW5nIGFsZ29yaXRobS4mbmJzcDsNCiBUaGV5IGRv IG5vdCBwcmV2ZW50IGF0dGFjayBieSBhIHN1ZmZpY2llbnRseSBwb3dlcmZ1bCBhdHRhY2tlci48 bzpwPjwvbzpwPjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwcHQ7 IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssIHNlcmlmOyBmb250LXNp emU6IDEycHQ7Ij4NCiZxdW90OyZxdW90OyZxdW90OzxvOnA+PC9vOnA+PC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwcHQ7IGZvbnQtZmFt aWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssIHNlcmlmOyBmb250LXNpemU6IDEycHQ7 Ij4NCjxvOnA+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw aW4gMGluIDBwdDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2Vy aWY7IGZvbnQtc2l6ZTogMTJwdDsiPg0KT24gRnJpLCBTZXAgMTksIDIwMTQgYXQgMjo0OSBQTSwg TWlrZSBKb25lcyAmbHQ7PGEgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjog dW5kZXJsaW5lOyIgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSIgdGFy Z2V0PSJfYmxhbmsiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDBwdDsg Zm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IGZvbnQtc2l6 ZTogMTJwdDsiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMXB0OyI+SSB3b3VsZCBhcHBy ZWNpYXRlIGl0IGlmIHlvdSB3b3VsZCB3cml0ZSBhIGRyYWZ0IG9mIHRoZSBwcm9wb3NlZCBzZWN1 cml0eSBjb25zaWRlcmF0aW9ucyB0ZXh0LCBSaWNoYXJkLiZuYnNwOyBQZXJoYXBzIHRpdGxlIHRo ZSBzZWN0aW9uIOKAnFVuc2VjdXJlZCBBbGdvcml0aG0gVmFsdWVz4oCdLjwvc3Bhbj48bzpwPjwv bzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDBwdDsgZm9udC1mYW1pbHk6 ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsiPg0K PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMXB0OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMHB0OyBmb250LWZhbWlseTogJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsgZm9udC1zaXplOiAxMnB0OyI+DQo8c3Bh biBzdHlsZT0iY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyBmb250LXNpemU6IDExcHQ7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhhbmtzITwvc3Bhbj48 bzpwPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDBwdDsgZm9udC1m YW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IGZvbnQtc2l6ZTogMTJw dDsiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMXB0OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1p a2U8L3NwYW4+PG86cD48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAw cHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssIHNlcmlmOyBmb250 LXNpemU6IDEycHQ7Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTFwdDsiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDBwdDsg Zm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IGZvbnQtc2l6 ZTogMTJwdDsiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2Vy aWY7IGZvbnQtc2l6ZTogMTBwdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6IFRhaG9tYSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMHB0OyI+PHNwYW4gY2xhc3M9 IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJpY2hhcmQgQmFybmVzIFttYWls dG86PGEgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIg aHJlZj0ibWFpbHRvOnJsYkBpcHYuc3giIHRhcmdldD0iX2JsYW5rIj5ybGJAaXB2LnN4PC9hPl08 c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPGI+ U2VudDo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PldlZG5lc2RheSwgU2VwdGVtYmVyIDE3LCAyMDE0IDY6MjQgQU08YnI+DQo8Yj5Ubzo8L2I+PHNw YW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlRlcm8gS2l2aW5l bjxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+TWlrZSBKb25lczs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PGEgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5k ZXJsaW5lOyIgaHJlZj0ibWFpbHRvOmllc2dAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pZXNn QGlldGYub3JnPC9hPjs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PGEgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5l OyIgaHJlZj0ibWFpbHRvOnNlY2RpckBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNlY2RpckBp ZXRmLm9yZzwvYT47PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjxhIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsi IGhyZWY9Im1haWx0bzppZXRmQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aWV0ZkBpZXRmLm9y ZzwvYT47PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxh IHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGhyZWY9 Im1haWx0bzpkcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItc2lnbmF0dXJlLmFsbEB0b29scy5pZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmRyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1zaWduYXR1cmUu YWxsQHRvb2xzLmlldGYub3JnPC9hPjs8YSBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNv cmF0aW9uOiB1bmRlcmxpbmU7IiBocmVmPSJtYWlsdG86am9zZUBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPmpvc2VAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9 IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBTZWNkaXIgcmV2aWV3IG9m IGRyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1zaWduYXR1cmUtMzE8L3NwYW4+PG86cD48L286cD48 L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMHB0OyBmb250LWZhbWls eTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsgZm9udC1zaXplOiAxMnB0OyI+ DQombmJzcDs8bzpwPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDBw dDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IGZvbnQt c2l6ZTogMTJwdDsiPg0KPGJyPg0KPGJyPg0KT24gV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMTcsIDIw MTQsIFRlcm8gS2l2aW5lbiAmbHQ7PGEgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3Jh dGlvbjogdW5kZXJsaW5lOyIgaHJlZj0ibWFpbHRvOmtpdmluZW5AaWtpLmZpIiB0YXJnZXQ9Il9i bGFuayI+a2l2aW5lbkBpa2kuZmk8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDBwdDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90Oywgc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsiPg0KUmljaGFyZCBCYXJuZXMg d3JpdGVzOjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO1BlcmhhcHMsIGJ1dCBpcyB0aGVy ZSBiZW5lZml0cyBmb3IgbGVhdmluZyB0aGUgYWxnIHdpdGhvdXQgcHJvdGVjdGlvbj88YnI+DQom Z3Q7PGJyPg0KJmd0OyBTaW1wbGljaXR5IChpZiB5b3Ugb21pdCBwcm90ZWN0ZWQgaGVhZGVycyBh bHRvZ2V0aGVyKSwgYW5kPGJyPg0KJmd0OyBjb21wYXRpYmlsaXR5IHdpdGggb3RoZXIgc2lnbmVk IHRoaW5ncy4mbmJzcDsgSW4gdGhlIHNlbnNlIHRoYXQgeW91IGNvdWxkPGJyPg0KJmd0OyB0cmFu c2Zvcm0gb25lIG9mIHRoZW0gaW50byBhIEpXUyB3aXRob3V0IHJlLXNpZ25pbmcuJm5ic3A7IFRo aXMgd291bGQ8YnI+DQomZ3Q7IGFwcGx5LCBmb3IgZXhhbXBsZSwgdG8gYW4gWC41MDkgY2VydGlm aWNhdGUgLS0ganVzdCBwYXJzZSB0aGUgb3V0ZXI8YnI+DQomZ3Q7IFNFUVVFTkNFLCBhbmQgcmUt YXNzZW1ibGUgaW50byBhIEpXUyB3aXRoIHRoZSB0YnNDZXJ0aWZpY2F0ZSBhczxicj4NCiZndDsg cGF5bG9hZC4mbmJzcDsgU2FtZSBzZWN1cml0eSBwcm9wZXJ0aWVzIHRoYXQgWC41MDkgYWxyZWFk eSBoYXMuPGJyPg0KPGJyPg0KT2ssIGhhdmluZyB0aGlzIGtpbmQgb2YgaW5mb3JtYXRpb24gc29t ZXdoZXJlIGluIHRoZSBkcmFmdCB3b3VsZCBoZWxwPGJyPg0KdG8gdW5kZXJzdGFuZCB0aGUgcmVh c29uLiBBbHNvIGhhdmluZyB0ZXh0IGV4cGxhaW5pbmcgdGhhdCBpczxicj4NCnBvc3NpYmxlLCBh bmQgdGhhdCB0aGUgc2VjdXJpdHkgcHJvcGVydGllcyBvZiB0aGlzIG9wdGlvbiAoaS5lLiBubzxi cj4NCnByb2JsZW0gd2l0aCBQS0NTIzEsIGV0Yy4uLiB0aGUgdGV4dCB5b3UgaGFkIGluIHRoZSBv dGhlciBlbWFpbCkuPGJyPg0KPGJyPg0KJmd0OyBJdCdzIGFsc28gY29tcGxldGVseSB1bm5lY2Vz c2FyeSBmb3IgUEtDUyMxIHNpZ25hdHVyZXMsIHdoaWNoIGFyZTxicj4NCiZndDsgdGhlIGRvbWlu YW50IHVzZSBjYXNlIHRvZGF5Ljxicj4NCjxicj4NCkkgYWdyZWUuPGJyPg0KPGJyPg0KJmd0OyBJ biBnZW5lcmFsLCBJJ20gb3Bwb3NlZCB0byBwcm90b2NvbHMgYmFraW5nIGluIG1vcmU8YnI+DQom Z3Q7IGFwcGxpY2F0aW9uLXNwZWNpZmljIGxvZ2ljIHRoYW4gdGhleSBuZWVkIHRvLiZuYnNwOyBU aGUgcG9pbnQgb2YgSk9TRSBpczxicj4NCiZndDsgdG8gZGVzY3JpYmUgdGhlIGNyeXB0b2dyYXBo aWMgb3BlcmF0aW9uIHRoYXQgd2FzIHBlcmZvcm1lZCwgYW5kPGJyPg0KJmd0OyBjYXJyeSB0aGUg cmVsZXZhbnQgYml0cyBhcm91bmQuJm5ic3A7IEl0cyBqb2IgaXMgbm90IHRvIGZpeCBhbGwgdGhl PGJyPg0KJmd0OyB3ZWFrbmVzc2VzIHRoYXQgZXZlcnkgYWxnb3JpdGhtIGhhcy4mbmJzcDs8YnI+ DQo8YnI+DQpZZXMsIGJ1dCB0aGlzIHByb3BlcnR5IG1pZ2h0IGhhdmUgc2VjdXJpdHkgaXNzdWVz LCBzbyB0aGV5IHNob3VsZCBiZTxicj4NCmNvdmVyZWQgYnkgdGhlIHNlY3VyaXR5IGNvbnNpZGVy YXRpb25zIHNlY3Rpb24uPG86cD48L286cD48L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBpbiAwaW4gMHB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCBzZXJpZjsgZm9udC1zaXplOiAxMnB0OyI+DQombmJzcDs8bzpwPjwvbzpwPjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDBwdDsgZm9udC1mYW1pbHk6 ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsiPg0K SSdtIHBlcmZlY3RseSBoYXBweSB0byBoYXZlIGl0IGRvY3VtZW50ZWQgaW4gdGhlIFNlY3VyaXR5 IENvbnNpZGVyYXRpb25zLiZuYnNwOzxvOnA+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMHB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsgZm9udC1zaXplOiAxMnB0OyI+DQombmJzcDs8bzpwPjwv bzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDBw dDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IGZvbnQt c2l6ZTogMTJwdDsiPg0KTWlrZTogU2hvdWxkIEkgZ2VuZXJhdGUgc29tZSB0ZXh0LCBvciBkbyB5 b3Ugd2FudCB0byB0YWtlIGEgc3RhYj88bzpwPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDBwdDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsiPg0KJm5ic3A7PG86cD48 L286cD48L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlci1zdHlsZTogbm9u ZSBub25lIG5vbmUgc29saWQ7IG1hcmdpbjogNXB0IDBpbiA1cHQgNC44cHQ7IHBhZGRpbmc6IDBp biAwaW4gMGluIDZwdDsgYm9yZGVyLWxlZnQtY29sb3I6IHJnYigyMDQsIDIwNCwgMjA0KTsgYm9y ZGVyLWxlZnQtd2lkdGg6IDFwdDsiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDBwdDsg Zm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IGZvbnQtc2l6 ZTogMTJwdDsiPg0KLS08YnI+DQo8YSBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0 aW9uOiB1bmRlcmxpbmU7IiBocmVmPSJtYWlsdG86a2l2aW5lbkBpa2kuZmkiPmtpdmluZW5AaWtp LmZpPC9hPjxvOnA+PC9vOnA+PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMHB0OyBmb250LWZhbWlseTogJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsgZm9udC1zaXplOiAxMnB0OyI+DQo8bzpw PiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kam9zZSBtYWlsaW5nIGxpc3Q8YnI+DQo8 YSBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBocmVm PSJtYWlsdG86am9zZUBpZXRmLm9yZyI+am9zZUBpZXRmLm9yZzwvYT48YnI+DQo8YSBzdHlsZT0i Y29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2pvc2UiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vam9zZTwvYT48YnI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4E1F6AAD24975D4BA5B16804296739439BA5C5C0TK5EX14MBXC286r_-- From nobody Fri Sep 19 20:37:23 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 217E91A008B; Fri, 19 Sep 2014 20:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 Tmd7XEEl5wL5; Fri, 19 Sep 2014 20:37:10 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3B181A0084; Fri, 19 Sep 2014 20:37:09 -0700 (PDT) Received: from Philemon (unknown [50.38.74.159]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id BD22B2CA0A; Fri, 19 Sep 2014 20:37:07 -0700 (PDT) From: "Jim Schaad" To: "'John Bradley'" References: <21512.21725.209461.976375@fireball.kivinen.iki.fi> <4E1F6AAD24975D4BA5B16804296739439AE9DD47@TK5EX14MBXC292.redmond.corp.microsoft.com> <21527.63989.999440.801542@fireball.kivinen.iki.fi> <21529.16232.880915.215045@fireball.kivinen.iki.fi> <4E1F6AAD24975D4BA5B16804296739439BA59EB7@TK5EX14MBXC286.redmond.corp.microsoft.com> <03a601cfd460$f8d71d70$ea855850$@augustcellars.com> In-Reply-To:

------=_NextPart_000_03C8_01CFD449.25766150-- From nobody Sat Sep 20 03:55:06 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7AB51A0255 for ; Sat, 20 Sep 2014 03:55:01 -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=unavailable 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 lfUqo-Q-ahsj for ; Sat, 20 Sep 2014 03:54:58 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A20621A0028 for ; Sat, 20 Sep 2014 03:54:57 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id z2so715059wiv.11 for ; Sat, 20 Sep 2014 03:54:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=UfM55ldNjqlOddvF7gOBJKdHTV88q2ZXZm6Wjubngtc=; b=JLqAV19T0jFFefKBLFxrXphR6hqS4EmqMznDraBvrk1KxG/G9fgQ8un2NVHXMRwbDf lwPumstT9+SJISnHZTJVlyYdxr4QLTMXnQJdXYyn5gtpzkn7C9a04IZk3BJAQhGEDKW6 x+5ry0zTL/2C/bxyODGEWkEjK7gqXvF88Gs5MsA97N0tMInWIYMO1Vdv85MSLJH8Zn1B pUQ05/hCmrB8bxfLyywbDFsNKiLseAHOdRhbMyf1bir0xnmqJWUuTEnU65QTbQU6aY2+ Gdwcu1FFtpHQqNf0pShJrEUlMu1o9c3ivLO2NzE4QTEK+0BG3lFPMES/tVE1d1FcrQe/ +V0Q== X-Gm-Message-State: ALoCoQmidFDp4CzXSjC+7UHMzaA0aMi3W0+wp9EmUZ+liJqKjcGntSsJaeEDe209gc4khGwAIGcs X-Received: by 10.180.231.3 with SMTP id tc3mr2682018wic.18.1411210496003; Sat, 20 Sep 2014 03:54:56 -0700 (PDT) Received: from [10.6.0.248] ([95.211.146.166]) by mx.google.com with ESMTPSA id mc20sm5005384wic.2.2014.09.20.03.54.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 20 Sep 2014 03:54:54 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_11C20C33-2D71-4367-A201-3526E5C0B94D"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 $1878.6$) From: John Bradley In-Reply-To: <03c701cfd483$d1cf45e0$756dd1a0$@augustcellars.com> Date: Sat, 20 Sep 2014 06:54:51 -0400 Message-Id: References: <21512.21725.209461.976375@fireball.kivinen.iki.fi> <4E1F6AAD24975D4BA5B16804296739439AE9DD47@TK5EX14MBXC292.redmond.corp.microsoft.com> <21527.63989.999440.801542@fireball.kivinen.iki.fi> <21529.16232.880915.215045@fireball.kivinen.iki.fi> <4E1F6AAD24975D4BA5B16804296739439BA59EB7@TK5EX14MBXC286.redmond.corp.microsoft.com> <03a601cfd460$f8d71d70$ea855850$@augustcellars.com> <03c701cfd483$d1cf45e0$756dd1a0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/AZKNkBFfybPqM8tZjimpK2Dbias Cc: ietf@ietf.org, secdir@ietf.org, Michael Jones , IESG , jose@ietf.org, draft-ietf-jose-json-web-signature.all@tools.ietf.org Subject: Re: [secdir] [jose] Secdir review of draft-ietf-jose-json-web-signature-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 10:55:02 -0000 --Apple-Mail=_11C20C33-2D71-4367-A201-3526E5C0B94D Content-Type: multipart/alternative; boundary="Apple-Mail=_1F4FEECB-FFDC-472B-A268-C9BF9ACB62AB" --Apple-Mail=_1F4FEECB-FFDC-472B-A268-C9BF9ACB62AB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Jim, I think I am missing something. If the sender is the attacker and has the mac key, then they can = integrity protect any plaintext they like with any hash that is = supported.. This seems more like the sender wants to use a different hash than the = receiver prefers situation. That seems to me like a different security concern than an attacker = taking a existing JWS and using a downgrade on the alg parameter to = substitute a less collision resistant hash, in order to substitute a = plain text (envelope and body in the Compact case) that has the same = hash value as that encrypted by the RSA/EC key. Thanks John B. On Sep 19, 2014, at 11:34 PM, Jim Schaad wrote: > =20 > =20 > From: jose [mailto:jose-bounces@ietf.org] On Behalf Of John Bradley > Sent: Friday, September 19, 2014 7:17 PM > To: Jim Schaad > Cc: ietf@ietf.org; secdir@ietf.org; Richard Barnes; Tero Kivinen; = Michael Jones; IESG; jose@ietf.org; = draft-ietf-jose-json-web-signature.all@tools.ietf.org > Subject: Re: [jose] Secdir review of = draft-ietf-jose-json-web-signature-31 > =20 > For HMAC changing the hash from SHA3 256 to SHA2 256 doesn't really = get the attacker much as they still don't know the key to be able to = create a appropriate fake plaintext. > So simply knowing a value that creates a collision is not sufficient = for an attack. > =20 > [JLS] remember that the attacker can be the sender of the message, in = this case the key is known to the attacker. > =20 > I interpreted Mike's comment on PKCS#1 as being that the signature = needs to be verified by the algorithm specified in the "alg" parameter. = That is not to say that if in the case of PKCS#1 padding if the OID is = not consistent with the value of "alg" that wouldn't be an error. I = think that would be a invalid JWS. I do think that should be made = clear. =20 > =20 > With PSS if the key is the same length it is true that you are going = to be vulnerable to collisions over the plaintext based on the weakest = hash you can get the receiver to accept. =20 > This is not a issue unique to JOSE in any way. One would be tempted = to rule out SHA1 now but it is differentiated by it's key length, so = can't be downgraded to from SHA2. > =20 > John B. > =20 > =20 > On Sep 19, 2014, at 7:25 PM, Jim Schaad = wrote: >=20 >=20 > =20 > =20 > From: Richard Barnes [mailto:rlb@ipv.sx]=20 > Sent: Friday, September 19, 2014 2:32 PM > To: Mike Jones > Cc: Tero Kivinen; iesg@ietf.org; secdir@ietf.org; ietf@ietf.org; = draft-ietf-jose-json-web-signature.all@tools.ietf.org;jose@ietf.org > Subject: Re: Secdir review of draft-ietf-jose-json-web-signature-31 > =20 > """ > # Signature Algorithm Protection >=20 > In some usages of JWS, there is a risk of algorithm substitution = attacks, in which an attacker can use an existing signature value with a = different signature algorithm to make it appear that a signer has signed = something that he actually has not. These attacks have been discussed = in detail in the context of CMS {{RFC 6211}}. The risk arises when all = of the following are true: >=20 > * Verifiers of a signature support multiple algorithms of different = strengths > * Given an existing signature, an attacker can find another payload = that produces the same signature value with a weaker algorithm > * In particular, the payload crafted by the attacker is valid in a = given application-layer context >=20 > For example, suppose a verifier is willing to accept both "PS1" and = "PS256" as "alg" values, and a signer creates a signature using "PS256". = If the attacker can craft a payload that has the same SHA-1 digest has = as the SHA-256 digest of the legitimate payload, then the "PS1" = signature over the bogus payload will be the same as the "PS256" = signature over the legitimate payload. > =20 > There are several ways for an application using JOSE to mitigate = algorithm substitution attacks: >=20 > * Don't accept signatures using vulnerable algorithms: Algorithm = substitution attacks do not arise for all signature algorithms. =20 > * Signatures using RSA PKCS#1 v1.5 ("RS1", "RS256", etc.) are not = subject to substitution attacks because the signature value itself = encodes the hash function used. =20 > * Signatures with HMAC algorithms ("HS1", "HS256", etc.) cannot be = substituted because the signature values have different lengths = Likewise for signatures with ECDSA algorithms ("ES256", "ES384", etc.). > =20 > [JLS] This is not a true statement. If you support both SHA256 and = SHA512/256 then the signature values have the same length. This will = also be an issue if you support both the SHA2 and the SHA3 algorithm = sets as they have results of the same length. > =20 > * The only algorithms defined in JWA = {{I-D.ietf-jose-json-web-algorithms}} that is vulnerable to algorithm = substitution attacks is RSA-PSS ("PS1", "PS256", etc.). An = implementation that does not support RSA-PSS is not vulnerable to = algorithm substitution attacks. > =20 > [JLS] ECDSA is open to this attack if you support both SHA256 and = SHA512/256 the hash lengths are the same. This will also be an issue if = you support both the SHA2 and the SHA3 algorithm sets as they have = results of the same length. > =20 > * Require that the "alg" parameter be carried in the protected header. = (This is the approach taken by RFC 6211.) >=20 > * Include a field reflecting the algorithm in the application payload, = and require that it be matched with the "alg" parameter during = verification (This is the approach taken by PKIX {{RFC5280}}.) > =20 > [JLS] RSA-PKCS#1.5 is open to this attack if the suggestion of Mike in = a message prior to this is put into the text. That is to allow for the = hash inside of the signature and that outside of the signature to differ = in value because you only enforce one of the two values. > =20 > Of these mitigations, the only sure solution is the first. Signing = over the "alg" parameter (directly or indirectly) only makes the = attacker's work more difficult, by requiring that the bogus payload also = contain bogus information about the signing algorithm. They do not = prevent attack by a sufficiently powerful attacker. > """ > =20 > On Fri, Sep 19, 2014 at 2:49 PM, Mike Jones = wrote: > I would appreciate it if you would write a draft of the proposed = security considerations text, Richard. Perhaps title the section = =93Unsecured Algorithm Values=94. > =20 > Thanks! > -- Mike > =20 > From: Richard Barnes [mailto:rlb@ipv.sx]=20 > Sent: Wednesday, September 17, 2014 6:24 AM > To: Tero Kivinen > Cc: Mike Jones; iesg@ietf.org; secdir@ietf.org; ietf@ietf.org; = draft-ietf-jose-json-web-signature.all@tools.ietf.org;jose@ietf.org > Subject: Re: Secdir review of draft-ietf-jose-json-web-signature-31 > =20 >=20 >=20 > On Wednesday, September 17, 2014, Tero Kivinen wrote: > Richard Barnes writes: > > Perhaps, but is there benefits for leaving the alg without = protection? > > > > Simplicity (if you omit protected headers altogether), and > > compatibility with other signed things. In the sense that you could > > transform one of them into a JWS without re-signing. This would > > apply, for example, to an X.509 certificate -- just parse the outer > > SEQUENCE, and re-assemble into a JWS with the tbsCertificate as > > payload. Same security properties that X.509 already has. >=20 > Ok, having this kind of information somewhere in the draft would help > to understand the reason. Also having text explaining that is > possible, and that the security properties of this option (i.e. no > problem with PKCS#1, etc... the text you had in the other email). >=20 > > It's also completely unnecessary for PKCS#1 signatures, which are > > the dominant use case today. >=20 > I agree. >=20 > > In general, I'm opposed to protocols baking in more > > application-specific logic than they need to. The point of JOSE is > > to describe the cryptographic operation that was performed, and > > carry the relevant bits around. Its job is not to fix all the > > weaknesses that every algorithm has.=20 >=20 > Yes, but this property might have security issues, so they should be > covered by the security considerations section. > =20 > I'm perfectly happy to have it documented in the Security = Considerations.=20 > =20 > Mike: Should I generate some text, or do you want to take a stab? > =20 > -- > kivinen@iki.fi > =20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > =20 --Apple-Mail=_1F4FEECB-FFDC-472B-A268-C9BF9ACB62AB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Jim,

I think I am missing = something.

If the sender is the attacker and = has the mac key, then they can integrity protect any plaintext they like = with any hash that is supported..

This seems = more like the sender wants to use a different hash than the receiver = prefers situation.

That seems to me like a = different security concern than an attacker taking a existing JWS and = using a downgrade on the alg parameter to substitute a less collision = resistant hash, in order to substitute a plain text (envelope and body = in the Compact case) that has the same hash value as that encrypted by = the RSA/EC key.

Thanks

John = B.

On Sep 19, 2014, at 11:34 PM, Jim = Schaad <ietf@augustcellars.com> = wrote:

From: jose [mailto:jose-bounces@ietf.org] On Behalf Of John = Bradley
Sent: Friday, September 19, 2014 = 7:17 PM
To: Jim = Schaad
Cc: ietf@ietf.org; secdir@ietf.org; Richard Barnes; Tero Kivinen; Michael = Jones; IESG; jose@ietf.org; draft-ietf-jose-json-web-signature.all@tools.ietf.org
<= b>Subject: Re: = [jose] Secdir review of = draft-ietf-jose-json-web-signature-31
<= div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: = 'Times New Roman', serif;">
For HMAC changing the hash from SHA3 256 to SHA2 256 = doesn't really get the attacker much as they still don't know the key to = be able to create a appropriate fake = plaintext.
So simply = knowing a value that creates a collision is not sufficient for an = attack.

[JLS] remember that the attacker can be the sender of = the message, in this case the key is known to the = attacker.

I = interpreted Mike's comment on PKCS#1 as being that the signature needs = to be verified by the algorithm specified in the "alg" parameter. = That is not to say that if in the case of PKCS#1 padding if the = OID is not consistent with the value of "alg" that wouldn't be an error. = I think that would be a invalid JWS. I do think = that should be made clear.

With PSS if the key is the same length it is true = that you are going to be vulnerable to collisions over the plaintext = based on the weakest hash you can get the receiver to accept. =
This = is not a issue unique to JOSE in any way. One would be tempted to = rule out SHA1 now but it is differentiated by it's key length, so can't = be downgraded to from SHA2.

John B.

On Sep 19, 2014, at 7:25 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

From: Richard Barnes [mailto:rlb@ipv.sx]
Sent: Friday, September 19, 2014 = 2:32 PM
To: Mike = Jones
Cc: Tero= Kivinen; iesg@ietf.org; secdir@ietf.org; ietf@ietf.org; draft-ietf-jose-json-web-signature.all@tools.ietf.org;= jose@ietf.org
Subject: Re: Secdir review of = draft-ietf-jose-json-web-signature-31

"""
# Signature = Algorithm Protection
In some usages of JWS, there is a risk of algorithm substitution = attacks, in which an attacker can use an existing signature value with a = different signature algorithm to make it appear that a signer has signed = something that he actually has not. These attacks have been = discussed in detail in the context of CMS {{RFC 6211}}. The risk = arises when all of the following are = true:

* = Verifiers of a signature support multiple algorithms of different = strengths
* = Given an existing signature, an attacker can find another payload that = produces the same signature value with a weaker = algorithm
* In particular, the payload crafted by the attacker is = valid in a given application-layer context
For example, suppose a verifier is willing to accept = both "PS1" and "PS256" as "alg" values, and a signer creates a signature = using "PS256". If the attacker can craft a payload that has the = same SHA-1 digest has as the SHA-256 digest of the legitimate payload, = then the "PS1" signature over the bogus payload will be the same as the = "PS256" signature over the legitimate = payload.

There are several ways for an application using JOSE to = mitigate algorithm substitution = attacks:
* = Don't accept signatures using vulnerable algorithms: Algorithm = substitution attacks do not arise for all signature = algorithms.
* Signatures = using RSA PKCS#1 v1.5 ("RS1", "RS256", etc.) are not subject to = substitution attacks because the signature value itself encodes the hash = function used.
* Signatures = with HMAC algorithms ("HS1", "HS256", etc.) cannot be substituted = because the signature values have different lengths Likewise for = signatures with ECDSA algorithms ("ES256", "ES384", = etc.).

[JLS] This is not a true = statement. If you support both SHA256 and SHA512/256 then the = signature values have the same length. This will also be an issue = if you support both the SHA2 and the SHA3 algorithm sets as they have = results of the same length.

* The only algorithms defined in JWA = {{I-D.ietf-jose-json-web-algorithms}} that is vulnerable to algorithm = substitution attacks is RSA-PSS ("PS1", "PS256", etc.). An = implementation that does not support RSA-PSS is not vulnerable to = algorithm substitution attacks.

[JLS] ECDSA is open to this attack = if you support both SHA256 and SHA512/256 the hash lengths are the = same. This will also be an issue if you support both the SHA2 and = the SHA3 algorithm sets as they have results of the same = length.

* Require that the "alg" parameter be carried in the = protected header. (This is the approach taken by RFC = 6211.)
* = Include a field reflecting the algorithm in the application payload, and = require that it be matched with the "alg" parameter during verification = (This is the approach taken by PKIX = {{RFC5280}}.)

[JLS] RSA-PKCS#1.5 is = open to this attack if the suggestion of Mike in a message prior to this = is put into the text. That is to allow for the hash inside of the = signature and that outside of the signature to differ in value because = you only enforce one of the two = values.

Of = these mitigations, the only sure solution is the first. Signing = over the "alg" parameter (directly or indirectly) only makes the = attacker's work more difficult, by requiring that the bogus payload also = contain bogus information about the signing algorithm. They do not = prevent attack by a sufficiently powerful = attacker.
"""

On Fri, Sep 19, 2014 at 2:49 PM, Mike Jones <Michael.Jones@microsoft.com> = wrote:
I would appreciate it if you would write a draft of = the proposed security considerations text, Richard. Perhaps title = the section =93Unsecured Algorithm = Values=94.

           &= nbsp;           &nb= sp;            = ;            &= nbsp;           = Thanks!
           &= nbsp;           &nb= sp;            = ;            &= nbsp;           -- = Mike

From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Wednesday, September 17, = 2014 6:24 AM
To: Tero = Kivinen
Cc: Mike Jones; iesg@ietf.org; secdir@ietf.org; ietf@ietf.org; draft-ietf-jose-json-web-signature.all@tools.ietf.org;= jose@ietf.org
Subject: Re: Secdir review of = draft-ietf-jose-json-web-signature-31

On Wednesday, September 17, 2014, Tero = Kivinen <kivinen@iki.fi> = wrote:
Richard Barnes writes:
> Perhaps, but = is there benefits for leaving the alg without = protection?
>
> Simplicity (if you omit protected headers = altogether), and
> compatibility with other signed things. = In the sense that you could
> transform one of them into a JWS = without re-signing. This would
> apply, for example, to an = X.509 certificate -- just parse the outer
> SEQUENCE, and = re-assemble into a JWS with the tbsCertificate as
> payload. = Same security properties that X.509 already has.

Ok, having this = kind of information somewhere in the draft would help
to understand = the reason. Also having text explaining that is
possible, and that = the security properties of this option (i.e. no
problem with PKCS#1, = etc... the text you had in the other email).

> It's also = completely unnecessary for PKCS#1 signatures, which are
> the = dominant use case today.

I agree.

> In general, I'm = opposed to protocols baking in more
> application-specific logic = than they need to. The point of JOSE is
> to describe the = cryptographic operation that was performed, and
> carry the = relevant bits around. Its job is not to fix all the
> = weaknesses that every algorithm has.

Yes, but this property = might have security issues, so they should be
covered by the security = considerations section.

I'm = perfectly happy to have it documented in the Security = Considerations.

Mike: = Should I generate some text, or do you want to take a = stab?

--
kivinen@iki.fi

_______________________________________________
jose = mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose<= /span>

= --Apple-Mail=_1F4FEECB-FFDC-472B-A268-C9BF9ACB62AB-- --Apple-Mail=_11C20C33-2D71-4367-A201-3526E5C0B94D Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNDA5MjAxMDU0NTFaMCMGCSqGSIb3DQEJBDEWBBQxUA6YsKo0MBMblz017H4N 4ynA4DCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQBdwuv5MY/GTgWK2LQCe3RKf6x4+zpLl3XYlrMzrKvCgen53SRksfYG tYkTPFva8sd6cEpbpuY73HvMi+gLiFV4W+xiZUQDDmnV9qOhPxHnWYElXePl4qAPsyvMuq5fSQ55 Rc/vrdJxC/mi4CjgmojDbqhQtWygLgNU0A5Gp2eU601wb3d8TH2CU1ABcVWKtjK4WKv64Q/C3wpb H0ImHZDOZK5MdkcEbz2cQ7agHtELaskrQd04n9HRvxWyMutAhPIpp/mdb5+HEcej5O7m16+BskQm dtYRAKp5YZmuXL4lW+7JupFSDaLKrtOSYgomfbn+mwORN5Eg5ugQneqGS+qqAAAAAAAA --Apple-Mail=_11C20C33-2D71-4367-A201-3526E5C0B94D-- From nobody Sat Sep 20 09:47:51 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA55B1A0190; Sat, 20 Sep 2014 09:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 feVbXDdgdJUe; Sat, 20 Sep 2014 09:47:36 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CA011A0188; Sat, 20 Sep 2014 09:47:36 -0700 (PDT) Received: from Philemon (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 38BB238EA5; Sat, 20 Sep 2014 09:47:33 -0700 (PDT) From: "Jim Schaad" To: "'John Bradley'" References: <21512.21725.209461.976375@fireball.kivinen.iki.fi> <4E1F6AAD24975D4BA5B16804296739439AE9DD47@TK5EX14MBXC292.redmond.corp.microsoft.com> <21527.63989.999440.801542@fireball.kivinen.iki.fi> <21529.16232.880915.215045@fireball.kivinen.iki.fi> <4E1F6AAD24975D4BA5B16804296739439BA59EB7@TK5EX14MBXC286.redmond.corp.microsoft.com> <03a601cfd460$f8d71d70$ea855850$@augustcellars.com> <03c701cfd483$d1cf45e0$756dd1a0$@augustcellars.com> In-Reply-To: Date: Sat, 20 Sep 2014 09:45:07 -0700 Message-ID: <043a01cfd4f2$3df75ff0$b9e61fd0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_043B_01CFD4B7.919F65C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHuOuT/hh4qDeGZm241cGqvJGlDHQGDSHSvAfo059oBmzmMjgKe6fc2AlAhJ5UBTPVdRAKLDxUuAlnvmcEBe7XC2gIGyytgAc7rQnwCY5XyuJsN+K0g Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/iahf34JafEM6ruDhcv0vbYAFGEc Cc: ietf@ietf.org, secdir@ietf.org, 'Michael Jones' , 'IESG' , jose@ietf.org, draft-ietf-jose-json-web-signature.all@tools.ietf.org Subject: Re: [secdir] [jose] Secdir review of draft-ietf-jose-json-web-signature-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 16:47:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_043B_01CFD4B7.919F65C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit No, the attack would run as follows: 1. I send you a message which is hashed 2. You send back a message which includes the signature in your hash 3. I take the other message with the bad signature to court and your signature on the hash confirming you received it. Jim From: John Bradley [mailto:ve7jtb@ve7jtb.com] Sent: Saturday, September 20, 2014 3:55 AM To: Jim Schaad Cc: ietf@ietf.org; secdir@ietf.org; Richard Barnes; Tero Kivinen; Michael Jones; IESG; jose@ietf.org; draft-ietf-jose-json-web-signature.all@tools.ietf.org Subject: Re: [jose] Secdir review of draft-ietf-jose-json-web-signature-31 Hi Jim, I think I am missing something. If the sender is the attacker and has the mac key, then they can integrity protect any plaintext they like with any hash that is supported.. This seems more like the sender wants to use a different hash than the receiver prefers situation. That seems to me like a different security concern than an attacker taking a existing JWS and using a downgrade on the alg parameter to substitute a less collision resistant hash, in order to substitute a plain text (envelope and body in the Compact case) that has the same hash value as that encrypted by the RSA/EC key. Thanks John B. On Sep 19, 2014, at 11:34 PM, Jim Schaad wrote: From: jose [ mailto:jose-bounces@ietf.org] On Behalf Of John Bradley Sent: Friday, September 19, 2014 7:17 PM To: Jim Schaad Cc: ietf@ietf.org; secdir@ietf.org; Richard Barnes; Tero Kivinen; Michael Jones; IESG; jose@ietf.org; draft-ietf-jose-json-web-signature.all@tools.ietf.org Subject: Re: [jose] Secdir review of draft-ietf-jose-json-web-signature-31 For HMAC changing the hash from SHA3 256 to SHA2 256 doesn't really get the attacker much as they still don't know the key to be able to create a appropriate fake plaintext. So simply knowing a value that creates a collision is not sufficient for an attack. [JLS] remember that the attacker can be the sender of the message, in this case the key is known to the attacker. I interpreted Mike's comment on PKCS#1 as being that the signature needs to be verified by the algorithm specified in the "alg" parameter. That is not to say that if in the case of PKCS#1 padding if the OID is not consistent with the value of "alg" that wouldn't be an error. I think that would be a invalid JWS. I do think that should be made clear. With PSS if the key is the same length it is true that you are going to be vulnerable to collisions over the plaintext based on the weakest hash you can get the receiver to accept. This is not a issue unique to JOSE in any way. One would be tempted to rule out SHA1 now but it is differentiated by it's key length, so can't be downgraded to from SHA2. John B. On Sep 19, 2014, at 7:25 PM, Jim Schaad < ietf@augustcellars.com> wrote: From: Richard Barnes [ mailto:rlb@ipv.sx] Sent: Friday, September 19, 2014 2:32 PM To: Mike Jones Cc: Tero Kivinen; iesg@ietf.org; secdir@ietf.org; ietf@ietf.org; draft-ietf-jose-json-web-signature.all@tools.ietf.org; jose@ietf.org Subject: Re: Secdir review of draft-ietf-jose-json-web-signature-31 """ # Signature Algorithm Protection In some usages of JWS, there is a risk of algorithm substitution attacks, in which an attacker can use an existing signature value with a different signature algorithm to make it appear that a signer has signed something that he actually has not. These attacks have been discussed in detail in the context of CMS {{RFC 6211}}. The risk arises when all of the following are true: * Verifiers of a signature support multiple algorithms of different strengths * Given an existing signature, an attacker can find another payload that produces the same signature value with a weaker algorithm * In particular, the payload crafted by the attacker is valid in a given application-layer context For example, suppose a verifier is willing to accept both "PS1" and "PS256" as "alg" values, and a signer creates a signature using "PS256". If the attacker can craft a payload that has the same SHA-1 digest has as the SHA-256 digest of the legitimate payload, then the "PS1" signature over the bogus payload will be the same as the "PS256" signature over the legitimate payload. There are several ways for an application using JOSE to mitigate algorithm substitution attacks: * Don't accept signatures using vulnerable algorithms: Algorithm substitution attacks do not arise for all signature algorithms. * Signatures using RSA PKCS#1 v1.5 ("RS1", "RS256", etc.) are not subject to substitution attacks because the signature value itself encodes the hash function used. * Signatures with HMAC algorithms ("HS1", "HS256", etc.) cannot be substituted because the signature values have different lengths Likewise for signatures with ECDSA algorithms ("ES256", "ES384", etc.). [JLS] This is not a true statement. If you support both SHA256 and SHA512/256 then the signature values have the same length. This will also be an issue if you support both the SHA2 and the SHA3 algorithm sets as they have results of the same length. * The only algorithms defined in JWA {{I-D.ietf-jose-json-web-algorithms}} that is vulnerable to algorithm substitution attacks is RSA-PSS ("PS1", "PS256", etc.). An implementation that does not support RSA-PSS is not vulnerable to algorithm substitution attacks. [JLS] ECDSA is open to this attack if you support both SHA256 and SHA512/256 the hash lengths are the same. This will also be an issue if you support both the SHA2 and the SHA3 algorithm sets as they have results of the same length. * Require that the "alg" parameter be carried in the protected header. (This is the approach taken by RFC 6211.) * Include a field reflecting the algorithm in the application payload, and require that it be matched with the "alg" parameter during verification (This is the approach taken by PKIX {{RFC5280}}.) [JLS] RSA-PKCS#1.5 is open to this attack if the suggestion of Mike in a message prior to this is put into the text. That is to allow for the hash inside of the signature and that outside of the signature to differ in value because you only enforce one of the two values. Of these mitigations, the only sure solution is the first. Signing over the "alg" parameter (directly or indirectly) only makes the attacker's work more difficult, by requiring that the bogus payload also contain bogus information about the signing algorithm. They do not prevent attack by a sufficiently powerful attacker. """ On Fri, Sep 19, 2014 at 2:49 PM, Mike Jones < Michael.Jones@microsoft.com> wrote: I would appreciate it if you would write a draft of the proposed security considerations text, Richard. Perhaps title the section "Unsecured Algorithm Values". Thanks! -- Mike From: Richard Barnes [mailto: rlb@ipv.sx] Sent: Wednesday, September 17, 2014 6:24 AM To: Tero Kivinen Cc: Mike Jones; iesg@ietf.org; secdir@ietf.org; ietf@ietf.org; draft-ietf-jose-json-web-signature.all@tools.ietf.org; jose@ietf.org Subject: Re: Secdir review of draft-ietf-jose-json-web-signature-31 On Wednesday, September 17, 2014, Tero Kivinen < kivinen@iki.fi> wrote: Richard Barnes writes: > Perhaps, but is there benefits for leaving the alg without protection? > > Simplicity (if you omit protected headers altogether), and > compatibility with other signed things. In the sense that you could > transform one of them into a JWS without re-signing. This would > apply, for example, to an X.509 certificate -- just parse the outer > SEQUENCE, and re-assemble into a JWS with the tbsCertificate as > payload. Same security properties that X.509 already has. Ok, having this kind of information somewhere in the draft would help to understand the reason. Also having text explaining that is possible, and that the security properties of this option (i.e. no problem with PKCS#1, etc... the text you had in the other email). > It's also completely unnecessary for PKCS#1 signatures, which are > the dominant use case today. I agree. > In general, I'm opposed to protocols baking in more > application-specific logic than they need to. The point of JOSE is > to describe the cryptographic operation that was performed, and > carry the relevant bits around. Its job is not to fix all the > weaknesses that every algorithm has. Yes, but this property might have security issues, so they should be covered by the security considerations section. I'm perfectly happy to have it documented in the Security Considerations. Mike: Should I generate some text, or do you want to take a stab? -- kivinen@iki.fi _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose ------=_NextPart_000_043B_01CFD4B7.919F65C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

No, the attack would run as follows:

1. = I send you a message which is hashed

2. = You send back a message which includes the signature in your = hash

3. = I take the other message with the bad signature to court and your = signature on the hash confirming you received = it.

Jim

From:= = John Bradley [mailto:ve7jtb@ve7jtb.com]
Sent: Saturday, = September 20, 2014 3:55 AM
To: Jim Schaad
Cc: = ietf@ietf.org; secdir@ietf.org; Richard Barnes; Tero Kivinen; Michael = Jones; IESG; jose@ietf.org; = draft-ietf-jose-json-web-signature.all@tools.ietf.org
Subject: = Re: [jose] Secdir review of = draft-ietf-jose-json-web-signature-31

Hi = Jim,

I = think I am missing something.

If the sender is the attacker and has the mac key, = then they can integrity protect any plaintext they like with any hash = that is supported..

This seems more like the sender wants to use a = different hash than the receiver prefers = situation.

That seems to me like a different security concern = than an attacker taking a existing JWS and using a downgrade on the alg = parameter to substitute a less collision resistant hash, in order to = substitute a plain text (envelope and body in the Compact case) that has = the same hash value as that encrypted by the RSA/EC = key.

Thanks

John B.

On Sep 19, 2014, at 11:34 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

From:= jose [mailto:jose-bounces@ietf.org] On Behalf Of John = Bradley
Sent: Friday, September 19, 2014 = 7:17 PM
To: Jim Schaad
Cc: ietf@ietf.org; secdir@ietf.org; Richard Barnes; Tero = Kivinen; Michael Jones; IESG; jose@ietf.org; draft-ietf-jose-json-web-signature.all@tools.ietf.= org
Subject: Re: [jose] Secdir review of = draft-ietf-jose-json-web-signature-31

For HMAC changing the hash from SHA3 256 to SHA2 = 256 doesn't really get the attacker much as they still don't know the = key to be able to create a appropriate fake = plaintext.

So simply = knowing a value that creates a collision is not sufficient for an = attack.

[JLS] remember that the attacker can be the sender of the message, in = this case the key is known to the = attacker.

I interpreted Mike's comment on PKCS#1 as being that = the signature needs to be verified by the algorithm specified in the = "alg" parameter. That is not to say that if in the case = of PKCS#1 padding if the OID is not consistent with the value of = "alg" that wouldn't be an error. I think that would be = a invalid JWS. I do think that should be made clear. =

With PSS if the key is the same length it is true that = you are going to be vulnerable to collisions over the plaintext based on = the weakest hash you can get the receiver to accept. =

This is = not a issue unique to JOSE in any way. One would be tempted to = rule out SHA1 now but it is differentiated by it's key length, so can't = be downgraded to from SHA2.

John B.

On Sep 19, 2014, at 7:25 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

From:= Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Friday, September 19, 2014 = 2:32 PM
To: Mike Jones
Cc: Tero Kivinen; iesg@ietf.org; secdir@ietf.org; ietf@ietf.org; draft-ietf-jose-json-web-signature.all@tools.ietf.= org;jose@ietf.org
Subject: Re: Secdir review of = draft-ietf-jose-json-web-signature-31

"""
# Signature = Algorithm Protection

In some usages of JWS, there is a risk of algorithm = substitution attacks, in which an attacker can use an existing signature = value with a different signature algorithm to make it appear that a = signer has signed something that he actually has not. These = attacks have been discussed in detail in the context of CMS {{RFC = 6211}}. The risk arises when all of the following are = true:

* Verifiers of a signature support multiple = algorithms of different = strengths

* Given an existing signature, an attacker can find = another payload that produces the same signature value with a weaker = algorithm

* In particular, the payload crafted by = the attacker is valid in a given application-layer = context

For example, = suppose a verifier is willing to accept both "PS1" and = "PS256" as "alg" values, and a signer creates a = signature using "PS256". If the attacker can craft a = payload that has the same SHA-1 digest has as the SHA-256 digest of the = legitimate payload, then the "PS1" signature over the bogus = payload will be the same as the "PS256" signature over the = legitimate payload.

There are several ways for an application = using JOSE to mitigate algorithm substitution = attacks:

* Don't = accept signatures using vulnerable algorithms: Algorithm substitution = attacks do not arise for all signature algorithms.
* Signatures using = RSA PKCS#1 v1.5 ("RS1", "RS256", etc.) are not = subject to substitution attacks because the signature value itself = encodes the hash function used.
* Signatures with = HMAC algorithms ("HS1", "HS256", etc.) cannot be = substituted because the signature values have different lengths = Likewise for signatures with ECDSA algorithms ("ES256", = "ES384", etc.).

[JLS] This is not a true statement. If you support both SHA256 = and SHA512/256 then the signature values have the same length. = This will also be an issue if you support both the SHA2 and the SHA3 = algorithm sets as they have results of the same = length.

* The only algorithms defined in JWA = {{I-D.ietf-jose-json-web-algorithms}} that is vulnerable to algorithm = substitution attacks is RSA-PSS ("PS1", "PS256", = etc.). An implementation that does not support RSA-PSS is not = vulnerable to algorithm substitution = attacks.

[JLS] ECDSA is open to this attack if you support both SHA256 and = SHA512/256 the hash lengths are the same. This will also be an = issue if you support both the SHA2 and the SHA3 algorithm sets as they = have results of the same = length.

* Require that the = "alg" parameter be carried in the protected header. = (This is the approach taken by RFC = 6211.)

* Include = a field reflecting the algorithm in the application payload, and require = that it be matched with the "alg" parameter during = verification (This is the approach taken by PKIX = {{RFC5280}}.)

[JLS] RSA-PKCS#1.5 is open to this attack if the suggestion of Mike = in a message prior to this is put into the text. That is to allow = for the hash inside of the signature and that outside of the signature = to differ in value because you only enforce one of the two = values.

Of these mitigations, the only sure solution is the = first. Signing over the "alg" parameter (directly or = indirectly) only makes the attacker's work more difficult, by requiring = that the bogus payload also contain bogus information about the signing = algorithm. They do not prevent attack by a sufficiently powerful = attacker.

"""

On Fri, Sep 19, 2014 at 2:49 PM, Mike Jones <Michael.Jones@microsoft.com> = wrote:

I would appreciate it if you would write a draft of the proposed = security considerations text, Richard. Perhaps title the section = “Unsecured Algorithm = Values”.

&nbs= p; = ; = &= nbsp; = Thanks!

&nbs= p; = ; = &= nbsp; -- = Mike

From:= Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Wednesday, September 17, 2014 = 6:24 AM
To: Tero = Kivinen
Cc: Mike Jones; iesg@ietf.org; secdir@ietf.org; ietf@ietf.org; draft-ietf-jose-json-web-signature.all@tools.ietf.= org;jose@ietf.org
Subject: Re: Secdir review of = draft-ietf-jose-json-web-signature-31

On Wednesday, September 17, 2014, Tero Kivinen = <kivinen@iki.fi> = wrote:

I'm perfectly happy to have it documented in the = Security Considerations.

Mike: Should I generate some text, or do you want to = take a stab?

--
kivinen@iki.fi

__________= _____________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose<= /a>

------=_NextPart_000_043B_01CFD4B7.919F65C0-- From nobody Sat Sep 20 10:07:55 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7349D1A0109 for ; Sat, 20 Sep 2014 10:07:53 -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 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 QSiiDgETFhf1 for ; Sat, 20 Sep 2014 10:07:49 -0700 (PDT) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 656011A0142 for ; Sat, 20 Sep 2014 10:07:48 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id d1so978783wiv.0 for ; Sat, 20 Sep 2014 10:07:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=unsyFIwFN3EBlG60wpICp7mE4vG2irhSTiiX7H7FjCk=; b=dkbmZ6OvMfSiMD2smh/Vv7iRLSLESY4wJQt74lqM4N1Ikr1EqgrR95hmDH7B6IJGP+ aNeuOHWcmWuKUGXkU50ckzhUvQwj2+Ifhy020utDoJ+H7NJVMNrEdjCI2UEyba4aX+3K 4Rp8l+l+SWx7qtO3nxlf97SOawqD0xrpY8pLopP6Cg0ZUkyuwFglNesW62bIjETyUbs5 ZwuudJ1xpUyhS2QJJ536dA1zeQ0pzN/UnBSR01qg0ZoTQ/rFUj5tiDoXhVtmOS0L0rLo 85iGDRHS+842AkeapFuDp5/rS4FVeFQyk3ZBUovgSU/f5aWkslgn3XHpTAZcJ2I0ULWV vgsQ== X-Gm-Message-State: ALoCoQlK/embRbIF03GADfosw/Ei4pRJgKZb6DKp4++W4F5rgtcmcuq/fdFqjynRViQOwppVySnf X-Received: by 10.180.102.68 with SMTP id fm4mr4209214wib.27.1411232866819; Sat, 20 Sep 2014 10:07:46 -0700 (PDT) Received: from [10.6.0.195] ([95.211.146.166]) by mx.google.com with ESMTPSA id s4sm2944999wjs.30.2014.09.20.10.07.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 20 Sep 2014 10:07:45 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_A7770E28-3D05-495F-AE2A-BF5E3FC047A4"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 $1878.6$) From: John Bradley In-Reply-To: <043a01cfd4f2$3df75ff0$b9e61fd0$@augustcellars.com> Date: Sat, 20 Sep 2014 13:07:37 -0400 Message-Id: <457A8BF9-8CDF-43C8-8040-CB42BE110805@ve7jtb.com> References: <21512.21725.209461.976375@fireball.kivinen.iki.fi> <4E1F6AAD24975D4BA5B16804296739439AE9DD47@TK5EX14MBXC292.redmond.corp.microsoft.com> <21527.63989.999440.801542@fireball.kivinen.iki.fi> <21529.16232.880915.215045@fireball.kivinen.iki.fi> <4E1F6AAD24975D4BA5B16804296739439BA59EB7@TK5EX14MBXC286.redmond.corp.microsoft.com> <03a601cfd460$f8d71d70$ea855850$@augustcellars.com> <03c701cfd483$d1cf45e0$756dd1a0$@augustcellars.com> <043a01cfd4f2$3df75ff0$b9e61fd0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Bv_Xh9OCXYAnXZkJ6TT7Bp0bmL8 Cc: ietf@ietf.org, secdir@ietf.org, Michael Jones , IESG , jose@ietf.org, draft-ietf-jose-json-web-signature.all@tools.ietf.org Subject: Re: [secdir] [jose] Secdir review of draft-ietf-jose-json-web-signature-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 17:07:53 -0000 --Apple-Mail=_A7770E28-3D05-495F-AE2A-BF5E3FC047A4 Content-Type: multipart/alternative; boundary="Apple-Mail=_1463590C-30CE-458D-B3EE-8801B05EC708" --Apple-Mail=_1463590C-30CE-458D-B3EE-8801B05EC708 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 OK but HMAC is not a signature so that won't get you very far. If I am the attacker and have a collision based on the weaker hash and = you accept that why would I bother with changing the Hash alg? I still see changing the hash alg as part of a digital digital signature = as different from doing the same thing with the hash alg of a HMAC = integrity protected message. John B. On Sep 20, 2014, at 12:45 PM, Jim Schaad wrote: > No, the attack would run as follows: > =20 > 1. I send you a message which is hashed > 2. You send back a message which includes the signature in your = hash > 3. I take the other message with the bad signature to court and = your signature on the hash confirming you received it. > =20 > Jim > =20 > =20 > From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20 > Sent: Saturday, September 20, 2014 3:55 AM > To: Jim Schaad > Cc: ietf@ietf.org; secdir@ietf.org; Richard Barnes; Tero Kivinen; = Michael Jones; IESG; jose@ietf.org; = draft-ietf-jose-json-web-signature.all@tools.ietf.org > Subject: Re: [jose] Secdir review of = draft-ietf-jose-json-web-signature-31 > =20 > Hi Jim, > =20 > I think I am missing something. > =20 > If the sender is the attacker and has the mac key, then they can = integrity protect any plaintext they like with any hash that is = supported.. > =20 > This seems more like the sender wants to use a different hash than the = receiver prefers situation. > =20 > That seems to me like a different security concern than an attacker = taking a existing JWS and using a downgrade on the alg parameter to = substitute a less collision resistant hash, in order to substitute a = plain text (envelope and body in the Compact case) that has the same = hash value as that encrypted by the RSA/EC key. > =20 > Thanks > John B. > =20 > On Sep 19, 2014, at 11:34 PM, Jim Schaad = wrote: >=20 >=20 > =20 > =20 > From: jose [mailto:jose-bounces@ietf.org] On Behalf Of John Bradley > Sent: Friday, September 19, 2014 7:17 PM > To: Jim Schaad > Cc: ietf@ietf.org; secdir@ietf.org; Richard Barnes; Tero Kivinen; = Michael Jones; IESG; jose@ietf.org; = draft-ietf-jose-json-web-signature.all@tools.ietf.org > Subject: Re: [jose] Secdir review of = draft-ietf-jose-json-web-signature-31 > =20 > For HMAC changing the hash from SHA3 256 to SHA2 256 doesn't really = get the attacker much as they still don't know the key to be able to = create a appropriate fake plaintext. > So simply knowing a value that creates a collision is not sufficient = for an attack. > =20 > [JLS] remember that the attacker can be the sender of the message, in = this case the key is known to the attacker. > =20 > I interpreted Mike's comment on PKCS#1 as being that the signature = needs to be verified by the algorithm specified in the "alg" parameter. = That is not to say that if in the case of PKCS#1 padding if the OID is = not consistent with the value of "alg" that wouldn't be an error. I = think that would be a invalid JWS. I do think that should be made = clear. =20 > =20 > With PSS if the key is the same length it is true that you are going = to be vulnerable to collisions over the plaintext based on the weakest = hash you can get the receiver to accept. =20 > This is not a issue unique to JOSE in any way. One would be tempted = to rule out SHA1 now but it is differentiated by it's key length, so = can't be downgraded to from SHA2. > =20 > John B. > =20 > =20 > On Sep 19, 2014, at 7:25 PM, Jim Schaad = wrote: >=20 >=20 >=20 > =20 > =20 > From: Richard Barnes [mailto:rlb@ipv.sx]=20 > Sent: Friday, September 19, 2014 2:32 PM > To: Mike Jones > Cc: Tero Kivinen; iesg@ietf.org; secdir@ietf.org; ietf@ietf.org; = draft-ietf-jose-json-web-signature.all@tools.ietf.org;jose@ietf.org > Subject: Re: Secdir review of draft-ietf-jose-json-web-signature-31 > =20 > """ > # Signature Algorithm Protection >=20 > In some usages of JWS, there is a risk of algorithm substitution = attacks, in which an attacker can use an existing signature value with a = different signature algorithm to make it appear that a signer has signed = something that he actually has not. These attacks have been discussed = in detail in the context of CMS {{RFC 6211}}. The risk arises when all = of the following are true: >=20 > * Verifiers of a signature support multiple algorithms of different = strengths > * Given an existing signature, an attacker can find another payload = that produces the same signature value with a weaker algorithm > * In particular, the payload crafted by the attacker is valid in a = given application-layer context >=20 > For example, suppose a verifier is willing to accept both "PS1" and = "PS256" as "alg" values, and a signer creates a signature using "PS256". = If the attacker can craft a payload that has the same SHA-1 digest has = as the SHA-256 digest of the legitimate payload, then the "PS1" = signature over the bogus payload will be the same as the "PS256" = signature over the legitimate payload. > =20 > There are several ways for an application using JOSE to mitigate = algorithm substitution attacks: >=20 > * Don't accept signatures using vulnerable algorithms: Algorithm = substitution attacks do not arise for all signature algorithms. =20 > * Signatures using RSA PKCS#1 v1.5 ("RS1", "RS256", etc.) are not = subject to substitution attacks because the signature value itself = encodes the hash function used. =20 > * Signatures with HMAC algorithms ("HS1", "HS256", etc.) cannot be = substituted because the signature values have different lengths = Likewise for signatures with ECDSA algorithms ("ES256", "ES384", etc.). > =20 > [JLS] This is not a true statement. If you support both SHA256 and = SHA512/256 then the signature values have the same length. This will = also be an issue if you support both the SHA2 and the SHA3 algorithm = sets as they have results of the same length. > =20 > * The only algorithms defined in JWA = {{I-D.ietf-jose-json-web-algorithms}} that is vulnerable to algorithm = substitution attacks is RSA-PSS ("PS1", "PS256", etc.). An = implementation that does not support RSA-PSS is not vulnerable to = algorithm substitution attacks. > =20 > [JLS] ECDSA is open to this attack if you support both SHA256 and = SHA512/256 the hash lengths are the same. This will also be an issue if = you support both the SHA2 and the SHA3 algorithm sets as they have = results of the same length. > =20 > * Require that the "alg" parameter be carried in the protected header. = (This is the approach taken by RFC 6211.) >=20 > * Include a field reflecting the algorithm in the application payload, = and require that it be matched with the "alg" parameter during = verification (This is the approach taken by PKIX {{RFC5280}}.) > =20 > [JLS] RSA-PKCS#1.5 is open to this attack if the suggestion of Mike in = a message prior to this is put into the text. That is to allow for the = hash inside of the signature and that outside of the signature to differ = in value because you only enforce one of the two values. > =20 > Of these mitigations, the only sure solution is the first. Signing = over the "alg" parameter (directly or indirectly) only makes the = attacker's work more difficult, by requiring that the bogus payload also = contain bogus information about the signing algorithm. They do not = prevent attack by a sufficiently powerful attacker. > """ > =20 > On Fri, Sep 19, 2014 at 2:49 PM, Mike Jones = wrote: > I would appreciate it if you would write a draft of the proposed = security considerations text, Richard. Perhaps title the section = =93Unsecured Algorithm Values=94. > =20 > Thanks! > -- Mike > =20 > From: Richard Barnes [mailto:rlb@ipv.sx]=20 > Sent: Wednesday, September 17, 2014 6:24 AM > To: Tero Kivinen > Cc: Mike Jones; iesg@ietf.org; secdir@ietf.org; ietf@ietf.org; = draft-ietf-jose-json-web-signature.all@tools.ietf.org;jose@ietf.org > Subject: Re: Secdir review of draft-ietf-jose-json-web-signature-31 > =20 >=20 >=20 > On Wednesday, September 17, 2014, Tero Kivinen wrote: > Richard Barnes writes: > > Perhaps, but is there benefits for leaving the alg without = protection? > > > > Simplicity (if you omit protected headers altogether), and > > compatibility with other signed things. In the sense that you could > > transform one of them into a JWS without re-signing. This would > > apply, for example, to an X.509 certificate -- just parse the outer > > SEQUENCE, and re-assemble into a JWS with the tbsCertificate as > > payload. Same security properties that X.509 already has. >=20 > Ok, having this kind of information somewhere in the draft would help > to understand the reason. Also having text explaining that is > possible, and that the security properties of this option (i.e. no > problem with PKCS#1, etc... the text you had in the other email). >=20 > > It's also completely unnecessary for PKCS#1 signatures, which are > > the dominant use case today. >=20 > I agree. >=20 > > In general, I'm opposed to protocols baking in more > > application-specific logic than they need to. The point of JOSE is > > to describe the cryptographic operation that was performed, and > > carry the relevant bits around. Its job is not to fix all the > > weaknesses that every algorithm has.=20 >=20 > Yes, but this property might have security issues, so they should be > covered by the security considerations section. > =20 > I'm perfectly happy to have it documented in the Security = Considerations.=20 > =20 > Mike: Should I generate some text, or do you want to take a stab? > =20 > -- > kivinen@iki.fi > =20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_1463590C-30CE-458D-B3EE-8801B05EC708 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 OK but = HMAC is not a signature so that won't get you very = far.

If I am the attacker and have a collision based = on the weaker hash and you accept that why would I bother with changing = the Hash alg?

I still see changing the hash alg = as part of a digital digital signature as different from doing the same = thing with the hash alg of a HMAC integrity protected = message.

John B.

On Sep 20, 2014, = at 12:45 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

No, the attack would run as = follows:

1.        I send you a message which is = hashed
2.       You send back a message which includes the signature = in your hash
3.       I take the other message with the bad signature to = court and your signature on the hash confirming you received = it.

Jim

From: John Bradley [mailto:ve7jtb@ve7jtb.com]
Sent: Saturday, September 20, = 2014 3:55 AM
To: Jim = Schaad
Cc: ietf@ietf.org; secdir@ietf.org; Richard Barnes; Tero Kivinen; Michael = Jones; IESG; jose@ietf.org; draft-ietf-jose-json-web-signature.all@tools.ietf.org
<= b>Subject: Re: = [jose] Secdir review of = draft-ietf-jose-json-web-signature-31
<= div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: = 'Times New Roman', serif;">
Hi Jim,

I = think I am missing something.

If the sender is the attacker and has the mac key, = then they can integrity protect any plaintext they like with any hash = that is supported..

This = seems more like the sender wants to use a different hash than the = receiver prefers situation.

That seems to me like a different security concern = than an attacker taking a existing JWS and using a downgrade on the alg = parameter to substitute a less collision resistant hash, in order to = substitute a plain text (envelope and body in the Compact case) that has = the same hash value as that encrypted by the RSA/EC = key.

Thanks
John = B.

On Sep 19, 2014, at 11:34 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

From: jose [mailto:jose-bounces@ietf.org] On Behalf Of John = Bradley
Sent: Friday, September 19, 2014 = 7:17 PM
To: Jim = Schaad
Cc: ietf@ietf.org; secdir@ietf.org; = Richard Barnes; Tero Kivinen; Michael Jones; IESG; jose@ietf.org; draft-ietf-jose-json-web-signature.all@tools.ietf.org<= br>Subject: Re: = [jose] Secdir review of = draft-ietf-jose-json-web-signature-31
<= div>

For = HMAC changing the hash from SHA3 256 to SHA2 256 doesn't really = get the attacker much as they still don't know the key to be able to = create a appropriate fake = plaintext.
So = simply knowing a value that creates a collision is not sufficient for an = attack.

[JLS] remember that the = attacker can be the sender of the message, in this case the key is known = to the attacker.

I interpreted Mike's comment on PKCS#1 as being that = the signature needs to be verified by the algorithm specified in the = "alg" parameter. That is not to say that if in the case of PKCS#1 = padding if the OID is not consistent with the value of "alg" that = wouldn't be an error. I think that would be a invalid JWS. = I do think that should be made clear. =

With = PSS if the key is the same length it is true that you are going to be = vulnerable to collisions over the plaintext based on the weakest hash = you can get the receiver to accept. =
This = is not a issue unique to JOSE in any way. One would be tempted to = rule out SHA1 now but it is differentiated by it's key length, so can't = be downgraded to from SHA2.

John B.

On Sep 19, 2014, at 7:25 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

From: Richard Barnes [mailto:rlb@ipv.sx]
Sent: Friday, September 19, 2014 = 2:32 PM
To: Mike = Jones
Cc: Tero= Kivinen; iesg@ietf.org; secdir@ietf.org; ietf@ietf.org; draft-ietf-jose-json-web-signature.all@tools.ietf.org;= jose@ietf.org
Subject: Re: Secdir review of = draft-ietf-jose-json-web-signature-31

"""
# Signature = Algorithm Protection
In some usages of JWS, there is a risk of algorithm substitution = attacks, in which an attacker can use an existing signature value with a = different signature algorithm to make it appear that a signer has signed = something that he actually has not. These attacks have been = discussed in detail in the context of CMS {{RFC 6211}}. The risk = arises when all of the following are = true:

* = Verifiers of a signature support multiple algorithms of different = strengths
* = Given an existing signature, an attacker can find another payload that = produces the same signature value with a weaker = algorithm
* In particular, the payload crafted by the attacker is = valid in a given application-layer context
For example, suppose a verifier is willing to accept = both "PS1" and "PS256" as "alg" values, and a signer creates a signature = using "PS256". If the attacker can craft a payload that has the = same SHA-1 digest has as the SHA-256 digest of the legitimate payload, = then the "PS1" signature over the bogus payload will be the same as the = "PS256" signature over the legitimate = payload.

There are several ways for an application using JOSE to = mitigate algorithm substitution = attacks:
* = Don't accept signatures using vulnerable algorithms: Algorithm = substitution attacks do not arise for all signature = algorithms.
* Signatures = using RSA PKCS#1 v1.5 ("RS1", "RS256", etc.) are not subject to = substitution attacks because the signature value itself encodes the hash = function used.
* Signatures = with HMAC algorithms ("HS1", "HS256", etc.) cannot be substituted = because the signature values have different lengths Likewise for = signatures with ECDSA algorithms ("ES256", "ES384", = etc.).

[JLS] This is not a true = statement. If you support both SHA256 and SHA512/256 then the = signature values have the same length. This will also be an issue = if you support both the SHA2 and the SHA3 algorithm sets as they have = results of the same length.

* The only algorithms defined in JWA = {{I-D.ietf-jose-json-web-algorithms}} that is vulnerable to algorithm = substitution attacks is RSA-PSS ("PS1", "PS256", etc.). An = implementation that does not support RSA-PSS is not vulnerable to = algorithm substitution attacks.

[JLS] ECDSA is open to this attack = if you support both SHA256 and SHA512/256 the hash lengths are the = same. This will also be an issue if you support both the SHA2 and = the SHA3 algorithm sets as they have results of the same = length.

* Require that the "alg" parameter be carried in the = protected header. (This is the approach taken by RFC = 6211.)
* = Include a field reflecting the algorithm in the application payload, and = require that it be matched with the "alg" parameter during verification = (This is the approach taken by PKIX = {{RFC5280}}.)

[JLS] RSA-PKCS#1.5 is = open to this attack if the suggestion of Mike in a message prior to this = is put into the text. That is to allow for the hash inside of the = signature and that outside of the signature to differ in value because = you only enforce one of the two = values.

Of = these mitigations, the only sure solution is the first. Signing = over the "alg" parameter (directly or indirectly) only makes the = attacker's work more difficult, by requiring that the bogus payload also = contain bogus information about the signing algorithm. They do not = prevent attack by a sufficiently powerful = attacker.
"""

On Fri, Sep 19, 2014 at 2:49 PM, Mike Jones <Michael.Jones@microsoft.com> = wrote:
I would appreciate it if you would write a draft of = the proposed security considerations text, Richard. Perhaps title = the section =93Unsecured Algorithm = Values=94.

           &= nbsp;           &nb= sp;            = ;            &= nbsp;           = Thanks!
           &= nbsp;           &nb= sp;            = ;            &= nbsp;           -- = Mike

From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Wednesday, September 17, = 2014 6:24 AM
To: Tero = Kivinen
Cc: Mike Jones; iesg@ietf.org; secdir@ietf.org; ietf@ietf.org; draft-ietf-jose-json-web-signature.all@tools.ietf.org;= jose@ietf.org
Subject: Re: Secdir review of = draft-ietf-jose-json-web-signature-31

On Wednesday, September 17, 2014, Tero = Kivinen <kivinen@iki.fi> = wrote:
Richard Barnes writes:
> Perhaps, but = is there benefits for leaving the alg without = protection?
>
> Simplicity (if you omit protected headers = altogether), and
> compatibility with other signed things. = In the sense that you could
> transform one of them into a JWS = without re-signing. This would
> apply, for example, to an = X.509 certificate -- just parse the outer
> SEQUENCE, and = re-assemble into a JWS with the tbsCertificate as
> payload. = Same security properties that X.509 already has.

Ok, having this = kind of information somewhere in the draft would help
to understand = the reason. Also having text explaining that is
possible, and that = the security properties of this option (i.e. no
problem with PKCS#1, = etc... the text you had in the other email).

> It's also = completely unnecessary for PKCS#1 signatures, which are
> the = dominant use case today.

I agree.

> In general, I'm = opposed to protocols baking in more
> application-specific logic = than they need to. The point of JOSE is
> to describe the = cryptographic operation that was performed, and
> carry the = relevant bits around. Its job is not to fix all the
> = weaknesses that every algorithm has.

Yes, but this property = might have security issues, so they should be
covered by the security = considerations section.

I'm = perfectly happy to have it documented in the Security = Considerations.

Mike: = Should I generate some text, or do you want to take a = stab?

--
kivinen@iki.fi

_______________________________________________
jose = mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose

= --Apple-Mail=_1463590C-30CE-458D-B3EE-8801B05EC708-- --Apple-Mail=_A7770E28-3D05-495F-AE2A-BF5E3FC047A4 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNDA5MjAxNzA3MzhaMCMGCSqGSIb3DQEJBDEWBBTmueZhbcDEWmlj2ZCoG2qo FDk7PjCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQAMeBroIe3I1BbwRa3DEZcuskbrDRCTQfMswQObOarCEisw2ZKiWDwX UY88nbkGBXeV63pMRDiDjf4MhzU+XCRE7mEffMzCYY7UlBQHvJmuI4lzhyMZmranJB8Gl6AiP6np blQGh7oz6wNtZc3DU1cAd0kiYWjrruxRUg2YE0NTyXlTnM+5mP/0fEGKZYqeqYZGkEQ0NatIh0x1 aL6heJNT6ov6Y5lLJLNXTYc+h++vyQiNMsc+qXmR3HYCDwkfCManVQU36MAuqWtHpCRDAOoI78pM bVASZLRKoJCwOi/thTX5pSPSbAMTRuq/kZTnMaGjV9mJM0E2nCq5EAxWYpy0AAAAAAAA --Apple-Mail=_A7770E28-3D05-495F-AE2A-BF5E3FC047A4-- From nobody Sun Sep 21 17:32:10 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 427D01A0395 for ; Sun, 21 Sep 2014 17:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.723 X-Spam-Level: X-Spam-Status: No, score=0.723 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 Uc4Xo8prbyM8 for ; Sun, 21 Sep 2014 17:32:07 -0700 (PDT) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4065F1A039C for ; Sun, 21 Sep 2014 17:32:02 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id l4so5784309lbv.2 for ; Sun, 21 Sep 2014 17:32:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/lHru6Plxk5l0mB5uxM89nE2j1YSu2SzfH3Gfnb/jkg=; b=Bfah0IybQcpnfHU7AjmIWb4L5OSBlL9RMZRK1vxpLC5QFpoYP5utKC01mURZbozSD+ xZRwT2558Zcl78dfoKXCYgsdbjaHhJYq/RSHI7dG+Jeyw7NysfsLP5BYC4UlkKXm9T1y eTGAV+WmcjFomJA16cTvNlFkDzNbXZ7ZmqnXN+4Eyu1FVvMLhw7gMzuofJDbyyv3yvrl FfzfW/DlTo+Ic4zXvsJeLMNQpwYkhawrHozQJ6KMUypxD3FwMNQxKuCKp+2URQ1CV1/o rf2YNnpHZyq0Z1G6o3r5wuxh1VP4kCn05AEaobQJj+y0AGisJeRxvcMaWYkPE9e+tXfK bqqw== X-Gm-Message-State: ALoCoQkMZabzzEDTzIc6yS3ORxpjChpsksLTG+hAThpDR9s19pTNrsJ9CQpnXtSMvMQwNcHQM0SS MIME-Version: 1.0 X-Received: by 10.152.6.40 with SMTP id x8mr21931287lax.18.1411345921192; Sun, 21 Sep 2014 17:32:01 -0700 (PDT) Received: by 10.25.159.84 with HTTP; Sun, 21 Sep 2014 17:32:01 -0700 (PDT) In-Reply-To: <457A8BF9-8CDF-43C8-8040-CB42BE110805@ve7jtb.com> References: <21512.21725.209461.976375@fireball.kivinen.iki.fi> <4E1F6AAD24975D4BA5B16804296739439AE9DD47@TK5EX14MBXC292.redmond.corp.microsoft.com> <21527.63989.999440.801542@fireball.kivinen.iki.fi> <21529.16232.880915.215045@fireball.kivinen.iki.fi> <4E1F6AAD24975D4BA5B16804296739439BA59EB7@TK5EX14MBXC286.redmond.corp.microsoft.com> <03a601cfd460$f8d71d70$ea855850$@augustcellars.com> <03c701cfd483$d1cf45e0$756dd1a0$@augustcellars.com> <043a01cfd4f2$3df75ff0$b9e61fd0$@augustcellars.com> <457A8BF9-8CDF-43C8-8040-CB42BE110805@ve7jtb.com> Date: Sun, 21 Sep 2014 20:32:01 -0400 Message-ID: From: Richard Barnes To: John Bradley Content-Type: multipart/alternative; boundary=089e0141a02049c41605039c9485 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/n1mFbbVrCJ40rc9zIFmykVp9zXU Cc: "ietf@ietf.org" , secdir , Jim Schaad , Michael Jones , IESG , "jose@ietf.org" , "draft-ietf-jose-json-web-signature.all@tools.ietf.org" Subject: Re: [secdir] [jose] Secdir review of draft-ietf-jose-json-web-signature-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 00:32:09 -0000 --089e0141a02049c41605039c9485 Content-Type: text/plain; charset=UTF-8 I think I may have erred by trying to write a treatise on which algorithms are vulnerable :) Here's some updated text, trying to be more concise. Jim: Your points about SHA-256 vs. SHA-512/256 and SHA-256 vs. SHA-3 don't really apply, since JOSE hasn't defined algorithm identifiers for SHA-512/256 or SHA-3. """ # Signature Algorithm Protection In some usages of JWS, there is a risk of algorithm substitution attacks, in which an attacker can use an existing signature value with a different signature algorithm to make it appear that a signer has signed something that he actually has not. These attacks have been discussed in detail in the context of CMS {{RFC 6211}}. The risk arises when all of the following are true: * Verifiers of a signature support multiple algorithms of different strengths * Given an existing signature, an attacker can find another payload that produces the same signature value with a weaker algorithm * In particular, the payload crafted by the attacker is valid in a given application-layer context For example, suppose a verifier is willing to accept both "PS256" and "PS384" as "alg" values, and a signer creates a signature using "PS256". If the attacker can craft a payload that results in the same signature with SHA-256 as the signature with SHA-384 of the legitimate payload, then the "PS256" signature over the bogus payload will be the same as the "PS384" signature over the legitimate payload. There are several ways for an application using JOSE to mitigate algorithm substitution attacks The simplest mitigation is to not accept signatures using vulnerable algorithms: Algorithm substitution attacks do not arise for all signature algorithms. The only algorithms defined in JWA {{I-D.ietf-jose-json-web-algorithms}} that may be vulnerable to algorithm substitution attacks is RSA-PSS ("PS256", etc.). An implementation that does not support RSA-PSS is not vulnerable to algorithm substitution attacks. (Obviously, if other algorithms are added, then they may introduce new risks.) In addition, substitution attacks are only feasible if an attacker can compute pre-images for the weakest hash function accepted by the recipient. All JOSE algorithms use SHA-2 hashes, for which there are no known pre-image attacks as of this writing. Until there begin to be attacks against SHA-2 hashes, even a JOSE implementation that supports PSS is safe from substitution attacks. Without restricting algorithms, there are also mitigations at the JOSE and application layer: At the level of JOSE, an application could require that the "alg" parameter be carried in the protected header. (This is the approach taken by RFC 6211.) The application could also include a field reflecting the algorithm in the application payload, and require that it be matched with the "alg" parameter during verification. (This is the approach taken by PKIX {{RFC5280}}.) Of these mitigations, the only sure solution is the first, not to accept vulnerable algorithms. Signing over the "alg" parameter (directly or indirectly) only makes the attacker's work more difficult, by requiring that the bogus payload also contain bogus information about the signing algorithm. They do not prevent attack by a sufficiently powerful attacker. """ --089e0141a02049c41605039c9485 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I think I may have erred by trying to write a treatis= e on which algorithms are vulnerable :)=C2=A0 Here's some updated text,= trying to be more concise.

Jim: Your points about SHA-25= 6 vs. SHA-512/256 and SHA-256 vs. SHA-3 don't really apply, since JOSE = hasn't defined algorithm identifiers for SHA-512/256 or SHA-3.

"""
# Signature Algorithm Protection

In some usages of JWS, there is a risk of algorithm substitution attacks,=20 in which an attacker can use an existing signature value with a=20 different signature algorithm to make it appear that a signer has signed something that he actually has not.=C2=A0 These attacks have been discusse= d=20 in detail in the context of CMS {{RFC 6211}}.=C2=A0 The risk arises when al= l=20 of the following are true:

* Verifiers of a signature support multiple algorithms of different= strengths

* Given an existing signature, an attacker can find another payload that=20 produces the same signature value with a weaker algorithm

* In partic= ular, the payload crafted by the attacker is valid in a given application-l= ayer context

For example, suppose a verifier is willing to accept both "PS256" an= d "PS384" as "alg" values, and a signer creates a signature using "PS= 256".=C2=A0 If=20 the attacker can craft a payload that results in the same signature with SH= A-256 as=20 the signature with SHA-384 of the legitimate payl= oad, then the "PS256" signature=20 over the bogus payload will be the same as the "PS3= 84" signature over=20 the legitimate payload.

=C2=A0

T= here are several ways for an application using JOSE to mitigate algorithm s= ubstitution attacks

The simplest mitigation is to not accept= signatures using vulnerable algorithms: Algorithm=20 substitution attacks do not arise for all signature algorithms.=C2=A0 The o= nly algorithms defined in JWA {{I-D.ietf-jose-json-web-algorithms}} that may be vulnerable to algorithm substitution attacks is RSA-PSS ("= ;PS256", etc.).=C2=A0 An implementation that does not support RSA-PSS = is not vulnerable to algorithm substitution attacks.=C2=A0 (Obviously, if other a= lgorithms are added, then they may introduce new risks.)=C2=A0

In a= ddition, substitution attacks are only feasible if an attacker can compute = pre-images for the weakest hash function accepted by the recipient.=C2=A0 A= ll JOSE algorithms use SHA-2 hashes, for which there are no known pre-image= attacks as of this writing.=C2=A0 Until there begin to be attacks against = SHA-2 hashes, even a JOSE implementation that supports PSS is safe from sub= stitution attacks.

Without restricting algorit= hms, there are also mitigations at the JOSE and application layer: At the l= evel of JOSE, an application could require that the "alg" paramet= er be carried in the protected header.=C2=A0 (This is the approach taken by= RFC 6211.)=C2=A0 The application could also include a field reflecting the= algorithm in the application payload,=20 and require that it be matched with the "alg" parameter during=20 verification. (This is the approach taken by PKIX {{RFC5280}}.)

Of these mitigations, the only sure solution is the first, not to accept vuln= erable algorithms.=C2=A0 Signing over=20 the "alg" parameter (directly or indirectly) only makes the attac= ker's=20 work more difficult, by requiring that the bogus payload also contain=20 bogus information about the signing algorithm.=C2=A0 They do not prevent=20 attack by a sufficiently powerful attacker.
"""

--089e0141a02049c41605039c9485-- From nobody Sun Sep 21 17:47:32 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7131A039F for ; Sun, 21 Sep 2014 17:47:29 -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 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 1iLhKpZr8ob0 for ; Sun, 21 Sep 2014 17:47:26 -0700 (PDT) Received: from mail-yk0-f174.google.com (mail-yk0-f174.google.com [209.85.160.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C2461A0396 for ; Sun, 21 Sep 2014 17:47:26 -0700 (PDT) Received: by mail-yk0-f174.google.com with SMTP id q9so361207ykb.5 for ; Sun, 21 Sep 2014 17:47:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=N9vHoyQo/Mm7vZ7alpVLo3Dvkgk4KXBNuXGLGjZFjC0=; b=OChmCzyROWw2SnO373O9NqR3C6I/sNMXUOas44rKHUB/NDJCDxneunUIMMvohA/c8s te09HnF65wLhveVSwt+OvqO0epXQD0F5pM31Ay1WMk1vgPXqG3zvfA7EN0W6wqpTWcH9 C/+GjNLFF8zK051DHY7kaDB7xxWmz07UZGTnPAaKGcK/RuaQkN7Bh97KPuvLisURQxKE Csn8qqiI9MHgcbE3/9VbmqDOT3tK7Om5L8bLAygtbsaIlweZ35IvSPohV1x+i4RdfS6O wkLSqF8SRuWE8AskEeAPIISDJc3KkJzn91TTijhkKRk8FHOb54GcaT1yiBiVXS4kiEyt ke/g== X-Gm-Message-State: ALoCoQkokoKHWI0YfyR5iZmevYoF70PPBqmif1P03Y7EL4HYLfYD+gBVLIJYtZvs8J+cIwVsCRNp X-Received: by 10.236.130.97 with SMTP id j61mr16699546yhi.5.1411346845271; Sun, 21 Sep 2014 17:47:25 -0700 (PDT) Received: from [192.168.10.171] (ip-64-134-188-245.public.wayport.net. [64.134.188.245]) by mx.google.com with ESMTPSA id s27sm3778238yho.6.2014.09.21.17.47.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 21 Sep 2014 17:47:24 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_B17E7959-A675-4FAD-8DE6-C0123E4E2F4B"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 $1878.6$) From: John Bradley In-Reply-To: Date: Sun, 21 Sep 2014 20:47:20 -0400 Message-Id: References: <21512.21725.209461.976375@fireball.kivinen.iki.fi> <4E1F6AAD24975D4BA5B16804296739439AE9DD47@TK5EX14MBXC292.redmond.corp.microsoft.com> <21527.63989.999440.801542@fireball.kivinen.iki.fi> <21529.16232.880915.215045@fireball.kivinen.iki.fi> <4E1F6AAD24975D4BA5B16804296739439BA59EB7@TK5EX14MBXC286.redmond.corp.microsoft.com> <03a601cfd460$f8d71d70$ea855850$@augustcellars.com> <03c701cfd483$d1cf45e0$756dd1a0$@augustcellars.com> <043a01cfd4f2$3df75ff0$b9e61fd0$@augustcellars.com> <457A8BF9-8CDF-43C8-8040-CB42BE110805@ve7jtb.com> To: Richard Barnes X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/0iNMjh0Bsf3ZPQzw_8toHpnaRCU Cc: "ietf@ietf.org" , secdir , Jim Schaad , Michael Jones , IESG , "jose@ietf.org" , "draft-ietf-jose-json-web-signature.all@tools.ietf.org" Subject: Re: [secdir] [jose] Secdir review of draft-ietf-jose-json-web-signature-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 00:47:29 -0000 --Apple-Mail=_B17E7959-A675-4FAD-8DE6-C0123E4E2F4B Content-Type: multipart/alternative; boundary="Apple-Mail=_56E2CB28-550C-47C2-A60A-D5656B6C711B" --Apple-Mail=_56E2CB28-550C-47C2-A60A-D5656B6C711B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I like the general direction. One question, wouldn't the recipient of a PSS signature detect the = substitution of SHA-284 with SHA-256 due to the different key length. I was under the perhaps mistaken impression that the key lengths needed = to be the same and just the alg different eg SHA3 and SHA2 keys of the = same length. If that is the case we probably have not defined any algs currently that = may be subject to this. That is not to say that we shouldn't warn = people as new algs are defined. John B. On Sep 21, 2014, at 8:32 PM, Richard Barnes wrote: > I think I may have erred by trying to write a treatise on which = algorithms are vulnerable :) Here's some updated text, trying to be = more concise. >=20 > Jim: Your points about SHA-256 vs. SHA-512/256 and SHA-256 vs. SHA-3 = don't really apply, since JOSE hasn't defined algorithm identifiers for = SHA-512/256 or SHA-3. >=20 > """ > # Signature Algorithm Protection >=20 > In some usages of JWS, there is a risk of algorithm substitution = attacks, in which an attacker can use an existing signature value with a = different signature algorithm to make it appear that a signer has signed = something that he actually has not. These attacks have been discussed = in detail in the context of CMS {{RFC 6211}}. The risk arises when all = of the following are true: >=20 >=20 > * Verifiers of a signature support multiple algorithms of different = strengths >=20 > * Given an existing signature, an attacker can find another payload = that produces the same signature value with a weaker algorithm >=20 > * In particular, the payload crafted by the attacker is valid in a = given application-layer context >=20 > For example, suppose a verifier is willing to accept both "PS256" and = "PS384" as "alg" values, and a signer creates a signature using "PS256". = If the attacker can craft a payload that results in the same signature = with SHA-256 as the signature with SHA-384 of the legitimate payload, = then the "PS256" signature over the bogus payload will be the same as = the "PS384" signature over the legitimate payload. > =20 > There are several ways for an application using JOSE to mitigate = algorithm substitution attacks >=20 > The simplest mitigation is to not accept signatures using vulnerable = algorithms: Algorithm substitution attacks do not arise for all = signature algorithms. The only algorithms defined in JWA = {{I-D.ietf-jose-json-web-algorithms}} that may be vulnerable to = algorithm substitution attacks is RSA-PSS ("PS256", etc.). An = implementation that does not support RSA-PSS is not vulnerable to = algorithm substitution attacks. (Obviously, if other algorithms are = added, then they may introduce new risks.) =20 >=20 > In addition, substitution attacks are only feasible if an attacker can = compute pre-images for the weakest hash function accepted by the = recipient. All JOSE algorithms use SHA-2 hashes, for which there are no = known pre-image attacks as of this writing. Until there begin to be = attacks against SHA-2 hashes, even a JOSE implementation that supports = PSS is safe from substitution attacks. >=20 > Without restricting algorithms, there are also mitigations at the JOSE = and application layer: At the level of JOSE, an application could = require that the "alg" parameter be carried in the protected header. = (This is the approach taken by RFC 6211.) The application could also = include a field reflecting the algorithm in the application payload, and = require that it be matched with the "alg" parameter during verification. = (This is the approach taken by PKIX {{RFC5280}}.) >=20 > Of these mitigations, the only sure solution is the first, not to = accept vulnerable algorithms. Signing over the "alg" parameter = (directly or indirectly) only makes the attacker's work more difficult, = by requiring that the bogus payload also contain bogus information about = the signing algorithm. They do not prevent attack by a sufficiently = powerful attacker. > """ --Apple-Mail=_56E2CB28-550C-47C2-A60A-D5656B6C711B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

I = like the general direction.

One question, = wouldn't the recipient of a PSS signature detect the substitution = of SHA-284 with SHA-256 due to the different key = length.

I was under the perhaps mistaken impression = that the key lengths needed to be the same and just the alg different eg = SHA3 and SHA2 keys of the same length.

If that = is the case we probably have not defined any algs currently that may be = subject to this. That is not to say that we shouldn't warn people = as new algs are defined.

John = B.

On Sep 21, 2014, at 8:32 PM, = Richard Barnes <rlb@ipv.sx> = wrote:

I think I may have erred by trying = to write a treatise on which algorithms are vulnerable :) Here's = some updated text, trying to be more concise.

Jim: = Your points about SHA-256 vs. SHA-512/256 and SHA-256 vs. SHA-3 don't = really apply, since JOSE hasn't defined algorithm identifiers for = SHA-512/256 or SHA-3.

"""
# Signature Algorithm = Protection

In some usages of JWS, there is a risk of algorithm substitution attacks,=20= in which an attacker can use an existing signature value with a=20 different signature algorithm to make it appear that a signer has signed something that he actually has not. These attacks have been = discussed=20 in detail in the context of CMS {{RFC 6211}}. The risk arises when = all=20 of the following are true:

* Verifiers of a signature support multiple = algorithms of different strengths
* Given an existing signature, an attacker can find another payload that=20= produces the same signature value with a weaker = algorithm
* In particular, the payload crafted by the = attacker is valid in a given application-layer context
For example, suppose a verifier is willing to accept both "PS256" and = "PS384" as "alg" values, and a signer creates a signature using "PS256". = If=20 the attacker can craft a payload that results in the same signature with = SHA-256 as=20 the signature with SHA-384 of the legitimate payload, then the "PS256" = signature=20 over the bogus payload will be the same as the "PS384" signature over=20 the legitimate payload.

There are several ways for an application = using JOSE to mitigate algorithm substitution attacks
The = simplest mitigation is to not accept signatures using vulnerable = algorithms: Algorithm=20 substitution attacks do not arise for all signature algorithms. = The only algorithms defined in JWA {{I-D.ietf-jose-json-web-algorithms}} that may be vulnerable to algorithm substitution attacks is RSA-PSS = ("PS256", etc.). An implementation that does not support RSA-PSS = is not vulnerable to algorithm substitution attacks. (Obviously, if = other algorithms are added, then they may introduce new risks.) =

In addition, substitution attacks are only feasible if an = attacker can compute pre-images for the weakest hash function accepted = by the recipient. All JOSE algorithms use SHA-2 hashes, for which = there are no known pre-image attacks as of this writing. Until = there begin to be attacks against SHA-2 hashes, even a JOSE = implementation that supports PSS is safe from substitution = attacks.

Without restricting algorithms, = there are also mitigations at the JOSE and application layer: At the = level of JOSE, an application could require that the "alg" parameter be = carried in the protected header. (This is the approach taken by = RFC 6211.) The application could also include a field reflecting = the algorithm in the application payload,=20 and require that it be matched with the "alg" parameter during=20 verification. (This is the approach taken by PKIX = {{RFC5280}}.)

Of these mitigations, the only sure solution is the first, not to accept = vulnerable algorithms. Signing over=20 the "alg" parameter (directly or indirectly) only makes the attacker's=20= work more difficult, by requiring that the bogus payload also contain=20 bogus information about the signing algorithm. They do not prevent=20= attack by a sufficiently powerful attacker.
"""

= --Apple-Mail=_56E2CB28-550C-47C2-A60A-D5656B6C711B-- --Apple-Mail=_B17E7959-A675-4FAD-8DE6-C0123E4E2F4B Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNDA5MjIwMDQ3MjFaMCMGCSqGSIb3DQEJBDEWBBSk4vy4xxtDXY08dkF8dqYj ze8V/TCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQBwy9/1F06zRSozmzsol+XgTo9ozEfEC5j06O7H8PSW5p9Q99QLBWAc ZCeRRp5yPq3P5rG7UqH1I3u3YHHM2tB0emFz9sexdq9NWxcVYCP5rujM8QzOKs4Chtd7Sb4Q/QbP Qno2dIwaT+eF534jV6gWJYf421WouPHQRm6kvYeJQGUBAvZ6CNwZ/c/CM9T7pSdJJvmdYiQbr7D8 +sMNBg3Qn4CzUxe6dWJ6vNLBrB+Ao+ZYRdDy4OMN2F2R4JReqTqmFCQGg8hNPmA6Fc0r0keMKSJL SfwPnV+3SM0m5tovA3+imL1dDDxkUIe6T2c23N39YSBvTFMTLHwvBrdLvW2LAAAAAAAA --Apple-Mail=_B17E7959-A675-4FAD-8DE6-C0123E4E2F4B-- From nobody Sun Sep 21 17:59:37 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43C931A03A8 for ; Sun, 21 Sep 2014 17:59:33 -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 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 dDPMOpkOSUCh for ; Sun, 21 Sep 2014 17:59:25 -0700 (PDT) Received: from mail-yh0-f52.google.com (mail-yh0-f52.google.com [209.85.213.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A5821A0396 for ; Sun, 21 Sep 2014 17:59:25 -0700 (PDT) Received: by mail-yh0-f52.google.com with SMTP id a41so1176531yho.11 for ; Sun, 21 Sep 2014 17:59:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=NesEmMU5YE22Dif4PE/3+nXQdxKfYdQCdrAtm7o+fEM=; b=Qr2vZyaTBiIg4Pdxm77lpb6shAhAsDp8QRjBhyl4tZm/uWiyO5RtnskLC0eUxumX1D PFQCWB1jCeihaoR749NvF917+6ly1WCA9oimbEnLP4Xl2Jf2WKX2oPl7OR7YFIVaqg4a +OZq307fqtWc7bQMXie4eYK/woH8q1H0dce2sYDZXslMFIJWXsYpyYuBwFfkDbku0z37 LTqeteQL5Gtg6SWtANAycn57rH/agL+E+BbLCu1AnhM4fEPB5lQZ2co2uUzZJoNcBxRX sRDfgX8XBfOwMIt12RwIbgpWX83ylu/H5EMPWQfKmA6wUNz9jfg5LEcqZciQ6iQl8jWe BIXw== X-Gm-Message-State: ALoCoQnJs+wyJ719WH3hXDRmUnIK5M28H08/+VwbKbfPBkHPJuTz8w5wZbfKxMQkfE8ULTylie63 X-Received: by 10.236.195.39 with SMTP id o27mr22344246yhn.29.1411347564747; Sun, 21 Sep 2014 17:59:24 -0700 (PDT) Received: from [192.168.10.171] (ip-64-134-188-245.public.wayport.net. [64.134.188.245]) by mx.google.com with ESMTPSA id f26sm3786682yhg.10.2014.09.21.17.59.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 21 Sep 2014 17:59:23 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_6D80B17A-A2DF-4059-A04B-5728419D2A5B"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 $1878.6$) From: John Bradley In-Reply-To: Date: Sun, 21 Sep 2014 20:59:22 -0400 Message-Id: <5EF71157-1102-4863-8DC1-2B2A397A4532@ve7jtb.com> References: <21512.21725.209461.976375@fireball.kivinen.iki.fi> <4E1F6AAD24975D4BA5B16804296739439AE9DD47@TK5EX14MBXC292.redmond.corp.microsoft.com> <21527.63989.999440.801542@fireball.kivinen.iki.fi> <21529.16232.880915.215045@fireball.kivinen.iki.fi> <4E1F6AAD24975D4BA5B16804296739439BA59EB7@TK5EX14MBXC286.redmond.corp.microsoft.com> <03a601cfd460$f8d71d70$ea855850$@augustcellars.com> <03c701cfd483$d1cf45e0$756dd1a0$@augustcellars.com> <043a01cfd4f2$3df75ff0$b9e61fd0$@augustcellars.com> <457A8BF9-8CDF-43C8-8040-CB42BE110805@ve7jtb.com>

To: Richard Barnes X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/cGck9zLNVJ-I9_sUn5NexiPfjDA Cc: "ietf@ietf.org" , secdir , Jim Schaad , Michael Jones , IESG , "jose@ietf.org" , "draft-ietf-jose-json-web-signature.all@tools.ietf.org" Subject: Re: [secdir] [jose] Secdir review of draft-ietf-jose-json-web-signature-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 00:59:33 -0000 --Apple-Mail=_6D80B17A-A2DF-4059-A04B-5728419D2A5B Content-Type: multipart/alternative; boundary="Apple-Mail=_C9EFA294-DFDC-4429-BB81-985581C076AE" --Apple-Mail=_C9EFA294-DFDC-4429-BB81-985581C076AE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Also with PSS the attack is largely mitigated if the mask function uses = the same hash as the message. http://tools.ietf.org/html/rfc3447#page-29 JWA sec 3.5 requires SHA2 MGF functions for SHA2 message hashes with = the equivalent length. If the same is done when SHA3 is added then I think PSS is not as = susceptible to a substitution attack as it might look on the surface. Sorry I just remembers that there was that mitigation for PSS. John B. On Sep 21, 2014, at 8:47 PM, John Bradley wrote: > I like the general direction. >=20 > One question, wouldn't the recipient of a PSS signature detect the = substitution of SHA-284 with SHA-256 due to the different key length. >=20 > I was under the perhaps mistaken impression that the key lengths = needed to be the same and just the alg different eg SHA3 and SHA2 keys = of the same length. >=20 > If that is the case we probably have not defined any algs currently = that may be subject to this. That is not to say that we shouldn't warn = people as new algs are defined. >=20 > John B. >=20 >=20 > On Sep 21, 2014, at 8:32 PM, Richard Barnes wrote: >=20 >> I think I may have erred by trying to write a treatise on which = algorithms are vulnerable :) Here's some updated text, trying to be = more concise. >>=20 >> Jim: Your points about SHA-256 vs. SHA-512/256 and SHA-256 vs. SHA-3 = don't really apply, since JOSE hasn't defined algorithm identifiers for = SHA-512/256 or SHA-3. >>=20 >> """ >> # Signature Algorithm Protection >>=20 >> In some usages of JWS, there is a risk of algorithm substitution = attacks, in which an attacker can use an existing signature value with a = different signature algorithm to make it appear that a signer has signed = something that he actually has not. These attacks have been discussed = in detail in the context of CMS {{RFC 6211}}. The risk arises when all = of the following are true: >>=20 >>=20 >> * Verifiers of a signature support multiple algorithms of different = strengths >>=20 >> * Given an existing signature, an attacker can find another payload = that produces the same signature value with a weaker algorithm >>=20 >> * In particular, the payload crafted by the attacker is valid in a = given application-layer context >>=20 >> For example, suppose a verifier is willing to accept both "PS256" and = "PS384" as "alg" values, and a signer creates a signature using "PS256". = If the attacker can craft a payload that results in the same signature = with SHA-256 as the signature with SHA-384 of the legitimate payload, = then the "PS256" signature over the bogus payload will be the same as = the "PS384" signature over the legitimate payload. >> =20 >> There are several ways for an application using JOSE to mitigate = algorithm substitution attacks >>=20 >> The simplest mitigation is to not accept signatures using vulnerable = algorithms: Algorithm substitution attacks do not arise for all = signature algorithms. The only algorithms defined in JWA = {{I-D.ietf-jose-json-web-algorithms}} that may be vulnerable to = algorithm substitution attacks is RSA-PSS ("PS256", etc.). An = implementation that does not support RSA-PSS is not vulnerable to = algorithm substitution attacks. (Obviously, if other algorithms are = added, then they may introduce new risks.) =20 >>=20 >> In addition, substitution attacks are only feasible if an attacker = can compute pre-images for the weakest hash function accepted by the = recipient. All JOSE algorithms use SHA-2 hashes, for which there are no = known pre-image attacks as of this writing. Until there begin to be = attacks against SHA-2 hashes, even a JOSE implementation that supports = PSS is safe from substitution attacks. >>=20 >> Without restricting algorithms, there are also mitigations at the = JOSE and application layer: At the level of JOSE, an application could = require that the "alg" parameter be carried in the protected header. = (This is the approach taken by RFC 6211.) The application could also = include a field reflecting the algorithm in the application payload, and = require that it be matched with the "alg" parameter during verification. = (This is the approach taken by PKIX {{RFC5280}}.) >>=20 >> Of these mitigations, the only sure solution is the first, not to = accept vulnerable algorithms. Signing over the "alg" parameter = (directly or indirectly) only makes the attacker's work more difficult, = by requiring that the bogus payload also contain bogus information about = the signing algorithm. They do not prevent attack by a sufficiently = powerful attacker. >> """ >=20 --Apple-Mail=_C9EFA294-DFDC-4429-BB81-985581C076AE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Also = with PSS the attack is largely mitigated if the mask function uses the = same hash as the message. http://tools.ietf.org/= html/rfc3447#page-29

JWA sec 3.5 requires = SHA2 MGF functions for SHA2 message hashes with the equivalent = length.

If the same is done when SHA3 is added = then I think PSS is not as susceptible to a substitution attack as it = might look on the surface.

Sorry I just = remembers that there was that mitigation for = PSS.

John B.

On Sep 21, 2014, at = 8:47 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

I = like the general direction.

One question, = wouldn't the recipient of a PSS signature detect the substitution = of SHA-284 with SHA-256 due to the different key = length.

I was under the perhaps mistaken impression = that the key lengths needed to be the same and just the alg different eg = SHA3 and SHA2 keys of the same length.

If that = is the case we probably have not defined any algs currently that may be = subject to this. That is not to say that we shouldn't warn people = as new algs are defined.

John = B.

On Sep 21, 2014, at 8:32 PM, = Richard Barnes <rlb@ipv.sx> = wrote:

I think I may have erred by trying = to write a treatise on which algorithms are vulnerable :) Here's = some updated text, trying to be more concise.

Jim: = Your points about SHA-256 vs. SHA-512/256 and SHA-256 vs. SHA-3 don't = really apply, since JOSE hasn't defined algorithm identifiers for = SHA-512/256 or SHA-3.

"""
# Signature Algorithm = Protection

In some usages of JWS, there is a risk of algorithm substitution attacks,=20= in which an attacker can use an existing signature value with a=20 different signature algorithm to make it appear that a signer has signed something that he actually has not. These attacks have been = discussed=20 in detail in the context of CMS {{RFC 6211}}. The risk arises when = all=20 of the following are true:

* Verifiers of a signature support multiple = algorithms of different strengths
* Given an existing signature, an attacker can find another payload that=20= produces the same signature value with a weaker = algorithm
* In particular, the payload crafted by the = attacker is valid in a given application-layer context
For example, suppose a verifier is willing to accept both "PS256" and = "PS384" as "alg" values, and a signer creates a signature using "PS256". = If=20 the attacker can craft a payload that results in the same signature with = SHA-256 as=20 the signature with SHA-384 of the legitimate payload, then the "PS256" = signature=20 over the bogus payload will be the same as the "PS384" signature over=20 the legitimate payload.

There are several ways for an application = using JOSE to mitigate algorithm substitution attacks
The = simplest mitigation is to not accept signatures using vulnerable = algorithms: Algorithm=20 substitution attacks do not arise for all signature algorithms. = The only algorithms defined in JWA {{I-D.ietf-jose-json-web-algorithms}} that may be vulnerable to algorithm substitution attacks is RSA-PSS = ("PS256", etc.). An implementation that does not support RSA-PSS = is not vulnerable to algorithm substitution attacks. (Obviously, if = other algorithms are added, then they may introduce new risks.) =

In addition, substitution attacks are only feasible if an = attacker can compute pre-images for the weakest hash function accepted = by the recipient. All JOSE algorithms use SHA-2 hashes, for which = there are no known pre-image attacks as of this writing. Until = there begin to be attacks against SHA-2 hashes, even a JOSE = implementation that supports PSS is safe from substitution = attacks.

Without restricting algorithms, = there are also mitigations at the JOSE and application layer: At the = level of JOSE, an application could require that the "alg" parameter be = carried in the protected header. (This is the approach taken by = RFC 6211.) The application could also include a field reflecting = the algorithm in the application payload,=20 and require that it be matched with the "alg" parameter during=20 verification. (This is the approach taken by PKIX = {{RFC5280}}.)

Of these mitigations, the only sure solution is the first, not to accept = vulnerable algorithms. Signing over=20 the "alg" parameter (directly or indirectly) only makes the attacker's=20= work more difficult, by requiring that the bogus payload also contain=20 bogus information about the signing algorithm. They do not prevent=20= attack by a sufficiently powerful attacker.
"""
=

= --Apple-Mail=_C9EFA294-DFDC-4429-BB81-985581C076AE-- --Apple-Mail=_6D80B17A-A2DF-4059-A04B-5728419D2A5B Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNDA5MjIwMDU5MjNaMCMGCSqGSIb3DQEJBDEWBBQ6WYlbqqeHacpfBU4e7JY4 NsvW4zCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQB8OX6lt1vSeh/t1ewBfDe+h5Ywa5XBmLpUxBwb6tCfvcR68bizLam1 fT74WfaCeuSBWMdAEedmP4EA/OlOMsmGzaKkgSLnlAtHEZZ8jrf4WvuUfVIdxsHH7u6+uO74A3v+ QpqNf+gYH/aa2RlbYkry1RuWzNV39a4dRTTE60XnqILub7JImOT00ZLvKfJXX7efQ27jAPFcRgrD p+vVtVyGqWCKmaleFTrTFLuR4AtAdg4Dct/NgMgeH564eGzbwhsodWIbBmCSDzl2C8ZpiCmCTurM dW9IVVBXcMAN0dOfPrNnqD7Gk2KlYX3NerRylZZmyslDLdp4GO+7RckqkvyIAAAAAAAA --Apple-Mail=_6D80B17A-A2DF-4059-A04B-5728419D2A5B-- From nobody Sun Sep 21 18:29:20 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6491A03D0 for ; Sun, 21 Sep 2014 18:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 YiiIj_8a0d3Y for ; Sun, 21 Sep 2014 18:29:11 -0700 (PDT) Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 296391A03A5 for ; Sun, 21 Sep 2014 18:29:10 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id mc6so5737540lab.6 for ; Sun, 21 Sep 2014 18:29:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=n0bQ8lzjDO4SUP5fQM4OtCvYvW2BmpkDu/pV4YPRPHc=; b=T08gSDXwgBv+W7+STI+vtvGnt0ndB0aX6hk65ILFZ188iShZ8RTj0MMpg4fuSuPATj 9Ufr9r0cq8S+d2glbmc8LpjCYajAiZ0vaCWdwVhzYN6QKrA/bzJ/qwjOONrD1w5Ton97 gxeds4lQs97cVZnAygHO6c3PsBmPXygiOH+XL+MUHkt74P5XfVkXeOFYVZoHslXcxK8x l8PsshlsKy7vYfXN/1Mx27wXy/umw83uPB7vpIPTTCBgN87uegbGXEwliaTJc2IMFA9L ant8tDSCVtw6vzEs3HXCQ2sga03aId6EC8Jyfl4U8/zSQpElZGJc0Xocje4WuUjxpM2C 4csQ== X-Gm-Message-State: ALoCoQlGj6+NaLxc/uj2pTvRceLgWFW8TMRfHnl9OCt+vyOb8GACVqnKsTdToeCqw+9DbrIzT4Lu MIME-Version: 1.0 X-Received: by 10.112.148.170 with SMTP id tt10mr21493540lbb.61.1411349349141; Sun, 21 Sep 2014 18:29:09 -0700 (PDT) Received: by 10.25.159.84 with HTTP; Sun, 21 Sep 2014 18:29:09 -0700 (PDT) In-Reply-To: References: <21512.21725.209461.976375@fireball.kivinen.iki.fi> <4E1F6AAD24975D4BA5B16804296739439AE9DD47@TK5EX14MBXC292.redmond.corp.microsoft.com> <21527.63989.999440.801542@fireball.kivinen.iki.fi> <21529.16232.880915.215045@fireball.kivinen.iki.fi> <4E1F6AAD24975D4BA5B16804296739439BA59EB7@TK5EX14MBXC286.redmond.corp.microsoft.com> <03a601cfd460$f8d71d70$ea855850$@augustcellars.com> <03c701cfd483$d1cf45e0$756dd1a0$@augustcellars.com> <043a01cfd4f2$3df75ff0$b9e61fd0$@augustcellars.com> <457A8BF9-8CDF-43C8-8040-CB42BE110805@ve7jtb.com>

Date: Sun, 21 Sep 2014 21:29:09 -0400 Message-ID: From: Richard Barnes To: John Bradley Content-Type: multipart/alternative; boundary=047d7b3a7d8e9c287005039d60a0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/fUX7D4IoS7P4CxKxj4KXPO4N9ho Cc: "ietf@ietf.org" , secdir , Jim Schaad , Michael Jones , IESG , "jose@ietf.org" , "draft-ietf-jose-json-web-signature.all@tools.ietf.org" Subject: Re: [secdir] [jose] Secdir review of draft-ietf-jose-json-web-signature-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 01:29:14 -0000 --047d7b3a7d8e9c287005039d60a0 Content-Type: text/plain; charset=UTF-8 On Sun, Sep 21, 2014 at 8:47 PM, John Bradley wrote: > I like the general direction. > > One question, wouldn't the recipient of a PSS signature detect the > substitution of SHA-284 with SHA-256 due to the different key length. > No, in both cases, the key is an RSA key. > I was under the perhaps mistaken impression that the key lengths needed to > be the same and just the alg different eg SHA3 and SHA2 keys of the same > length. > I think you're probably thinking about HMAC. --Richard If that is the case we probably have not defined any algs currently that > may be subject to this. That is not to say that we shouldn't warn people > as new algs are defined. > > John B. > > > On Sep 21, 2014, at 8:32 PM, Richard Barnes wrote: > > I think I may have erred by trying to write a treatise on which algorithms > are vulnerable :) Here's some updated text, trying to be more concise. > > Jim: Your points about SHA-256 vs. SHA-512/256 and SHA-256 vs. SHA-3 don't > really apply, since JOSE hasn't defined algorithm identifiers for > SHA-512/256 or SHA-3. > > """ > # Signature Algorithm Protection > > In some usages of JWS, there is a risk of algorithm substitution attacks, > in which an attacker can use an existing signature value with a different > signature algorithm to make it appear that a signer has signed something > that he actually has not. These attacks have been discussed in detail in > the context of CMS {{RFC 6211}}. The risk arises when all of the following > are true: > > > * Verifiers of a signature support multiple algorithms of different > strengths > > * Given an existing signature, an attacker can find another payload that > produces the same signature value with a weaker algorithm > > * In particular, the payload crafted by the attacker is valid in a given > application-layer context > For example, suppose a verifier is willing to accept both "PS256" and > "PS384" as "alg" values, and a signer creates a signature using "PS256". > If the attacker can craft a payload that results in the same signature with > SHA-256 as the signature with SHA-384 of the legitimate payload, then the > "PS256" signature over the bogus payload will be the same as the "PS384" > signature over the legitimate payload. > > > There are several ways for an application using JOSE to mitigate algorithm > substitution attacks > The simplest mitigation is to not accept signatures using vulnerable > algorithms: Algorithm substitution attacks do not arise for all signature > algorithms. The only algorithms defined in JWA > {{I-D.ietf-jose-json-web-algorithms}} that may be vulnerable to algorithm > substitution attacks is RSA-PSS ("PS256", etc.). An implementation that > does not support RSA-PSS is not vulnerable to algorithm substitution > attacks. (Obviously, if other algorithms are added, then they may > introduce new risks.) > > In addition, substitution attacks are only feasible if an attacker can > compute pre-images for the weakest hash function accepted by the > recipient. All JOSE algorithms use SHA-2 hashes, for which there are no > known pre-image attacks as of this writing. Until there begin to be > attacks against SHA-2 hashes, even a JOSE implementation that supports PSS > is safe from substitution attacks. > > Without restricting algorithms, there are also mitigations at the JOSE and > application layer: At the level of JOSE, an application could require that > the "alg" parameter be carried in the protected header. (This is the > approach taken by RFC 6211.) The application could also include a field > reflecting the algorithm in the application payload, and require that it be > matched with the "alg" parameter during verification. (This is the approach > taken by PKIX {{RFC5280}}.) > > Of these mitigations, the only sure solution is the first, not to accept > vulnerable algorithms. Signing over the "alg" parameter (directly or > indirectly) only makes the attacker's work more difficult, by requiring > that the bogus payload also contain bogus information about the signing > algorithm. They do not prevent attack by a sufficiently powerful attacker. > """ > > > --047d7b3a7d8e9c287005039d60a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sun, Sep 21, 2014 at 8:47 PM, John Bradley <ve7jtb@ve7jtb.com&g= t; wrote:

I like the general direction.

One ques= tion, =C2=A0wouldn't the recipient of a PSS signature detect the substi= tution of SHA-284 with SHA-256 due to the different key length.
<= /div>

No, in both cases, the key is an RSA = key.

=C2=A0

I was under the perhaps mistaken impressio= n that the key lengths needed to be the same and just the alg different eg = SHA3 and SHA2 keys of the same length.

I think you're probably thinking about HMAC.

=C2= =A0

--Richard

If that is the cas= e we probably have not defined any algs currently that may be subject to th= is.=C2=A0 That is not to say that we shouldn't warn people as new algs = are defined.

John B.
<= div>

On Sep 21, 2014, at 8:32 PM, Richard Barne= s <rlb@ipv.sx> wr= ote:

I think I may= have erred by trying to write a treatise on which algorithms are vulnerabl= e :)=C2=A0 Here's some updated text, trying to be more concise.

=
Jim: Your points about SHA-256 vs. SHA-512/256 and SHA-256 vs. S= HA-3 don't really apply, since JOSE hasn't defined algorithm identi= fiers for SHA-512/256 or SHA-3.

"""
# S= ignature Algorithm Protection

In some usages of JWS, there is a risk of algorithm substitution attacks,=20 in which an attacker can use an existing signature value with a=20 different signature algorithm to make it appear that a signer has signed something that he actually has not.=C2=A0 These attacks have been discusse= d=20 in detail in the context of CMS {{RFC 6211}}.=C2=A0 The risk arises when al= l=20 of the following are true:

* Ver= ifiers of a signature support multiple algorithms of different strengths
* Given an existing signature, an attacker can find another payload that=20 produces the same signature value with a weaker algorithm
<= p class=3D"MsoNormal" style=3D"margin-bottom:12pt">* In particular, the pay= load crafted by the attacker is valid in a given application-layer context<= /p>For example, suppose a verifier is willing to accept both "PS256" an= d "PS384" as "alg" values, and a signer creates a signature using "PS= 256".=C2=A0 If=20 the attacker can craft a payload that results in the same signature with SH= A-256 as=20 the signature with SHA-384 of the legitimate payload, then the "PS256&= quot; signature=20 over the bogus payload will be the same as the "PS384" signature = over=20 the legitimate payload.
=C2=A0
There are several ways for an application= using JOSE to mitigate algorithm substitution attacks
The s= implest mitigation is to not accept signatures using vulnerable algorithms:= Algorithm=20 substitution attacks do not arise for all signature algorithms.=C2=A0 The o= nly algorithms defined in JWA {{I-D.ietf-jose-json-web-algorithms}} that may be vulnerable to algorithm substitution attacks is RSA-PSS ("= ;PS256", etc.).=C2=A0 An implementation that does not support RSA-PSS = is not vulnerable to algorithm substitution attacks.=C2=A0 (Obviously, if other a= lgorithms are added, then they may introduce new risks.)=C2=A0

In a= ddition, substitution attacks are only feasible if an attacker can compute = pre-images for the weakest hash function accepted by the recipient.=C2=A0 A= ll JOSE algorithms use SHA-2 hashes, for which there are no known pre-image= attacks as of this writing.=C2=A0 Until there begin to be attacks against = SHA-2 hashes, even a JOSE implementation that supports PSS is safe from sub= stitution attacks.

Without restricting algorit= hms, there are also mitigations at the JOSE and application layer: At the l= evel of JOSE, an application could require that the "alg" paramet= er be carried in the protected header.=C2=A0 (This is the approach taken by= RFC 6211.)=C2=A0 The application could also include a field reflecting the= algorithm in the application payload,=20 and require that it be matched with the "alg" parameter during=20 verification. (This is the approach taken by PKIX {{RFC5280}}.)

Of these mitigations, the only sure solution is the first, not to accept vuln= erable algorithms.=C2=A0 Signing over=20 the "alg" parameter (directly or indirectly) only makes the attac= ker's=20 work more difficult, by requiring that the bogus payload also contain=20 bogus information about the signing algorithm.=C2=A0 They do not prevent=20 attack by a sufficiently powerful attacker.
"""

--047d7b3a7d8e9c287005039d60a0-- From nobody Sun Sep 21 18:32:08 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD4B1A0439 for ; Sun, 21 Sep 2014 18:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 lRrRqW9Gpbix for ; Sun, 21 Sep 2014 18:31:58 -0700 (PDT) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3386A1A03A5 for ; Sun, 21 Sep 2014 18:31:55 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id z12so5875813lbi.36 for ; Sun, 21 Sep 2014 18:31:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hbQtFlkRhtDk8RpUYSpKC4Kl1TATV4Cr4U8ACz1LsFQ=; b=AyZlipkcOcoUrLHyUxSJ0VPEMNk5XereF8vDo+n6LHb8WY348NRo1tinEZrN77LXlr hAPWE9JHqAseo7XJvqrJjWRHH7MsI+ZYeWjPGufpnQS5Bc/ctfMbP5wta1p2EbJvswWP TzbASWEzLiVuC1y5k7dfTTIJO+OOr4pHZh3oEd2+TVJ8kXxEuJPo6S4Mh/NUstPU/zXc gGPkGdsAkFUUKc1oLfjZyJ/f5fiMtx89jJhh1kXfprsMEVwicrTlQ5UOMIkvv2vrAARS OJTHD/UPVLFglnzPaKMsze65myDIal7cjw+xx4JVxKtpBxBc6dbCF+V1GNeGBrTVM7EX 2z0Q== X-Gm-Message-State: ALoCoQkm+DRpo+WTmmfV59pZX49IZrqGuAogrUBsV+dSOEz/dLxqfW80S6C8eFJv4eDUJWmhViot MIME-Version: 1.0 X-Received: by 10.112.148.170 with SMTP id tt10mr21503385lbb.61.1411349513437; Sun, 21 Sep 2014 18:31:53 -0700 (PDT) Received: by 10.25.159.84 with HTTP; Sun, 21 Sep 2014 18:31:53 -0700 (PDT) In-Reply-To: <5EF71157-1102-4863-8DC1-2B2A397A4532@ve7jtb.com> References: <21512.21725.209461.976375@fireball.kivinen.iki.fi> <4E1F6AAD24975D4BA5B16804296739439AE9DD47@TK5EX14MBXC292.redmond.corp.microsoft.com> <21527.63989.999440.801542@fireball.kivinen.iki.fi> <21529.16232.880915.215045@fireball.kivinen.iki.fi> <4E1F6AAD24975D4BA5B16804296739439BA59EB7@TK5EX14MBXC286.redmond.corp.microsoft.com> <03a601cfd460$f8d71d70$ea855850$@augustcellars.com> <03c701cfd483$d1cf45e0$756dd1a0$@augustcellars.com> <043a01cfd4f2$3df75ff0$b9e61fd0$@augustcellars.com> <457A8BF9-8CDF-43C8-8040-CB42BE110805@ve7jtb.com>

<5EF71157-1102-4863-8DC1-2B2A397A4532@ve7jtb.com> Date: Sun, 21 Sep 2014 21:31:53 -0400 Message-ID: From: Richard Barnes To: John Bradley Content-Type: multipart/alternative; boundary=047d7b3a7d8e67085c05039d6a4e Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/nsMsy1dHlzaR5AdcSDM_4rCqGfs Cc: "ietf@ietf.org" , secdir , Jim Schaad , Michael Jones , IESG , "jose@ietf.org" , "draft-ietf-jose-json-web-signature.all@tools.ietf.org" Subject: Re: [secdir] [jose] Secdir review of draft-ietf-jose-json-web-signature-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: ,

On Sun, Sep 21, 2014 at 10:10 PM, Jim Schaad <ietf@augustcellars.= com> wrote:

=C2=A0
=C2=A0
From: jose = [mailto:jose-bou= nces@ietf.org] On Behalf Of Richard Barnes
Sent: Sunda= y, September 21, 2014 5:32 PM
To: John Bradley
Cc: ietf@ietf.org; secdir; J= im Schaad; Tero Kivinen; Michael Jones; IESG; jose@ietf.org; draft-ietf-jose-js= on-web-signature.all@tools.ietf.org
Subject:= Re: [jose] Secdir review of draft-ietf-jose-json-web-signature-31
=C2=A0
=
I think I may have= erred by trying to write a treatise on which algorithms are vulnerable :)= =C2=A0 Here's some updated text, trying to be more concise.
Jim: Your points a= bout SHA-256 vs. SHA-512/256 and SHA-256 vs. SHA-3 don't really apply, = since JOSE hasn't defined algorithm identifiers for SHA-512/256 or SHA-= 3.
= =C2=A0
[JLS] Richard =E2=80=93 are you planning to update this t= ext when (not if) they are defined?=C2=A0 If not then this is still part of= the problem even if currently not constrained.=C2=A0 The same could also b= e said to be not a problem for all of the ECDSA algorithms since there is o= nly one hash defined of any given length.=C2=A0 (I will ignore the really f= un problem for DSA and ECDSA where there is a modulus operation that occurs= on the hash value thus creating collisions within the same hash function a= nd making matching of hash function lengths and key lengths of primary impo= rtance.)=C2=A0 However, as these will almost certainly be defined in the fu= ture, they merit inclusion in the potential problems. =C2=A0=C2=A0I believe= that this should be included in the discussion as it is much easier to do = than to break the mask function of RSA.=C2=A0 (Breaking the same hash funct= ion twice is very non-trival, having two hash functions that produce the sa= me length hash is much easier.)

Is the phrase "Obviously, if other algorithms = are added, then they may introduce new risks" insufficient?

--Richard

=C2=A0

"""
# Signature Alg= orithm Protection
In some usages of JWS, there is a risk of algorithm substit= ution attacks, in which an attacker can use an existing signature value wit= h a different signature algorithm to make it appear that a signer has signe= d something that he actually has not.=C2=A0 These attacks have been discuss= ed in detail in the context of CMS {{RFC 6211}}.=C2=A0 The risk arises when= all of the following are true:
* Verifiers of a signature support multiple algorithms of different streng= ths
* Given an existing signature, = an attacker can find another payload that produces the same signature value= with a weaker algorithm
* In particular, the payload crafted by the attacker is = valid in a given application-layer context
For example, suppose a verifier is willing to accept both "PS2= 56" and "PS384" as "alg" values, and a signer crea= tes a signature using "PS256".=C2=A0 If the attacker can craft a = payload that results in the same signature with SHA-256 as the= signature with SHA-384 of the legitimate payload, then the &q= uot;PS256" signature over the bogus payload will be the same as the &q= uot;PS384" signature over the legitimate payload.<= u>
=C2=A0
There are several ways for an = application using JOSE to mitigate algorithm substitution attacks=
The simplest mitigation is to not accep= t signatures using vulnerable algorithms: Algorithm substitution attacks do= not arise for all signature algorithms.=C2=A0 The only algorithms defined = in JWA {{I-D.ietf-jose-json-web-algorithms}} that may be vulnerable to algo= rithm substitution attacks is RSA-PSS ("PS256", etc.).=C2=A0 An i= mplementation that does not support RSA-PSS is not vulnerable to algorithm = substitution attacks.=C2=A0 (Obviously, if other algorithms are added, then= they may introduce new risks.)=C2=A0

In addition, substitution att= acks are only feasible if an attacker can compute pre-images for the weakes= t hash function accepted by the recipient.=C2=A0 All JOSE algorithms use SH= A-2 hashes, for which there are no known pre-image attacks as of this writi= ng.=C2=A0 Until there begin to be attacks against SHA-2 hashes, even a JOSE= implementation that supports PSS is safe from substitution attacks.=
=C2=A0
=
Without restricting algorithms, there are also = mitigations at the JOSE and application layer: At the level of JOSE, an app= lication could require that the "alg" parameter be carried in the= protected header.=C2=A0 (This is the approach taken by RFC 6211.)=C2=A0 Th= e application could also include a field reflecting the algorithm in the ap= plication payload, and require that it be matched with the "alg" = parameter during verification. (This is the approach taken by PKIX {{RFC528= 0}}.)
=C2=A0
Of these mitigations, the only sure solu= tion is the first, not to accept vulnerable algorithms.=C2=A0 Signing over = the "alg" parameter (directly or indirectly) only makes the attac= ker's work more difficult, by requiring that the bogus payload also con= tain bogus information about the signing algorithm.=C2=A0 They do not preve= nt attack by a sufficiently powerful attacker.
"""=

--001a11c3c178a27dcd05039e1c6d-- From nobody Sun Sep 21 23:42:18 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0E291A1A37; Sun, 21 Sep 2014 23:42:16 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains text/plain,.exe X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 m1inyfN0GhrF; Sun, 21 Sep 2014 23:42:14 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D89831A1A32; Sun, 21 Sep 2014 23:42:13 -0700 (PDT) Received: from Philemon (unknown [50.38.74.159]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 2CFAD38EEC; Sun, 21 Sep 2014 23:42:12 -0700 (PDT) From: "Jim Schaad" To: "'Richard Barnes'" References: <21512.21725.209461.976375@fireball.kivinen.iki.fi> <4E1F6AAD24975D4BA5B16804296739439AE9DD47@TK5EX14MBXC292.redmond.corp.microsoft.com> <21527.63989.999440.801542@fireball.kivinen.iki.fi> <21529.16232.880915.215045@fireball.kivinen.iki.fi> <4E1F6AAD24975D4BA5B16804296739439BA59EB7@TK5EX14MBXC286.redmond.corp.microsoft.com> <03a601cfd460$f8d71d70$ea855850$@augustcellars.com> <03c701cfd483$d1cf45e0$756dd1a0$@augustcellars.com> <043a01cfd4f2$3df75ff0$b9e61fd0$@augustcellars.com> <457A8BF9-8CDF-43C8-8040-CB42BE110805@ve7jtb.com> < 04fd01cfd60a$71d0cc80$ 55726580$@augustcellars.com> In-Reply-To: Date: Sun, 21 Sep 2014 23:39:38 -0700 Message-ID: <053201cfd630$00f64eb0$02e2ec10$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0533_01CFD5F5.549AF920" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHuOuT/hh4qDeGZm241cGqvJGlDHQGDSHSvAfo059oBmzmMjgKe6fc2AlAhJ5UBTPVdRAKLDxUuAlnvmcEBe7XC2gIGyytgAc7rQnwCY5XyuAGYB4o3Am359pkCB7d7agGvJ3w5Ab4TRKiaxJyRUA== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/82_yYfIwWNtHYGmX86KCxrtNjRs Cc: ietf@ietf.org, 'secdir' , 'Michael Jones' , 'IESG' , jose@ietf.org, 'John Bradley' , draft-ietf-jose-json-web-signature.all@tools.ietf.org Subject: Re: [secdir] [jose] Secdir review of draft-ietf-jose-json-web-signature-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 06:42:17 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0533_01CFD5F5.549AF920 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Richard Barnes [mailto:rlb@ipv.sx]=20 Sent: Sunday, September 21, 2014 7:22 PM To: Jim Schaad Cc: John Bradley; ietf@ietf.org; secdir; Tero Kivinen; Michael Jones; = IESG; jose@ietf.org; = draft-ietf-jose-json-web-signature.all@tools.ietf.org Subject: Re: [jose] Secdir review of = draft-ietf-jose-json-web-signature-31 =20 =20 =20 On Sun, Sep 21, 2014 at 10:10 PM, Jim Schaad = wrote: =20 =20 From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes Sent: Sunday, September 21, 2014 5:32 PM To: John Bradley Cc: ietf@ietf.org; secdir; Jim Schaad; Tero Kivinen; Michael Jones; = IESG; jose@ietf.org; = draft-ietf-jose-json-web-signature.all@tools.ietf.org Subject: Re: [jose] Secdir review of = draft-ietf-jose-json-web-signature-31 =20 I think I may have erred by trying to write a treatise on which = algorithms are vulnerable :) Here's some updated text, trying to be = more concise. Jim: Your points about SHA-256 vs. SHA-512/256 and SHA-256 vs. SHA-3 = don't really apply, since JOSE hasn't defined algorithm identifiers for = SHA-512/256 or SHA-3. =20 [JLS] Richard =E2=80=93 are you planning to update this text when (not = if) they are defined? If not then this is still part of the problem = even if currently not constrained. The same could also be said to be = not a problem for all of the ECDSA algorithms since there is only one = hash defined of any given length. (I will ignore the really fun problem = for DSA and ECDSA where there is a modulus operation that occurs on the = hash value thus creating collisions within the same hash function and = making matching of hash function lengths and key lengths of primary = importance.) However, as these will almost certainly be defined in the = future, they merit inclusion in the potential problems. I believe that = this should be included in the discussion as it is much easier to do = than to break the mask function of RSA. (Breaking the same hash = function twice is very non-trival, having two hash functions that = produce the same length hash is much easier.) =20 Is the phrase "Obviously, if other algorithms are added, then they may = introduce new risks" insufficient? [JLS] Given the context of the sentence I would say no. It would seem = to apply only to RSA-SSA-PSS and not to any of the DSA/ECDSA algorithms. --Richard =20 """ # Signature Algorithm Protection In some usages of JWS, there is a risk of algorithm substitution = attacks, in which an attacker can use an existing signature value with a = different signature algorithm to make it appear that a signer has signed = something that he actually has not. These attacks have been discussed = in detail in the context of CMS {{RFC 6211}}. The risk arises when all = of the following are true: * Verifiers of a signature support multiple algorithms of different = strengths * Given an existing signature, an attacker can find another payload that = produces the same signature value with a weaker algorithm * In particular, the payload crafted by the attacker is valid in a given = application-layer context For example, suppose a verifier is willing to accept both "PS256" and = "PS384" as "alg" values, and a signer creates a signature using "PS256". = If the attacker can craft a payload that results in the same signature = with SHA-256 as the signature with SHA-384 of the legitimate payload, = then the "PS256" signature over the bogus payload will be the same as = the "PS384" signature over the legitimate payload. =20 There are several ways for an application using JOSE to mitigate = algorithm substitution attacks The simplest mitigation is to not accept signatures using vulnerable = algorithms: Algorithm substitution attacks do not arise for all = signature algorithms. The only algorithms defined in JWA = {{I-D.ietf-jose-json-web-algorithms}} that may be vulnerable to = algorithm substitution attacks is RSA-PSS ("PS256", etc.). An = implementation that does not support RSA-PSS is not vulnerable to = algorithm substitution attacks. (Obviously, if other algorithms are = added, then they may introduce new risks.) =20 In addition, substitution attacks are only feasible if an attacker can = compute pre-images for the weakest hash function accepted by the = recipient. All JOSE algorithms use SHA-2 hashes, for which there are no = known pre-image attacks as of this writing. Until there begin to be = attacks against SHA-2 hashes, even a JOSE implementation that supports = PSS is safe from substitution attacks. =20 Without restricting algorithms, there are also mitigations at the JOSE = and application layer: At the level of JOSE, an application could = require that the "alg" parameter be carried in the protected header. = (This is the approach taken by RFC 6211.) The application could also = include a field reflecting the algorithm in the application payload, and = require that it be matched with the "alg" parameter during verification. = (This is the approach taken by PKIX {{RFC5280}}.) =20 Of these mitigations, the only sure solution is the first, not to accept = vulnerable algorithms. Signing over the "alg" parameter (directly or = indirectly) only makes the attacker's work more difficult, by requiring = that the bogus payload also contain bogus information about the signing = algorithm. They do not prevent attack by a sufficiently powerful = attacker. """ =20 ------=_NextPart_000_0533_01CFD5F5.549AF920 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

From:= = Richard Barnes [mailto:rlb@ipv.sx]
Sent: Sunday, September = 21, 2014 7:22 PM
To: Jim Schaad
Cc: John Bradley; = ietf@ietf.org; secdir; Tero Kivinen; Michael Jones; IESG; jose@ietf.org; = draft-ietf-jose-json-web-signature.all@tools.ietf.org
Subject: = Re: [jose] Secdir review of = draft-ietf-jose-json-web-signature-31

On Sun, = Sep 21, 2014 at 10:10 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

From:= = jose [mailto:jose-bounces@ietf.org] On Behalf Of Richard = Barnes
Sent: Sunday, September 21, 2014 5:32 PM
To: = John Bradley
Cc: ietf@ietf.org; secdir; Jim Schaad; Tero Kivinen; = Michael Jones; IESG; jose@ietf.org; draft-ietf-jose-json-web-signature.all@tools.ietf.org
Subject: Re: [jose] Secdir review of = draft-ietf-jose-json-web-signature-31

<= /o:p>

I think I may = have erred by trying to write a treatise on which algorithms are = vulnerable :) Here's some updated text, trying to be more = concise.

Jim: Your = points about SHA-256 vs. SHA-512/256 and SHA-256 vs. SHA-3 don't really = apply, since JOSE hasn't defined algorithm identifiers for SHA-512/256 = or SHA-3.

[JLS] Richard =E2=80=93 are you planning to update this text when = (not if) they are defined? If not then this is still part of the = problem even if currently not constrained. The same could also be = said to be not a problem for all of the ECDSA algorithms since there is = only one hash defined of any given length. (I will ignore the = really fun problem for DSA and ECDSA where there is a modulus operation = that occurs on the hash value thus creating collisions within the same = hash function and making matching of hash function lengths and key = lengths of primary importance.) However, as these will almost = certainly be defined in the future, they merit inclusion in the = potential problems. I believe that this should be included = in the discussion as it is much easier to do than to break the mask = function of RSA. (Breaking the same hash function twice is very = non-trival, having two hash functions that produce the same length hash = is much easier.)

Is the phrase "Obviously, if other = algorithms are added, then they may introduce new risks" = insufficient?

[JLS] Given the context of the sentence I would say no.=C2=A0 It = would seem to apply only to RSA-SSA-PSS and not to any of the DSA/ECDSA = algorithms.

--Richard

""&q= uot;
# Signature Algorithm = Protection
In some = usages of JWS, there is a risk of algorithm substitution attacks, in = which an attacker can use an existing signature value with a different = signature algorithm to make it appear that a signer has signed something = that he actually has not. These attacks have been discussed in = detail in the context of CMS {{RFC 6211}}. The risk arises when = all of the following are true:

* = Verifiers of a signature support multiple algorithms of different = strengths
* Given an = existing signature, an attacker can find another payload that produces = the same signature value with a weaker algorithm
* In particular, = the payload crafted by the attacker is valid in a given = application-layer context
For = example, suppose a verifier is willing to accept both "PS256" = and "PS384" as "alg" values, and a signer creates a = signature using "PS256". If the attacker can craft a = payload that results in the same signature with SHA-256 as the signature = with SHA-384 of the legitimate payload, then the "PS256" = signature over the bogus payload will be the same as the = "PS384" signature over the legitimate = payload.
<= /o:p>
There are several = ways for an application using JOSE to mitigate algorithm substitution = attacks
The = simplest mitigation is to not accept signatures using vulnerable = algorithms: Algorithm substitution attacks do not arise for all = signature algorithms. The only algorithms defined in JWA = {{I-D.ietf-jose-json-web-algorithms}} that may be vulnerable to = algorithm substitution attacks is RSA-PSS ("PS256", = etc.). An implementation that does not support RSA-PSS is not = vulnerable to algorithm substitution attacks. (Obviously, if other = algorithms are added, then they may introduce new risks.) =

In addition, substitution attacks are only feasible if an = attacker can compute pre-images for the weakest hash function accepted = by the recipient. All JOSE algorithms use SHA-2 hashes, for which = there are no known pre-image attacks as of this writing. Until = there begin to be attacks against SHA-2 hashes, even a JOSE = implementation that supports PSS is safe from substitution = attacks.
<= /o:p>
Without = restricting algorithms, there are also mitigations at the JOSE and = application layer: At the level of JOSE, an application could require = that the "alg" parameter be carried in the protected = header. (This is the approach taken by RFC 6211.) The = application could also include a field reflecting the algorithm in the = application payload, and require that it be matched with the = "alg" parameter during verification. (This is the approach = taken by PKIX {{RFC5280}}.)
<= /o:p>
Of these = mitigations, the only sure solution is the first, not to accept = vulnerable algorithms. Signing over the "alg" parameter = (directly or indirectly) only makes the attacker's work more difficult, = by requiring that the bogus payload also contain bogus information about = the signing algorithm. They do not prevent attack by a = sufficiently powerful = attacker.
"""

------=_NextPart_000_0533_01CFD5F5.549AF920-- From nobody Mon Sep 22 03:36:33 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D129D1A1A96; Mon, 22 Sep 2014 03:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 nzrm1ABMtaWJ; Mon, 22 Sep 2014 03:36:30 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 710071A19F5; Mon, 22 Sep 2014 03:36:29 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id p10so2232500wes.31 for ; Mon, 22 Sep 2014 03:36:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=LUq10DQVLAOYU14S6k/0IscwuhY2F37nctQ3P/PWCtE=; b=AECBuANgUgblPoa7c+YVQC9SovyJfY+Nq0FQpoYw3q5CN+y8KT8ckGFfrDIcPg452B 3wdNaCNNo+u57RjyvowxFTBl71qyN8C66ysqUCniA0JISM0OfwobdvaCNvG497/x7+ye rMn7lzidtbpYQubR9npBCcpC2H4yPD+pGWd9yGgwPqsRHT/rzLRV5iSajFf+k7yVUnjo bEcwYbZ1LP+z7zvP1r7rs6nRR/O98Gt2Bv2TxRdsdBWF45v/VVsi+EEetyyHHtRizV7t u1iaoHnZLRI2PxXu33dPWQnBxdmSW845VxzXdMm8bqc1zHoncHCvbixLBcgyRitXyXmw Gj2g== X-Received: by 10.180.14.74 with SMTP id n10mr14669161wic.50.1411382186993; Mon, 22 Sep 2014 03:36:26 -0700 (PDT) Received: from [172.24.251.145] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id cj7sm11819036wjc.37.2014.09.22.03.36.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Sep 2014 03:36:26 -0700 (PDT) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_CFDE267B-7E90-40ED-A8F4-968B1E13B22C" Message-Id: <9C5040B7-CCA9-49AA-AEC7-9AC26CE263D7@gmail.com> Date: Mon, 22 Sep 2014 13:36:23 +0300 To: "" , IESG , draft-ietf-eppext-reg.all@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 $1878.6$) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/MWz8186x5YqIOzpa5saS34nvm6I Subject: [secdir] SecDir Review of draft-ietf-eppext-reg-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 10:36:32 -0000 --Apple-Mail=_CFDE267B-7E90-40ED-A8F4-968B1E13B22C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. TL;DR: The document is ready.=20 The document specifies no new protocol. EPP is already specified in RFC = 5730, and extending EPP is already specified in RFC 3735. This document = only specifies the IANA registry for such extensions. Most of the = document is about criteria for considerations by the designated expert, = and there's a 3-page IANA considerations section (includes lots of = examples). Some elements that seemed strange to me. I=92m not trying to = second-guess the working group that produced this, as I=92ve never = participated in it, but I am pointing these things out: The registry policy is "specification required", which seems OK, and the = document points out correctly that this policy implies expert review. = I=92m used to multiple registries with a single expert (such as in = IPsec), so I was surprised to see the requirements in section 2.1.1: The IESG should appoint a small pool of individuals (perhaps 3 - 5) to serve as designated experts as described in Section 3.2 of RFC 5226. The pool should have a single administrative chair who is appointed by the IESG. The designated experts should use the existing eppext mailing list (eppext@ietf.org) for public discussion of registration requests. This implies that the mailing list should remain open after the work of the EPPEXT working group has concluded. I guess the number of experts relates to the amount of work to be done, = so it depends on the per-document requirements in RFC 3735 and on the = amount of documents that arrive in a unit of time.=20 NIT: Section 2.1 says, "An English language version of the extension = specification will appear in the registry=94. The intent, I guess, is = that the English-language version is referenced from the registry. Section 2.2.1 specifies the format for the registration form, which = includes an email address, I=92m guessing that it=92s used as a contact = address. For standards-track documents the email address should be = iesg@ietf.org. I don=92t know if that=92s a good idea. Probably best to = leave either the editor=92s address or the eppext working group. Section 2.2.3 has some requirements for IANA, so it should be reviewed = by IANA. I think it needs a pointer from the IANA considerations = section, which is what they review. The document just sets up an IANA registry. As such, security = considerations should probably be no different than any other = interaction with IANA. The security considerations describes a possible = spoofing attack on the submission process, which is done via email. This = seems very unspecific to this document. What's more, I'm not sure I = understand why this document requires that submissions be done through = email. If IANA decides that they're opening a facebook page, and = registration requests should from here on be posted to their "wall", do = we need to rev this document? This document makes no reference to the security of the extensions = themselves. Extensions that break the security assumptions of base = protocols are a real issue. This is covered to some extent in RFC 3735, = but I would have liked the document to specifically mention that this is = part of the job of the expert reviewer. Specifically, where section = 2.1.1 says: OLD: Extensions should be evaluated for architectural soundness using the guidelines described in RFC 3735 [RFC3735]. =20 I think it would be better to add at the end there ", including the = Security Considerations section of that document.=94 NEW: Extensions should be evaluated for architectural soundness using the guidelines described in RFC 3735 [RFC3735], including the Security=20 Considerations section of that document. Yoav --Apple-Mail=_CFDE267B-7E90-40ED-A8F4-968B1E13B22C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi

I have = reviewed this document as part of the security = directorate's ongoing effort to review all IETF documents being = processed by the IESG. These comments were written primarily = for the benefit of the security area directors. Document = editors and WG chairs should treat these comments just like any = other last call comments.

TL;DR: The document is = ready.

The document specifies no new = protocol. EPP is already specified in RFC 5730, and extending EPP is = already specified in RFC 3735. This document only specifies the IANA = registry for such extensions. Most of the document is about criteria for = considerations by the designated expert, and there's a 3-page IANA = considerations section (includes lots of = examples).

Some elements that seemed strange to = me. I=92m not trying to second-guess the working group that produced = this, as I=92ve never participated in it, but I am pointing these things = out:

The registry policy is = "specification required", which seems OK, and the document points out = correctly that this policy implies expert review. I=92m used to multiple = registries with a single expert (such as in IPsec), so I was surprised = to see the requirements in section 2.1.1:
The IESG should appoint a small pool of individuals = (perhaps 3 - 5)
to serve as designated experts as = described in Section 3.2 of RFC
5226. The pool = should have a single administrative chair who is
= appointed by the IESG. The designated experts should use = the
existing eppext mailing list (eppext@ietf.org) for public = discussion
of registration requests. This implies = that the mailing list should
remain open after the work = of the EPPEXT working group has concluded.
I guess the = number of experts relates to the amount of work to be done, so it = depends on the per-document requirements in RFC 3735 and on the amount = of documents that arrive in a unit of time.
NIT: = Section 2.1 says, "An English language version of the extension = specification will appear in the registry=94. The intent, I guess, is = that the English-language version is referenced from the = registry.
Section 2.2.1 specifies the format for the = registration form, which includes an email address, I=92m guessing that = it=92s used as a contact address. For standards-track documents the = email address should be iesg@ietf.org. I don=92t know if = that=92s a good idea. Probably best to leave either the editor=92s = address or the eppext working group.
Section 2.2.3 has = some requirements for IANA, so it should be reviewed by IANA. I think it = needs a pointer from the IANA considerations section, which is what they = review.
The document just sets up an IANA registry. As = such, security considerations should probably be no different than any = other interaction with IANA. The security considerations describes a = possible spoofing attack on the submission process, which is done via = email. This seems very unspecific to this document. What's more, I'm not = sure I understand why this document requires that submissions be done = through email. If IANA decides that they're opening a facebook page, and = registration requests should from here on be posted to their "wall", do = we need to rev this document?
This document makes no = reference to the security of the extensions themselves. Extensions that = break the security assumptions of base protocols are a real issue. This = is covered to some extent in RFC 3735, but I would have liked the = document to specifically mention that this is part of the job of the = expert reviewer. Specifically, where section 2.1.1 = says:

OLD:
= Extensions should be evaluated for architectural soundness = using the
guidelines described in RFC 3735 = [RFC3735].

I think it would be better to = add at the end there ", including the Security Considerations section of = that document.=94

NEW:
= Extensions should = be evaluated for architectural soundness using the
= guidelines described in RFC 3735 [RFC3735], including the Security =
Considerations section of that = document.

Yoav

= = --Apple-Mail=_CFDE267B-7E90-40ED-A8F4-968B1E13B22C-- From nobody Mon Sep 22 06:27:24 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D183E1A1ADB; Mon, 22 Sep 2014 06:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_NEUTRAL=0.779] autolearn=ham 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 eZKYPKo6JQKW; Mon, 22 Sep 2014 06:27:06 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 A56071A1AC9; Mon, 22 Sep 2014 06:27:03 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s8MDQwTr026343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 22 Sep 2014 16:26:58 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s8MDQun3023591; Mon, 22 Sep 2014 16:26:56 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21536.9120.451498.905934@fireball.kivinen.iki.fi> Date: Mon, 22 Sep 2014 16:26:56 +0300 From: Tero Kivinen To: Richard Barnes In-Reply-To: References: <21512.21725.209461.976375@fireball.kivinen.iki.fi> <4E1F6AAD24975D4BA5B16804296739439AE9DD47@TK5EX14MBXC292.redmond.corp.microsoft.com> <21527.63989.999440.801542@fireball.kivinen.iki.fi> <21529.16232.880915.215045@fireball.kivinen.iki.fi> <4E1F6AAD24975D4BA5B16804296739439BA59EB7@TK5EX14MBXC286.redmond.corp.microsoft.com> <03a601cfd460$f8d71d70$ea855850$@augustcellars.com> <03c701cfd483$d1cf45e0$756dd1a0$@augustcellars.com> <043a01cfd4f2$3df75ff0$b9e61fd0$@augustcellars.com> <457A8BF9-8CDF-43C8-8040-CB42BE110805@ve7jtb.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 15 min X-Total-Time: 19 min Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/6S55853Q0k23b7hJ64IalZonCN4 Cc: "ietf@ietf.org" , secdir , Jim Schaad , Michael Jones , IESG , "jose@ietf.org" , John Bradley , "draft-ietf-jose-json-web-signature.all@tools.ietf.org" Subject: Re: [secdir] [jose] Secdir review of draft-ietf-jose-json-web-signature-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 13:27:18 -0000 Richard Barnes writes: > * Given an existing signature, an attacker can find another payload > that produces the same signature value with a weaker algorithm I think one of the major points is that hash algorithms try to make sure that collisions are hard but ONLY INSIDE the same algorithm. I.e. it is hard to find collisions for SHA-256. On the other hand nothing is said how hard it is said to create SHA-1 hash that matches some SHA-256-160 message. I.e. all the security analysis we have for SHA-256 are worthless as they do not cover creating collision between SHA-256 and SHA-1. I.e. SHA-256 was designed to be collision resistant with SHA-256, but not with SHA-1. It might be secure, or it might not. I think there are some papers talking about creating collisions between MD5 and SHA-1, but those are done by analysing the hash functions, i.e. not while designing the algorithms. I.e. this kind of attacks were not major design criteria when algorithms were made. I.e. most of the properties designed in to the hash functions are not true anymore if we try to match two different algorithms against each other. On the other hand I think that one of the design criteria for creating SHA-2 family was that there is no collisions between different algorithms in the same family. -- kivinen@iki.fi From nobody Mon Sep 22 06:59:16 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACEA1A1AC2 for ; Mon, 22 Sep 2014 06:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 FFFUciXc_yCA for ; Mon, 22 Sep 2014 06:59:03 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E587B1A1ADF for ; Mon, 22 Sep 2014 06:41:53 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id q1so6763235lam.31 for ; Mon, 22 Sep 2014 06:41:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fRXw4mLXedJ2a98iMuZXPuhlfIJVlIZb3eoNdnEDVc4=; b=nHDzGXmvD+QKe/o+/xI/5KBRsgIUqqUeSTD6+QB2Ghp5YSVnYdOXwq9DJ0FnZYaCRz jYYCvDyPLZumq5BF7rqZeyZVkv5HFnZPkrKS30JRZ2y1dk09eDQ3K/Cy5sbl8/SFau9G xSZqoAU2Y8tNnyp7e+F3UZBg3pnMhCG774BJQBurBltq1kpIOoanfHFo7Tt5skrIeCIx 4/JCfnBQlm+1U+QM96clACd4JAifmy/a+op1fLJnsHZgwk7vOciRpA78qlkV9rVT9rks u/67RtW1/ua3+dcIe0SH6lpoLHx+HNaPW52D043PHO3gU4Dzv0QdrFx3x7skWKSKfEOl ikSA== X-Gm-Message-State: ALoCoQl4wKTBROmeTkTMRVSnpeDzAjaJSbwdbtodwIDJKubHYCgCKvaBQ0hZeAWBabEhErSWu/6c MIME-Version: 1.0 X-Received: by 10.152.234.76 with SMTP id uc12mr26267883lac.50.1411393312165; Mon, 22 Sep 2014 06:41:52 -0700 (PDT) Received: by 10.25.159.84 with HTTP; Mon, 22 Sep 2014 06:41:52 -0700 (PDT) In-Reply-To: <21536.9120.451498.905934@fireball.kivinen.iki.fi> References: <21512.21725.209461.976375@fireball.kivinen.iki.fi> <4E1F6AAD24975D4BA5B16804296739439AE9DD47@TK5EX14MBXC292.redmond.corp.microsoft.com> <21527.63989.999440.801542@fireball.kivinen.iki.fi> <21529.16232.880915.215045@fireball.kivinen.iki.fi> <4E1F6AAD24975D4BA5B16804296739439BA59EB7@TK5EX14MBXC286.redmond.corp.microsoft.com> <03a601cfd460$f8d71d70$ea855850$@augustcellars.com> <03c701cfd483$d1cf45e0$756dd1a0$@augustcellars.com> <043a01cfd4f2$3df75ff0$b9e61fd0$@augustcellars.com> <457A8BF9-8CDF-43C8-8040-CB42BE110805@ve7jtb.com> <21536.9120.451498.905934@fireball.kivinen.iki.fi> Date: Mon, 22 Sep 2014 09:41:52 -0400 Message-ID: From: Richard Barnes To: Tero Kivinen Content-Type: multipart/alternative; boundary=001a11340f1202a2150503a79d3b Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/aMDoN4H1OInVKxYsSLlPJOYVy2c Cc: "ietf@ietf.org" , secdir , Jim Schaad , Michael Jones , IESG , "jose@ietf.org" , John Bradley , "draft-ietf-jose-json-web-signature.all@tools.ietf.org" Subject: Re: [secdir] [jose] Secdir review of draft-ietf-jose-json-web-signature-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 13:59:04 -0000 --001a11340f1202a2150503a79d3b Content-Type: text/plain; charset=UTF-8 On Mon, Sep 22, 2014 at 9:26 AM, Tero Kivinen wrote: > Richard Barnes writes: > > * Given an existing signature, an attacker can find another payload > > that produces the same signature value with a weaker algorithm > > I think one of the major points is that hash algorithms try to make > sure that collisions are hard but ONLY INSIDE the same algorithm. I.e. > it is hard to find collisions for SHA-256. On the other hand nothing > is said how hard it is said to create SHA-1 hash that matches some > SHA-256-160 message. I.e. all the security analysis we have for > SHA-256 are worthless as they do not cover creating collision between > SHA-256 and SHA-1. I.e. SHA-256 was designed to be collision resistant > with SHA-256, but not with SHA-1. It might be secure, or it might not. > > I think there are some papers talking about creating collisions > between MD5 and SHA-1, but those are done by analysing the hash > functions, i.e. not while designing the algorithms. I.e. this kind of > attacks were not major design criteria when algorithms were made. > > I.e. most of the properties designed in to the hash functions are not > true anymore if we try to match two different algorithms against each > other. > > On the other hand I think that one of the design criteria for creating > SHA-2 family was that there is no collisions between different > algorithms in the same family. > -- > kivinen@iki.fi > Do you think the above is inaccurate or incomplete, or misses critical detail? The level of detail you're talking about doesn't really seem appropriate for this spec, which is consuming crypto, not designing it. --001a11340f1202a2150503a79d3b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Sep 22, 2014 at 9:26 AM, Tero Kivinen <kivinen@iki.f= i> wrote:

Ri= chard Barnes writes:
> * Given an existing signature, an attacker can find another payload > that produces the same signature value with a weaker algorithm

I think one of the major points is that hash algorithms try to make<= br> sure that collisions are hard but ONLY INSIDE the same algorithm. I.e.
it is hard to find collisions for SHA-256. On the other hand nothing
is said how hard it is said to create SHA-1 hash that matches some
SHA-256-160 message. I.e. all the security analysis we have for
SHA-256 are worthless as they do not cover creating collision between
SHA-256 and SHA-1. I.e. SHA-256 was designed to be collision resistant
with SHA-256, but not with SHA-1. It might be secure, or it might not.

I think there are some papers talking about creating collisions
between MD5 and SHA-1, but those are done by analysing the hash
functions, i.e. not while designing the algorithms. I.e. this kind of
attacks were not major design criteria when algorithms were made.

I.e. most of the properties designed in to the hash functions are not
true anymore if we try to match two different algorithms against each
other.

On the other hand I think that one of the design criteria for creating
SHA-2 family was that there is no collisions between different
algorithms in the same family.
--
kivinen@iki.fi

Do you think the above is inaccu= rate or incomplete, or misses critical detail?=C2=A0 The level of detail yo= u're talking about doesn't really seem appropriate for this spec, w= hich is consuming crypto, not designing it.

--001a11340f1202a2150503a79d3b-- From nobody Mon Sep 22 06:59:33 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3BEB1A1AD4; Mon, 22 Sep 2014 06:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_NEUTRAL=0.779] autolearn=ham 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 3KstAjHsbE9f; Mon, 22 Sep 2014 06:59:10 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 68C431A1B54; Mon, 22 Sep 2014 06:42:04 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s8MDg2Hg014435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 22 Sep 2014 16:42:02 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s8MDg2Jl004278; Mon, 22 Sep 2014 16:42:02 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21536.10026.506235.155913@fireball.kivinen.iki.fi> Date: Mon, 22 Sep 2014 16:42:02 +0300 From: Tero Kivinen To: Mike Jones In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BA5A04D@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <21512.21725.209461.976375@fireball.kivinen.iki.fi> <4E1F6AAD24975D4BA5B16804296739439AEABA21@TK5EX14MBXC292.redmond.corp.microsoft.com> <21528.638.485017.482257@fireball.kivinen.iki.fi> <4E1F6AAD24975D4BA5B16804296739439BA5A04D@TK5EX14MBXC286.redmond.corp.microsoft.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 7 min X-Total-Time: 7 min Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/ZYY8B-ugf3TVjUouI43snn_chB4 Cc: "jose@ietf.org" , "ietf@ietf.org" , "iesg@ietf.org" , "draft-ietf-jose-json-web-signature.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-jose-json-web-signature-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 13:59:13 -0000 Mike Jones writes: > Tero - for your point "2) Hash inside "alg" and inside the > signature", could you please write proposed security considerations > text addressing this issue? I'd think it should describe the need > for implementations to ensure that signature verification is done > for the exact algorithm specified in the "alg" header parameter, no > matter what algorithm information may (or may not) have been encoded > into the signature value in an algorithm-specific manner. Something like this: In case of algorithms where there is algorithm parameters specified also inside the actual signature, the implementations MUST verify that the parameters inside the signature and the parameters specified by the "alg" Header Parameter match. This includes for example the RSASSA-PKCS-v1_5 algorithms ("RS*") where the signature contains the hash algorithm and most libraries actually use the hash algorithm specified inside the signature when verifying the signature. This test is required as the steps in the section 5.2 verify that algorithms specified by the "alg" Header Parameter are acceptable, and if those algorithms could be different the attacker could be able to claim to use strong hash algorithm while actually using weak one inside the signature. > For your point "3) There is no explicit warning about the "alg" > "none"", I plan to add the additional step that you suggested. In my text above I assumed you had already added step in section 5.2 to verify that "alg" is acceptable. > For your point "4) Thumbprint formats" if you or someone else wants > to define an additional thumbprint format for use in IoT contexts > (or any other contexts), I encourage you to write an Internet Draft > that does so, registering the new header parameter defined in the > JSON Web Signature and Encryption Header Parameters registry. That can of course be done, but I would have hoped the initial version of the specification would also be usable in the IoT context, where the use of raw public keys will most likely arise. -- kivinen@iki.fi From nobody Mon Sep 22 12:20:32 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDD2B1A1ACA; Mon, 22 Sep 2014 12:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 Ji_v1DFnBx3A; Mon, 22 Sep 2014 12:20:12 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0146.outbound.protection.outlook.com [65.55.169.146]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1811E1A1BD3; Mon, 22 Sep 2014 12:20:12 -0700 (PDT) Received: from DM2PR03CA0026.namprd03.prod.outlook.com (10.141.96.25) by BY1PR0301MB1207.namprd03.prod.outlook.com (25.161.203.156) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Mon, 22 Sep 2014 19:20:10 +0000 Received: from BN1AFFO11FD025.protection.gbl (2a01:111:f400:7c10::193) by DM2PR03CA0026.outlook.office365.com (2a01:111:e400:2428::25) with Microsoft SMTP Server (TLS) id 15.0.1029.13 via Frontend Transport; Mon, 22 Sep 2014 19:20:09 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD025.mail.protection.outlook.com (10.58.52.85) with Microsoft SMTP Server (TLS) id 15.0.1029.15 via Frontend Transport; Mon, 22 Sep 2014 19:20:09 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.23]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.03.0195.002; Mon, 22 Sep 2014 19:19:33 +0000 From: Mike Jones To: Tero Kivinen Thread-Topic: Secdir review of draft-ietf-jose-json-web-signature-31 Thread-Index: AQHPyDgrWdMUgOdf8EqNa4N9Ytbe4ZvzQwoggARGNkCADAcqAIAFVMkQgARgVwCAAFyUwA== Date: Mon, 22 Sep 2014 19:19:32 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BA6811A@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <21512.21725.209461.976375@fireball.kivinen.iki.fi> <4E1F6AAD24975D4BA5B16804296739439AEABA21@TK5EX14MBXC292.redmond.corp.microsoft.com> <21528.638.485017.482257@fireball.kivinen.iki.fi> <4E1F6AAD24975D4BA5B16804296739439BA5A04D@TK5EX14MBXC286.redmond.corp.microsoft.com> <21536.10026.506235.155913@fireball.kivinen.iki.fi> In-Reply-To: <21536.10026.506235.155913@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(199003)(189002)(51704005)(83322001)(2656002)(20776003)(44976005)(87936001)(92566001)(92726001)(19580395003)(84676001)(31966008)(85806002)(69596002)(79102003)(76176999)(97756001)(15975445006)(23726002)(66066001)(6806004)(55846006)(21056001)(99396002)(26826002)(64706001)(74662003)(81542003)(81342003)(81156004)(50466002)(47776003)(86362001)(46102003)(77096002)(77982003)(83072002)(95666004)(93886004)(76482002)(106116001)(110136001)(104016003)(33656002)(80022003)(74502003)(46406003)(68736004)(86612001)(106466001)(97736003)(230783001)(90102001)(85306004)(85852003)(107046002)(50986999)(54356999)(4396001)(120916001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0301MB1207; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0301MB1207; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 034215E98F Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/NjOB0d_YOUY-ag5C0OadxwHzGwE Cc: "jose@ietf.org" , "ietf@ietf.org" , "iesg@ietf.org" , "draft-ietf-jose-json-web-signature.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-jose-json-web-signature-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 19:20:16 -0000 >> For your point "4) Thumbprint formats" if you or someone else wants to=20 >> define an additional thumbprint format for use in IoT contexts (or any=20 >> other contexts), I encourage you to write an Internet Draft that does=20 >> so, registering the new header parameter defined in the JSON Web=20 >> Signature and Encryption Header Parameters registry. > > That can of course be done, but I would have hoped the initial version of= the specification would also be usable in the IoT context, where the use o= f raw public keys will most likely arise. If what you want is a thumbprint over a raw key, see the individual submiss= ion draft https://tools.ietf.org/html/draft-jones-jose-jwk-thumbprint-01, w= hich defines a method for doing this. The -01 version incorporates working= group feedback from Toronto. In Toronto, I'd asked whether the working gr= oup wanted to adopt it as a working group draft and a decision hasn't been = made on that yet. If this would be useful for IoT applications, that would= be good to know. -- Mike From nobody Mon Sep 22 18:29:55 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91D401A1BF6; Mon, 22 Sep 2014 18:29:49 -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, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 wJO1aoa-mVAh; Mon, 22 Sep 2014 18:29:47 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0719.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::719]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF3401A1B32; Mon, 22 Sep 2014 18:29:46 -0700 (PDT) Received: from CY1PR0301MB1210.namprd03.prod.outlook.com (25.161.212.144) by CY1PR0301MB1180.namprd03.prod.outlook.com (25.160.165.23) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Tue, 23 Sep 2014 01:29:18 +0000 Received: from CH1PR03CA010.namprd03.prod.outlook.com (10.255.156.155) by CY1PR0301MB1210.namprd03.prod.outlook.com (25.161.212.144) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Tue, 23 Sep 2014 01:29:16 +0000 Received: from BN1AFFO11FD005.protection.gbl (10.255.156.132) by CH1PR03CA010.outlook.office365.com (10.255.156.155) with Microsoft SMTP Server (TLS) id 15.0.1034.13 via Frontend Transport; Tue, 23 Sep 2014 01:29:15 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD005.mail.protection.outlook.com (10.58.52.65) with Microsoft SMTP Server (TLS) id 15.0.1029.15 via Frontend Transport; Tue, 23 Sep 2014 01:29:15 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.23]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.03.0195.002; Tue, 23 Sep 2014 01:28:36 +0000 From: Mike Jones To: Richard Barnes , Tero Kivinen Thread-Topic: [jose] Secdir review of draft-ietf-jose-json-web-signature-31 Thread-Index: AQHPyDgrWdMUgOdf8EqNa4N9Ytbe4ZvzQwoggArT4gCABW9RgIABPl2AgABFmwCAAFrAgIADfttQgAAuJgCAAB+JAIAAMAGAgAAVnoCAAHsMgIAAYd2AgAAGSYCAAg5/gIAA2IMAgAAELACAAMCY8A== Date: Tue, 23 Sep 2014 01:28:36 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BA6A6FA@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <21512.21725.209461.976375@fireball.kivinen.iki.fi> <4E1F6AAD24975D4BA5B16804296739439AE9DD47@TK5EX14MBXC292.redmond.corp.microsoft.com> <21527.63989.999440.801542@fireball.kivinen.iki.fi> <21529.16232.880915.215045@fireball.kivinen.iki.fi> <4E1F6AAD24975D4BA5B16804296739439BA59EB7@TK5EX14MBXC286.redmond.corp.microsoft.com> <03a601cfd460$f8d71d70$ea855850$@augustcellars.com> <03c701cfd483$d1cf45e0$756dd1a0$@augustcellars.com> <043a01cfd4f2$3df75ff0$b9e61fd0$@augustcellars.com> <457A8BF9-8CDF-43C8-8040-CB42BE110805@ve7jtb.com> <21536.9120.451498.905934@fireball.kivinen.iki.fi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439BA6A6FATK5EX14MBXC286r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(189002)(199003)(93886004)(44976005)(92726001)(16236675004)(31966008)(19580395003)(19300405004)(85306004)(86362001)(83322001)(6806004)(2656002)(10300001)(120916001)(76482002)(87936001)(19625215002)(92566001)(84326002)(84676001)(106116001)(106466001)(81156004)(95666004)(20776003)(80022003)(90102001)(74662003)(77096002)(85806002)(54356999)(66066001)(55846006)(97736003)(85852003)(86612001)(76176999)(64706001)(230783001)(107046002)(69596002)(26826002)(104016003)(33656002)(46102003)(15202345003)(21056001)(81542003)(79102003)(81342003)(512874002)(74502003)(77982003)(83072002)(71186001)(15975445006)(68736004)(99396002)(4396001)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB1210; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:;UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB1210; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0343AC1D30 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB1180; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/fMu9UTWgz7KK5jOWZjrse_wvcAQ Cc: "ietf@ietf.org" , secdir , Jim Schaad , IESG , "jose@ietf.org" , John Bradley , "draft-ietf-jose-json-web-signature.all@tools.ietf.org" Subject: Re: [secdir] [jose] Secdir review of draft-ietf-jose-json-web-signature-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 01:29:49 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439BA6A6FATK5EX14MBXC286r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TXkgY3VycmVudCBlZGl0b3LigJlzIGRyYWZ0IGNvbnRhaW5zIHRoZSBmb2xsb3dpbmcgc2VjdXJp dHkgY29uc2lkZXJhdGlvbnMgc3Vic2VjdGlvbiwgd2hpY2ggaXMgZGVyaXZlZCBmcm9tIFJpY2hh cmTigJlzIHByb3Bvc2VkIHRleHQuICBJ4oCZbSBzZW5kaW5nIGl0IG5vdyBmb3Igd29ya2luZyBn cm91cCByZXZpZXcsIHdpdGggdGhlIGludGVudCB0byBwdWJsaXNoIHVwZGF0ZWQgZHJhZnRzIGFk ZHJlc3NpbmcgYWxsIHRoZSBHZW4tQVJUIGFuZCBzZWNkaXIgY29tbWVudHMgcmVjZWl2ZWQsIHBv c3NpYmx5IGFzIGVhcmx5IGFzIHNvbWV0aW1lIHRvbW9ycm93Lg0KDQpUaGlzIHN1YnNlY3Rpb24g aXMgb3ZlciB0aHJlZSB0aW1lcyB0aGUgc2l6ZSBvZiBhbnkgb2YgdGhlIG90aGVyIHNlY3VyaXR5 IGNvbnNpZGVyYXRpb25zIHN1YnNlY3Rpb25zLiAgSXTigJlzIG15IGhvcGUsIGFzIGFuIGVkaXRv ciwgdGhhdCBwZW9wbGUgd2lsbCBzdWdnZXN0IHdheXMgdG8gZHJhc3RpY2FsbHkgc2hvcnRlbiBp dCwgd2hpbGUgcmV0YWluaW5nIHVuZGVyc3RhbmRhYmxlIGFuZCBhY3Rpb25hYmxlIGNvbnRlbnQs IGJlZm9yZSBJIHB1Ymxpc2ggYW4gdXBkYXRlZCBkcmFmdC4NCg0KSSBvYnZpb3VzbHkgaG9wZSB0 aGF0IHBlb3BsZSB3aWxsIGFsc28gcmV2aWV3IGl0IGZvciBjb3JyZWN0bmVzcy4NCg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFRoYW5rIHlvdSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCjEwLjcuICBBbGdvcml0aG0gUHJvdGVjdGlv bg0KDQpJbiBzb21lIHVzYWdlcyBvZiBKV1MsIHRoZXJlIGlzIGEgcmlzayBvZiBhbGdvcml0aG0g c3Vic3RpdHV0aW9uIGF0dGFja3MsIGluIHdoaWNoIGFuIGF0dGFja2VyIGNhbiB1c2UgYW4gZXhp c3Rpbmcgc2lnbmF0dXJlIHZhbHVlIHdpdGggYSBkaWZmZXJlbnQgc2lnbmF0dXJlIGFsZ29yaXRo bSB0byBtYWtlIGl0IGFwcGVhciB0aGF0IGEgc2lnbmVyIGhhcyBzaWduZWQgc29tZXRoaW5nIHRo YXQgaXQgaGFzIG5vdC4gVGhlc2UgYXR0YWNrcyBoYXZlIGJlZW4gZGlzY3Vzc2VkIGluIGRldGFp bCBpbiB0aGUgY29udGV4dCBvZiBDTVMgW1JGQzYyMTFdLiBUaGUgcmlzayBhcmlzZXMgd2hlbiBh bGwgb2YgdGhlIGZvbGxvd2luZyBhcmUgdHJ1ZToNCsK3ICAgICAgICAgVmVyaWZpZXJzIG9mIGEg c2lnbmF0dXJlIHN1cHBvcnQgbXVsdGlwbGUgYWxnb3JpdGhtcy4NCsK3ICAgICAgICAgR2l2ZW4g YW4gZXhpc3Rpbmcgc2lnbmF0dXJlLCBhbiBhdHRhY2tlciBjYW4gZmluZCBhbm90aGVyIHBheWxv YWQgdGhhdCBwcm9kdWNlcyB0aGUgc2FtZSBzaWduYXR1cmUgdmFsdWUgd2l0aCBhIGRpZmZlcmVu dCBhbGdvcml0aG0uDQrCtyAgICAgICAgIFRoZSBwYXlsb2FkIGNyYWZ0ZWQgYnkgdGhlIGF0dGFj a2VyIGlzIHZhbGlkIGluIHRoZSBhcHBsaWNhdGlvbiBjb250ZXh0Lg0KDQpGb3IgZXhhbXBsZSwg c3VwcG9zZSBhIHZlcmlmaWVyIGlzIHdpbGxpbmcgdG8gYWNjZXB0IGJvdGggUFMyNTYgYW5kIFBT Mzg0IGFzIGFsZyB2YWx1ZXMsIGFuZCBhIHNpZ25lciBjcmVhdGVzIGEgc2lnbmF0dXJlIHVzaW5n IFBTMjU2LiBJZiB0aGUgYXR0YWNrZXIgY2FuIGNyYWZ0IGEgcGF5bG9hZCB0aGF0IGhhcyB0aGUg c2FtZSBTSEEtMjU2IGRpZ2VzdCBhcyB0aGUgU0hBLTM4NCBkaWdlc3Qgb2YgdGhlIGxlZ2l0aW1h dGUgcGF5bG9hZCwgdGhlbiB0aGUgUFMyNTYgc2lnbmF0dXJlIG92ZXIgdGhlIGJvZ3VzIHBheWxv YWQgd2lsbCBiZSB0aGUgc2FtZSBhcyB0aGUgUFMzODQgc2lnbmF0dXJlIG92ZXIgdGhlIGxlZ2l0 aW1hdGUgcGF5bG9hZC4NCg0KVGhlcmUgYXJlIHNldmVyYWwgd2F5cyBmb3IgYW4gYXBwbGljYXRp b24gdG8gbWl0aWdhdGUgYWxnb3JpdGhtIHN1YnN0aXR1dGlvbiBhdHRhY2tzOg0KwrcgICAgICAg ICBEb24ndCBhY2NlcHQgc2lnbmF0dXJlcyB1c2luZyBhbGdvcml0aG1zIHZ1bG5lcmFibGUgdG8g c3Vic3RpdHV0aW9uIGF0dGFja3MuIEFsZ29yaXRobSBzdWJzdGl0dXRpb24gYXR0YWNrcyBhcmUg bm90IHBvc3NpYmxlIGZvciBhbGwgc2lnbmF0dXJlIGFsZ29yaXRobXMuIFRoZSBvbmx5IGFsZ29y aXRobXMgZGVmaW5lZCBpbiBKV0EgW0pXQV0gdGhhdCBtYXkgYmUgdnVsbmVyYWJsZSB0byBhbGdv cml0aG0gc3Vic3RpdHV0aW9uIGF0dGFja3MgYXJlIHRoZSBSU0FTU0EtUFNTIChQUzI1NiwgUFMz ODQsIGV0Yy4pIGFsZ29yaXRobXMuIEFuIGltcGxlbWVudGF0aW9uIHRoYXQgZG9lcyBub3Qgc3Vw cG9ydCBSU0FTU0EtUFNTIG9yIG90aGVyIHZ1bG5lcmFibGUgYWxnb3JpdGhtcyBpcyBub3Qgc3Vz Y2VwdGlibGUgdG8gYWxnb3JpdGhtIHN1YnN0aXR1dGlvbiBhdHRhY2tzLiBTdWJzdGl0dXRpb24g YXR0YWNrcyBhcmUgb25seSBmZWFzaWJsZSBpZiBhbiBhdHRhY2tlciBjYW4gY29tcHV0ZSBwcmUt aW1hZ2VzIGZvciBhIGhhc2ggZnVuY3Rpb24gYWNjZXB0ZWQgYnkgdGhlIHJlY2lwaWVudC4gQWxs IEpXQS1kZWZpbmVkIGFsZ29yaXRobXMgdXNlIFNIQS0yIGhhc2hlcywgZm9yIHdoaWNoIHRoZXJl IGFyZSBubyBrbm93biBwcmUtaW1hZ2UgYXR0YWNrcywgYXMgb2YgdGhlIHRpbWUgb2YgdGhpcyB3 cml0aW5nLiBVbnRpbCB0aGVyZSBhcmUgYXR0YWNrcyBhZ2FpbnN0IFNIQS0yIGhhc2hlcywgZXZl biBpbXBsZW1lbnRhdGlvbnMgdGhhdCBzdXBwb3J0IFJTQVNTQS1QU1MgYXJlIG5vdCBzdXNjZXB0 aWJsZSB0byBzdWJzdGl0dXRpb24gYXR0YWNrcy4NCsK3ICAgICAgICAgUmVxdWlyZSB0aGF0IHRo ZSBhbGcgSGVhZGVyIFBhcmFtZXRlciBiZSBjYXJyaWVkIGluIHRoZSBwcm90ZWN0ZWQgaGVhZGVy LiAoVGhpcyBpcyBhbHdheXMgdGhlIGNhc2Ugd2hlbiB1c2luZyB0aGUgSldTIENvbXBhY3QgU2Vy aWFsaXphdGlvbiBhbmQgaXMgdGhlIGFwcHJvYWNoIHRha2VuIGJ5IENNUyBbUkZDNjIxMV0uKQ0K wrcgICAgICAgICBJbmNsdWRlIGEgZmllbGQgY29udGFpbmluZyB0aGUgYWxnb3JpdGhtIGluIHRo ZSBhcHBsaWNhdGlvbiBwYXlsb2FkLCBhbmQgcmVxdWlyZSB0aGF0IGl0IGJlIG1hdGNoZWQgd2l0 aCB0aGUgYWxnIEhlYWRlciBQYXJhbWV0ZXIgZHVyaW5nIHZlcmlmaWNhdGlvbi4gKFRoaXMgaXMg dGhlIGFwcHJvYWNoIHRha2VuIGJ5IFBLSVggW1JGQzUyODBdLikNCg0K --_000_4E1F6AAD24975D4BA5B16804296739439BA6A6FATK5EX14MBXC286r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAg MCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFu b3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpU YWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpWZXJkYW5hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8q IFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNv Tm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpoMw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoiSGVhZGluZyAzIENoYXIi Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMy41 cHQ7DQoJZm9udC1mYW1pbHk6IkhlbHZldGljYSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMzMzMz MzM7DQoJZm9udC13ZWlnaHQ6Ym9sZDt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzsNCgltYXJnaW4tcmlnaHQ6MjQuMHB0Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjI0LjBwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KdHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6IzAwMzM2Njt9DQpzcGFuLkVtYWls U3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5IZWFkaW5nM0No YXINCgl7bXNvLXN0eWxlLW5hbWU6IkhlYWRpbmcgMyBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3Jp dHk6OTsNCgltc28tc3R5bGUtbGluazoiSGVhZGluZyAzIjsNCglmb250LWZhbWlseToiSGVsdmV0 aWNhIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzMzMzMzMzsNCglmb250LXdlaWdodDpib2xkO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8N CkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjEyNDg1ODIzNzsNCgltc28tbGlzdC10ZW1wbGF0ZS1p ZHM6LTExNzAzODE4Mjt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3Qt aWQ6OTkxMDU4MTg4Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotNzQ0MDc5NTMwO30NCkBsaXN0 IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZl bC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Ijt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTps ZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZl bDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDoxMjM5MDU0ODU4Ow0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczo2Nzk0OTIxMTQ7fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1z by1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwyOmxldmVsMw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwyOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwz DQoJe21zby1saXN0LWlkOjE2OTIxMDI4OTQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjg5NDA5 ODE5ODt9DQpAbGlzdCBsMzpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxl dmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDM6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEu NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDM6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2 ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw2DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDM6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw5 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwN Cgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5NeSBjdXJyZW50IGVkaXRvcuKAmXMgZHJhZnQgY29udGFpbnMgdGhlIGZvbGxvd2luZyBz ZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzdWJzZWN0aW9uLCB3aGljaCBpcyBkZXJpdmVkIGZyb20g UmljaGFyZOKAmXMgcHJvcG9zZWQgdGV4dC4mbmJzcDsgSeKAmW0gc2VuZGluZyBpdCBub3cgZm9y DQogd29ya2luZyBncm91cCByZXZpZXcsIHdpdGggdGhlIGludGVudCB0byBwdWJsaXNoIHVwZGF0 ZWQgZHJhZnRzIGFkZHJlc3NpbmcgYWxsIHRoZSBHZW4tQVJUIGFuZCBzZWNkaXIgY29tbWVudHMg cmVjZWl2ZWQsIHBvc3NpYmx5IGFzIGVhcmx5IGFzIHNvbWV0aW1lIHRvbW9ycm93LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+VGhpcyBzdWJzZWN0aW9uIGlzIG92ZXIgdGhyZWUgdGltZXMgdGhlIHNpemUgb2YgYW55IG9m IHRoZSBvdGhlciBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzdWJzZWN0aW9ucy4mbmJzcDsgSXTi gJlzIG15IGhvcGUsIGFzIGFuIGVkaXRvciwgdGhhdCBwZW9wbGUgd2lsbCBzdWdnZXN0DQogd2F5 cyB0byBkcmFzdGljYWxseSBzaG9ydGVuIGl0LCB3aGlsZSByZXRhaW5pbmcgdW5kZXJzdGFuZGFi bGUgYW5kIGFjdGlvbmFibGUgY29udGVudCwgYmVmb3JlIEkgcHVibGlzaCBhbiB1cGRhdGVkIGRy YWZ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+SSBvYnZpb3VzbHkgaG9wZSB0aGF0IHBlb3BsZSB3aWxsIGFsc28gcmV2 aWV3IGl0IGZvciBjb3JyZWN0bmVzcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBUaGFuayB5b3UsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8aDM+PHNwYW4gbGFuZz0iRU4iPjEwLjcuJm5ic3A7IEFs Z29yaXRobSBQcm90ZWN0aW9uPG86cD48L286cD48L3NwYW4+PC9oMz4NCjxwPjxzcGFuIGxhbmc9 IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5JbiBzb21lIHVzYWdlcyBvZiBKV1MsIHRoZXJlIGlzIGEg cmlzayBvZiBhbGdvcml0aG0gc3Vic3RpdHV0aW9uIGF0dGFja3MsIGluIHdoaWNoIGFuIGF0dGFj a2VyIGNhbiB1c2UgYW4gZXhpc3Rpbmcgc2lnbmF0dXJlIHZhbHVlIHdpdGggYSBkaWZmZXJlbnQg c2lnbmF0dXJlIGFsZ29yaXRobSB0byBtYWtlIGl0IGFwcGVhcg0KIHRoYXQgYSBzaWduZXIgaGFz IHNpZ25lZCBzb21ldGhpbmcgdGhhdCBpdCBoYXMgbm90LiBUaGVzZSBhdHRhY2tzIGhhdmUgYmVl biBkaXNjdXNzZWQgaW4gZGV0YWlsIGluIHRoZSBjb250ZXh0IG9mIENNUyBbUkZDNjIxMV0uIFRo ZSByaXNrIGFyaXNlcyB3aGVuIGFsbCBvZiB0aGUgZm9sbG93aW5nIGFyZSB0cnVlOg0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21hcmdpbi1yaWdodDoyNC4wcHQ7bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bWFyZ2luLWxlZnQ6NjAuMHB0O3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMyBsZXZl bDEgbGZvMyI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOmJsYWNrIj48c3BhbiBzdHls ZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4i IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPlZlcmlmaWVycyBvZiBhIHNpZ25hdHVyZSBzdXBwb3J0IG11bHRp cGxlIGFsZ29yaXRobXMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLXJpZ2h0OjI0LjBwdDtt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo2MC4wcHQ7dGV4dC1pbmRlbnQ6 LS4yNWluO21zby1saXN0OmwzIGxldmVsMSBsZm8zIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxz cGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2w7 Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9 ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwh W2VuZGlmXT48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+R2l2ZW4gYW4gZXhpc3Rp bmcgc2lnbmF0dXJlLCBhbiBhdHRhY2tlciBjYW4gZmluZCBhbm90aGVyIHBheWxvYWQgdGhhdCBw cm9kdWNlcyB0aGUgc2FtZSBzaWduYXR1cmUgdmFsdWUgd2l0aCBhIGRpZmZlcmVudCBhbGdvcml0 aG0uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLXJpZ2h0OjI0LjBwdDttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo2MC4wcHQ7dGV4dC1pbmRlbnQ6LS4yNWluO21zby1s aXN0OmwzIGxldmVsMSBsZm8zIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVO IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6YmxhY2si PjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQg JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3Bh biBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VGhlIHBheWxvYWQgY3JhZnRlZCBieSB0aGUg YXR0YWNrZXIgaXMgdmFsaWQgaW4gdGhlIGFwcGxpY2F0aW9uIGNvbnRleHQuDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Rm9yIGV4 YW1wbGUsIHN1cHBvc2UgYSB2ZXJpZmllciBpcyB3aWxsaW5nIHRvIGFjY2VwdCBib3RoDQo8L3Nw YW4+PHR0PjxzcGFuIGxhbmc9IkVOIj5QUzI1Njwvc3Bhbj48L3R0PjxzcGFuIGxhbmc9IkVOIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj4gYW5kDQo8L3NwYW4+PHR0PjxzcGFuIGxhbmc9IkVOIj5QUzM4NDwv c3Bhbj48L3R0PjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFu YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4gYXMNCjwvc3Bhbj48 dHQ+PHNwYW4gbGFuZz0iRU4iPmFsZzwvc3Bhbj48L3R0PjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj4gdmFsdWVzLCBhbmQgYSBzaWduZXIgY3JlYXRlcyBhIHNpZ25hdHVyZSB1c2lu Zw0KPC9zcGFuPjx0dD48c3BhbiBsYW5nPSJFTiI+UFMyNTY8L3NwYW4+PC90dD48c3BhbiBsYW5n PSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+LiBJZiB0aGUgYXR0YWNrZXIgY2FuIGNyYWZ0IGEgcGF5 bG9hZCB0aGF0IGhhcyB0aGUgc2FtZSBTSEEtMjU2IGRpZ2VzdCBhcyB0aGUgU0hBLTM4NCBkaWdl c3Qgb2YgdGhlIGxlZ2l0aW1hdGUgcGF5bG9hZCwgdGhlbiB0aGUNCjwvc3Bhbj48dHQ+PHNwYW4g bGFuZz0iRU4iPlBTMjU2PC9zcGFuPjwvdHQ+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPiBzaWduYXR1cmUgb3ZlciB0aGUgYm9ndXMgcGF5bG9hZCB3aWxsIGJlIHRoZSBzYW1lIGFz IHRoZQ0KPC9zcGFuPjx0dD48c3BhbiBsYW5nPSJFTiI+UFMzODQ8L3NwYW4+PC90dD48c3BhbiBs YW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+IHNpZ25hdHVyZSBvdmVyIHRoZSBsZWdpdGltYXRl IHBheWxvYWQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTiIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+VGhlcmUgYXJlIHNldmVyYWwgd2F5cyBmb3IgYW4gYXBwbGljYXRpb24g dG8gbWl0aWdhdGUgYWxnb3JpdGhtIHN1YnN0aXR1dGlvbiBhdHRhY2tzOg0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21hcmdpbi1yaWdodDoyNC4wcHQ7bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFy Z2luLWxlZnQ6NjAuMHB0O3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZv NCI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNv LWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4iIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPkRvbid0IGFjY2VwdCBzaWduYXR1cmVzIHVzaW5nIGFsZ29yaXRobXMgdnVs bmVyYWJsZSB0byBzdWJzdGl0dXRpb24gYXR0YWNrcy4gQWxnb3JpdGhtIHN1YnN0aXR1dGlvbiBh dHRhY2tzIGFyZSBub3QgcG9zc2libGUgZm9yIGFsbCBzaWduYXR1cmUgYWxnb3JpdGhtcy4NCiBU aGUgb25seSBhbGdvcml0aG1zIGRlZmluZWQgaW4gSldBIFtKV0FdIHRoYXQgbWF5IGJlIHZ1bG5l cmFibGUgdG8gYWxnb3JpdGhtIHN1YnN0aXR1dGlvbiBhdHRhY2tzIGFyZSB0aGUgUlNBU1NBLVBT UyAoPC9zcGFuPjx0dD48c3BhbiBsYW5nPSJFTiI+UFMyNTY8L3NwYW4+PC90dD48c3BhbiBsYW5n PSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+LA0KPC9zcGFuPjx0dD48c3BhbiBsYW5nPSJFTiI+UFMz ODQ8L3NwYW4+PC90dD48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Zl cmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+LCBldGMuKSBh bGdvcml0aG1zLiBBbiBpbXBsZW1lbnRhdGlvbiB0aGF0IGRvZXMgbm90IHN1cHBvcnQgUlNBU1NB LVBTUyBvciBvdGhlciB2dWxuZXJhYmxlIGFsZ29yaXRobXMgaXMgbm90IHN1c2NlcHRpYmxlIHRv IGFsZ29yaXRobSBzdWJzdGl0dXRpb24NCiBhdHRhY2tzLiBTdWJzdGl0dXRpb24gYXR0YWNrcyBh cmUgb25seSBmZWFzaWJsZSBpZiBhbiBhdHRhY2tlciBjYW4gY29tcHV0ZSBwcmUtaW1hZ2VzIGZv ciBhIGhhc2ggZnVuY3Rpb24gYWNjZXB0ZWQgYnkgdGhlIHJlY2lwaWVudC4gQWxsIEpXQS1kZWZp bmVkIGFsZ29yaXRobXMgdXNlIFNIQS0yIGhhc2hlcywgZm9yIHdoaWNoIHRoZXJlIGFyZSBubyBr bm93biBwcmUtaW1hZ2UgYXR0YWNrcywgYXMgb2YgdGhlIHRpbWUgb2YgdGhpcyB3cml0aW5nLg0K IFVudGlsIHRoZXJlIGFyZSBhdHRhY2tzIGFnYWluc3QgU0hBLTIgaGFzaGVzLCBldmVuIGltcGxl bWVudGF0aW9ucyB0aGF0IHN1cHBvcnQgUlNBU1NBLVBTUyBhcmUgbm90IHN1c2NlcHRpYmxlIHRv IHN1YnN0aXR1dGlvbiBhdHRhY2tzLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1yaWdodDoy NC4wcHQ7bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NjAuMHB0O3RleHQt aW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvNCI+DQo8IVtpZiAhc3VwcG9ydExp c3RzXT48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 U3ltYm9sO2NvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFu IHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwv c3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtW ZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlJlcXVpcmUg dGhhdCB0aGUNCjwvc3Bhbj48dHQ+PHNwYW4gbGFuZz0iRU4iPmFsZzwvc3Bhbj48L3R0PjxzcGFu IGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4gSGVhZGVyIFBhcmFtZXRlciBiZSBjYXJyaWVk IGluIHRoZSBwcm90ZWN0ZWQgaGVhZGVyLiAoVGhpcyBpcyBhbHdheXMgdGhlIGNhc2Ugd2hlbiB1 c2luZyB0aGUgSldTIENvbXBhY3QgU2VyaWFsaXphdGlvbiBhbmQgaXMgdGhlIGFwcHJvYWNoIHRh a2VuDQogYnkgQ01TIFtSRkM2MjExXS4pIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tcmlnaHQ6 MjQuMHB0O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjYwLjBwdDt0ZXh0 LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzQiPg0KPCFbaWYgIXN1cHBvcnRM aXN0c10+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OlN5bWJvbDtjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3Bh biBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48 L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5JbmNsdWRl IGEgZmllbGQgY29udGFpbmluZyB0aGUgYWxnb3JpdGhtIGluIHRoZSBhcHBsaWNhdGlvbiBwYXls b2FkLCBhbmQgcmVxdWlyZSB0aGF0IGl0IGJlIG1hdGNoZWQgd2l0aCB0aGUNCjwvc3Bhbj48dHQ+ PHNwYW4gbGFuZz0iRU4iPmFsZzwvc3Bhbj48L3R0PjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj4gSGVhZGVyIFBhcmFtZXRlciBkdXJpbmcgdmVyaWZpY2F0aW9uLiAoVGhpcyBpcyB0 aGUgYXBwcm9hY2ggdGFrZW4gYnkgUEtJWCBbUkZDNTI4MF0uKQ0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9iPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4E1F6AAD24975D4BA5B16804296739439BA6A6FATK5EX14MBXC286r_-- From nobody Tue Sep 23 02:18:15 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 033751A6FBB; Tue, 23 Sep 2014 02:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_NEUTRAL=0.779] autolearn=ham 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 gC5Ad2x7NIOd; Tue, 23 Sep 2014 02:18:04 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 20D751A6FA0; Tue, 23 Sep 2014 02:18:03 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s8N9Hx83004757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 23 Sep 2014 12:17:59 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s8N9Hw1v016628; Tue, 23 Sep 2014 12:17:58 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21537.15046.788802.440800@fireball.kivinen.iki.fi> Date: Tue, 23 Sep 2014 12:17:58 +0300 From: Tero Kivinen To: Mike Jones In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BA6811A@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <21512.21725.209461.976375@fireball.kivinen.iki.fi> <4E1F6AAD24975D4BA5B16804296739439AEABA21@TK5EX14MBXC292.redmond.corp.microsoft.com> <21528.638.485017.482257@fireball.kivinen.iki.fi> <4E1F6AAD24975D4BA5B16804296739439BA5A04D@TK5EX14MBXC286.redmond.corp.microsoft.com> <21536.10026.506235.155913@fireball.kivinen.iki.fi> <4E1F6AAD24975D4BA5B16804296739439BA6811A@TK5EX14MBXC286.redmond.corp.microsoft.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 19 min X-Total-Time: 21 min Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/SmscKfQhFjQtl3wjgj_4LTUR7qI Cc: "jose@ietf.org" , "ietf@ietf.org" , "iesg@ietf.org" , "draft-ietf-jose-json-web-signature.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-jose-json-web-signature-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 09:18:07 -0000 Mike Jones writes: > >> For your point "4) Thumbprint formats" if you or someone else wants to > >> define an additional thumbprint format for use in IoT contexts (or any > >> other contexts), I encourage you to write an Internet Draft that does > >> so, registering the new header parameter defined in the JSON Web > >> Signature and Encryption Header Parameters registry. > > > > That can of course be done, but I would have hoped the initial > > version of the specification would also be usable in the IoT > > context, where the use of raw public keys will most likely arise. > > If what you want is a thumbprint over a raw key, see the individual > submission draft > https://tools.ietf.org/html/draft-jones-jose-jwk-thumbprint-01, > which defines a method for doing this. The -01 version incorporates > working group feedback from Toronto. In Toronto, I'd asked whether > the working group wanted to adopt it as a working group draft and a > decision hasn't been made on that yet. If this would be useful for > IoT applications, that would be good to know. That looks ok for the jwk use, but for the hash over the SPKI parts of the X.509 is better because that is already used in other places. I.e. if you want to create fingerprint that can be used to match the key used in other protocols, they are not using that format defined in your draft, thus you need to regenerate the JWK format from their internal public/private key formats and generate new hash. For example DANE x 1 x format (i.e. 3 1 1 for SHA-256, or 3 1 2 for SHA-512) defined RFC6698 section 2.1.3 are calculated over the exact same binary object which is transmitted in the raw keys used in the TLS (RFC7250 section 3), which is again same binary object used in the in the IKEv2 (draft-kivinen-ipsecme-oob-pubkey). In the IoT context it will most likely be quite common to define the configuration of who can connect to you by using list of hashes of raw public keys. I.e. the device has list of hashes, and when connection comes (either over TLS or IKEv2 or whatever), then that raw public key sent inside the connection protocol is hashed and it is matched against that list of hashes. If match is found, the connection is allowed, if not the connection is dropped. Now json might be one way of this configuration could be transmitted to the IoT device, thus ability to be able to represent hashes in the format that makes it possible to match the binary blobs used on the wire, would be useful. One of the reasons the SPKI is used, that it can also be extracted from the self-signed certificate, i.e. early implementations might use self-signed certificates in the TLS (for example) before the RFC7250 implementations come out. The draft-jones-jose-jwk-thumbprint format is in such format that it is quite hard to match that against the binary blob we get from the wire, as to do so would require to format the public key received to JWK and then calculating the fingerprint of that newly created object. Parsing SPKI format (and parsing JSON also if we use that for configurations) is required in the implementations anyways, but in normal case the IoT devices do not need code for generating JSON objects. So I do not think the format you are specifying there is suitable for IoT uses, but I assume it will still be useful in the JWK in general. -- kivinen@iki.fi From nobody Tue Sep 23 06:46:58 2014 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DCDB31A8546; Tue, 23 Sep 2014 06:36:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1411479367; bh=Ty5uMymEPxzijrcyoFgq+elMpr5Ur2sVfWu279sz/Hw=; h=From:Date:To:Message-Id:Mime-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=QFWAp8y2TC0OwhIActQbLbjTifGHzA1bciixkrVESnyHjYgosvQ/SoGU8LtJOF+S7 xbe6adSMLhQdAbVfAj9zOZe64RoZf2nYu2QB0qDeIWlLTfDq/z5flEQinF4MKjx6X+ hz0hgmZW/gHiK8jHx7oX3xEHPB/ZBwQMbSN1Fypg= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB1DE1A8028 for ; Tue, 23 Sep 2014 06:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.988 X-Spam-Level: X-Spam-Status: No, score=-4.988 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 ttp0cs3k1n5z for ; Tue, 23 Sep 2014 06:36:01 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E7E61A802F for ; Tue, 23 Sep 2014 06:36:01 -0700 (PDT) Received: from 205-178-89-72.c3-0.nwb-ubr1.chi-nwb.il.cable.rcn.com ([205.178.89.72] helo=[192.168.1.100]) by jay.w3.org with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1XWQG8-00054r-4E; Tue, 23 Sep 2014 09:36:00 -0400 From: Ian Jacobs Date: Tue, 23 Sep 2014 08:35:58 -0500 To: "new-work@ietf.org" Message-Id: <1BCD3BE9-4196-4DC1-B66B-1FEA3C011950@w3.org> Mime-Version: 1.0 (Mac OS X Mail 6.6 $1510$) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/new-work/G7xv1R1TOeJTmo0m-tpEklgjo0U X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/OSOzJp-d573CIUqBVpR4s4J2qJ8 X-Mailman-Approved-At: Tue, 23 Sep 2014 06:46:57 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Scalable Vector Graphics Working Group (until 2014-10-20) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 13:36:08 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the Graphics Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the Scalable Vector Graphics Working Group: http://www.w3.org/Graphics/SVG/2014/charter As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2014-10-20 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [2], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Chris Lilley, Graphics Activity Lead . Thank you, Ian Jacobs, Head of W3C Communications [0] http://www.w3.org/Graphics/ [1] http://www.w3.org/2014/Process-20140801/#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Ian Jacobs http://www.w3.org/People/Jacobs Tel: +1 718 260 9447 _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Tue Sep 23 15:51:29 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5750B1A1BB0; Tue, 23 Sep 2014 15:51:24 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 3kg1zLtjp1sZ; Tue, 23 Sep 2014 15:51:22 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0102.outbound.protection.outlook.com [65.55.169.102]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D093E1A1B3F; Tue, 23 Sep 2014 15:51:21 -0700 (PDT) Received: from BN3PR0301CA0081.namprd03.prod.outlook.com (25.160.152.177) by DM2PR0301MB1214.namprd03.prod.outlook.com (25.160.219.155) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Tue, 23 Sep 2014 22:51:24 +0000 Received: from BL2FFO11FD049.protection.gbl (2a01:111:f400:7c09::122) by BN3PR0301CA0081.outlook.office365.com (2a01:111:e400:401e::49) with Microsoft SMTP Server (TLS) id 15.0.1034.13 via Frontend Transport; Tue, 23 Sep 2014 22:51:20 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD049.mail.protection.outlook.com (10.173.161.211) with Microsoft SMTP Server (TLS) id 15.0.1029.15 via Frontend Transport; Tue, 23 Sep 2014 22:51:20 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.23]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.03.0195.002; Tue, 23 Sep 2014 22:51:09 +0000 From: Mike Jones To: "jose@ietf.org" Thread-Topic: JOSE -32 and JWT -26 drafts addressing IETF Last Call comments Thread-Index: Ac/XgNa19S8xdv/2R86jWszcWuzHlw== Date: Tue, 23 Sep 2014 22:51:08 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BA6EB43@TK5EX14MBXC286.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.78] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439BA6EB43TK5EX14MBXC286r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(438002)(199003)(189002)(87936001)(15975445006)(2656002)(106466001)(81156004)(95666004)(21056001)(4396001)(97736003)(85306004)(19300405004)(69596002)(84676001)(120916001)(55846006)(19580395003)(68736004)(84326002)(6806004)(44976005)(81542003)(46102003)(2501002)(80022003)(104016003)(83322001)(74502003)(81342003)(19617315012)(90102001)(79102003)(110136001)(50986999)(54356999)(15202345003)(71186001)(229853001)(107046002)(512954002)(2351001)(16297215004)(77982003)(99396002)(66066001)(86362001)(16236675004)(19625215002)(92726001)(85852003)(76482002)(83072002)(33656002)(31966008)(74662003)(77096002)(64706001)(20776003)(86612001)(92566001)(10300001)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB1214; H:mail.microsoft.com; FPR:; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB1214; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0343AC1D30 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/NkaLfP5y3MHQwhAYhkECFAmfBow Cc: Roni Even , "ietf@ietf.org" , "secdir@ietf.org" , "gen-art@ietf.org" Subject: [secdir] JOSE -32 and JWT -26 drafts addressing IETF Last Call comments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 22:51:24 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439BA6EB43TK5EX14MBXC286r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable New versions of the JSON Object Signing and Encryption (JOSE) and JSON Web = Token (JWT) specifications have been published incorporating feedback recei= ved in IETF Last Call comments. Thanks to Russ Housley and Roni Even for t= heir Gen-ART reviews, to Tero Kivinen, Scott Kelly, Stephen Kent, Charlie K= aufman, and Warren Kumari for their secdir reviews, to Tom Yu for his indiv= idual review, and to James Manger and Chuck Mortimore who provided feedback= based on deployment experiences, as well as to the many JOSE and OAuth wor= king group members who pitched in to discuss resolutions. Many clarificati= ons resulted. No breaking changes were made. The specifications are available at: * http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-32 * http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-32 * http://tools.ietf.org/html/draft-ietf-jose-json-web-key-32 * http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-32 * http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-26 HTML formatted versions are available at: * http://self-issued.info/docs/draft-ietf-jose-json-web-signature-3= 2.html * http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-= 32.html * http://self-issued.info/docs/draft-ietf-jose-json-web-key-32.html * http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-= 32.html * http://self-issued.info/docs/draft-ietf-oauth-json-web-token-26.h= tml -- Mike P.S. This notice was also posted at http://self-issued.info/?p=3D1284 and a= s @selfissued. --_000_4E1F6AAD24975D4BA5B16804296739439BA6EB43TK5EX14MBXC286r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

New versions of the JSON Object Signing and Encrypti= on (JOSE) and JSON Web Token (JWT) specifications have been published incor= porating feedback received in IETF Last Call comments. Thanks to Russ= Housley and Roni Even for their Gen-ART reviews, to Tero Kivinen, Scott Kelly, Stephen Kent, Charlie Kaufman, and = Warren Kumari for their secdir reviews, to Tom Yu for his individual review= , and to James Manger and Chuck Mortimore who provided feedback based on de= ployment experiences, as well as to the many JOSE and OAuth working group members who pitched in to discuss= resolutions. Many clarifications resulted. No breaking changes= were made.

The specifications are available at:

· http://tools.ietf.org/html/draft-ietf-jose= -json-web-signature-32

· http://tools.ietf.org/html/draft-ietf-jos= e-json-web-encryption-32

· http://tools.ietf.org/html/draft-ietf-jose-json-= web-key-32

· http://tools.ietf.org/html/draft-ietf-jos= e-json-web-algorithms-32

· http://tools.ietf.org/html/draft-ietf-oauth-j= son-web-token-26

HTML formatted versions are available at:=

· http://self-issued.info/docs/draft-= ietf-jose-json-web-signature-32.html

· http://self-issued.info/docs/draft= -ietf-jose-json-web-encryption-32.html

· http://self-issued.info/docs/draft-ietf-j= ose-json-web-key-32.html

· http://self-issued.info/docs/draft= -ietf-jose-json-web-algorithms-32.html

· http://self-issued.info/docs/draft-iet= f-oauth-json-web-token-26.html

&nbs= p; &= nbsp; &nbs= p; &= nbsp; &nbs= p; -- Mike

P.S. This notice was also posted at http://self-issued.info/?p=3D1284 and as @selfissued.

--_000_4E1F6AAD24975D4BA5B16804296739439BA6EB43TK5EX14MBXC286r_-- From nobody Tue Sep 23 16:08:41 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C70981A891B; Tue, 23 Sep 2014 16:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 QHLD_iClh8Ky; Tue, 23 Sep 2014 16:08:35 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0103.outbound.protection.outlook.com [207.46.100.103]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0645E1A895E; Tue, 23 Sep 2014 16:08:34 -0700 (PDT) Received: from CO2PR03CA0051.namprd03.prod.outlook.com (10.141.194.178) by CY1PR0301MB1212.namprd03.prod.outlook.com (25.161.212.146) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Tue, 23 Sep 2014 23:08:33 +0000 Received: from BN1AFFO11FD059.protection.gbl (2a01:111:f400:7c10::134) by CO2PR03CA0051.outlook.office365.com (2a01:111:e400:1414::50) with Microsoft SMTP Server (TLS) id 15.0.1034.13 via Frontend Transport; Tue, 23 Sep 2014 23:08:12 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD059.mail.protection.outlook.com (10.58.53.74) with Microsoft SMTP Server (TLS) id 15.0.1029.15 via Frontend Transport; Tue, 23 Sep 2014 23:08:11 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.23]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.03.0195.002; Tue, 23 Sep 2014 23:07:31 +0000 From: Mike Jones To: Charlie Kaufman , "secdir@ietf.org" Thread-Topic: Secdir review of draft-ietf-jose-json-web-algorithms-31 Thread-Index: Ac/EILVlvaO6koWmSBq1KV+ptV1KBQC8PqQwBBxUMCA= Date: Tue, 23 Sep 2014 23:07:30 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BA6EF7C@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739439AE76076@TK5EX14MBXC294.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439AE76076@TK5EX14MBXC294.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.78] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439BA6EF7CTK5EX14MBXC286r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(438002)(377454003)(51914003)(199003)(189002)(77982003)(4396001)(31966008)(74502003)(92566001)(95666004)(46102003)(86362001)(74662003)(68736004)(69596002)(92726001)(77096002)(85852003)(81542003)(76482002)(83072002)(81342003)(97736003)(80022003)(15975445006)(79102003)(19580395003)(10300001)(120916001)(2501002)(6806004)(19580405001)(85306004)(21056001)(107046002)(90102001)(19617315012)(44976005)(512954002)(81156004)(19300405004)(85806002)(551984002)(66066001)(106466001)(2656002)(76176999)(16236675004)(20776003)(84326002)(15202345003)(99396002)(104016003)(83322001)(19625215002)(64706001)(55846006)(87936001)(54356999)(86612001)(33656002)(84676001)(551544002)(50986999)(230783001)(71186001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB1212; H:mail.microsoft.com; FPR:; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB1212; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0343AC1D30 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/kB4McbPpZXbkOYyIrUgVW_DQmGA Cc: "iesg@ietf.org" , "jose@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-jose-json-web-algorithms-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 23:08:39 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439BA6EF7CTK5EX14MBXC286r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks again for your review, Charlie. The proposed resolutions below have= been applied in the -32 draft. -- Mike From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones Sent: Tuesday, September 02, 2014 6:39 PM To: Charlie Kaufman; secdir@ietf.org Cc: draft-ietf-jose-json-web-algorithms.all@tools.ietf.org; iesg@ietf.org; = jose@ietf.org Subject: Re: [jose] Secdir review of draft-ietf-jose-json-web-algorithms-31 Thanks for the useful review, Charlie. Responses and proposed resolutions = follow inline. Working group - please review. From: Charlie Kaufman [mailto:charliekaufman@outlook.com] Sent: Saturday, August 30, 2014 12:12 AM To: secdir@ietf.org Cc: draft-ietf-jose-json-web-algorithms.all@tools.ietf.org; iesg@ietf.org Subject: Secdir review of draft-ietf-jose-json-web-algorithms-31 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. This document sets the initial IANA registry values for the labels to be us= ed to specify choices of cryptographic algorithms in the context of the JSO= N Web Encryption, JSON Web Signature, and JSON Web Key documents (parallel = I-Ds). Some aspects of how the algorithms are used are specified here; othe= rs aspects reference other documents. The issues I found with this document (all of which are minor): Section 3.4 line 4 says Elliptic Curves are generally faster to execute (fo= r equivalent security) than RSA. While that is true for private key operati= ons (and even more dramatically so for key generation), it is generally not= true for public key operations. This is a nit in the text since these trad= e-offs are well understood. What if we were to change the phrase "with greater processing speed" to "wi= th greater processing speed for many operations"? Section 4.5 Direct Encryption: It might be too late to change existing impl= ementations, but it generally a good idea when using pre-negotiated keys to= include some key identifier in the header to remove ambiguity in the case = where there are multiple pre-negotiated keys (perhaps because they are in t= he process of being updated and they are not atomically updated on both end= s of the connection). The "kid" (Key ID) header parameter defined in the JWE spec already enables= this to be done. Section 5.1: I don't believe the pairings of AES128/HMAC-SHA256, AES192/HMA= C-SHA384, and AES256/HMAC-SHA512 are "natural" in the sense of providing eq= uivalent cryptographic strength. Without the HMAC, they would, but I believ= e HMAC-SHA256 is generally believed to have 256 bits of cryptographic stren= gth, making it suitable for pairing with any of the three AES key sizes. Th= e choices of the longer SHA2 variants are conservative, however, and so do = no harm if these pairings are already in widespread use. They are in use and are the pairings chosen by David McGrew, a just departe= d CRFG chair, and Kenny Paterson, a current CRFG chair, in draft-mcgrew-aea= d-aes-cbc-hmac-sha2. Section 5.2: Similarly, it is not appropriate to have the length of the Mes= sage Authentication Code (MAC) reflect the key length, since it does not af= fect cryptographic strength but rather the strength against on-line MAC gue= ssing attacks. For this purpose, 128 bits is generally considered adequate = for all key sizes and many implementations truncate this to 96 bits or even= 64. Again, the current specification is conservative (if slightly wasteful= of bandwidth), and so does not harm if this is already in widespread use. (Same answer as to the previous comment) Section 5.2.2.1 says "The number of octets in the input key K is the sum of= MAC_KEY_LEN and ENC_KEY_LEN." I believe it would be better to say somethin= g like "MUST BE the sum". The text goes on to say that the two keys must no= t overlap, but it is also important that an implementation not tolerate a g= ap between the two keys is a too large key is provided. OK Section 5.2.2.2 says the authenticated decryption operation has four inputs= ... . I believe it has a fifth: the IV. Alternately, the IV is pre-pended t= o the ciphertext (and hence implicitly included in 'E'). Agreed the IV is a fifth input. I'll make this change. Section 5.3 specifies AES/GCM in much less detail than the description of A= ES/HMAC in Section 5.2. Is this because the referenced document [NIST.800-3= 8D] includes all the needed details (like use of PKCS7 padding)? Yes Section 6.2.1.1: Because of the controversy over NSA allegedly planting bac= kdoors in the "NIST curves" listed, there is a growing demand that addition= al curves be supported. You might want to specify how additional curves can= be specified in-line and/or how to get additional curves added to the IANA= registry. Agreed. We can tweak the IANA language in this section (and possibly other= s using similar language) to be clearer on this point. Section 8.7: I believe the advice in this section is too strong. It is gene= rally considered secure to encrypt multiple data sets with the same key so = long as the IV is correctly chosen and it is also generally considered secu= re to encrypt the same data set with multiple different keys. There are man= y scenarios in which this is nearly impossible to avoid. It is important th= at when encryption multiple data sets with the same key that the IV be chos= en appropriately - which is very challenging when using GCM as noted in sec= tion 8.4. The current language was added to resolve issue #28 http://trac.tools.ietf.= org/wg/jose/trac/ticket/28 and is a result of a good bit of discussion with= Michael Peck, Jim Schaad, and others in the working group on the JOSE mail= ing list between June 2013 and August 2013, with the issue being closed by = Jim in October 2013. I recognize that of the problem here is that the security considerations ac= tually vary by algorithm and yet this subsection is trying to provide gener= al guidance. Is there a specific wording change that you'd like to propose that would we= aken the advice when it's OK to weaken it, but not in any other circumstanc= es? Section 8.8: I believe the advice in this section is too weak. It is genera= lly bad practice to derive cryptographic keys from passwords as passwords a= lmost never have adequate entropy. Where possible, it would be better to ha= ve a strong (i.e. randomly chosen) cryptographic key associated with an ent= ity and then use the password to acquire that cryptographic key. There are = a number of means for doing that, including having the strong key encrypted= with the password (or XORed with it) stored someplace the entity can acces= s it, by having a server that will return the key based on a provided passw= ord, or with a strong password authentication protocol. Deriving the key fr= om a password using PBES should be a last resort and demanding a longer pas= sword to derive a 256 bit key is only fooling yourself... you are never lik= ely to get more than 64 bits of entropy. Note that password-based encryption, as used by this specification, does em= ploy a randomly chosen content encryption key, and uses the password-based = encryption only to encrypt the CEK. Does that alleviate your concerns? If= not, could you supply specific proposed wording changes that would? --Charlie Thanks agai= n, -- Mike --_000_4E1F6AAD24975D4BA5B16804296739439BA6EF7CTK5EX14MBXC286r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks again for your = review, Charlie. The proposed resolutions below have been applied in = the -32 draft.

&nbs= p; &= nbsp; &nbs= p; &= nbsp; &nbs= p; -- Mike=

From: jose [ma= ilto:jose-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Tuesday, September 02, 2014 6:39 PM
To: Charlie Kaufman; secdir@ietf.org
Cc: draft-ietf-jose-json-web-algorithms.all@tools.ietf.org; iesg@iet= f.org; jose@ietf.org
Subject: Re: [jose] Secdir review of draft-ietf-jose-json-web-algori= thms-31

Thanks for the useful = review, Charlie. Responses and proposed resolutions follow inline.&nb= sp; Working group – please review.

From: Charlie = Kaufman [mailto:charliekaufma= n@outlook.com]
Sent: Saturday, August 30, 2014 12:12 AM
To: secdir@ietf.org
Cc: draft-ietf-jose-json-web-algorithms.all@tools.ietf.org; iesg@ietf.org
Subject: Secdir review of draft-ietf-jose-json-web-algorithms-31

The issues I found with this document (all of which = are minor):

What if we were to cha= nge the phrase “with greater processing spee= d” to “with greater processing speed for many operations”?

The “kid” = (Key ID) header parameter defined in the JWE spec already enables this to b= e done.

They are in use and ar= e the pairings chosen by David McGrew, a just departed CRFG chair, and Kenn= y Paterson, a current CRFG chair, in draft-mcgrew-aead-aes-cbc-hmac-sha2.

(Same answer as to the= previous comment)

Agreed the IV is a fif= th input. I’ll make this change.

Yes<= /p>

Agreed. We can t= weak the IANA language in this section (and possibly others using similar l= anguage) to be clearer on this point.

I recognize that of th= e problem here is that the security considerations actually vary by algorit= hm and yet this subsection is trying to provide general guidance.

Is there a specific wo= rding change that you’d like to propose that would weaken the advice = when it’s OK to weaken it, but not in any other circumstances?

&nbs= p; --Charlie

&nbs= p; &= nbsp; &nbs= p; &= nbsp; &nbs= p; Thanks again,=

&nbs= p; &= nbsp; &nbs= p; &= nbsp; &nbs= p; -- Mike=

--_000_4E1F6AAD24975D4BA5B16804296739439BA6EF7CTK5EX14MBXC286r_-- From nobody Tue Sep 23 16:14:17 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F96B1A6F04; Tue, 23 Sep 2014 16:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 Ve3xBhelXZVc; Tue, 23 Sep 2014 16:14:07 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0126.outbound.protection.outlook.com [65.55.169.126]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 827F21A024C; Tue, 23 Sep 2014 16:14:07 -0700 (PDT) Received: from CO2PR03CA0046.namprd03.prod.outlook.com (10.141.194.173) by BLUPR03MB391.namprd03.prod.outlook.com (10.141.78.21) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Tue, 23 Sep 2014 23:14:05 +0000 Received: from BN1BFFO11FD023.protection.gbl (2a01:111:f400:7c10::1:158) by CO2PR03CA0046.outlook.office365.com (2a01:111:e400:1414::45) with Microsoft SMTP Server (TLS) id 15.0.1034.13 via Frontend Transport; Tue, 23 Sep 2014 23:14:04 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD023.mail.protection.outlook.com (10.58.144.86) with Microsoft SMTP Server (TLS) id 15.0.1029.15 via Frontend Transport; Tue, 23 Sep 2014 23:14:04 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.23]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.03.0195.002; Tue, 23 Sep 2014 23:13:26 +0000 From: Mike Jones To: Scott Kelly Thread-Topic: secdir review of draft-ietf-jose-json-web-encryption-31 Thread-Index: AQHPxFQt46oyUhN9qUyAY7sezVzBjpvzIWwQgAKW0gCAGcYRgA== Date: Tue, 23 Sep 2014 23:13:25 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BA6EFF7@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <3266E6F3-AB87-4B45-9C6F-A3B6976DBCEC@hyperthought.com> <4E1F6AAD24975D4BA5B16804296739439AE9D53F@TK5EX14MBXC292.redmond.corp.microsoft.com> <88AAAE10-880A-410A-A582-245FBB07E592@hyperthought.com> In-Reply-To: <88AAAE10-880A-410A-A582-245FBB07E592@hyperthought.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.78] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(51704005)(24454002)(189002)(51914003)(13464003)(52604005)(69234005)(51444003)(377454003)(199003)(110136001)(19580395003)(83322001)(106116001)(92566001)(21056001)(2656002)(50986999)(76482002)(50466002)(83072002)(6806004)(79102003)(64706001)(107046002)(19580405001)(85852003)(77982003)(33656002)(20776003)(84676001)(92726001)(69596002)(74502003)(85306004)(74662003)(44976005)(23676002)(97736003)(90102001)(86362001)(81342003)(99396002)(54356999)(561944003)(81156004)(230783001)(76176999)(81542003)(15975445006)(104016003)(95666004)(86612001)(47776003)(68736004)(106466001)(55846006)(4396001)(80022003)(85806002)(46102003)(77096002)(66066001)(87936001)(15202345003)(31966008)(10300001)(120916001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB391; H:mail.microsoft.com; FPR:; MLV:sfv; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB391; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0343AC1D30 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/rotuQuHivmJ5XjSTBj7J-HmE2mk Cc: "draft-ietf-jose-json-web-encryption.all@tools.ietf.org" , "iesg@ietf.org" , "jose@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-jose-json-web-encryption-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 23:14:11 -0000 VGhhbmtzIGFnYWluIGZvciB5b3VyIHJldmlldywgU2NvdHQuICBUaGUgcmVzb2x1dGlvbnMgZGlz Y3Vzc2VkIGJlbG93IGhhdmUgYmVlbiBhcHBsaWVkIGluIHRoZSAtMzIgZHJhZnQsIGV4Y2VwdCBm b3IgdGhlIHByb3Bvc2FsIHRvIHVzZSBtb3JlIG5vcm1hdGl2ZSByZWZlcmVuY2VzIGluIHRoZSBT ZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uLCB3aGljaCBKaW0gU2NoYWFkIGRpc2FncmVl ZCB3aXRoLg0KDQoJCQkJLS0gTWlrZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogU2NvdHQgS2VsbHkgW21haWx0bzpzY290dEBoeXBlcnRob3VnaHQuY29tXSANClNlbnQ6IFN1 bmRheSwgU2VwdGVtYmVyIDA3LCAyMDE0IDY6MzUgQU0NClRvOiBNaWtlIEpvbmVzDQpDYzogc2Vj ZGlyQGlldGYub3JnOyBkcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItZW5jcnlwdGlvbi5hbGxAdG9v bHMuaWV0Zi5vcmc7IGllc2dAaWV0Zi5vcmc7IGpvc2VAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBz ZWNkaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1lbmNyeXB0aW9uLTMxDQoN CkhpIE1pa2UsDQoNClJlc3BvbnNlcyBpbmxpbmUgYmVsb3figKYNCg0KT24gU2VwIDUsIDIwMTQs IGF0IDQ6MTMgUE0sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4gd3Jv dGU6DQoNCj4gVGhhbmtzIGZvciB0aGUgdXNlZnVsIHJldmlldywgU2NvdHQuICBJ4oCZdmUgY2Pi gJllZCB0aGUgd29ya2luZyBncm91cCBpbiBteSByZXBseSBzbyB0aGF0IHRoZXnigJlyZSBhd2Fy ZSBvZiB0aGUgY29udGVudHMgb2YgeW91ciByZXZpZXcuICBKaW0gU2NoYWFkIOKAkyBhbHNvIHBs ZWFzZSBzZWUgcXVlc3Rpb25zIHRvIHlvdSBiZWxvdy4gIFJlcGxpZXMgYXJlIGlubGluZSBiZWxv d+KApg0KPiAgDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFNjb3R0IEtl bGx5IFttYWlsdG86c2NvdHRAaHlwZXJ0aG91Z2h0LmNvbV0gDQo+IFNlbnQ6IFNhdHVyZGF5LCBB dWd1c3QgMzAsIDIwMTQgNjoxMyBBTQ0KPiBUbzogc2VjZGlyQGlldGYub3JnOyBkcmFmdC1pZXRm LWpvc2UtanNvbi13ZWItZW5jcnlwdGlvbi5hbGxAdG9vbHMuaWV0Zi5vcmc7IGllc2dAaWV0Zi5v cmcNCj4gU3ViamVjdDogc2VjZGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLWpvc2UtanNvbi13ZWIt ZW5jcnlwdGlvbi0zMQ0KPiAgDQo+IEkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBh cnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3Mgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3 IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuICBUaGVzZSBj b21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgc2Vj dXJpdHkgYXJlYSBkaXJlY3RvcnMuICBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hv dWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNv bW1lbnRzLg0KPiAgDQo+IEZyb20gdGhlIGFic3RyYWN0LCBKU09OIFdlYiBFbmNyeXB0aW9uIChK V0UpIHJlcHJlc2VudHMgZW5jcnlwdGVkIGNvbnRlbnQgdXNpbmcgSmF2YVNjcmlwdCBPYmplY3Qg Tm90YXRpb24gKEpTT04pIGJhc2VkIGRhdGEgc3RydWN0dXJlcy4gQSBsaXR0bGUgbGlrZSBDTVMg Zm9yIHdlYiB0cmFuc2FjdGlvbnMuDQo+ICANCj4gVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25z IHNlY3Rpb24gYmVnaW5zDQo+ICANCj4gICAgIkFsbCBvZiB0aGUgc2VjdXJpdHkgaXNzdWVzIHRo YXQgYXJlIHBlcnRpbmVudCB0byBhbnkgY3J5cHRvZ3JhcGhpYw0KPiAgICBhcHBsaWNhdGlvbiBt dXN0IGJlIGFkZHJlc3NlZCBieSBKV1MvSldFL0pXSyBhZ2VudHMuICBBbW9uZyB0aGVzZQ0KPiAg ICBpc3N1ZXMgYXJlIHByb3RlY3RpbmcgdGhlIHVzZXIncyBhc3ltbWV0cmljIHByaXZhdGUgYW5k IHN5bW1ldHJpYw0KPiAgICBzZWNyZXQga2V5cywgcHJldmVudGluZyB2YXJpb3VzIGF0dGFja3Ms IGFuZCBoZWxwaW5nIGF2b2lkIG1pc3Rha2VzDQo+ICAgIHN1Y2ggYXMgaW5hZHZlcnRlbnRseSBl bmNyeXB0aW5nIGEgbWVzc2FnZSB0byB0aGUgd3JvbmcgcmVjaXBpZW50Lg0KPiAgICBUaGUgZW50 aXJlIGxpc3Qgb2Ygc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgaXMgYmV5b25kIHRoZSBzY29wZSBv Zg0KPiAgICB0aGlzIGRvY3VtZW50LCBidXQgc29tZSBzaWduaWZpY2FudCBjb25zaWRlcmF0aW9u cyBhcmUgbGlzdGVkIGhlcmUuIg0KPiAgDQo+ICAgIkFsbCB0aGUgc2VjdXJpdHkgY29uc2lkZXJh dGlvbnMgaW4gdGhlIEpXUyBzcGVjaWZpY2F0aW9uIGFsc28gYXBwbHkNCj4gICAgdG8gdGhpcyBz cGVjaWZpY2F0aW9uLiAgTGlrZXdpc2UsIGFsbCB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMg aW4NCj4gICAgWE1MIEVuY3J5cHRpb24gMS4xIFtXM0MuUkVDLXhtbGVuYy1jb3JlMS0yMDEzMDQx MV0gYWxzbyBhcHBseSwgb3RoZXINCj4gICAgdGhhbiB0aG9zZSB0aGF0IGFyZSBYTUwgc3BlY2lm aWMuIg0KPiAgDQo+IElmIHlvdSBhcmUgZ29pbmcgdG8gcG9pbnQgdG8gdGhlIEpXUyBzcGVjaWZp Y2F0aW9uLCB5b3Ugc2hvdWxkIHVzZSBhIG5vcm1hdGl2ZSByZWZlcmVuY2UuIEl0J3MgZmluZSB0 byBwb2ludCBhdCBvdGhlciByZWZlcmVuY2VzIHRvIGF2b2lkIHJlLXN0YXRpbmcgdGhlIG9idmlv dXMsIGJ1dCBhbGwgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgKmFyZSogd2l0aGluIHNjb3BlLCBh bmQgcmVxdWlyZSBjb3ZlcmFnZSwgZWl0aGVyIGRpcmVjdGx5IG9yIGJ5IHJlZmVyZW5jZS4gSSBo YXZlbid0IHJldmlld2VkIHRoZSByZWZlcmVuY2VkIFczQyBzcGVjLCBzbyBJJ20gbm90IHN1cmUg dGhhdCBldmVyeXRoaW5nIGhhcyBiZWVuIGNvdmVyZWQuIFRoZSBKV1Mgc2VjdXJpdHkgY29uc2lk ZXJhdGlvbnMgc2VjdGlvbiBvbmx5IHRhbGtzIGFib3V0IGNyeXB0byBhbGdzIGFuZCBzZXJ2ZXIg aWRlbnRpdHkgdmVyaWZpY2F0aW9uLiBTbywgdGhlIEFEcyB3aWxsIHdhbnQgdG8gcGF5IGF0dGVu dGlvbiBoZXJlLg0KPiAgDQo+IFdlIHBsYW4gdG8gcmVtb3ZlIHRoZSBzZW50ZW5jZSDigJxUaGUg ZW50aXJlIGxpc3Qgb2Ygc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgaXMgYmV5b25kIHRoZSBzY29w ZSBvZiB0aGlzIGRvY3VtZW50LCBidXQgc29tZSBzaWduaWZpY2FudCBjb25zaWRlcmF0aW9ucyBh cmUgbGlzdGVkIGhlcmXigJ0gc2luY2Ugc2V2ZXJhbCByZXZpZXdlcnMgaGF2ZSB0YWtlbiBleGNl cHRpb24gdG8gaXQuDQo+ICANCj4gSeKAmW0gYSBiaXQgY29uZnVzZWQgYnkgeW91ciBjb21tZW50 IGFib3V0IG5vcm1hdGl2ZSByZWZlcmVuY2VzLCBiZWNhdXNlIHRoZSBKV1MgcmVmZXJlbmNlIGFs cmVhZHkgaXMgbm9ybWF0aXZlLg0KDQpJIHN0YXJ0ZWQgYnkgcmVhZGluZyB0aGUgc2VjdXJpdHkg Y29uc2lkZXJhdGlvbnMsIGFuZCB0aGF0IGNvbW1lbnQgd2FzIHRyaWdnZXJlZCBieSB0aGUgZmFj dCB0aGF0IGl0IHNheXMg4oCcdGhlIEpXUyBzcGVjaWZpY2F0aW9u4oCdIHJhdGhlciB0aGFuIFtK V1NdLiBUaGlzIGlzIGEgbml0LCBub3Qgc3VyZSBpdHMgaW1wb3J0YW50IHNvIGxvbmcgYXMgeW91 IGRvIGFscmVhZHkgaGF2ZSB0aGUgcmVmZXJlbmNlLg0KDQo+ICANCj4gSmltIFNjaGFhZCwgZXRj LiwgZG8geW91IGFncmVlIHRoYXQgdGhlIFhNTEVOQyByZWZlcmVuY2Ugc2hvdWxkIGJlY29tZSBu b3JtYXRpdmU/ICBJ4oCZZCB0aG91Z2ggdGhhdCBlYXJsaWVyIHlvdeKAmWQgYWR2aXNlZCBtZSB0 aGF0IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHJlZmVyZW5jZXMgc2hvdWxkIGJlIGluZm9ybWF0 aXZlLg0KDQpTZWUgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvbm9ybWF0aXZl LWluZm9ybWF0aXZlLmh0bWwsIHdoZXJlIGl0IHNheXMNCg0KICAgIldpdGhpbiBhbiBSRkMsIHJl ZmVyZW5jZXMgdG8gb3RoZXIgZG9jdW1lbnRzIGZhbGwgaW50byB0d28gZ2VuZXJhbCANCiAgICBj YXRlZ29yaWVzOiAibm9ybWF0aXZlIiBhbmQgImluZm9ybWF0aXZlIi4gTm9ybWF0aXZlIHJlZmVy ZW5jZXMgc3BlY2lmeQ0KICAgIGRvY3VtZW50cyB0aGF0IG11c3QgYmUgcmVhZCB0byB1bmRlcnN0 YW5kIG9yIGltcGxlbWVudCB0aGUgdGVjaG5vbG9neSANCiAgICBpbiB0aGUgbmV3IFJGQywgb3Ig d2hvc2UgdGVjaG5vbG9neSBtdXN0IGJlIHByZXNlbnQgZm9yIHRoZSB0ZWNobm9sb2d5DQogICAg aW4gdGhlIG5ldyBSRkMgdG8gd29yay4gQW4gaW5mb3JtYXRpdmUgcmVmZXJlbmNlIGlzIG5vdCBu b3JtYXRpdmU7IA0KICAgIHJhdGhlciwgaXQgb25seSBwcm92aWRlcyBhZGRpdGlvbmFsIGluZm9y bWF0aW9uLiBGb3IgZXhhbXBsZSwgYW4gDQogICAgaW5mb3JtYXRpdmUgcmVmZXJlbmNlIG1pZ2h0 IHByb3ZpZGUgYmFja2dyb3VuZCBvciBoaXN0b3JpY2FsIGluZm9ybWF0aW9uLg0KICAgIEluZm9y bWF0aXZlIHJlZmVyZW5jZXMgYXJlIG5vdCByZXF1aXJlZCB0byBpbXBsZW1lbnQgdGhlIHRlY2hu b2xvZ3kgaW4gDQogICAgdGhlIFJGQy4iDQoNCklmIHdoYXQgaXMgYmVpbmcgZGVzY3JpYmVkIGFy ZSBzZWN1cml0eSAqcmVxdWlyZW1lbnRzKiwgdGhlbiBJIHRoaW5rIHRoZSByZWZlcmVuY2Ugc2hv dWxkIGJlIG5vcm1hdGl2ZS4NCg0KDQo+ICANCj4gRllJLCBhcyBwYXJ0IG9mIGFkZHJlc3Npbmcg UnVzcyBIb3VzbGV54oCZcyBjb21tZW50cyBvbiB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMg c2VjdGlvbiwgSSBkbyBleHBlY3QgdG8gZXhwbGljaXRseSByZWZlcmVuY2UgYSBudW1iZXIgb2Yg c2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgY2FsbGVkIG91dCBpbiBYTUxFTkMsIHN1Y2ggYXMgdGhl IHRleHQgb24gY2hvc2VuLWNpcGhlcnRleHQgYXR0YWNrcywgYmFja3dhcmRzIGNvbXBhdGliaWxp dHkgYXR0YWNrcywgZXRjLg0KPiAgDQo+IEluIHNlY3Rpb24gNS4xIChNZXNzYWdlIEVuY3J5cHRp b24pLCBzdGVwIDE2IHNheXMgIkVuY3J5cHQgTS4uLiIgd2l0aG91dCBldmVyIGRlZmluaW5nIE0u IE9uZSBtaWdodCBndWVzcyBpdCBzdGFuZHMgZm9yIE1lc3NhZ2UsIGJ1dCB0aGlzIHNob3VsZCBi ZSBzdGF0ZWQuDQo+ICANCj4gQWdyZWVkDQo+ICANCj4gU2VjdGlvbiA4IChUTFMgUmVxdWlyZW1l bnRzKSBwb2ludHMgYXQgSldTLCBidXQgbmVpdGhlciBkb2N1bWVudCByZWZlcmVuY2VzIHRoZSBj aGFubmVsIGJpbmRpbmcgcHJvYmxlbS4gSWYgeW91IGFyZSBkZXBlbmRpbmcgb24gVExTIHRvIHBy b3ZpZGUgZXNzZW50aWFsIGFuZCBuZWNlc3Nhcnkgc2VjdXJpdHkgZmVhdHVyZXMgKHdoaWNoLCBw cmVzdW1hYmx5LCB5b3UgYXJlIHNpbmNlIFRMUyBpcyBhIE1VU1QpLCB0aGVuIHlvdSBzaG91bGQg Z2l2ZSBjbGVhciBndWlkYW5jZSBhcyB0byBob3cgdG8gZWZmZWN0aXZlbHkgdXNlIGl0LiBKV1Mg cmVxdWlyZXMgY29tYmluZWQgY29uZmlkZW50aWFsaXR5IGFuZCBpbnRlZ3JpdHkgcHJvdGVjdGlv biwgYW5kIGFsc28gcmVxdWlyZXMgc2VydmVyIGlkZW50aXR5IHZlcmlmaWNhdGlvbiBwZXIgUkZD NjEyNSwgYnV0IGRvZXMgbm90IG1lbnRpb24gY2hhbm5lbCBiaW5kaW5nLg0KPiAgDQo+IFNjb3R0 LCBpcyB0aGVyZSB0ZXh0IG9uIHRoZSBjaGFubmVsIGJpbmRpbmcgcHJvYmxlbSBpbiBhbm90aGVy IHNwZWNpZmljYXRpb24gdGhhdCB5b3XigJlkIHJlY29tbWVuZCB0aGF0IHdlIHJlZmVyZW5jZSBv ciB1c2U/ICBJZiBub3QsIHdvdWxkIHlvdSBtaW5kIHN1cHBseWluZyBwcm9wb3NlZCB0ZXh0IGZv ciB1cyB0byB1c2U/DQoNClJGQzUwNTYgY292ZXJzIGNoYW5uZWwgYmluZGluZ3MsIGFuZCBSRkM1 OTI5IGNvdmVycyBjaGFubmVsIGJpbmRpbmdzIGZvciBUTFMuIE15IGNvbW1lbnQgaXMgcmVsYXRl ZCB0byB0aGUgcmVxdWlyZW1lbnQgZm9yIFRMUywgd2hpY2ggaXMgZGVzY3JpYmVkIGluIHRoZSBK V1MgZG9jdW1lbnQuIE5vdGUgdGhhdCBJIGRpZG7igJl0IHNheSBjaGFubmVsIGJpbmRpbmdzIGFy ZSBkZWZpbml0ZWx5IGEgcHJvYmxlbSBoZXJlLCBvbmx5IHRoYXQgSeKAmW0gc3VycHJpc2VkIHRo ZXkgYXJlIG5vdCBtZW50aW9uZWQuDQoNCldoZXRoZXIgb3Igbm90IGNoYW5uZWwgYmluZGluZ3Mg bmVlZCB0byBiZSBhZGRyZXNzZWQgZGVwZW5kcyBvbiB0aGUgdGhyZWF0cyB5b3UgaW50ZW5kIHRv IGFkZHJlc3MuIFNvbWUgb2YgbXkgb3RoZXIgY29tbWVudHMgd2VyZSBpbnRlbmRlZCB0byBpbmRp Y2F0ZSB0aGF0IHRoZSBzY29wZSBvZiB0aHJlYXRzL3Byb3RlY3Rpb25zIGFyZSBub3QgZXhwbGlj aXQgaW4gdGhpcyBkcmFmdCwgYW5kIGFmdGVyIGEgcXVpY2sgc2NhbiBvZiBKV1MsIHRoZXkgc3Rp bGwgd2VyZSBub3QgY2xlYXIgdG8gbWUuIEFueSBBRHMgcmVhZGluZyBhbGwgdGhlIGRyYWZ0cyB3 aWxsIGhhdmUgaW5mb3JtYXRpb24vY29udGV4dCBJIGxhY2ssIHNvIHRoZSBjb21tZW50IHdhcyBp bnRlbmRlZCBhcyBhIGhlYWRzIHVwLg0KDQo+ICANCj4gU2VjdGlvbiAxMS4xIChVc2luZyBNYXRj aGluZyBBbGdvcml0aG0gU3RyZW5ndGhzKSBzYXlzDQo+ICANCj4gICAiQWxnb3JpdGhtcyBvZiBt YXRjaGluZyBzdHJlbmd0aHMgc2hvdWxkIGJlIHVzZWQgdG9nZXRoZXIgd2hlbmV2ZXINCj4gICAg cG9zc2libGUuICBGb3IgaW5zdGFuY2UsIHdoZW4gQUVTIEtleSBXcmFwIGlzIHVzZWQgd2l0aCBh IGdpdmVuIGtleQ0KPiAgICBzaXplLCB1c2luZyB0aGUgc2FtZSBrZXkgc2l6ZSBpcyByZWNvbW1l bmRlZCB3aGVuIEFFUyBHQ00gaXMgYWxzbw0KPiAgICB1c2VkLiINCj4gIA0KPiBUaGlzIGRvZXNu J3QgcXVpdGUgc2NhbiBmb3IgbWUsIGJ1dCBlZGl0b3JpYWwgbml0cyBhc2lkZSwgaXQgbWlnaHQg YmUgZ29vZCB0byBzYXkgZ3JlYXRlciBvciBlcXVhbCBrZXkgc2l6ZXMgc2hvdWxkIGJlIHVzZWQg Zm9yIHdyYXBwaW5nLg0KPiAgDQo+IFRoZSDigJxtYXRjaGluZyBzdHJlbmd0aHPigJ0gZ3VpZGFu Y2UgY2FtZSBmcm9tIEVyaWMgUmVzY29ybGEgYW5kIEkgYmVsaWV2ZSB3YXMgc3VwcG9ydGVkIGJ5 IHRoZW4tU2VjdXJpdHkgQUQgU2VhbiBUdXJuZXIuICBJdOKAmXMgbm90IGNsZWFyIHRvIG1lIHRo YXQgdGhlIOKJpSBsYW5ndWFnZSBpcyBiZXR0ZXIgdGhhbiB3aGF04oCZcyB0aGVyZSBub3csIGlu IHBhcnQgYmVjYXVzZSBpZiB0aGUgc3RyZW5ndGhzIGRvbuKAmXQgbWF0Y2gsIGl04oCZcyBub3Qg Y2xlYXIgdG8gbWUgd2hpY2ggd2F5IHRoZSBpbmVxdWFsaXR5IHNob3VsZCBnby4NCg0KUnVsaW5n IG91dCB0aGUgdXNlIG9mIHN0cm9uZ2VyIGtleXMgZm9yIHdyYXBwaW5nIHNlZW1zIG5vbi1pbnR1 aXRpdmUgdG8gbWUsIGJ1dCB5b3VyIHBvaW50IGlsbHVzdHJhdGVzIHRoYXQgdGhpcyBtYXkgaW50 cm9kdWNlIGFkZGl0aW9uYWwgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMuIFBlcnNvbmFsbHksIEkg bGlrZSB0aGUgbGFuZ3VhZ2UgaW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24g b2YgUkZDNTY1MjoNCg0KICAgIldoZW4gdXNpbmcga2V5LWFncmVlbWVudCBhbGdvcml0aG1zIG9y IHByZXZpb3VzbHkgZGlzdHJpYnV0ZWQNCiAgIHN5bW1ldHJpYyBrZXktZW5jcnlwdGlvbiBrZXlz LCBhIGtleS1lbmNyeXB0aW9uIGtleSBpcyB1c2VkIHRvDQogICBlbmNyeXB0IHRoZSBjb250ZW50 LWVuY3J5cHRpb24ga2V5LiAgSWYgdGhlIGtleS1lbmNyeXB0aW9uIGFuZA0KICAgY29udGVudC1l bmNyeXB0aW9uIGFsZ29yaXRobXMgYXJlIGRpZmZlcmVudCwgdGhlIGVmZmVjdGl2ZSBzZWN1cml0 eQ0KICAgaXMgZGV0ZXJtaW5lZCBieSB0aGUgd2Vha2VyIG9mIHRoZSB0d28gYWxnb3JpdGhtcy4g IElmLCBmb3IgZXhhbXBsZSwNCiAgIGNvbnRlbnQgaXMgZW5jcnlwdGVkIHdpdGggVHJpcGxlLURF UyB1c2luZyBhIDE2OC1iaXQgVHJpcGxlLURFUw0KICAgY29udGVudC1lbmNyeXB0aW9uIGtleSwg YW5kIHRoZSBjb250ZW50LWVuY3J5cHRpb24ga2V5IGlzIHdyYXBwZWQNCiAgIHdpdGggUkMyIHVz aW5nIGEgNDAtYml0IFJDMiBrZXktZW5jcnlwdGlvbiBrZXksIHRoZW4gYXQgbW9zdCA0MCBiaXRz DQogICBvZiBwcm90ZWN0aW9uIGlzIHByb3ZpZGVkLiAgQSB0cml2aWFsIHNlYXJjaCB0byBkZXRl cm1pbmUgdGhlIHZhbHVlDQogICBvZiB0aGUgNDAtYml0IFJDMiBrZXkgY2FuIHJlY292ZXIgdGhl IFRyaXBsZS1ERVMga2V5LCBhbmQgdGhlbiB0aGUNCiAgIFRyaXBsZS1ERVMga2V5IGNhbiBiZSB1 c2VkIHRvIGRlY3J5cHQgdGhlIGNvbnRlbnQuICBUaGVyZWZvcmUsDQogICBpbXBsZW1lbnRlcnMg bXVzdCBlbnN1cmUgdGhhdCBrZXktZW5jcnlwdGlvbiBhbGdvcml0aG1zIGFyZSBhcyBzdHJvbmcN CiAgIG9yIHN0cm9uZ2VyIHRoYW4gY29udGVudC1lbmNyeXB0aW9uIGFsZ29yaXRobXMu4oCdDQoN Cj4gIEFuZCB5b3UgbWlnaHQgd2FudCB0byBwb2ludCB0byBSRkMzNzY2IGZvciBCQ1BzIHdoZW4g dXNpbmcgcHVibGljIGtleXMuDQo+ICANCj4gVGhlIFJGQyAzNzY2IHJlZmVyZW5jZSBsb29rcyBs aWtlIGEgZ29vZCBvbmUuICBUaGFua3MgZm9yIHByb3ZpZGluZyBpdC4NCj4gIA0KPiBTZWN0aW9u IDExLjIgaW50cm9kdWNlcyB0aGUgdGVybSAia2V5IHRhaW50aW5nIi4gIlN0cmljdCBrZXkgbWFu YWdlbWVudC91c2FnZSBwb2xpY3kiIG1pZ2h0IGJlIGJldHRlciB1bmRlcnN0b29kLiBBbHNvLCBp dCBtaWdodCBiZSB2YWx1YWJsZSB0byB1c2UgU0hPVUxEIGhlcmUuDQo+ICANCj4gSmltIFNjaGFh ZCwgeW91IHN1Z2dlc3RlZCB1c2luZyB0aGUgdGVybSDigJxrZXkgdGFpbnRpbmfigJ0uICBJcyB0 aGVyZSBhIHBsYWNlIHdoZXJlIHRoaXMgdGVybSBpcyBkZWZpbmVkLCB3aGljaCB3ZSBjb3VsZCBy ZWZlcmVuY2U/DQo+ICANCj4gQWxzbywgSmltLCBJIGJlbGlldmUgaW4gb3VyIGluLXBlcnNvbiBk aXNjdXNzaW9ucyBvZiBpc3N1ZSAjNzAgKFJldmlldyBvZiAyMTE5IExhbmd1YWdlKSB5b3XigJlk IHN1Z2dlc3RlZCB0aGF0IHdlIHVzZSAyMTE5IGtleXdvcmRzIGluIHRoZSBTZWN1cml0eSBDb25z aWRlcmF0aW9ucyBzdGF0ZW1lbnRzLiAgQW0gSSByZW1lbWJlcmluZyB0aGF0IHJpZ2h0LCBvciB3 b3VsZCB5b3UgcHJlZmVyIHRoYXQgdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb25z IHVzZSAyMTE5IGxhbmd1YWdlPw0KPiAgDQo+IEkgd2FzIHN1cnByaXNlZCBub3QgdG8gc2VlIGFu eSBtZW50aW9uIG9mIHRoZSBsYWNrIG9mIHJlcGxheSBwcm90ZWN0aW9uLiBUTFMgY2hhbm5lbCBi aW5kaW5nIGNvdWxkIHByZXN1bWFibHkgYmUgbGV2ZXJhZ2VkIGZvciB0aGlzIHB1cnBvc2UsIGJ1 dCBpbiBhbnkgZXZlbnQsIHRoZSBmYWN0IHRoYXQgSldFcyBjYW4gYmUgcmVwbGF5ZWQgc2hvdWxk IGJlIG1lbnRpb25lZC4NCj4gIA0KPiBJdOKAmXMgbm90IGNsZWFyIHRvIG1lIHRoYXQgYmVpbmcg YWJsZSB0byBkZWNyeXB0IGFuIGVuY3J5cHRlZCBvYmplY3QgbXVsdGlwbGUgdGltZXMgaWYgeW91 IGhvbGQgdGhlIGNvcnJlY3Qga2V5IGNvbnN0aXR1dGVzIGFuIGF0dGFjaywgYW55IG1vcmUgdGhh biBiZWluZyBhYmxlIHRvIGNoZWNrIGEgc2lnbmF0dXJlIG11bHRpcGxlIHRpbWVzIGRvZXMuDQoN Ck9uZSBleGFtcGxlOiBvbmNlIGEgc3ltbWV0cmljIGtleSBpcyBjb21wcm9taXNlZCAod3JhcHBp bmcgb3Igd3JhcHBlZCBrZXkpLCB0aGUgYmFkIGFjdG9yIHdobyBob2xkcyB0aGF0IGtleSBjYW4g aW1wZXJzb25hdGUgdGhlIHNlcnZlciBhbmQgcHJvdmlkZSB0aGUgd3JhcHBlZCBrZXkgdG8gdGhl IHRhcmdldCBjbGllbnQuIFRoaXMgaXMgb25lIG9mIHRoZSB0aHJlYXRzIHlvdSBtYXkgYmUgaW50 ZW5kaW5nIHRvIG1pdGlnYXRlIHdpdGggVExTLCBidXQgYmFzZWQgb24gbXkgcmVhZGluZywgdGhh dCBpcyBub3QgY2xlYXIgdG8gbWUuIEFuZCBJIHRoaW5rIHRoYXQgdG8gZnVsbHkgbGV2ZXJhZ2Ug VExTIGZvciB0aGlzIHB1cnBvc2UsIHlvdSBtdXN0IGFkZHJlc3MgdGhlIGNoYW5uZWwgYmluZGlu Z3MgcHJvYmxlbS4NCiANCihJIHRoaW5rIHlvdSBhbGx1ZGUgdG8gdGhpcyBpbiB0aGUgbmV4dCBw YXJhZ3JhcGggb2YgeW91ciByZXBseSwgYnV0IGl0IHNlZW1zIGxlc3MgY29uZnVzaW5nIHRvIGlu c2VydCB0aGlzIGNvbW1lbnQgaGVyZSkNCg0KPiBJIGFncmVlIHdpdGggeW91IHRoYXQgc29tZSBo aWdoZXItbGV2ZWwgb2JqZWN0cyB0aGF0IG1heSB1c2UgSldFIChvciBKV1MpIG1heSB3YW50IHJl cGxheSBwcm90ZWN0aW9uLiAgRm9yIGluc3RhbmNlLGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4tMjUjc2VjdGlvbi00LjEuNyBkZXNjcmli ZXMgYSBtZWFucyBvZiByZXBsYXkgcHJvdGVjdGlvbiBmb3IgSldUcy4gIEF0IG1vc3QsIGlmIHdl IG1lbnRpb24gcmVwbGF5IHByb3RlY3Rpb24sIEkgd291bGQgcHJvcG9zZSB0aGF0IHdlIHNheSB0 aGF0IHNvbWUgYXBwbGljYXRpb25zIHVzaW5nIEpXRSBlbmNyeXB0aW9uIG1heSBjaG9vc2UgdG8g aW5jb3Jwb3JhdGUgcmVwbGF5IHByb3RlY3Rpb24gbWVjaGFuaXNtcywgc3VjaCBhcyBieSBpbmNs dWRpbmcgSURzIGluIHRoZSBwcm90ZWN0ZWQgY29udGVudCB0aGF0IGNoYW5nZSB3aXRoIGVhY2gg YXBwbGljYXRpb24tbGV2ZWwgdXNhZ2UuICBXb3VsZCB0aGF0IHdvcmsgZm9yIHlvdSBTY290dCwg b3IgaXMgdGhlcmUgc29tZXRoaW5nIGVsc2UgeW91IGhhZCBpbiBtaW5kPw0KPiAgDQo+IEFzIGFs d2F5cywgaWYgeW91IGNhbiBzdXBwbHkgc3BlY2lmaWMgcHJvcG9zZWQgbGFuZ3VhZ2UgdG8gYWRk cmVzcyB5b3VyIGNvbmNlcm4sIHRoYXQgd291bGQgcHJvYmFibHkgYmUgdGhlIGNsZWFyZXN0IHN0 YXRlbWVudCBvZiB3aGF0IHlvdeKAmWQgbGlrZSB0byBzZWUuDQo+ICANCj4gSSB3b3VsZCBzdWdn ZXN0IHRoYXQgdGhlIGF1dGhvcnMgcmVhZCB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgaW4g cmZjNTY1MjsgbW9zdCBvZiB0aGUgc2FtZSBjb25jZXJucyBhcHBseSBoZXJlLCBhbmQgeW91IGNv dWxkIGFsbW9zdCBjdXQvcGFzdGUgZnJvbSB0aGVyZSB0byBoZXJlLg0KPiAgDQo+IFRoYW5rcy4g IEkgZXhwZWN0IHRvIHJlZmVyZW5jZSBzb21lIG9mIHRoZXNlIGFzIHdlbGwgd2hlbiBhZGRyZXNz aW5nIFJ1c3MgSG91c2xleeKAmXMgZ2VuLWFydCByZXZpZXcgY29tbWVudHMgb2YgSldTLg0KPiAg DQo+IEZvciB0aGUgQURzOiBJJ20gbm90IHN1cmUgaWYgb25lIG9mIHRoZSBjb21wYW5pb24gZG9j dW1lbnRzIHByb3ZpZGVzIGEgY29tcHJlaGVuc2l2ZSB0aHJlYXQgbW9kZWwsIGJ1dCB5b3Ugd2ls bCB3YW50IHRvIHBheSBhdHRlbnRpb24gaGVyZS4gVGhpcyBkb2MgZG9lcyBub3QuDQo+ICANCj4g RWFjaCBkb2MgdHJpZXMgdG8gbGlzdCBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzcGVjaWZpYyB0 byB0aGF0IGRvY3VtZW50IGFuZCB3aGVyZSB0aGV5IHNwYW4gZG9jdW1lbnRzLCB0aGV5IGFyZSBk ZXNjcmliZWQgaW4gb25lIGFuZCByZWZlcmVuY2VkIGluIG90aGVycy4NCj4gIA0KPiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg VGhhbmtzIGFnYWluLCBTY290dCwNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KT25lIG1vcmUgY29tbWVu dCByZWxhdGVkIHRvIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLCBjb21wcmVoZW5zaXZlIHRocmVh dCBtb2RlbCwgZXRjLjogUkZDMzU1MiBnaXZlcyBhIHJvYWRtYXAgZm9yIHNlY3VyaXR5IGNvbnNp ZGVyYXRpb25zLiBZb3VyIGZhbWlseSBvZiBkb2N1bWVudHMgc2hvdWxkIGNvdmVyIHRoYXQgcm9h ZG1hcC4gSSB1bmRlcnN0YW5kIHRoYXQgeW91IGRvbuKAmXQgd2FudCB0byByZXBlYXQgdGhpbmdz IGluIGV2ZXJ5IGRvY3VtZW50LCBidXQgdGhlIEFEcyB3aWxsIGhhdmUgdG8gZW5zdXJlIHRoYXQs IGhvd2V2ZXIgeW91IGFwcHJvYWNoIGl0LCBldmVyeXRoaW5nIGlzIGNvdmVyZWQuIFRoYXQgd2Fz IG15IHBvaW50Lg0KDQrigJRTY290dA0KIA0K From nobody Tue Sep 23 16:21:21 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 554591A8972; Tue, 23 Sep 2014 16:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 koO6mDIK0foM; Tue, 23 Sep 2014 16:21:08 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0142.outbound.protection.outlook.com [65.55.169.142]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BDFE1A8973; Tue, 23 Sep 2014 16:21:08 -0700 (PDT) Received: from BN3PR0301CA0009.namprd03.prod.outlook.com (25.160.180.147) by DM2PR0301MB1216.namprd03.prod.outlook.com (25.160.219.17) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Tue, 23 Sep 2014 23:21:07 +0000 Received: from BY2FFO11FD019.protection.gbl (2a01:111:f400:7c0c::132) by BN3PR0301CA0009.outlook.office365.com (2a01:111:e400:4000::19) with Microsoft SMTP Server (TLS) id 15.0.1034.13 via Frontend Transport; Tue, 23 Sep 2014 23:21:06 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD019.mail.protection.outlook.com (10.1.14.107) with Microsoft SMTP Server (TLS) id 15.0.1029.15 via Frontend Transport; Tue, 23 Sep 2014 23:21:05 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.23]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.03.0195.002; Tue, 23 Sep 2014 23:20:33 +0000 From: Mike Jones