explicitly denote RSA signature scheme

[equalsJeffH]

in the table in {#generating-an-attestation-statement}, the "Public key algorithm and encoding" row says in part:

  2. 0x0102. Raw encoded RSA PKCS1 or RSASSA-PSS public key...

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.:

  2. 0x0102. RSA public key; signature algorithm: RSASSA-PSS with SHA-256 hash.
  3. 0x0104. RSA public key, signature algorithm: RSASSA-PKCS1-v1_5 with SHA-256 hash.

( 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 )

[vijaybh]

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:

1. JWK identifier, in the current version of the packed attestation format for example - for RSA this captures padding mode and hashing algorithm.
2. WebCrypto algorithm type, in ScopedCredentialParameters. Can capture padding and hash depending on how specified.
3. This homegrown two-byte identifier. Captures neither padding nor hash.
4. The DER SubjectPublicKeyInfo @equalsJeffH suggested in a commit for RSA credential public key encoding in "attestation data" incorrectly specified? #240. This captures padding but not hash.

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.

[equalsJeffH]

Agreed the present overall state is messy and we need to clean it up.

WRT the attested credential public key:

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)

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?

[equalsJeffH]

wrt @vijaybh 's comment #239 (comment) above, AFAIK we need to also explicitly denote the RSA signature scheme employed by the authnr