Subject: Re: [jose] JWS Unencoded Payload Option spec addressing WGLC comments

From: Mike Jones <[email-masked]>
Date: Mon, 2 Nov 2015 09:22:42 +0000

Thanks for your note and for thinking this through, James.  Your comments were useful and made me think, as always.  As I see it, there are several cases to consider.

If the producer implements the extension correctly, then as I wrote on the 21st, if the consumer doesn't understand it, then the signature will fail.  That's the case I was writing about earlier

So the case you're describing has to instead be one in which the producer is an attacker and intentionally not implementing the extension correctly.  In that case, example you give is possible if the receiver doesn't understand the extension.  I used to be concerned about this but now I'm not.  Here are two reasons why:

1.  The recipient is implementing an application that uses JWS - one property of which is a specification by the application of whether the extension is used or not.  If the application uses the extension, then a correctly implemented application client will implement the extension.  In that case, if the attacker uses "b64":false but signs as if "b64" were true (your described attack), then the signature verification will fail.  Whereas, if you start with the premise that the recipient incorrectly implements the application, which your attack requires, then all bets are off in the first place.

2.  The recipient is already making a trust decision dictated by the application's rules for using JWS about whether to trust the sender based on verifying its signature and therefore its identity within the application context.  If the sender is actually an attacker and yet trusted by the recipient once its signature is verified, the recipient has bigger problems than the possibility of the sender being able to generate the same signature for both encoded and unencoded values.  If the sender is an attacker trusted by the recipient, there are likely much worse ways for the sender to trick the recipient, for instance, by signing maliciously generated content, which the recipient then uses.

