-
Notifications
You must be signed in to change notification settings - Fork 167
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
explicitly denote RSA signature scheme #239
Comments
The more I look at this the more I wonder if we're over-complicating things by keeping this homegrown identifier scheme. Building on what @equalsJeffH says in #123, it seems like there are currently four proposed ways of denoting algorithms currently floating around in the spec:
None of the above captures key length. This seems to be really messy. I wonder if we could just standardize on one - say JWK since it's most concise and informative? - and use that everywhere. Also, for the public key in the attestation, I wonder if we could just use a CBOR map of the JsonWebKey structure (using binary fields not DER encoding) and thus gain a lot of flexibility and future-proofing. |
Agreed the present overall state is messy and we need to clean it up. WRT the attested credential public key:
A good question for implementors -- offhand it seems the two top choices are the CBOR-encoded JWK suggestion above, or traditional DER-encoded ASN.1 type of RSAPublicKey from https://tools.ietf.org/html/draft-moriarty-pkcs1-03#appendix-A.1 -- i could be convinced to do either one. this is overall a question for server-side implementors, yes? the client-side stack should just regard this as a blob as noted in #244 yes? |
wrt @vijaybh 's comment #239 (comment) above, AFAIK we need to also explicitly denote the RSA signature scheme employed by the authnr |
Fixed small wording and markdown issues. This completes the changes to make attestation opaque to UAs, which fixes #286, fixes #287, and fixes #289. It also fixes #239 by removing the homegrown algorithm identifiers and specifying the algorithm explicitly in attestation data using JWK identifiers. It also fixes #240 by encoding keys in CBOR which specifies lengths of fields.
in the table in {#generating-an-attestation-statement}, the "Public key algorithm and encoding" row says in part:
Which seems to be saying: given a value of
0x0102
for "Public key algorithm and encoding", the conveyed credential public key is of type RSA, and the signature alg employed (for "authentication signatures") is either of type RSASSA-PKCS1-v1_5 or RSASSA-PSS.However, should not the RP validating an authentication signature with an RSA public key know beforehand which signature alg (RSASSA-PKCS1-v1_5 or RSASSA-PSS) was employed?
Or, is there some standardized means to determine by inspection of a RSA signature value which algorithm was employed in generating the signature value?
If not, then we need to allocate two values for RSA "Public key algorithm and encoding" rather than just one, e.g.:
( wrt these hex values: see also https://lists.w3.org/Archives/Public/public-webauthn/2016Oct/0110.html ;
wrt other related aspects of this, see: PR #235 & issue #94, as well as #238 , #233 , #123 )
The text was updated successfully, but these errors were encountered: