Enterprise packed attestation guidance #1954
Conversation
This is separately proposed for general packed attestation verification.
index.bs
Outdated
| 1. From a hardware device which is manufactured with a device-specific attestation statement and key | ||
| 2. Via a provisioned attestation statement, such as with a platform authenticator configured via managed policy | ||
|
|
||
| For attestation statements provisioned at manufacturing, the Extension OID `1.3.6.1.4.1.45724.1.1.2` (`id-fido-gen-ce-sernum`) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
I'd raise to someone more familiar such as @ve7jtb
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
will update to recommend against this for software-provisioned EAs
Co-authored-by: Emil Lundberg <[email protected]>
| @@ -5787,6 +5787,18 @@ The attestation certificate MUST have the following fields/extensions: | |||
| are both OPTIONAL as the status of many attestation certificates is available through authenticator metadata services. | |||
| See, for example, the FIDO Metadata Service [[FIDOMetadataService]]. | |||
|
|
|||
| ### Certificate Requirements for Enterprise Packed Attestation Statements ### {#sctn-enterprise-packed-attestation-cert-requirements} | |||
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Also, do any of the packed attestation certificate requirements above also apply to enterprise attestation certificates, or are these checks mutually exclusive?
There was a problem hiding this comment.
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.
Enterprise attestation is used elsewhere without capitalization, and it could be said to be a characteristic and not a format like Packed. Change "provisioned at manufacturing" to "provided at manufacturing" to clarify difference from MDM-provisioned attestations.
| @@ -5787,6 +5787,18 @@ The attestation certificate MUST have the following fields/extensions: | |||
| are both OPTIONAL as the status of many attestation certificates is available through authenticator metadata services. | |||
| See, for example, the FIDO Metadata Service [[FIDOMetadataService]]. | |||
|
|
|||
| ### Certificate Requirements for Enterprise Packed Attestation Statements ### {#sctn-enterprise-packed-attestation-cert-requirements} | |||
There was a problem hiding this comment.
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.
| For attestation statements provided at manufacturing, the Extension OID `1.3.6.1.4.1.45724.1.1.2` (`id-fido-gen-ce-sernum`) | ||
| MUST be present, containing a unique serial number for the device as an OCTET STRING. The extension MUST NOT be marked as critical. |
There was a problem hiding this comment.
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?
|
@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:
|
Fixes #1916
Creates a new section describing verification when packed format is used for enterprise attestation.
Preview | Diff