Enterprise packed attestation guidance

[dwaite]

Fixes #1916

Creates a new section describing verification when packed format is used for enterprise attestation.

---

Preview | Diff

[agl]

You enumerate two cases just above, but then only mention one here. Are provisioned enterprise attestations forbidden from using this extension? Or can either use them?

[dwaite]

I'd raise to someone more familiar such as @ve7jtb

[dwaite]

We are still pending guidance here on usage for MDM-provisioned EAs. Since these can be dynamic (reprovisioned by the MDM or by switching which software provides the credentials), I would lean toward either saying this should not be used, or that it must indicate a persistent device identifier (and not some software value).

[dwaite]

will update to recommend against this for software-provisioned EAs

[sbweeden]

What in the spec references this section - i.e. when does an RP detect it has received an enterprise attestation, and should apply these processing rules?
This seems particularly important because there was talk about when an RP requests enterprise attestation, and none is available, it could fallback to direct.

[sbweeden]

Also, do any of the packed attestation certificate requirements above also apply to enterprise attestation certificates, or are these checks mutually exclusive?

[emlun]

I agree the section should probably be referenced somewhere. It's a bit weird, though, because this would of course only apply in the case of verifying an enterprise attestation. But perhaps this could just be an optional step of the verification procedure? I.e.:

• Verify that attestnCert meets the requirements in § 8.2.1 Certificate Requirements for Packed Attestation Statements.
• If verifying an {{AttestationConveyancePreference/enterprise}} attestation, verify that attestnCert meets the requirements in § 8.2.2. Certificate Requirements for Enterprise Packed Attestation Statements.

[emlun]

I agree the section should probably be referenced somewhere. It's a bit weird, though, because this would of course only apply in the case of verifying an enterprise attestation. But perhaps this could just be an optional step of the verification procedure? I.e.:

• Verify that attestnCert meets the requirements in § 8.2.1 Certificate Requirements for Packed Attestation Statements.
• If verifying an {{AttestationConveyancePreference/enterprise}} attestation, verify that attestnCert meets the requirements in § 8.2.2. Certificate Requirements for Enterprise Packed Attestation Statements.

[emlun]

Is there any way the RP can detect whether this is the case, and thus enforce this requirement? If not, the only actually actionable requirement in this section is that when the extension is present, the RP can verify that it is not marked critical. It's already a bit awkward that many of the requirements set in §8.2.1 (in particular the requirements for the subject field, other than Subject-OU) can only really be verified by a certification auditor, and not by a WebAuthn RP.

If this requirement is not really actionable for RPs, perhaps we should rephrase this section from a set of requirements to verify, to just a description of how these values can be retrieved and parsed if present?

[dwaite]

@emlun I took a pass at some new proposed text, based on your above feedback and the corresponding conversation on the call about the variance of enterprise attestations:

8.2.2. Certificate Requirements for Enterprise Packed Attestation Statements

Enterprise attestations are often used to restrict access to enterprise resources to a small set of specific, vetted authenticators. Examples might include issuing hardware-based roaming authenticators to employees with a specific configuration, or deploying software authenticators via a system for managing corporate-owned devices.

This close relationship between relying party and authenticator may lead to a higher degree of variance in the attributes available in the enterprise attestation. Similar to non-enterprise attestations, there may be certification bodies that set additional requirements on enterprise attestations in order to achieve certification.

The Extension OID 1.3.6.1.4.1.45724.1.1.2 ( id-fido-gen-ce-sernum ) MAY be present, and if so MUST indicate a unique value per device against a particular AAGUID. This value MUST remain constant through factory resets, but MAY be distinct from any other serial number or other hardware identifier associated with the device. This extension MUST NOT be marked as critical, and the corresponding value is encoded as an OCTET STRING. This extension MUST NOT be present in non-enterprise attestations.

[emlun]

The text looks mostly fine to me, but I wonder if we even need to comment at all on the "higher degree of variance ..." etc. To me it seems rather obvious, and rather irrelevant to the WebAuthn spec, that some certification bodies might impose additional requirements. I would also hesitate to write "are often used" about a feature not yet deployed. 🙂

So yeah, I would omit the second paragraph. Probably the first one too, leaving just the actual requirements. I reckon the use cases of a unique serial number are probably obvious enough.

8.2.2. Certificate Requirements for Enterprise Packed Attestation Statements
The Extension OID 1.3.6.1.4.1.45724.1.1.2 ( id-fido-gen-ce-sernum ) MAY be present, and if so MUST indicate a unique value per device against a particular AAGUID. This value MUST remain constant through factory resets, but MAY be distinct from any other serial number or other hardware identifier associated with the device. This extension MUST NOT be marked as critical, and the corresponding value is encoded as an OCTET STRING. This extension MUST NOT be present in non-enterprise attestations.

I also haven't yet seen a clear answer to my question above: is this OCTET STRING value in general an encoded integer, or just an opaque octet string with undefined internal structure?

[dwaite]

So yeah, I would omit the second paragraph. Probably the first one too, leaving just the actual requirements. I reckon the use cases of a unique serial number are probably obvious enough.

This text exists because there not text describing what enterprise attestations actually are (delegated to CTAP), and it is meant to be a section on requirements on what to expect/how to process these attestations. Those sorts of processing instructions aren't really provided by CTAP (which is not really describing RP behavior).

