DID WG Public Key Discussion (2nd.) — Minutes
Date: 2019-11-13
See also the Agenda and the IRC Log
Attendees
Present: Michael Lodder, Ganesh Annan, Manu Sporny, Kenneth Ebert, Amy Guy, Michael Jones, Dave Longley, Yancy Ribbens, Orie Steele, Brent Zundel, Markus Sabadello, Oliver Terbu, David Lehn, Jonathan Holt
Regrets:
Guests:
Chair: Brent Zundel
Scribe(s): Kenneth Ebert
Content:
1. Public Key Formats
Michael Jones: I thought when we last met that to support interoperability we would support JWK as the key format for keys.
… Other key formats would be considered on a case-by-case basis.
… This is not what was written.
… I am disappointed by this outcome.
Dave Longley: I thought the consensus was that for each key type we would look at each key and select the most popular to recommend.
… There may have been misunderstanding on what the consensus was.
Michael Jones: The point of standards is to make choices for an international standard.
… Standards involves making choices.
… In my mind, the reason we were willing to allow a single non-json encoding is that we would have a standard for the json encoding.
… I hope we can a agree on JWK for all key types; secondarily consider other representations where there is a compelling reason.
Orie Steele: There is progress on what signatures are being used. And libraries.
… If we think in terms of “If a given key type is represented by a JWK, no processor should throw an error.”
… If you want something else, that should be ok, too.
… There is some support for PEM. There is some support for others.
Kenneth Ebert: mike-lodder: I don’t see why each method can’t choose a format. We shouldn’t force everyone to use just one.
Orie Steele: I think other formats such as hex or pem are just as interoperable.
Dave Longley: Interop should be the focus.
Daniel Buchner: Am I the only one not hearing anything?
Michael Lodder: agreed dlongley
Dave Longley: We could consider apps that are trying to understand did docs.
… I agree it makes sense to pick something for apps. Picking JWK might not be the best choice. We need to see how peoople are using the key types.
… This could help us avoid multiple representations for each type.
… Representing keys in their native formats could simplify our work.
Orie Steele: This discussion is not about things other than public keys (lets not drag ethereum into this) :)
Dave Longley: It might be better to represent a key in its native format.
… Another argument for not using JWK is that not all libraries adopted a new standard and forced the community to create conversion tools.
… This creates a interop burden.
Michael Jones: I agree with Orie that we agreed that no processor would err on JWK.
… Dave’s points about native formats are good.
… For RSA, ASN.1 would be problematic to convert.
Michael Lodder: Compressed Points vs Uncompressed for ECDSA
Michael Jones: For elliptic curves the native formats are all binary.
… Every processor of elliptic curves is already capable of conversion between base58 or base64 to binary.
… Library burden is small for the conversion of elliptic curves to JWK.
Daniel Buchner: I think that most methods under the covers could be using CBOR or other formats. On output can be in any format or representation.
… Having a universal output format has some benefits.
… I don’t know if this is compelling.
Daniel Buchner: In the native Method code, you should be free to use brainfuck or TypedArrays
Orie Steele: I think we have an opportunity to decide on a representation that will not cause errors. This does not preclude using other methods in your method.
Daniel Buchner: but what are we losing by saying we will output one format?
Manu Sporny: daniel - implementation complexity
Manu Sporny: daniel - the people that are opposed to that are concerned about implementation complexity
Daniel Buchner: So it’s more complex to know you’re going to get back the same format every time?
Manu Sporny: daniel - it’s complex to convert when you don’t have to today.
Daniel Buchner: But why would you ever error on any of them under this direction?
Orie Steele: Pem could even be the format. There will be methods that have multiple key formats. I prefer JWK.
Daniel Buchner: you’d just warn that it is unsupported
Dmitri Zagidulin: daniel: I think the main argument is the ol’ federalist vs state rights argument :) Does the core DID spec dictate a single key type, or do individual DID methods dictate a key type for themselves.
Manu Sporny: daniel - for example, if you use PEM today … zero conversion going to/from openssl … but if it’s JWK, then you have to go to/from that format to PEM
Ganesh Annan: can someone clarify what we mean by we don’t “error”? what is throwing the error? a resolver? a did library? etc.?
Daniel Buchner: Does the browser dictate HTML?
Daniel Buchner: why don’t they use Gopher?
Orie Steele: I would like to see better interop by saying that no one should err out on a single key format.
Manu Sporny: There are at least three suggestions.
… The spec will end up with MUST, SHOULD, or MAY.
Dmitri Zagidulin: +1 to gannan_’s question about clarifying what we mean about throwing an error
Daniel Buchner: Why not support Dart in the standard JS engines in browsers?
Manu Sporny: It the secondary representation a MUST or MAY.
Orie Steele: MUST support JWK, MAY support PEM, or vice versa.
Manu Sporny: selfissued would be happy with MUST be JWK.
Daniel Buchner: But you can convert to other formats, no?
Manu Sporny: Others including mike-lodder and dlongley would not be happy with that.
… From an editor’s perspective, the language we would use in unclear.
Manu Sporny: https://docs.google.com/spreadsheets/d/12dwUaAruKKpq3a3IfEMEMhpRhI7oM1tQnkmDbW2VGoU/edit
Manu Sporny: Survey of existing libs ^
Manu Sporny: DID Method implementer survey here: https://forms.gle/Hovf3irBJ5KwgXLQ6
Manu Sporny: There is a survey of existing libraries and did methods to gather information.
… This will help us determine what is currently in use.
… There are arguments being made without data behind it.
… Some people are fine without the mandate to use JWK. Don’t make my life more difficult by mandating JWK.
… There is not a single path to interoperability.
Dave Longley: MUST vs SHOULD from a implementors perspective.
… Cryptography is trying to make development simpler by using libraries to make simple methods.
Daniel Buchner: If multiple formats are allowed, I think we MUST have everyone who implements using a format/type commit to a common lib that encompasses every one in common usage, and they all swear to commit the resources necessary to maintain that lib in perpetuity
Dave Longley: If we just use ed25519, I would prefer a single representation. If we have to add JWK support to our node software, it will require additional work.
Daniel Buchner: That lib can depend on other modules, but we better have a simple, single lib that works in the most common envs that we track, update, maintain, and strongly protect
Dave Longley: Can we select a single JWK representation that we have to add, even though we don’t have a use for them right now?
… Did methods should not have to deal with the extra complexity that isn’t needed for the did method or the application.
… I’m interested to hear what mike-lodder who uses the same ed25519 that we do thinks?
Michael Jones: mike-lodder said “can’t we let the did methods choose their methods?
Michael Lodder: I’m less resistant to mandating ed25519 to base58
Manu Sporny: I agree with selfissued here… we don’t want the DID Methods defining what key representations they support, that’s the other extreme.
Michael Jones: As new key methods are added we have to keep adding new code.
Dave Longley: it may be significantly more difficult to revise DID method code (DLT technology) than application/resolution driver code
Michael Jones: I thought we agreed to limit the key formats to a finite set.
… All formats MUST be supported.
… Pick a small set that we can agree on.
Manu Sporny: All MUSTs?
Michael Jones: Yes.
Daniel Buchner: I agree there
Manu Sporny: I agree with selfissued here… we did say we’d limit DID Document public key formats.
Daniel Buchner: And not only MUST in the spec, but everyone here needs to pick up a shovel and commit to maintaining shared libs
Michael Jones: If we don’t, then the set will grow continually.
… The native formats are all binary for most new key formats.
Daniel Buchner: Should be a repo somewhere like DIF where we can aggressively maintain the lib to ensure devs have an option for use across common envs
Michael Jones: I hope we can agree on the call to define a format which always is supported and then add some other things.
Dave Longley: there are two different groups: DID method implementers and DID Doc consumers
Michael Jones: This is for the benefit of developers.
Daniel Buchner: Yeah, none of this should encumber the internal DID Method internal representations
Michael Lodder: from a DLT perspective, JWKs require more bytes,
Manu Sporny: Yes, but PEM/DER/ASN.1 is implemented everywhere
Manu Sporny: (not for elliptic curve)
Manu Sporny: and agree with selfissued there.
Dave Longley: agrees that ASN.1/DER is grossly over complicated … but it is implemented everywhere
Michael Jones: I could understand choosing pem, but its support for elliptic curves is not mature.
Orie Steele: https://w3id.org/security#publicKeyPem
Dave Longley: it is implemented for elliptic curve in OpenSSL
Orie Steele: On the question of pem is from my experiencing trying to use the universal resolver.
Daniel Buchner: Hell, i’d even like to see a spreadsheet with names of DID Method maintainers and what types they are introducing in the world, with an email, telephone numbers, and other ways to contact them if their support in the shared library lapsts
Orie Steele: I am not a did method implementor.
Daniel Buchner: *lapses
Orie Steele: I deal with pem and jwk all the time.
Daniel Buchner: I want to call someone and say “Buddy, pal, you wanted to use ASNPEMDAS v12.3.54564, so you need to get your module in this lib updated NOW, because your DIDs are circulating everywhere”
Orie Steele: I am asking for each did method MUST support JWK and pem. Or one or the other.
Jonathan Holt: I am a proponent of multi formats.
… It is onerous to keep up with all the different representations.
Daniel Buchner: Secp256k1 is
Michael Lodder: I don’t want to be stuck with JSON as the only format for keys which is what JWKs require
Daniel Buchner: it was recently added
Jonathan Holt: With JWK you are stuck with the represenrations in the registry.
Orie Steele: … its a good idea to use unregistered crypto in standards? … shouldn’t we register the crypto we use?
Daniel Buchner: It was added in direct response to this ecosystem’s desire to have it
Jonathan Holt: It is behind the times in keeping up with the most recent curves.
Michael Jones: That registry is extensible by anyone who wants to register the algorithm with a spec.
Michael Lodder: Part of good crypto is also considering constant time operations. I haven’t seen a constant time JWK implementation
Daniel Buchner: If the decision is made to select more than one format, I think it is not in the best of the world because it can cause failures.
Michael Lodder: CS is important when designing end user handlers where timing and power attacks are real
Daniel Buchner: A set of modular libraries that is maintained will be critical.
Michael Lodder: and I doubt I ever will see a JWK CS implementation
Manu Sporny: What is next? I will continue to gather data regarding did methods to base decisions on.
… I would like to make a few proposals.
Orie Steele: +1 for removing options
Michael Lodder: I would like to see a fixed set of encodings that are allowed like a key MUST be encoded in one of the following
Kyle Den Hartog: Yeah I’m good for that
Proposed resolution: Standardize on JWK as the only public key format that MUST be supported. (Manu Sporny)
Michael Lodder: -1
Yancy Ribbens: -1
Orie Steele: -1
Dave Longley: -1
Kenneth Ebert: -1
Manu Sporny: -1
Jonathan Holt: NO
Ganesh Annan: -1
Jonathan Holt: -1
Oliver Terbu: -1
Michael Jones: +1
Proposed resolution: Standardize on JWK and PEM as the only two supported key formats for at least RSA, secp256k1, secp256r1, ed25519, Curve25519. At least ONE format MUST be supported. (Manu Sporny)
Manu Sporny: That one will not fly.
Michael Lodder: -1
Dave Longley: -1
Yancy Ribbens: -1
Daniel Buchner: +1
Michael Jones: -1
Orie Steele: +1
Jonathan Holt: -1
Kenneth Ebert: -1
Manu Sporny: -1
Orie Steele: rofl dead
Manu Sporny: Nope.
Proposed resolution: Standardize on JWK (FormatA) and a per key type format as the only two supported key formats for at least RSA, secp256k1, secp256r1, ed25519, Curve25519. At least ONE format MUST be supported. (Manu Sporny)
Michael Jones: +1
Orie Steele: +1
Daniel Buchner: +1
Dmitri Zagidulin: +1
Michael Lodder: +1
Markus Sabadello: +1
Dave Longley: +1 to OR
Yancy Ribbens: +1
Brent Zundel: +1
Oliver Terbu: 0
Manu Sporny: This means JWK for everything or just BASE58 raw bites encoding
Kenneth Ebert: +1
Manu Sporny: +0.5
Jonathan Holt: -1
Ganesh Annan: +1
Michael Lodder: not just base58
Michael Jones: 0
Daniel Buchner: lol 0.5, that was funny
Manu Sporny: OK
Proposed resolution: Standardize on JWK (FormatA) and a per key type format as the only two supported key formats for at least RSA, secp256k1, secp256r1, ed25519, Curve25519. At least TWO formats MUST be supported. (Manu Sporny)
Michael Jones: +1
Orie Steele: -1
Dave Longley: -1
Michael Lodder: -1
Yancy Ribbens: -1
Kenneth Ebert:
Kenneth Ebert: -1
Manu Sporny: You have to support both.
Ganesh Annan: -1
Manu Sporny: THis is too gauge support only.
Manu Sporny: -0.5
Michael Jones: There is a difference between producers and consumers
Manu Sporny: Yes more polls would be needed.
Orie Steele: thanks for that elimination process!
Dave Longley: +1 to there being a difference between producers and consumers and DID methods/applications
Dmitri Zagidulin: All are for interop. Our main audiences are did method developers and app developers.
… Most will use one method or rely on a universal resolver.
Kyle Den Hartog: skip me
Dmitri Zagidulin: The burden is concentrated.
Kyle Den Hartog: I’ll type
Dave Longley: There is a difference between producers and consumers; we should explore this further.
Michael Jones: I think there was agreement about having all the key representations in the spec.
Proposed resolution: There will be a small fixed set of key representations for DID documents described in the spec (Michael Jones)
Michael Jones: +1
Manu Sporny: +1
Orie Steele: +1
Ganesh Annan: +1
Dave Longley: +1 plus – you can extend to add more but not for the same key type
Tobias Looker: +1
Markus Sabadello: +1
Oliver Terbu: +1
Michael Lodder: +1
Brent Zundel: +1
Kenneth Ebert: +1
Yancy Ribbens: +1
Michael Jones: Good
Dave Longley: i think my main issue right now is figuring out which software MUST support these different key representations is unclear
Michael Jones: Can manu create a PR to say that there is a fixed set?
Manu Sporny: I could do it if you will write some concrete text.
Orie Steele: great progress, thanks all!
Brent Zundel: Thanks all for the progress today.
Orie Steele: +1
Michael Lodder: yes
Ganesh Annan: +1
Michael Jones: +1
Kenneth Ebert: +1
Kyle Den Hartog: +1
Tobias Looker: +1
Brent Zundel: Do we need another special call?
Michael Lodder: thanks
Brent Zundel: Yes. We’ll schedule another call.
Dave Longley: another important point to consider … JWK has a number of places that would allow someone to sneak in PII – which is a problem for DID methods that use blockchain tech… so DID method software/validators that accept JWK may have to reject some JWKs and not others.
Dave Longley: none of this impacts applications on the consumer side.