On 26/08/2019 18:07, Jim Schaad wrote:
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 beOK 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 Ihaven't even touched a constrained implementation). [JLS] I am not sure that I understand why you believe that this isunderspecified.
Because the AD said so ;-)Seriously: I believe that this warrants more text, since it must be at least clarified that this construct assumes two pre-configured keys shared between AS and RS: one for encrypting the inner cnf element and one for integrity protecting the whole CWT.
Despite the fact that I have not implemented this, I do not believe that it would be all that problematic to implement in general, and would be even easier to implement in a constrained system as only one format of CWT should ever be expected by a single small device so that the structure can be hard coded.
Perhaps 'headache' was a hyperbole on my part, but there is definitely a code-complexity difference between "parsing CBOR" and "parsing CBOR, interrupt the parsing to decrypt stuff, continue parsing CBOR".
[JLS] There is a potential case for the first of those options, having different authority servers that are passing things back and forth and a desire to do validation that the correct permissions exist. That is the client AS sends a request to the Resource AS which creates a token for the RS and the client AS wants to double check the permissions granted to the client. But I have not heard that anybody is planning to do such an implementation yet. So far everybody is combining the two AS roles into a single system. If you are ever in the second case, I would argue that you are better off using asymmetric keys all the way around.
I can see this use case. That rules out my option 1. of removing this construct.
/Ludwig -- 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
