Skip to content

Conversation

@bochaco
Copy link
Contributor

@bochaco bochaco commented Apr 5, 2019

No description provided.

@bochaco bochaco requested a review from nbaksalyar May 6, 2019 17:53
Copy link
Contributor

@joshuef joshuef left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bochaco "a private MutableData entry that the resolver cannot decrypt will need to be assumed as being unencrypted."

This part isn't super clear to me. Is the base point that we can't know if encrypted or no, so no effort is made to decrypt unless a private key is provided?

@bochaco
Copy link
Contributor Author

bochaco commented May 7, 2019

Yes, correct @joshuef , even if we had a decryption key provided with some mechanism, there is nothing we can do if it fails to decrypt. An straight answer could be, well we fail the request in such cases, but we also need to always remember that applications could corrupt data, e.g. by adding non-conformant data entries, which we should ignore if we want to be able to still read the data that is valid. So basically, it's about doing the best we can to extract the data which follows the convention/spec/format our resolver conforms to, as a way to coexist with other formats in the same data resource/object. This is how I see it at least.

@bochaco
Copy link
Contributor Author

bochaco commented Aug 6, 2019

This is obsolete now, and all changes needed as per last research are covered with PR #337

@bochaco bochaco closed this Aug 6, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants