DID WG Topical Call on Key Formats and JOSE — Minutes

Date: 2020-07-21

See also the Agenda and the IRC Log

Attendees

Present: Manu Sporny, Markus Sabadello, Tobias Looker, Dave Longley, Kyle Den Hartog, Brent Zundel, Michael Jones, Jonathan Holt, Daniel Buchner, Drummond Reed, Orie Steele

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Dave Longley, Brent Zundel

Content:

Brent Zundel: https://github.com/w3c/did-core/labels/keys

Brent Zundel: https://github.com/w3c/did-core/labels/jose

Manu Sporny: Should we restrict JWK in spec? https://github.com/w3c/did-core/issues/240

Manu Sporny: first issue that needs resolving
… this raises the question: there seem to be two lines of thought: if the did core spec says use the full breadth of JWK then we can’t restrict it. But if we can’t do that, then anything you can do with JWK goes.
… that could lead to putting private keys in a DID Document, etc.
… other things related to some curves we may not want to support. what that does is open up the security attack surface more broadly than we want.

Brent Zundel: so, first question is do we want to restrict. if yes, what things?

Manu Sporny: we should start broad and go narrow.

Dave Longley: did methods can and will restrict what jwk things can go in a did doc.
… I don’t think we can restrict from a spec perspective, but should have very clear privacy statements around what’s involved.
… we might be able to say must nor use a private key, but most other things may no be able to restrict.

Kyle Den Hartog: dlongley hit it on the head. I’m fine with restricting private keys, that’s beneficial. on the other hand, the kitchen sink didn’t happen by chance
… normative ideally, but a note if that’s where consensus is.
… I think we leave that up to methods

Markus Sabadello: I think its only partially method specific. they should restrict what sort of keys you can put in a did document.
… while
… I agree that this is a method concern to a certain extent, we do need to address this is did core.

Dave Longley: a note to everyone that may not know: the JWK format can contain all kinds of arbitrary information, not just key material

Michael Jones: we did see an actual bank put an actual private key into some certification input, so I’m all for security statements like, “you must not put an unencrypted private or symmetric key in a did document”
… I’m fine with an implementation guide recommending curves and algorithms, but various countries have different requirements, so we should avoid normative statements.
… another good reason to avoid this is algorithms will come and go: we should recommend listening to CFRG guidance

Jonathan Holt: the “we know best” mentality is a slippery slope

Kyle Den Hartog: is there ever a time when a did document is going to only be available to a private system where a private key might be appropriate?

Manu Sporny: https://www.iana.org/assignments/jose/jose.xhtml

Manu Sporny: let’s link to the JOSE registry
… the default is everything listed there can be done
… that is very broad
… I’m hearing people say “no RSA SHA1”
… but if we don’t kick that out it is legal. We should throw errors for things that are known to be bad:
… RSA SHA1, MD5, no private keys
… I’m hearing two things: don’t be normative, and people can do terrible things that are avoidable
… it is possible for did documents to be used privately in all sorts of ways, but we want to prevent did documents from being used in terrible ways
… for example, will the test suite fail if there is a did document with a private key?

Brent Zundel: .. I argue that it should

Michael Jones: The JOSE registry includes algorithm guidance

Michael Jones: For instance…

Michael Jones: RS1 RSASSA-PKCS1-v1_5 with SHA-1 JWK Prohibited

Michael Jones: HS1 HMAC using SHA-1 JWK Prohibited

Jonathan Holt: two instances: ethereum and proving project. cross client encryption of private keys. not sure why that would be used. also microsoft using double key encryption.
… this is hard because there are public key fingerprints using sha1

Michael Jones: There’s perfectly good key distribution methods that aren’t did documents
… the JOSE registry already contains guidance for the registered algorithms
… at least for JWK there is a clear source for guidance. We could have non-normative statements encouraging folks to follow that guidance.
… and this isn’t restricted to JWK, PEM and other formats can share private keys as well

Kyle Den Hartog: I’m satisfied with no private keys, but I wanted to bring that up. Regarding DId Core, I have a potential proposal

Markus Sabadello: I agree with others, private keys shouldn’t be in valid did documents
… I think we all agree on that. We should focus on algorithms and flexibility

