Add UTF-8 encoding option to the envelope document and proto.

[AdamZWu]

For issues #63

[MarkLodato]

This probably needs a version bump and a note about backwards compatibility.

[AdamZWu]

Thanks so much for all the editing suggestions!

Regarding versioning, I don't think it is originally versioned; and also there is no field defined in the envelope to reflect versions. I guess we will need to add a version field in the envelope, don't we?

Assuming we embrace Semantic Versioning, do we start (current) from 1.0 and bump to 1.1?
Or start from 0.1 and bump to 1.0, like in-toto? But the latter is a major version bump...
Or maybe start from 0.1 and bump to 0.2, to keep this a minor version bump?

[MarkLodato]

Sorry, I meant versioning of the spec itself. It's currently v1.0. I lean towards calling this v1.1 rather than v2.0 since the signature is still backwards compatible and contains the string DSSEv1. Then again, I could be convinced to call it v2.0 since newly created envelopes would be unreadable by old clients.

I personally don't think a version number is needed in the envelope. Instead of going by version, you can go by what fields are present. A v1.1/v2.0 envelope with payload looks just the same as v1.0. I worry that a version field will lead to unnecessary incompatibility or worse, bugs or vulnerabilities.

[AdamZWu]

Thanks for clarifying. I bumped up the version in envelope.md and added the "change history" section.

[trishankatdatadog]

@MarkLodato Not sure that a version field would lead to vulnerabilities: at least, I don't see why that is necessarily more insecure than conditionally parsing fields. At least a version field would give you an unauthenticated hint you don't need to blindly trust, but for which you know you need to double-check by looking for other, expected fields.