Re: Bag of Data Anti-pattern (was: Re: DID Spec Closure Process: Harmonize our two Cryptographic Key Material Proposals?)

Given Mike's comment with respect to biometrics, would we ever want a
public biometric template in the DID document or is a template always
proprietary and/or method-specific?

Adrian

On Thu, Jan 4, 2018 at 12:14 PM, Mike Lodder <mike.lodder@evernym.com>
wrote:

>
>
> On Thu, Jan 4, 2018 at 1:37 AM, =Drummond Reed <drummond.reed@evernym.com>
> wrote:
>
>> I'm late coming to this thread (just arrived back from vacation last
>> night—been catching up all day), so just few overall comments to grease the
>> skids for what I believe will be a very productive discussion of this topic
>> on tomorrow's DID Spec Closure call (10AM PT - all are welcome - see Susan
>> Bradford's message to the list with details).
>>
>> First, I've always chafed a little bit at the using the "bag of keys"
>> analogy to talk about the proposed "keys" array in Proposal #1 of the Cryptographic
>> Key Material Proposals for the DID Specification
>> <https://docs.google.com/document/d/13fp7V3v1nBuhxTI55Al8KLG2kyxFthBz-Ush-ZL58KA/edit#>
>> doc.
>>
>> Call it a "bag of keys" and comparing it to a braindead "data:..." field
>> is a little like saying a flat-file database is stupid because it doesn't
>> do joins. An array of the right kind of metadata to describe a particular
>> data structure (like a cryptographic key) can be every bit as useful as a
>> simple flat-file database. It's only a dumb "bag of keys" if you ignore the
>> proposed design, which: a) makes every key description object uniquely
>> globally addressable, and b) proposes a single property of each key
>> description object ("type") to describe all the required metadata to select
>> the proper key for any particular usage.
>>
>> The global addressability means that the DID document owner does not have
>> to treat the whole array as a single monolithic authorization structure,
>> but can create and uniquely address every single member of that array. So
>> the DID document owner can be as granular as needed with permissions over
>> key description objects.
>>
>> Secondly, I'm seeing a lot of support, including Joe's proposal, for
>> breaking out "purpose" from the rest of the type metadata describing a
>> member of this array. On tomorrow's call I want to ask two related
>> questions:
>>
>>    1. Can any of the experienced crypto engineers on the CG give a
>>    common example where the same key is used for more than one purpose?
>>
>> This depends on the algorithm but as most algorithms are using elliptic
> curves these days then there are only two I can think of: Signatures and
> Key Agreements. In the case of key agreements I could see this used for
> static certificate like public keys for bootstrapping a connection.
> Otherwise its recommended to not use static keys in order to have forward
> secrecy. Which means that all other uses are for signatures. Signatures can
> be used for either authentication (proving something about you) or
> authorization (proving you are allowed to perform a certain action like
> read a file or update a database). RSA is the only algorithm that the
> general populace would use for encryption. But if you're going to put a key
> in the DID Doc for encryption its most likely going to be used for the same
> purpose as key agreement for bootstrapping a connection as only the holder
> of the corresponding private key can decrypt the message. Perhaps someone
> would use it for one off messages but again its not recommended. So I
> believe its ultimately going to be used for authentication or
> authorization. I've always thought that keys in the DID document were going
> to be used for authorization proof that the DID document can be updated by
> a particular key. A private key should not be used by more than one person
> as this opens the door to impersonation. Instead another private key should
> be used by another party. If that party is going to be acting on my behalf,
> then I should sign a permission slip or have some indication that they are
> allowed to perform actions on my behalf signed by my private key. Similar
> to how certificates currently work, the root CA signs an intermediate CA
> who can then sign end user keys. I know the root CA is not directly
> interacting with me, but I know the intermediate CA is allowed to perform
> actions on their behalf.
>
>>
>>    1. Will it be more or less confusing to a developer to have purpose
>>    described in a separate property or to have it be part of the type name in
>>    a single type property?  If keys are used for anything other than
>>    updating the DID document, I think this should be DID method specific
>>    because it requires more details and how many details are required can be a
>>    deep rabbit hole.
>>
>> If the answer to #1 is "yes" and the answer to #2 is "less confusing",
>> then I can support breaking out "purpose" into a separate property. If not,
>> we should seriously consider the benefits of giving developers a single
>> property to match exactly the type of key they should be looking for any
>> particular application (and giving application developer a single URI
>> or JSON-LD name to use to specify the type of key to use with their
>> particular application).
>>
>> Thirdly, I support breaking out encodings as proposed by Dave so that the
>> same key could have multiple encodings.
>>
>> Lastly—and I'm going to push really hard on this (having just finished
>> Steven Levy's 18-year-old book Crypto
>> <https://en.wikipedia.org/wiki/Crypto_(book)>, which reads like it could
>> have been written yesterday)—IMHO the problem we are trying to solve with
>> this particular topic is KEY MANAGEMENT. As in the key management
>> <https://en.wikipedia.org/wiki/Key_management> needed to support public
>> key cryptography <https://en.wikipedia.org/wiki/Public-key_cryptography>.
>> To be really crisp about this, let me quote the introduction to the
>> Wikipedia article:
>>
>> *Key management* is the name of management of cryptographic keys
>> <https://en.wikipedia.org/wiki/Key_(cryptography)> in a cryptosystem
>> <https://en.wikipedia.org/wiki/Cryptosystem>. This includes dealing with
>> the generation, exchange, storage, use, crypto-shredding
>> <https://en.wikipedia.org/wiki/Crypto-shredding> (destruction) and
>> replacement of keys. It includes cryptographic protocol
>> <https://en.wikipedia.org/wiki/Cryptographic_protocol> design, key
>> servers <https://en.wikipedia.org/wiki/Key_server_(cryptographic)>, user
>> procedures, and other relevant protocols.[1]
>> <https://en.wikipedia.org/wiki/Key_management#cite_note-Turner-What-is-key-management-1>
>>
>> Key management concerns keys at the user level, either between users or
>> systems. This is in contrast to key scheduling
>> <https://en.wikipedia.org/wiki/Key_scheduling>, which typically refers
>> to the internal handling of keys within the operation of a cipher.
>>
>> Successful key management is critical to the security of a cryptosystem.
>> It is the more challenging side of cryptography
>> <https://en.wikipedia.org/wiki/Cryptography> in a sense that it involves
>> aspects of social engineering such as system policy, user training,
>> organizational and departmental interactions, and coordination between all
>> of these elements, in contrast to pure mathematical practices that can be
>> automated.
>>
>>
>> This DOES NOT mean I am opposed to DID documents including other types of
>> "proofs" that can be used for authentication, such as the oft-mentioned
>> biometric proof (which, to my understanding, still works as a type of
>> cryptographic key). But it DOES mean that IF those types of data structures
>> ARE NOT KEYS, then we should not be trying to manage them in a data
>> structure designed to communicate public keys.  When I hear biometric
>> proof on a public ledger I cringe because what exactly does this mean. If
>> it means by biometric data is open on the public, then anyone can copy and
>> use it to impersonate me. If its not–which I believe is the case here, then
>> it means its working like key and used for authentication or authorization
>> and its no different than a regular key EXCEPT that rotating it can be more
>> complex. Just like you say before, I believe DID documents are about key
>> management so I go back to why I wouldn't want biometric data on a public
>> ledger. I could be convinced otherwise but this is what I believe for now.
>>
>> They should go in a different branch of the DID document graph.
>>
>> That's all my thoughts for tonight—see you on the call tomorrow.
>>
>> =Drummond
>>
>>
>>
>>
>> On Wed, Jan 3, 2018 at 12:02 PM, Christopher Lemmer Webber <
>> cwebber@dustycloud.org> wrote:
>>
>>> Manu Sporny writes:
>>>
>>> > On 12/27/2017 02:16 AM, =Drummond Reed wrote:
>>> >> It would allow developers or applications who prefer "naive JSON" to
>>> >> use the DID document for basic key management with a simple array of
>>> >> keys described by type.
>>> >
>>> > Before proposing something, it's important to identify a
>>> > standards-making anti-pattern that we keep coming back to in this
>>> > discussion. Let's call it the "Bag of Data" anti-pattern for now, and
>>> it
>>> > goes something like this:
>>>
>>> [... snip ...]
>>>
>>> > Let's now apply this principle to what's being suggested in "Proposal
>>> > #1: Simple Flat Array of Key Description Objects":
>>> >
>>> > {
>>> >   "keys": [ ... ]
>>> > }
>>> >
>>> > This data structure raises the following questions:
>>> >
>>> > Q1. Are those keys the DID owns or any key that the DID document
>>> >     references?
>>> > Q2. Are all software applications allowed to add/remove any key in that
>>> >     array, or just a subset?
>>> > Q3. Can I put a biometric authentication mechanism in that array?
>>> > Q4. Can I specify a key reference into that array, or can I put
>>> >     complete key descriptions elsewhere in the document?
>>> >
>>> > As a developer, I could easily jump to the conclusion that:
>>> >
>>> > A1. All keys must go in this array, including descriptions of other
>>> >     people's keys.
>>> > A2. Any software application is allowed to manage any key in that
>>> array.
>>> > A3. Biometrics should not go in that array.
>>> > A4. I must put all keys in that array and nowhere else, even if they're
>>> >     buried deep in another subtree of the data structure.
>>>
>>> It may be useful to look at how having a more general key bucket can
>>> lead to some real security vulnerabilities.  First off, I really
>>> recommend reading this article:
>>>
>>>   https://sandstorm.io/news/2015-05-01-is-that-ascii-or-protobuf
>>>
>>> In that article a scenario is given where you use your key to respond to
>>> an arbitrary-looking random string in a challenge-response type system
>>> to prove that you are who you say you are.  Sounds good... except it
>>> turns out that that random looking string was actually a datastructure
>>> that was asking you to authorize a payment, and your client signs it.
>>>
>>>   "Oops, it appears you just signed a bank check after all – and you
>>>   were trying so hard not to!"
>>>
>>> We can easily imagine such attacks in our own domain.  Imagine someone
>>> is using their DID + key materials for the following purposes:
>>>
>>>  - In a peer to peer protocol where nodes are signing that yes, they
>>>    really did see another node produce this object at a particular time
>>>  - An authorization of payment, or anything else serious (surgery,
>>>    sharing of private information, selling your house, etc)
>>>
>>> Without distinguishing between the function of keys, it would be
>>> possible to trick a node into performing the former with a key in their
>>> general keys bucket but to use that object for the latter purpose.
>>> A verifier being presented the object in the context of the latter
>>> purpose (but which was signed by the node under the former purpose) may
>>> say "oh yes, all looks good here... go forward with that payment /
>>> surgery / sale of house!"
>>>
>>> That seems like a serious issue to consider?
>>>
>>>  - Christopher Lemmer Webber
>>>
>>>
>>
>
>
> --
> Mike Lodder
> Senior Crypto Engineer
>
>
>


-- 

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: https://patientprivacyrights.org/donate-3/