Open mmccool opened 4 years ago
See also https://w3c-ccg.github.io/ld-proofs/, which are designed for JSON-LD files, and are what DID document integrity proofs are based on.
I think we agree we should adopt a common standard for signing json-ld documents. However, we should review the proposed json-ld signing spec above (ld-proofs) to ensure it has the "right stuff".
As noted in the proposed new section 7.4 in the security guidelines document, there are alternatives like JWS that might be considered for "external" signing. These might make sense in the content of a directory service (that might return a TD that does not have "intrinsic" signatures like in ld-proofs). This might also apply when a directory returns part of TD, e.g. the result of a query.
I will work on a PR for this... using ld-proofs... will see if I can do it in time for the TD 1.1 FPWD, if it's optional then it can be backward-compatible.
Created an issue in the TD repo where it belongs... will follow up there. Already given the TD group a heads-up also. https://github.com/w3c/wot-thing-description/issues/940
PR Available, but WIP, need to resolve relationship to DID ontology, etc. Should consider what steps we need to complete this (for TD 2.0), and also a testing/implementation plan.
So this PR is now obsolete and will have to be redone, and of course we'll have to deal with canonicalization.
Discussed in APA call the need for "progressive disclosure" in many circumstances. This is related to the general idea of returning different variants of TDs to different users. This shows up in at least the following use cases:
So the question is... how do we handle signing in this case? Is "proof chaining" sufficient? This does imply that a "master" exists which contains the "original". The above processes can add, delete, or modify information. But in general I won't know what was changed, so in addition to knowing that there was a change, should I have a general mechanism to get access to the original or a diff? Defeats the purpose in some use cases (e.g. hiding information).
Requirements arising from memory limitations:
The above generally means that profiles will probably have the requirements that TDs and TD templates are stored and transmitted in canonical form, and should be pre-validated.
See https://github.com/w3c/wot-testing/blob/main/events/2021.03.Online/reference/hw.md for a discussion of minimum hardware requirements. One note that is relevant: security requirements should be aligned with hardware acceleration availability.
Use case for consuming TDs on constrained devices needed. One example:
Notes:
Canonicalization requirements:
TODO:
Need to update proposal. Consistency with available HW acceleration for signing capabilities would be useful (see PR https://github.com/w3c/wot-security/pull/199); in addition, we have to decide how to populate the namespace for various signing algorithms. The following might be useful for that: https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-18 In addition, we do have some existing names defined, e.g. for tokens, and it would probably also be useful to be consistent with names used by protocols, e.g. HTTP and CoAP. The "alg" examples for token are consistent with jws/jwt/jwe, and it makes sense (since a TD is a JSON object) for signing to use jwe, etc. We can start with LD-PROOFS (https://w3c-ccg.github.io/ld-proofs/#linked-data-signatures) but don't need to be constrained by it.
Signing should also require:
Signature type? If we could have only one, what should it be? @Citrullin I suggest SHA256 (cryptographic hash) combined with ECDSA signatures (note: elliptic curve, so compute required, regardless SW implementation is ok for small devices, but there are also lots of cheap HW implementation, e.g. you can get chips for $0.60)
There is a small list for crypto ICs.
So... different elliptic curves can be used with ECDSA/EdDSA. Let's further specify the curve: NIST-P256, which is widely supported in HW as well. However, this is not perfect, and there are other ones that could be used in the future. Not everyone will agree on which sig is best (for example, X25519/Curve25519), so maybe we should allow multiple signatures (with different cryptosuites) as well. We might be able to deal with this with a small update (to the TD spec... 1.2?) in 2022 or so. Alternatively we just wait for 2.0 (and LDS) in 2023. We could also list both NIST-P256 and X25519 (and if they are at risk, and we can't test both, then we just drop one...). These two curves should cover the needs of most communities. And it turns out the SW implementations of X25519 are pretty fast, so...
A "proof" section, like in DIDs, should be added to TDs to protect their integrity. This is important if we want to do things like refer to public keys, etc. from inside TDs; we don't want a man-in-the-middle to spoof that information.