Dave Longley: I do want to focus on algorithms etc, but you can put a lot of arbitrary data in a JWK, so people should be aware of that as we move forawrd.

Dave Longley: so we can already put anything into a DID document in the same way – but we need people to be careful with using out-of-the-box JWK/JOSE libraries that might allow data that people aren’t expecting

Dave Longley: and encrypted use too :)

Manu Sporny: my concern is that if we keep making general statements, it will be hard to get something concrete to put in the spec.
… there are a couple of dangerous things tat we do want to say: don’t do that, throw an error
… the other point is that you can put anything in a JWK, the way they are currently expressed is just as a JSON object, you could throw the constitution in there.
… so do we restrict them to only JWK properties? if not, what are the GDPR consequences of that?
… I want to get to something concrete
… if you see a JWK property with a d in it, throw an error.
… I think we could start general, but I’d like to propose throwing an error if there’s a d value in a JWK

Michael Jones: there’s 3 things
… d is only meaningful relative to the key type
… part of the reason JWK is extensible is different key types may have wildly different structures
… you can put anything in it is a complaint about JSON, not JWKs
… people are strangely silent about symmetric keys, which is also bad. Both should be restricted.

Daniel Buchner: I’m curious where the spec would mandate language to fail certain things. validation typically for the patches of your document is not happening at ingest, but at resolution.
… so at that point it may be too late.
… if folks want a scalable system, think about the requirements on ingest, versus the firehose.
… I have concerns for what the language would be that mandates certain checks.

Kyle Den Hartog: One of the things that Daniel brings up is important to consider. I don’t know how (indy? india?) is going to do DID compliance. It would have to be done by the DID resolver.
… When it comes to the different values that come inside here. We’ll see a variety of a different kind of things to be used. Some of us are looking at how to use certificates and bind those that have already been issued to a DID.
… I think we’re going to want to say don’t use RSA in general at some point because of various attacks. As much as I’d like to restrict these kinds of things, I don’t think it’s the WG’s job to restrict it because it may cause undue implementation burden in the future.

Michael Jones: I agree that we shouldn’t be writing runtime requirements. The text we’re talking about should be in the security/privacy considerations section.
… I’m not in favor of code that says, if key type == ‘ec’ and element ‘d’ occurs, then fail.

Manu Sporny: That was the exact proposal I was getting ready to put in here. So, I wanted to speak to something Kyle said.
… I think saying that you want to limit RSA but the rest of the world may want to use it so it shouldn’t be limited – is a false choice. There are things that all of us agree that there are universally bad things to do but I’m concerned we’re not going to do anything as a group to put enforcing language in there.
… The group that has the authority over this is us. Throwing our hands up and saying it’s somebody else’s issue is problematic. I’m not saying that is what anyone in the group is saying, but in effect, it will be what happens because no one else will make statements about what can normatively be in a DID Document. By saying nothing we are allowing it.
… We are allowing the thing we say nothing about. I’d like to get a feel from the group on whether or not they’d be willing to say something about private keys in the document.

Michael Jones: -1

Manu Sporny: +1

Michael Jones: This is a security consideration

Orie Steele: -1

Drummond Reed: +1

Manu Sporny: I tried to pick the language carefully, someone has tried to express a private key in the DID Document – are we going to say something normatively about that in the spec.

Markus Sabadello: +1

Markus Sabadello: I would support this. I also wanted to add a question, what might we want to restrict beyond private keys. Talking about public keys – we say we need a type for verification methods, those types are in the DID spec registries.
… Some types are very restrictive and others are more flexible. There was some discussion around cryptographic agility, some types make conscious choices to avoid security problems.
… On the other hand, some types, especially the JWS key that Orie had been working on, there was some discussion on whether it should be more restricted.

Michael Jones: Again, there’s no reason to enforce at runtime, every security property that you could imagine anyone doing wrong. You could check implementations once and usually catch this. We shouldn’t mandate if statements for every bad thing that may occur. That’s not a normal way to write a spec.
… I oppose the statement that we’re doing nothing. If we put language in the security consideration section it’s still normative.