We can eliminate the first paragraph by pointing to https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-errata-20220621.html#sctn-feature-descriptions-enterp-attstn

I agree the second paragraph doesn't belong in normative text and thus should be removed. Also, I would happily entertain another document where implementation guidance would be more appropriate.

I also haven't yet seen a clear answer to my question above: is this OCTET STRING value in general an encoded integer, or just an opaque octet string with undefined internal structure?

@ve7jtb @dturnerx do you have any guidance here? The only example I have access to is an OCTET_STRING of an OCTET_STRING of a binary serial number.

[dwaite]

Will proceed to redo this shortly based on the immediately previous proposal and the example I have access to (OCTET STRING of OCTET STRING of binary serial value)

[ve7jtb]

As currently defined by Fido it is an opaque blob. That allows vendors to encode ehat they like in it. Some may encode a intiger and others my have alpha numeric serials. We registerd the OID so that Fido servers could have a standard place to find the info. The RP should be using it to look up what the public key for the attestation should be in the information they receved from the vendor when purchasing the key. So yes there should probably be some dicument outside of webAuthn to explain what the RP could/should do with an enterprise attestation. Diffrent RP will pronbably do diffrent things, Example:

1. check the attestation sig and AAGUID to see if it is one that they purchased.
2. check the opaque serial string to see if it matches a key that was assigned to a specific user, or just record the serial of the key durring registration. For example, Google, if a serial is seen coming in from a new user when they create a credential, any credentials created by another user with that same serial are deprovisiond from those users (This is a sort of cleanup).
3. lookup the attestation public key from the serial blob from outof band provisioning information from the vendor and reject if the key dosen't match the serial.

Some combinatio of all of those are possible.

[dwaite]

@emlun, could you review the simplified text (both in this section and the modification on the "enterprise" attestation conveyance if it solves your text issues?

@sbweeden and @emlun, since the enterprise attestation requirements really amount to one optional attribute, do you feel this section needs processing requirements or that perhaps we should instead have separate, generalized RP guidance outside "packed" attestations?

@emlun and @ve7jtb, do you want to see additional text around comparing serial numbers beyond the tweaks I made to the text?

[dwaite]

I additionally still plan to add a mock enterprise attestation to this section.

[sbweeden]

@sbweeden and @emlun, since the enterprise attestation requirements really amount to one optional attribute, do you feel this section needs processing requirements or that perhaps we should instead have separate, generalized RP guidance outside "packed" attestations?

I find it disappointing that there is no defined structure for the data contained within the enterprise OID extension, similar to what there is for the packed attestation OID 1.3.6.1.4.1.45724.1.1.4. Makes it impossible for an RP to build a product that has consistent processing for different enterprise attestations.

I realise this is not within WebAuthn WG's domain, but still... As for WebAuthn, perhaps text that says it must be validated using a vendor specified process, or similar?

[dwaite]

I find it disappointing that there is no defined structure for the data contained within the enterprise OID extension, similar to what there is for the packed attestation OID 1.3.6.1.4.1.45724.1.1.4. Makes it impossible for an RP to build a product that has consistent processing for different enterprise attestations.

The value is meant to be unique per AAGUID as an octet string, so comparison itself is defined.

The non-defined, vendor specific part is how those binary values are supplied. If the authenticator is listed in a CSV with a serial number of 12345678, there isn't a single industry process to convert that into the OCTET_STRING for comparison.

Likewise, if there is a serial number is printed onto the authenticator, there isn't a process for how the field can be displayed in a way that can be used to correlate the two (or that the two actually be the same).

I realise this is not within WebAuthn WG's domain, but still... As for WebAuthn, perhaps text that says it must be validated using a vendor specified process, or similar?

I think this is a good item to add to the hypothetical implementor's guidance for enterprise attestation.

[sbweeden]

I find it disappointing that there is no defined structure for the data contained within the enterprise OID extension, similar to what there is for the packed attestation OID 1.3.6.1.4.1.45724.1.1.4. Makes it impossible for an RP to build a product that has consistent processing for different enterprise attestations.

The value is meant to be unique per AAGUID as an octet string, so comparison itself is defined.

The non-defined, vendor specific part is how those binary values are supplied. If the authenticator is listed in a CSV with a serial number of 12345678, there isn't a single industry process to convert that into the OCTET_STRING for comparison.

Likewise, if there is a serial number is printed onto the authenticator, there isn't a process for how the field can be displayed in a way that can be used to correlate the two (or that the two actually be the same).

I realise this is not within WebAuthn WG's domain, but still... As for WebAuthn, perhaps text that says it must be validated using a vendor specified process, or similar?

I think this is a good item to add to the hypothetical implementor's guidance for enterprise attestation.

If the value is bytes, unique to the authenticator (per AAGUID), then the processing rules could just say that these bytes are to be validated or interpreted "per an individual authenticator vendor's process" then that's good enough.

We could suggest an example, such as: "The bytes encapsulate a unique serial number for the authenticator, within the scope of its AAGUID. A relying party would typically ensure that these bytes conform to the expected format defined by the authenticator vendor, and bind the value represented by those bytes to the user account registering the credential".

Does this, or something like it, seem reasonable?