Only if the application dynamically switches between b64:false and b64:true (something prohibited in https://tools.ietf.org/html/draft-ietf-jose-jws-signing-input-options-03#section-6), would it be necessary for the application to require the use of "crit":["b64"].  That would cause incorrectly implemented application clients to nonetheless reject content signed with b64:false when it doesn't implement "b64".
I will add the thoughts above to the Security Considerations section.

And similarly to argument 1 above, if the application specifies the use of b46:false with the compact serialization *and* the application will use non-baseurl-safe payload characters such as comma, then it already has to be prepared to accurately communicate those characters within the application context.  There is no backwards compatibility problem for existing applications - only new options for new applications, if they choose to use the option.  If the existence of the extension would break any existing applications or require any actions upon their part, then I would agree that this spec should be marked as updating RFC 7515.  But as it is, it's just a spec using the IANA registry to register a new header parameter value.  We certainly don't want to set the precedent that every new header parameter registration will also require updating RFC 7515.

Jim, I believe that the thoughts above also address the two questions in your October 18th note in the same thread.  Please let me know if you disagree.

                                                            -- Mike

From: Manger, James [mailto:[email-masked]]
Sent: Thursday, October 22, 2015 9:32 AM
To: Jim Schaad; Mike Jones; [email-masked]
Subject: RE: [jose] JWS Unencoded Payload Option spec addressing WGLC comments

Unfortunately Mike, the signature validation will not fail. By design draft-ietf-jose-jws-signing-input-options mimics RFC7515 in using "bytes before the 2nd dot" as the bytes to sign/verify. Consider a signer choosing the b64=false option from draft-ietf-jose-jws-signing-input-options to sign the 12-byte message "IOU_5000_USD". The header is {"alg":"HS256","b64":false} giving the JWS:
  eyJhbGciOiJIUzI1NiIsImI2NCI6ZmFsc2V9.IOU_5000_USD.xxxxxxxxxxxxxxxxxxxxxxxx

A verifier that only understands RFC7515 JWS interprets this as a normal JWS with an unknown but ignorable header member. The signature is still over eyJ..USD so it still verifies. The verifier then base64url-decodes the IOU.. part to get the validly-signed 9-byte content (in hex) 20 E5 3F E7 4D 34 FD 44  83.
Ouch! One JWS can be interpreted as a signed 12-byte or 9-byte message.

One fix might be to make the b64=false signing input:
  BASE64URL(UTF8(JWS Protected Header)) || '..' || JWS Payload
The two dots ensure the bytes signed when b64=false can never look like bytes signed according to RFC7515.
draft-ietf-jose-jws-signing-input-options should probably do this in addition to setting the crit field (so you can get a meaningful error message of "unsupported variety of JWS", instead of "signature failure" that could have all sorts of causes).

>From RFC7515 JWS, it would be perfectly reasonable to store a collection of compact-serialized-JWSs as comma-separated values - since a RFC7515 compact-serialized-JWS cannot contain a comma. draft-ietf-jose-jws-signing-input-options breaks that perfectly reasonable choice as now an unencoded non-detached JWS can have any bytes and still be called a compact-serialized-JWS. Saying draft-ietf-jose-jws-signing-input-options updates RFC7515 is the minimum required to note this, though that isn't really adequate. A better solution is to not allow an unencoded non-detached message to be called a compact-serialized-JWS: either don't define this combination, or call it something else (eg JWS raw serialization).

--
James Manger

From: Jim Schaad [mailto:[email-masked]]
Sent: Thursday, 22 October 2015 9:53 AM
To: 'Mike Jones'; Manger, James; [email-masked]<mailto:[email-masked]>
Subject: RE: [jose] JWS Unencoded Payload Option spec addressing WGLC comments

Does making 'crit' not required open one up to the possibility of an attack along the following lines:

1.       Create a JWS with a b64=true header

2.      Sign it using the b64=false construction

3.      Send it to a validator that does not understand the b64 header.

4.      Claim that the validator should have failed validation and not performed the signed command

Jim

From: jose [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Wednesday, October 21, 2015 2:16 PM
To: Manger, James <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] JWS Unencoded Payload Option spec addressing WGLC comments

As I see it, explicitly updating JWS isn't necessary, since JWS established the JSON Web Signature and Encryption Header Parameters Registry to allow for additional Header Parameters to be defined, and so implementers are expected to refer to the registry and gracefully handle the possibility of extensions registered there.  The JWS Unencoded Payload Option specification registers such an extension.

As to whether "crit" is required, "crit" is only necessary if an explicit directive is required that the validation must fail if the header parameter is not understood.  However, in this case, if "b64" is not understood and simply ignored, the validation will fail without needing to use "crit", since the signature validation will fail.  Thus, the use of "crit" is unnecessary for "b64".

                                                                -- Mike

From: Manger, James [mailto:[email-masked]]
Sent: Tuesday, October 13, 2015 7:55 PM
To: Mike Jones <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: JWS Unencoded Payload Option spec addressing WGLC comments

Shouldn't draft-ietf-jose-jws-signing-input-options update RFC 7515 "JWS"? That seems quite important as draft-ietf-jose-jws-signing-input-options changes the meaning of valid JWS messages (new "b64" field that cannot be ignored, but is not listed in "crit"), and allows a bunch of previously invalid chars in JWS Compact Serializations (invalidating the JWS definition of Compact Serialization as a "URL-safe string").

--
James Manger

From: jose [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Wednesday, 14 October 2015 10:49 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [jose] JWS Unencoded Payload Option spec addressing WGLC comments

Draft -03 of the JWS Unencoded Payload Option specification addresses the working group last call comments received.  Thanks to Jim Schaad, Vladimir Dzhuvinov, John Bradley, and Nat Sakimura for the useful comments.  Changes were:

*         Allowed the ASCII space character and all printable ASCII characters other than period ('.') in non-detached unencoded payloads using the JWS Compact Serialization.

*         Updated the abstract to say that that the spec updates RFC 7519.

*         Removed unused references.

*         Changed the change controller to IESG.

The specification is available at:

*         https://tools.ietf.org/html/draft-ietf-jose-jws-signing-input-options-03<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-jose-jws-signing-input-options-03&data=01%7c01%7cMichael.Jones%40microsoft.com%7c67566ac2856449dd329b08d2d442d2c8%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=cwfExLlgEK11IEBTdvKI63EI6xNBi1JTV0KVipTf8JU%3d>

An HTML formatted version is also available at:

*         http://self-issued.info/docs/draft-ietf-jose-jws-signing-input-options-03.html<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fself-issued.info%2fdocs%2fdraft-ietf-jose-jws-signing-input-options-03.html&data=01%7c01%7cMichael.Jones%40microsoft.com%7c67566ac2856449dd329b08d2d442d2c8%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=5nAlXMo6uPDM600pp0Kf1JQliQ4maLZc5eCMKfzCdQ8%3d>

                                                                -- Mike

P.S.  This note was also published at http://self-issued.info/?p=1465<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fself-issued.info%2f%3fp%3d1465&data=01%7c01%7cMichael.Jones%40microsoft.com%7c67566ac2856449dd329b08d2d442d2c8%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=L6oZmQ6tOl1eW%2fmh9zyorKeY4ouQZTGMn4o9Zid5snk%3d> and as @selfissued<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftwitter.com%2fselfissued&data=01%7c01%7cmichael.jones%40microsoft.com%7c3a69db7b8b6c4d47da0f08d2937a3d82%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ggurSMkRVW%2bR8Nv93Mnbsf16CmVGqfjB9lW8SV5gAKM%3d>.

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 2 Nov 2015 20:35:50 +0900

From: Mike Jones [mailto:[email-masked]] 
Sent: Monday, November 02, 2015 6:23 PM
To: Manger, James <[email-masked]>; Jim Schaad
<[email-masked]>; [email-masked]
Subject: RE: [jose] JWS Unencoded Payload Option spec addressing WGLC
comments

Thanks for your note and for thinking this through, James.  Your comments
were useful and made me think, as always.  As I see it, there are several
cases to consider.

If the producer implements the extension correctly, then as I wrote on the
21st, if the consumer doesn't understand it, then the signature will fail.
That's the case I was writing about earlier

So the case you're describing has to instead be one in which the producer is
an attacker and intentionally not implementing the extension correctly.  In
that case, example you give is possible if the receiver doesn't understand
the extension.  I used to be concerned about this but now I'm not.  Here are
two reasons why:

1.  The recipient is implementing an application that uses JWS - one
property of which is a specification by the application of whether the
extension is used or not.  If the application uses the extension, then a
correctly implemented application client will implement the extension.  In
that case, if the attacker uses "b64":false but signs as if "b64" were true
(your described attack), then the signature verification will fail.
Whereas, if you start with the premise that the recipient incorrectly
implements the application, which your attack requires, then all bets are
off in the first place.

2.  The recipient is already making a trust decision dictated by the
application's rules for using JWS about whether to trust the sender based on
verifying its signature and therefore its identity within the application
context.  If the sender is actually an attacker and yet trusted by the
recipient once its signature is verified, the recipient has bigger problems
than the possibility of the sender being able to generate the same signature
for both encoded and unencoded values.  If the sender is an attacker trusted
by the recipient, there are likely much worse ways for the sender to trick
the recipient, for instance, by signing maliciously generated content, which
the recipient then uses.

Only if the application dynamically switches between b64:false and b64:true
(something prohibited in
https://tools.ietf.org/html/draft-ietf-jose-jws-signing-input-options-03#sec
tion-6), would it be necessary for the application to require the use of
"crit":["b64"].  That would cause incorrectly implemented application
clients to nonetheless reject content signed with b64:false when it doesn't
implement "b64".

[JLS] I would disagree that this is prohibited in the section referred to.
The text says "it is intended" this is not that say as saying you MUST only
use one.

And similarly to argument 1 above, if the application specifies the use of
b46:false with the compact serialization *and* the application will use
non-baseurl-safe payload characters such as comma, then it already has to be
prepared to accurately communicate those characters within the application
context.  There is no backwards compatibility problem for existing
applications - only new options for new applications, if they choose to use
the option.  If the existence of the extension would break any existing
applications or require any actions upon their part, then I would agree that
this spec should be marked as updating RFC 7515.  But as it is, it's just a
spec using the IANA registry to register a new header parameter value.  We
certainly don't want to set the precedent that every new header parameter
registration will also require updating RFC 7515.

Jim, I believe that the thoughts above also address the two questions in
your October 18th note in the same thread.  Please let me know if you
disagree.

                                                            -- Mike

From: Manger, James [mailto:[email-masked]] 
Sent: Thursday, October 22, 2015 9:32 AM
To: Jim Schaad; Mike Jones; [email-masked] <mailto:[email-masked]> 
Subject: RE: [jose] JWS Unencoded Payload Option spec addressing WGLC
comments

Unfortunately Mike, the signature validation will not fail. By design
draft-ietf-jose-jws-signing-input-options mimics RFC7515 in using "bytes
before the 2nd dot" as the bytes to sign/verify. Consider a signer choosing
the b64=false option from draft-ietf-jose-jws-signing-input-options to sign
the 12-byte message "IOU_5000_USD". The header is
{"alg":"HS256","b64":false} giving the JWS:

A verifier that only understands RFC7515 JWS interprets this as a normal JWS
with an unknown but ignorable header member. The signature is still over
eyJ..USD so it still verifies. The verifier then base64url-decodes the IOU..
part to get the validly-signed 9-byte content (in hex) 20 E5 3F E7 4D 34 FD
44  83.

The two dots ensure the bytes signed when b64=false can never look like
bytes signed according to RFC7515.

draft-ietf-jose-jws-signing-input-options should probably do this in
addition to setting the crit field (so you can get a meaningful error
message of "unsupported variety of JWS", instead of "signature failure" that
could have all sorts of causes).

>From RFC7515 JWS, it would be perfectly reasonable to store a collection of
compact-serialized-JWSs as comma-separated values - since a RFC7515
compact-serialized-JWS cannot contain a comma.
draft-ietf-jose-jws-signing-input-options breaks that perfectly reasonable
choice as now an unencoded non-detached JWS can have any bytes and still be
called a compact-serialized-JWS. Saying
draft-ietf-jose-jws-signing-input-options updates RFC7515 is the minimum
required to note this, though that isn't really adequate. A better solution
is to not allow an unencoded non-detached message to be called a
compact-serialized-JWS: either don't define this combination, or call it
something else (eg JWS raw serialization).

--

James Manger

From: Jim Schaad [mailto:[email-masked]] 
Sent: Thursday, 22 October 2015 9:53 AM
To: 'Mike Jones'; Manger, James; [email-masked] <mailto:[email-masked]> 
Subject: RE: [jose] JWS Unencoded Payload Option spec addressing WGLC
comments

Does making 'crit' not required open one up to the possibility of an attack
along the following lines:

4.      Claim that the validator should have failed validation and not
performed the signed command

Jim

From: jose [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Wednesday, October 21, 2015 2:16 PM
To: Manger, James <[email-masked]
<mailto:[email-masked]> >; [email-masked]
<mailto:[email-masked]> 
Subject: Re: [jose] JWS Unencoded Payload Option spec addressing WGLC
comments

As I see it, explicitly updating JWS isn't necessary, since JWS established
the JSON Web Signature and Encryption Header Parameters Registry to allow
for additional Header Parameters to be defined, and so implementers are
expected to refer to the registry and gracefully handle the possibility of
extensions registered there.  The JWS Unencoded Payload Option specification
registers such an extension.

As to whether "crit" is required, "crit" is only necessary if an explicit
directive is required that the validation must fail if the header parameter
is not understood.  However, in this case, if "b64" is not understood and
simply ignored, the validation will fail without needing to use "crit",
since the signature validation will fail.  Thus, the use of "crit" is
unnecessary for "b64".

                                                                -- Mike

From: Manger, James [mailto:[email-masked]] 
Sent: Tuesday, October 13, 2015 7:55 PM
To: Mike Jones <[email-masked]
<mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]>

Shouldn't draft-ietf-jose-jws-signing-input-options update RFC 7515 "JWS"?
That seems quite important as draft-ietf-jose-jws-signing-input-options
changes the meaning of valid JWS messages (new "b64" field that cannot be
ignored, but is not listed in "crit"), and allows a bunch of previously
invalid chars in JWS Compact Serializations (invalidating the JWS definition
of Compact Serialization as a "URL-safe string").

--

James Manger

From: jose [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Wednesday, 14 October 2015 10:49 AM
To: [email-masked] <mailto:[email-masked]> 
Subject: [jose] JWS Unencoded Payload Option spec addressing WGLC comments

Draft -03 of the JWS Unencoded Payload Option specification addresses the
working group last call comments received.  Thanks to Jim Schaad, Vladimir
Dzhuvinov, John Bradley, and Nat Sakimura for the useful comments.  Changes
were:

*         Allowed the ASCII space character and all printable ASCII
characters other than period ('.') in non-detached unencoded payloads using
the JWS Compact Serialization. 

*
https://tools.ietf.org/html/draft-ietf-jose-jws-signing-input-options-03
<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf
.org%2fhtml%2fdraft-ietf-jose-jws-signing-input-options-03&data=01%7c01%7cMi
chael.Jones%40microsoft.com%7c67566ac2856449dd329b08d2d442d2c8%7c72f988bf86f
141af91ab2d7cd011db47%7c1&sdata=cwfExLlgEK11IEBTdvKI63EI6xNBi1JTV0KVipTf8JU%
3d> 

*
http://self-issued.info/docs/draft-ietf-jose-jws-signing-input-options-03.ht
ml
<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fself-issued
.info%2fdocs%2fdraft-ietf-jose-jws-signing-input-options-03.html&data=01%7c0
1%7cMichael.Jones%40microsoft.com%7c67566ac2856449dd329b08d2d442d2c8%7c72f98
8bf86f141af91ab2d7cd011db47%7c1&sdata=5nAlXMo6uPDM600pp0Kf1JQliQ4maLZc5eCMKf
zCdQ8%3d> 

                                                                -- Mike

P.S.  This note was also published at http://self-issued.info/?p=1465
<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fself-issued
.info%2f%3fp%3d1465&data=01%7c01%7cMichael.Jones%40microsoft.com%7c67566ac28
56449dd329b08d2d442d2c8%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=L6oZmQ6
tOl1eW%2fmh9zyorKeY4ouQZTGMn4o9Zid5snk%3d>  and as @selfissued
<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftwitter.co
m%2fselfissued&data=01%7c01%7cmichael.jones%40microsoft.com%7c3a69db7b8b6c4d
47da0f08d2937a3d82%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ggurSMkRVW%2
bR8Nv93Mnbsf16CmVGqfjB9lW8SV5gAKM%3d> .

---

From: Mike Jones <[email-masked]>
Date: Tue, 3 Nov 2015 00:39:14 +0000

You're right Jim, that my "prohibited" language below was too strong.  The proposed language on when "crit" is needed below will handle the case where the application decides to ignore the intended usage and dynamically switch between JWS objects with both "b64":true and "b64":false.

                                                            -- Mike

From: Jim Schaad [mailto:[email-masked]]
Sent: Monday, November 02, 2015 8:36 PM
To: Mike Jones; 'Manger, James'; [email-masked]
Subject: RE: [jose] JWS Unencoded Payload Option spec addressing WGLC comments

From: Mike Jones [mailto:[email-masked]]
Sent: Monday, November 02, 2015 6:23 PM
To: Manger, James <[email-masked]>; Jim Schaad <[email-masked]>; [email-masked]
Subject: RE: [jose] JWS Unencoded Payload Option spec addressing WGLC comments

[JLS] I would disagree that this is prohibited in the section referred to.  The text says "it is intended" this is not that say as saying you MUST only use one.

                                                            -- Mike

From: Manger, James [mailto:[email-masked]]
Sent: Thursday, October 22, 2015 9:32 AM
To: Jim Schaad; Mike Jones; [email-masked]<mailto:[email-masked]>
Subject: RE: [jose] JWS Unencoded Payload Option spec addressing WGLC comments

--
James Manger

Jim

                                                                -- Mike

--
James Manger

                                                                -- Mike

---

From: "Manger, James" <[email-masked]>
Date: Wed, 4 Nov 2015 18:19:33 +1100

Mike,

draft-ietf-jose-jws-signing-input-options section 6 "Intended Use by Applications" feels a bit silly. If "b64" is "not intended to be dynamically varied with different payloads" then why are we making it a per-message field?
If an "application context" needs to pick either JWS-without-b64 or JWS-with-b64-false, but never both, then don't let "JWS" be a name than encompasses both - because that is the name apps will use.
"Application context" is itself a dodgy concept here. The point of standardizing JWS is that it works the same regardless of context (so a common library can be used in many contexts). Of course a new feature (like unencoded payloads) can break old apps, but the new feature mustn't silently succeed with the wrong semantics.

The very least (and it isn't nearly enough) there need to be another Security Considerations paragraph:

  A JWS using these signing options can be successfully verified but give the wrong payload if it is ever consumed by a JWS implementation that does not understand these options. Consequently, these options MUST only be used when the signer can guarantee that every possible legitimate verifier has implemented this specification.

--
James Manger

From: Mike Jones [mailto:[email-masked]]
Sent: Tuesday, 3 November 2015 11:39 AM
To: Jim Schaad <[email-masked]>; Manger, James <[email-masked]>; [email-masked]
Subject: RE: [jose] JWS Unencoded Payload Option spec addressing WGLC comments

                                                            -- Mike

From: Jim Schaad [mailto:[email-masked]]
Sent: Monday, November 02, 2015 8:36 PM
To: Mike Jones; 'Manger, James'; [email-masked]<mailto:[email-masked]>
Subject: RE: [jose] JWS Unencoded Payload Option spec addressing WGLC comments

From: Mike Jones [mailto:[email-masked]]
Sent: Monday, November 02, 2015 6:23 PM
To: Manger, James <[email-masked]<mailto:[email-masked]>>; Jim Schaad <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [jose] JWS Unencoded Payload Option spec addressing WGLC comments

                                                            -- Mike

--
James Manger

---

From: Mike Jones <[email-masked]>
Date: Wed, 11 Nov 2015 15:37:50 +0000

Draft -04 now contains security considerations text addressing the confusion about whether the payload is encoded or not that can be created by an attacker under some circumstances, as well as calling out cases in which there is no security problem.

Thanks again for your thoughtful reading of the draft.

                                                            -- Mike

From: Manger, James [mailto:[email-masked]]
Sent: Wednesday, November 04, 2015 4:20 PM
To: Mike Jones; Jim Schaad; [email-masked]
Subject: RE: [jose] JWS Unencoded Payload Option spec addressing WGLC comments

Mike,

--
James Manger

From: Mike Jones [mailto:[email-masked]]
Sent: Tuesday, 3 November 2015 11:39 AM
To: Jim Schaad <[email-masked]<mailto:[email-masked]>>; Manger, James <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [jose] JWS Unencoded Payload Option spec addressing WGLC comments

                                                            -- Mike

                                                            -- Mike

--
James Manger

---

From: Mike Jones <[email-masked]>
Date: Wed, 11 Nov 2015 15:37:55 +0000

This is addressed in new security considerations text in draft -04.  Thanks again for thinking through this case.

                                                            -- Mike

From: Jim Schaad [mailto:[email-masked]]
Sent: Thursday, October 22, 2015 7:53 AM
To: Mike Jones; 'Manger, James'; [email-masked]
Subject: RE: [jose] JWS Unencoded Payload Option spec addressing WGLC comments

Jim

                                                                -- Mike

--
James Manger

                                                                -- Mike