Re: [webauthn] define "self-signed basic attestation type" (#1498)

In the X.509 world, PKIX Validation (based on RFC 5280) is a "best 
practice" and is mandated in some environments while strongly encouraged 
in others.

PKIX Validation can apply to chains of certificates or to self-signed 
ones. What is important, however, is that the certificate(s) must have 
the appropriate extensions in them, pointing to information (Certificate 
Policy, Certification Practices, CRL Distribution Point, etc.) from 
which the Relying Party (RP) can glean enough information to base their 
trust decision of the certificate(s). A "byte for byte" comparison of 
certificates is NOT PKIX Validation and tells you nothing about whether 
you can trust the certificate(s).

In the absence of PKIX Validation, it is possible for an RP to validate 
the Attestation certificate through other channels/means and determine 
the degree of trust they choose to establish in it. This can be 
reflected through security policies and other mechanisms on FIDO servers 
(which are implementation dependent).

Having spent 22+ years in the PKI world, I don't see a reason for a 
separate attestation type for a self-signed certificate or chain; 
(technically, ALL certificate chains are self-signed - some just happen 
to have their Root CA certificates embedded in browsers and other 
platforms to automate the trust decision for users).

The current Basic scheme will work; RPs just have to be knowledgeable 
enough to make these decisions on their own, or work with companies who 
know how to navigate this. The WebAuthn spec is convoluted enough to 
rival PKI RFCs for complexity IMO - the simpler it gets or can be kept, 
the better for adoption.

Arshad Noor
StrongKey

On 10/15/20 3:56 PM, Shane Weeden via GitHub wrote:
> I think a more explicit description of why it is believed this needs to 
> be differentiated from "Basic" attestation might help with a more open 
> discussion. My limited understanding is that this somehow ties back in 
> to RFC5280, but I am not sure where (or if) WebAuthn defines that 
> "Basic" attestation x5c verification must always follow RFC5280. Is this 
> explicit anywhere?
> 
> Step 21 (3rd sub-bullet) of section 7.1 of the current editors draft 
> uses the text: "Otherwise, use the X.509 certificates returned as the 
> attestation trust path from the verification procedure to verify that 
> the attestation public key correctly chains up to an acceptable root 
> certificate".
> RFC5280 might surely be one (even the preferred) way to do that, but 
> couldn't we simply indicate that for self-signed attestation certs there 
> are other ways this might be done without having to introduce a new type 
> of attestation definition?

Received on Wednesday, 28 October 2020 20:26:36 UTC