Jonathan Holt: I don’t object to this as we are already explicitly stating that this is decentralized PUBLIC key infrastructure, not private key, so it is implicit, but there may be use cases where this is a solution and we have now painted ourselves in a corner

Michael Jones: We’re just not going out of our way to say you must throw an error if you dereference a null pointer in C, it’s just what happens.

Daniel Buchner: This is navel gazing

Manu Sporny: dbuc_, then propose something that the group will agree on. :)

Daniel Buchner: if you inflict this sort of processing on ingest, you are effectively declaring that you are not intending to implement scalable DID Methods

Daniel Buchner: (and I honestly think many folks don’t intend to, whether they are aware of it or not)

Kyle Den Hartog: I didn’t vote because I had a question for this – feel free to ignore it if too esoteric. Right now, we’re just putting free form JSON into things, and it’s not processing. So it’s still compliant but doesn’t solve the problem. I’m wondering, how is this language actually helping us. What a DID Document processor is is still fuzzy in my eyes. Is it a resolver, a ledger?

Daniel Buchner: This is like saying you MUST not use a entropy-weak brainwallet secret for your bitcoin txns

Daniel Buchner: It’s like “Cool story, but we can’t check that on ingest, because it’s impractical”

Kyle Den Hartog: I’m not certain this restriction is going to give us the teeth that we’re looking for or it will cause problems for implementations.

Orie Steele: My comment is similar to Kyles and why I voted -1. I don’t know what a DID Document processor is here. There is a use case for putting private keys in DID Documents which is for test scenarios. Those processors may need to handle that. The question is – does a DID Doc processor handle those or is it only for production? I’m unclear on this.
… If there’s a way to specify a production/a DID Doc returned from a Verifiable DID Registry should not have that data that’s language I can get behind, but otherwise it’s too difficult to figure out.

Manu Sporny: What I meant by processor was a producer or a consumer. I was trying to be vague – as long as it goes somewhere we say that it’s bad to do. We can put it in the production code that says you must not produce a ‘d’ value in a DID Document in anything other than a test scenario. Those are valid ways to put normative language about what should be produced/not produced.

Orie Steele: I’m fine with it with language “ outside of test scenario”

Manu Sporny: Same thing on the consumer side. A consumer in a “public mode” should do something with that ‘d’ thing – it’s identified as a known bad value. We know it’s a grenade, don’t bring it into the tent.
… That’s where I think the language could go. The other thing I think we could state is that we can point to the registries on what’s acceptable and what isn’t. We can update that more regularly than the spec. We can be more responsive to changes in the crypto community to talk about those things in the registry.

Orie Steele: no, its like saying iss is required in JWT.

Manu Sporny: We can potentially even start out as overly restrictive and then pull back without having to publish a new spec. I don’t want people to get wrapped around the axle on how we get the language in there, but that we say we’re going to get some kind of language around these things.

Brent Zundel: Could we phrase the language around producers rather than processors/consumers – would that make it more palatable?

Michael Jones: Two things. Kyle made a resolution that we never finished considering. I think we should do that rather than this new one, first. Secondly, I would like to have language that people designing profiles should consider the algorithm recommendations in the JOSE registry.

Proposed resolution: did-core will restrict usage of prohibited algorithms and further restrictions can be set by did method authors (Kyle Den Hartog)

Michael Jones: I don’t know why we didn’t finish Kyle’s resolution.

Kyle Den Hartog: +1

Dave Longley: +1

Michael Jones: +1

Orie Steele: +1

Tobias Looker: +1

Brent Zundel: +1

Drummond Reed: +1

Manu Sporny: +0 – I think there’s something better that we can do, don’t know if that’ll have any effect.

Brent Zundel: I see no objections.

Resolution #1: did-core will restrict usage of prohibited algorithms and further restrictions can be set by did method authors

Kyle Den Hartog: +1 to pointing at the JOSE registry for algorithms

Manu Sporny: The reason I didn’t +1 the proposal is that I’m not clear on who is designing what a prohibited algorithm is. Multiple ways to do that – one way is to point to the JOSE registry and say don’t use anything prohibited in there. And I agree with that, we should do that. But I think we should go further. There are things that are specific to DID Docs that we need to say more on.
… Like don’t use a ‘d’ in a JWK.
… I’m taking that as built-in that you don’t use prohibited things in the JOSE spec, I took that as a given but we should add that spec text to be clear.

