Thanks Ilari, and sorry for the late reply. I don't mean to ignore these concerns, I just lost track of this thread in between other work.
By "reserved", I mean likes of A192CTR in JOSE. Those are used by > WebCrypto, not JOSE. > Sorry, I still don't understand what you mean here. The "Name" values like ESP256-split are indeed not registered, they're just used as more human-readable aliases of the COSE numbers. Is something like that what you mean? Oh, this is for Javascript API, not for protocol between digester and > signer? CBOR (that is not crypto blobs) in such context seems rather > cursed to me. > It's both: a JavaScript API that is an API between digester (WebAuthn RP, javascript invoking the browser's WebAuthn API) and signer (WebAuthn authenticator). I agree that involving CBOR in that is not ideal, but the CBOR part (COSE_Sign_Args) is only needed for algorithms that need additional arguments. Signing algorithms that only have key and data parameters (for example plain ECDSA) don't have to deal with CBOR in this API. > I would expect stuff like this to be passed as a parameter of JSON > object type. And then the API code marshalls it into whatever form is > required by the token. > Yes, but that would require the JSON/JS API to define bindings for every individual signing algorithm, and would require browsers to implement each of them individually. We would have to update the extension specification and all browser implementations of it every time we want to add a new algorithm. That is why the extension is instead generically defined and referring to the external COSE registry for the algorithm definitions. We need the COSE_Sign_Args data structure in the authenticator layer to carry generic signing arguments, and we need to expose that through to the application layer (WebAuthn JS API) in order to not need browser implementation updates for every new algorithm (to define new transformations from JSON to CBOR and such). > If direct access to underlying CBOR passed to the token is needed (e.g., > because the fields vary in complicated ways), I would expect the CBOR > structure to be defined by WebAuthn. That structure just seems useless > for COSE. > It needs to be defined in a registry external from WebAuthn so that you can add algorithms without a whole new WebAuthn release. We figured COSE was the most natural place for it, and we've tried to design COSE_Sign_Args so that it can also be useful outside this WebAuthn extension, even if it's not directly necessary for producing or consuming other COSE structures. Now, that API uses COSE algorithm identifiers to identify algorithms, > but those algorithms are not of any supported type in COSE. This to me > seems exactly analogous to the WebCrypto algorithms in the JOSE > registry. > Sorry, I don't follow what you mean by "those algorithms are not of any supported type in COSE". Do you mean that not every COSE algorithm identifier is valid for use in WebAuthn? If so, then isn't that already the case even internally in COSE? It would be nonsensical to set `alg: -34 (ECDH-SS + A256KW)` in a COSE_Sign1 header, just as it would be nonsensical to request -34 as a credential key algorithm in WebAuthn. I agree that it's a bit of a "design smell" that the "*-split" algs are an additional subset of COSE signature algorithm identifiers that aren't valid for use in all places that take COSE signature algorithm identifiers. I don't think that's a big enough problem to warrant a separate new registry for them, though, since it's already the case that not all algorithm identifiers are valid in all places that take algorithm identifiers. > So for any needed algorithm identifiers, I would expect WebAuthn to > request allocation (the allocations are subject to Expert Review). > Yes, and that's precisely what we're doing, no? :) Note that to eliminate need for CBOR in the no-additional-parameters case, one would need to move the algorithm identifier away from the > parameters. > No, the extension API also uses a standalone array of COSE algorithm identifiers in the initial algorithm negotiation during key generation, just like the top-level WebAuthn API does. COSE_Sign_Args (and thus CBOR) is only needed if the RP and authenticator agree on a COSE algorithm identifier whose signing algorithm needs additional arguments, for example the ESP256-split-ARKG algorithm defined in draft-bradleylundberg-cfrg-arkg <https://www.ietf.org/archive/id/draft-bradleylundberg-cfrg-arkg-11.html#name-cose-algorithms>. CBOR processing is also needed if the RP wants provenance attestation for the signing key, but that is also optional. Emil Lundberg Staff Engineer | Yubico <http://www.yubico.com/>
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
