Hi Ben,fixed more of your comments here: https://github.com/cwt-cnf/i-d/pull/24 (waiting for Mike to double-check and merge them).
As for those that are still open, comments are inline. /Ludwig On 13/08/2019 01:15, Benjamin Kaduk wrote:
The "COSE_Key" member MAY also be used for a COSE_Key representing a symmetric key, provided that the CWT is encrypted so that the key is not revealed to unintended parties. The means of encrypting a CWT is explained in [RFC8392]. If the CWT is not encrypted, the symmetric key MUST be encrypted as described in Section 3.3. It's hard for me to escape the conclusion that this paragraph needs to be a dedicated section with a bit more discussion about how exactly this usage is performed and encoded.This mirrors the corresponding procedure in RFC 7800. Would it be OK to just refer to that document (https://tools.ietf.org/html/rfc7800#section-3 or actually 3.3)?(Section 3.2, it seems -- JWT and CWT cover aysmmetric and symmetric in the opposite order.) Well, I still wouldn't like it. But I don't think I have grounds to block the document from advancing if you just refer back to JWT.
Göran and I have discussed this, and we agree that it is indeed underspecified (e.g. which key is used to encrypt this "inner" COSE_Encrypt0 contained in the cnf element?). Additionally I can personally confirm that this is a headache to implement (and I haven't even touched a constrained implementation).
We see two alternatives here:1.) Remove the possibility to have a separate encrypted cnf element. Instead mandate that the whole CWT should be encrypted if it contains a secret key.
+ make spec easier (to implement) and doesn't requires a long specification on how to handle this case
- breaks direct equivalence with RFC 78002.) Add some dedicated section that explains how the key for this inner encrypted cnf element is selected and communicated to the RS.
+ The draft remains functionally equivalent to RFC 7800 - Increased draft complexity at questionable gain - Possible implementer headaches, especially on constrained devices There is an issue about this here: https://github.com/cwt-cnf/i-d/issues/19
The following example CWT Claims Set of a CWT (using CBOR diagnostic notation, with linebreaks for readability) illustrates the use of an encrypted symmetric key as the "Encrypted_COSE_Key" member value: { /iss/ 1 : "coaps://server.example.com", /sub/ 2 : "24400320", /aud/ 3: "s6BhdRkqt3", /exp/ 4 : 1311281970, /iat/ 5 : 1311280970, /cnf/ 8 : { /COSE_Encrypt0/ 2 : [ Should this be "/Encrypted_COSE_Key/" and not "/COSE_Enrypt0/"? [I did not validate the COSE_Encrypt0 output]COSE_Encrypt0 is a defined construct of COSE, while Encrypted_COSE_Key is not. We'd have to define it or write an explanatory comment.Maybe I'm confused about how the diagnostic notation works, but the top-level CWT map key name ("claim") is "Encrypted_COSE_Key", as matches iss/sub/aud/etc. in the preceding notation. If the rules are different for map keys whose corresponding values are themselves structured data types, then I should just unconfuse myself and we can move on with things...
Issue created here https://github.com/cwt-cnf/i-d/issues/20 Will fix.
o A recipient can decide not to use a CWT based on a created Key ID if it does not fit the recipient's requirements. I'm not sure I understand the semantics being described here. Are we saying that the issuer might give a presenter a CWT, and by the time the presenter presents the CWT to the recipient, the recipient says "this is no good" and denies the transaction in question, forcing the presenter to go back to the issuer and try again? (How do we know that the issuer would make any different choices the second time around?)This risk always exists. In a constrained device world, the recipient may already have cleared out the key referenced by the key ID, which would force it to reject a CWT using this as proof-of-possession. I'm not sure how to give good guidance in this case. The error message delivered by the recipient rejecting the CWT might be helpful I suppose. Do you think this merits some text?It's not entirely clear to me that we need to add more text here, but if we did, it would focus on what "decide not to use" means at a protocol level, and perhaps how the CWT might not "fit the recipient's requirements" (e.g., the key id having fallen out of cache as you describe).
Issue created here: https://github.com/cwt-cnf/i-d/issues/21 Will fix.
from changing any elements conveyed within the CWT payload. Special care has to be applied when carrying symmetric keys inside the CWT since those not only require integrity protection but also confidentiality protection. Do we want to reiterate the common mechanisms for providing confidentiality protection here, or just leave the existing text earlier in the document to cover it?Doesn't it say a few sentences before: "it is necessary to apply data origin authentication and integrity protection (via a keyed message digest or a digital signature)." ? I would consider this to be enough.That doesn't cover the *confidentiality* protection, specifically. (So it seems the answer to my original question is still unclear, at least to me.)
Issue created here: https://github.com/cwt-cnf/i-d/issues/22 Will fix.
Section 6 ensure correct processing. The recipient needs to be able to use credentials to verify the authenticity, integrity, and potentially the confidentiality of the CWT and its content. This requires the Just from a rhetorical point of view, can you help me understand how credentials would be used to verify the confidentiality of a CWT? It seems like this depends on either (or both of) how the CWT is transmitted or how it is prepared, and I am not sure how the recipient's credentials come into play.This text is referring to the issuer's credentials (e.g. the Authorization Server issuing the CWT), that the recipient needs to verify the CWT. Do you want us to clarify this sentence?Note that I was specifically asking about "potentially the confidentiality"; I don't understand the intended workflow for verification of confidentiality (and thus which credentials are involved). I don't really see how a credential held solely by the issuer could proide confidentiality protection when it needs to be understood by some other protocol participant.
Issue created here: https://github.com/cwt-cnf/i-d/issues/23 Will fix.
Section 7 Criteria that should be applied by the Designated Experts include determining whether the proposed registration duplicates existing functionality, determining whether it is likely to be of general applicability or whether it is useful only for a single application, and evaluating the security properties of the item being registered and whether the registration makes sense. I know we've been using (variations of) this text for a while, but it seems to me that it could be more clear than it currently is -- is duplication of functionality grounds for denial of registration? What about general vs. specific applicability? The latter seems more clearly applicable for determining which range from which to allocate, since that has impact on the encoding size. Can the experts insist on updates to the security considerations text of a specification prior to granting approval, or are they limited to denying registration of values with poor security properties or insufficient documentation thereof?I'm too unfamiliar with the designated expert system to provide a good answer on this one. Can one of my co-authors chip in here?
Issue created here: https://github.com/cwt-cnf/i-d/issues/25 Will fix. -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