Daniel Buchner: Are we doing this for all key types and formats?

Orie Steele: See also: https://tools.ietf.org/html/rfc7517#section-9.2

Kyle Den Hartog: As a part of the private aspect of it… what if we say, DID Document producers must not produce JWKs that include a private parameter information class as a part of the JWK parameters. The JWK spec already says what are private and what are public factors.

Manu Sporny: also, agree with Markus

Manu Sporny: “For example…”

Markus Sabadello: I think it’s too narrow to make these statements just about JWKs. You can have an ed25519 verification key, but you could have a property that says “privateKeyBase58”. We should write this in a way that’s a bit broader.

Orie Steele: yes, privateKeyBase58 is actually a common member of key classes.

Proposed resolution: JWK formats MUST NOT include JWK parameters that are listed as “Private” in the parameter information class (Kyle Den Hartog)

Manu Sporny: Agree with Markus and Kyle. I like the proposal, which is to talk about the information class.
… If you look at the JOSE registry, there are information classes and we don’t want to allow any kind of private information class expressed in a public DID Document.
… And we can say, for example, and mention some of the things from the JOSE registry.
… Then we can apply that to any key expression in the key document. I think if we do that, we can write concrete tests on producers.

Orie Steele: +1 to what Manu is saying.

Markus Sabadello: +1

Dave Longley: +1

Brent Zundel: One problem with the proposal is we’re missing the producer language.

Kyle Den Hartog: I will modify it because I was going to add a recommendation for consumers as well.

Proposed resolution: DID Document producers MUST NOT include JWK parameters that are listed as “Private” in the parameter information class and it’s recommended that consumers not accept DID Documents with JWK private parameter information class data (Kyle Den Hartog)

Orie Steele: +1

Orie Steele: prefer to generalize.

Manu Sporny: Can we generalize this more?

Tobias Looker: +1 to generalize

Kyle Den Hartog: I’d like to generalize more.
… I’m not sure how to reference things – happy to do it if possible.

Tobias Looker: The above is missing “Private”?

Tobias Looker: Sorry mis-read

Proposed resolution: Producers that express cryptographic values in DID Documents MUST NOT include Parameter Information Classes that are private in nature. For example, JWK formats MUST NOT include JWK parameters that are listed as “Private” in the parameter information class. (Manu Sporny)

Drummond Reed: +1

Markus Sabadello: +1

Manu Sporny: +1

Dave Longley: +1

Orie Steele: +1

Kyle Den Hartog: +1

Markus Sabadello: The term “parameter information class” that is a JWK specific or is it generic? Doesn’t matter for the proposal, for actual spec text we’ll need something else.

Manu Sporny: Yes, for the spec we’ll need to define what that means.

Kyle Den Hartog: We may not have time for this, but it’s related. Around the type naming. One proposal is for the types to be more generic than just verification key.

Resolution #2: Producers that express cryptographic values in DID Documents MUST NOT include Parameter Information Classes that are private in nature. For example, JWK formats MUST NOT include JWK parameters that are listed as “Private” in the parameter information class.

Kyle Den Hartog: I’ll drop a link in.

Manu Sporny:

Kyle Den Hartog: Consumers that consume cryptographic values from DID Documents SHOULD NOT consume Parameter Information Classes that are private in nature. For example, JWK formats including JWK parameters that are listed as “Private” in the parameter information class MUST NOT be consumed.

Manu Sporny: What’s the reasoning for SHOULD NOT?

Orie Steele: …we have no write side protection for decentralized systems.

Kyle Den Hartog: In both side tree and the indy ledger, I’d expect those to be classified as consumers. By doing that on ingestion point it affects it as a scalability point and that could be rejected. You’d expect it to come onto the ledger … but no longer provide that data back. It’s a performance issue.

Orie Steele: It’s more like, there’s no right-side verification validation. Some systems are append-only – and people can’t stop people from putting data on ledgers. Sometimes it’s not possible to enforce it.

Brent Zundel: We made good progress, we will continue. See you all next week.

1. Resolutions