From bd15e8bdfad1becc7c7be606bcf83b4b09862791 Mon Sep 17 00:00:00 2001 From: David Waite Date: Wed, 12 Jul 2023 12:57:42 -0600 Subject: [PATCH 01/12] Initial packed enterprise attestation requirements. --- index.bs | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/index.bs b/index.bs index c0d33b9dd..089b37123 100644 --- a/index.bs +++ b/index.bs @@ -5750,7 +5750,7 @@ implementable by [=authenticators=] with limited resources (e.g., secure element [=attestation trust path=]. -### Packed Attestation Statement Certificate Requirements ### {#sctn-packed-attestation-cert-requirements} +### Certificate Requirements for Packed Attestation Statements ### {#sctn-packed-attestation-cert-requirements} The attestation certificate MUST have the following fields/extensions: @@ -5787,6 +5787,21 @@ 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 are two potential sources for Enterprise Attestestations in Packed format: + +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`) +MUST be present, containing a unique serial number for the device as an OCTET STRING. The extension MUST NOT be marked as critical. + +For attestation statements provisioned at manufacturing, the extension OID `1.3.6.1.4.1.45724.1.1.5` (`id-fido-gen-ce-fw-version`) +MUST be present, containing an unsigned INTEGER which is incremented for new firmware release versions. The extension MUST NOT be marked as critical. + +As enterprise attestations are normally consumed by relying parties which are looking for particular authenticators, +there MAY be additional extensions used to convey information based on prior agreement. ## TPM Attestation Statement Format ## {#sctn-tpm-attestation} From c92aec35494e1df431ee558d0b593ad6b2904dd1 Mon Sep 17 00:00:00 2001 From: Shane Weeden Date: Wed, 19 Jul 2023 09:18:54 +1000 Subject: [PATCH 02/12] Clarify TPM attestation verification instructions --- index.bs | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/index.bs b/index.bs index c0d33b9dd..b239757b4 100644 --- a/index.bs +++ b/index.bs @@ -5874,8 +5874,8 @@ engine. - Verify that `extraData` is set to the hash of |attToBeSigned| using the hash algorithm employed in "alg". - Verify that `attested` contains a `TPMS_CERTIFY_INFO` structure as specified in [[!TPMv2-Part2]] section 10.12.3, whose `name` field contains a valid Name for |pubArea|, - as computed using the algorithm in the `nameAlg` field of |pubArea| using the procedure specified in [[!TPMv2-Part1]] - section 16. + as computed using the procedure specified in [[!TPMv2-Part1]] + section 16. Note that the hash algorithm is included within the attested `name` field of the TPMS_CERTIFY_INFO structure. - Verify that |x5c| is present. - Note that the remaining fields in the "Standard Attestation Structure" [[!TPMv2-Part1]] section 31.2, i.e., `qualifiedSigner`, `clockInfo` and `firmwareVersion` are ignored. From 6298db7ecdceb639e63037d5729edce86bfe049b Mon Sep 17 00:00:00 2001 From: David Waite Date: Wed, 30 Aug 2023 12:37:46 -0600 Subject: [PATCH 03/12] Remove non-enterprise sepcific firmware version This is separately proposed for general packed attestation verification. --- index.bs | 3 --- 1 file changed, 3 deletions(-) diff --git a/index.bs b/index.bs index 089b37123..05a4b88a3 100644 --- a/index.bs +++ b/index.bs @@ -5797,9 +5797,6 @@ There are two potential sources for Enterprise Attestestations in Packed format: For attestation statements provisioned 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. -For attestation statements provisioned at manufacturing, the extension OID `1.3.6.1.4.1.45724.1.1.5` (`id-fido-gen-ce-fw-version`) -MUST be present, containing an unsigned INTEGER which is incremented for new firmware release versions. The extension MUST NOT be marked as critical. - As enterprise attestations are normally consumed by relying parties which are looking for particular authenticators, there MAY be additional extensions used to convey information based on prior agreement. From d57cd65cd43cb686f52a0f225b62a26e51855904 Mon Sep 17 00:00:00 2001 From: David Waite Date: Wed, 6 Sep 2023 12:33:04 -0600 Subject: [PATCH 04/12] abbreviate and link "RPs" Co-authored-by: Emil Lundberg --- index.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.bs b/index.bs index 05a4b88a3..cec3a0f26 100644 --- a/index.bs +++ b/index.bs @@ -5797,7 +5797,7 @@ There are two potential sources for Enterprise Attestestations in Packed format: For attestation statements provisioned 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. -As enterprise attestations are normally consumed by relying parties which are looking for particular authenticators, +As enterprise attestations are normally consumed by [=[RPS]=] which are looking for particular authenticators, there MAY be additional extensions used to convey information based on prior agreement. ## TPM Attestation Statement Format ## {#sctn-tpm-attestation} From c294f84caf7dad88149d26decf86fe3b85bb5777 Mon Sep 17 00:00:00 2001 From: David Waite Date: Wed, 27 Mar 2024 11:51:27 -0600 Subject: [PATCH 05/12] Update per agl editorial comments --- index.bs | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/index.bs b/index.bs index cf68c5114..a644b7266 100644 --- a/index.bs +++ b/index.bs @@ -5874,10 +5874,10 @@ The attributes above are structured within this certificate as such: ### Certificate Requirements for Enterprise Packed Attestation Statements ### {#sctn-enterprise-packed-attestation-cert-requirements} -There are two potential sources for Enterprise Attestestations in Packed format: +There are two potential sources for Enterprise Attestations in Packed format. -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 +1. Attestation statements from a hardware device, which was manufactured with the statement and a corresponding private key. +2. Attestation statements which have been provisioned, such as 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`) MUST be present, containing a unique serial number for the device as an OCTET STRING. The extension MUST NOT be marked as critical. From 9212bc492a2d5b303b93e7b107b26d81c835e0a5 Mon Sep 17 00:00:00 2001 From: David Waite Date: Wed, 27 Mar 2024 12:01:01 -0600 Subject: [PATCH 06/12] Lowercase enterprise attestation in text. 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. --- index.bs | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/index.bs b/index.bs index a644b7266..ba9b53e0b 100644 --- a/index.bs +++ b/index.bs @@ -5874,12 +5874,12 @@ The attributes above are structured within this certificate as such: ### Certificate Requirements for Enterprise Packed Attestation Statements ### {#sctn-enterprise-packed-attestation-cert-requirements} -There are two potential sources for Enterprise Attestations in Packed format. +There are two potential sources for enterprise attestations in Packed format. 1. Attestation statements from a hardware device, which was manufactured with the statement and a corresponding private key. 2. Attestation statements which have been provisioned, such as 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`) +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. As enterprise attestations are normally consumed by [=[RPS]=] which are looking for particular authenticators, From 115c2f9372f903ee6b14526b6411f9dd6cd5028d Mon Sep 17 00:00:00 2001 From: Emil Lundberg Date: Mon, 19 Aug 2024 13:47:21 +0200 Subject: [PATCH 07/12] Clarify meaning of "unless" in UP flag validation --- index.bs | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/index.bs b/index.bs index 6fac0abec..ec6bbb16b 100644 --- a/index.bs +++ b/index.bs @@ -5635,7 +5635,9 @@ a numbered step. If outdented, it (today) is rendered as a bullet in the midst o 1. Verify that the [=rpIdHash=] in |authData| is the SHA-256 hash of the [=RP ID=] expected by the [=[RP]=]. -1. Verify that the [=UP=] bit of the [=flags=] in |authData| is set, unless |options|.{{CredentialCreationOptions/mediation}} is set to {{CredentialMediationRequirement/conditional}}. +1. Verify that the [=UP=] bit of the [=flags=] in |authData| is set. + If |options|.{{CredentialCreationOptions/mediation}} is set to {{CredentialMediationRequirement/conditional}}, + ignore this verification step. 1. If the [=[RP]=] requires [=user verification=] for this registration, verify that the [=authData/flags/UV=] bit of the [=flags=] in |authData| is set. From e0fb9b2326cc00a9331444f855af7b67375f020f Mon Sep 17 00:00:00 2001 From: Emil Lundberg Date: Wed, 4 Sep 2024 13:55:40 +0200 Subject: [PATCH 08/12] Update obsolete privacy concerns about throwing errors early --- index.bs | 24 +++++++++++++----------- 1 file changed, 13 insertions(+), 11 deletions(-) diff --git a/index.bs b/index.bs index 0e61497b8..a5ff4e724 100644 --- a/index.bs +++ b/index.bs @@ -2234,9 +2234,7 @@ a numbered step. If outdented, it (today) is rendered as a bullet in the midst o -1. Throw a "{{NotAllowedError}}" {{DOMException}}. In order to prevent information leak that could identify the - user without [=user consent|consent=], this step MUST NOT be executed before |lifetimeTimer| has expired. See - [[#sctn-make-credential-privacy]] for details. +1. Throw a "{{NotAllowedError}}" {{DOMException}}. During the above process, the user agent SHOULD show some UI to the user to guide them in the process of selecting and authorizing an authenticator. When |options|.{{CredentialCreationOptions/mediation}} is set to {{CredentialMediationRequirement/conditional}}, prominent modal UI should not be shown unless credential creation was previously consented to via means determined by the user agent. @@ -2683,9 +2681,7 @@ When this method is invoked, the user agent MUST execute the following algorithm 1. Return |constructAssertionAlg| and terminate this algorithm. -1. Throw a "{{NotAllowedError}}" {{DOMException}}. In order to prevent information leak that could identify the - user without [=user consent|consent=], this step MUST NOT be executed before |lifetimeTimer| has expired. See - [[#sctn-assertion-privacy]] for details. +1. Throw a "{{NotAllowedError}}" {{DOMException}}. @@ -8806,8 +8802,8 @@ credential|credentials=] listed by the [=[RP]=] in {{PublicKeyCredentialCreation If the above cases are distinguishable, information is leaked by which a malicious [=[RP]=] could identify the user by probing for which [=public key credential|credentials=] are available. For example, one such information leak is if the client returns a failure response as soon as an excluded [=authenticator=] becomes available. In this case - especially if the excluded -[=authenticator=] is a [=platform authenticator=] - the [=[RP]=] could detect that the [=ceremony=] was canceled before the -timeout and before the user could feasibly have canceled it manually, and thus conclude that at least one of the [=public key +[=authenticator=] is a [=platform authenticator=] - the [=[RP]=] could detect that the [=ceremony=] was canceled +before the user could feasibly have canceled it manually, and thus conclude that at least one of the [=public key credential|credentials=] listed in the {{PublicKeyCredentialCreationOptions/excludeCredentials}} parameter is available to the user. The above is not a concern, however, if the user has [=user consent|consented=] to create a new credential before a @@ -8826,12 +8822,18 @@ key credential|credential=] is listed by the [=[RP]=] in {{PublicKeyCredentialRe - A named [=public key credential|credential=] is available, but the user does not [=user consent|consent=] to use it. If the above cases are distinguishable, information is leaked by which a malicious [=[RP]=] could identify the user by probing -for which [=public key credential|credentials=] are available. For example, one such information leak is if the client returns a -failure response as soon as the user denies [=user consent|consent=] to proceed with an [=authentication ceremony=]. In this -case the [=[RP]=] could detect that the [=ceremony=] was canceled by the user and not the timeout, and thus conclude that at least +for which [=public key credential|credentials=] are available. +For example, one such information leak may happen if the client displays instructions and controls +for canceling or proceeding with the [=authentication ceremony=] +only after discovering an [=authenticator=] that [=contains=] a named [=credential=]. +In this case, if the [=[RP]=] is aware of this [=client=] behavior, +the [=[RP]=] could detect that the [=ceremony=] was canceled by the user and not the timeout, and thus conclude that at least one of the [=public key credential|credentials=] listed in the {{PublicKeyCredentialRequestOptions/allowCredentials}} parameter is available to the user. +This concern may be addressed by displaying controls allowing the user to cancel an [=authentication ceremony=] at any time, +regardless of whether any named [=credentials=] are available. + ### Privacy Between Operating System Accounts ### {#sctn-os-account-privacy} From 693a498452f4596c18f7a37e2ee39231333ee5bb Mon Sep 17 00:00:00 2001 From: Emil Lundberg Date: Wed, 11 Sep 2024 11:06:55 +0200 Subject: [PATCH 09/12] Clarify behaviour of duplicate hints --- index.bs | 1 + 1 file changed, 1 insertion(+) diff --git a/index.bs b/index.bs index 0e61497b8..69c2fdd79 100644 --- a/index.bs +++ b/index.bs @@ -4473,6 +4473,7 @@ Note: The {{PublicKeyCredentialHints}} enumeration is deliberately not reference
[=[WRPS]=] may use this enumeration to communicate hints to the user-agent about how a request may be best completed. These hints are not requirements, and do not bind the user-agent, but may guide it in providing the best experience by using contextual information that the [=[RP]=] has about the request. Hints are provided in order of decreasing preference so, if two hints are contradictory, the first one controls. Hints may also overlap: if a more-specific hint is defined a [=[RP]=] may still wish to send less specific ones for user-agents that may not recognise the more specific one. In this case the most specific hint should be sent before the less-specific ones. + If the same hint appears more than once, its second and later appearences are ignored. Hints MAY contradict information contained in credential {{PublicKeyCredentialDescriptor/transports}} and {{AuthenticatorSelectionCriteria/authenticatorAttachment}}. When this occurs, the hints take precedence. (Note that {{PublicKeyCredentialDescriptor/transports}} values are not provided when using [=discoverable credentials=], leaving hints as the only avenue for expressing some aspects of such a request.) From 39733f08b59471c641abc458bd60fd05662bc704 Mon Sep 17 00:00:00 2001 From: David Waite Date: Wed, 18 Sep 2024 12:50:25 -0600 Subject: [PATCH 10/12] Added simplified text based on feedback --- index.bs | 13 ++----------- 1 file changed, 2 insertions(+), 11 deletions(-) diff --git a/index.bs b/index.bs index f389f1f77..bba005757 100644 --- a/index.bs +++ b/index.bs @@ -3871,7 +3871,7 @@ Note: The {{AttestationConveyancePreference}} enumeration is deliberately not re :: The [=[RP]=] wants to receive the [=attestation statement=] as generated by the [=authenticator=]. : enterprise - :: The [=[RP]=] wants to receive an [=attestation statement=] that may include uniquely identifying information. This is intended for controlled deployments within an enterprise where the organization wishes to tie registrations to specific authenticators. User agents MUST NOT provide such an attestation unless the user agent or authenticator configuration permits it for the requested [=RP ID=]. + :: The [=[RP]=] wants to receive an enterprise attestation, which is an [=attestation statement=] that may include information which uniquely identifies the authenticator. This is intended for controlled deployments within an enterprise where the organization wishes to tie registrations to specific authenticators. User agents MUST NOT provide such an attestation unless the user agent or authenticator configuration permits it for the requested [=RP ID=]. If permitted, the user agent SHOULD signal to the authenticator (at [invocation time](#CreateCred-InvokeAuthnrMakeCred)) that enterprise attestation is requested, and convey the resulting [=/AAGUID=] and [=attestation statement=], unaltered, to the [=[RP]=].
@@ -6460,16 +6460,7 @@ The attributes above are structured within this certificate as such: ### Certificate Requirements for Enterprise Packed Attestation Statements ### {#sctn-enterprise-packed-attestation-cert-requirements} -There are two potential sources for enterprise attestations in Packed format. - -1. Attestation statements from a hardware device, which was manufactured with the statement and a corresponding private key. -2. Attestation statements which have been provisioned, such as a platform authenticator configured via managed policy. - -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. - -As enterprise attestations are normally consumed by [=[RPS]=] which are looking for particular authenticators, -there MAY be additional extensions used to convey information based on prior agreement. +The Extension OID `1.3.6.1.4.1.45724.1.1.2` ( `id-fido-gen-ce-sernum` ) MAY additionally be present in packed attestations for enterprise use. If present, this extension MUST indicate a unique octet string 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. ## TPM Attestation Statement Format ## {#sctn-tpm-attestation} From 176ea8173cc571abf7fb787aaebed7ef84d31402 Mon Sep 17 00:00:00 2001 From: David Waite Date: Wed, 18 Sep 2024 13:58:42 -0600 Subject: [PATCH 11/12] Remove prior bikeshed workaround --- index.bs | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/index.bs b/index.bs index c7de61dcf..8032e1446 100644 --- a/index.bs +++ b/index.bs @@ -6427,7 +6427,7 @@ The firmware of a particular authenticator model MAY be differentiated using the For example, the following is an attestation certificate containing the above extension OIDs as well as required fields: ~~~ pem ------BEGIN CERTIFICATE----- +-----BEGIN CERTIFICATE----- MIIBzTCCAXOgAwIBAgIUYHS3FJEL/JTfFqafuAHvlAS+hDYwCgYIKoZIzj0EAwIw QTELMAkGA1UEBhMCVVMxFDASBgNVBAoMC1dlYkF1dGhuIFdHMRwwGgYDVQQDDBNF eGFtcGxlIEF0dGVzdGF0aW9uMCAXDTI0MDEwMzE3NDUyMVoYDzIwNTAwMTA2MTc0 @@ -6438,7 +6438,7 @@ YH9yMOOcci3nr+Q/jOBaWVERo0cwRTAhBgsrBgEEAYLlHAEBBAQSBBDNjDlcJu3u 3mU7AHl9A8o8MBIGCysGAQQBguUcAQEFBAMCASowDAYDVR0TAQH/BAIwADAKBggq hkjOPQQDAgNIADBFAiA3k3aAUVtLhDHLXOgY2kRnK2hrbRgf2EKdTDLJ1Ds/RAIh AOmIblhI3ALCHOaO0IO7YlMpw/lSTvFYv3qwO3m7H8Dc ------END CERTIFICATE----- +-----END CERTIFICATE----- ~~~ The attributes above are structured within this certificate as such: From 6cae8a57d3afbcc513a0ab2381866eae750a93a4 Mon Sep 17 00:00:00 2001 From: Matthew Miller Date: Tue, 24 Sep 2024 12:04:50 +0200 Subject: [PATCH 12/12] Reword UP flag validation per review suggestion --- index.bs | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/index.bs b/index.bs index ec6bbb16b..0e9dc593c 100644 --- a/index.bs +++ b/index.bs @@ -5635,9 +5635,8 @@ a numbered step. If outdented, it (today) is rendered as a bullet in the midst o 1. Verify that the [=rpIdHash=] in |authData| is the SHA-256 hash of the [=RP ID=] expected by the [=[RP]=]. -1. Verify that the [=UP=] bit of the [=flags=] in |authData| is set. - If |options|.{{CredentialCreationOptions/mediation}} is set to {{CredentialMediationRequirement/conditional}}, - ignore this verification step. +1. If |options|.{{CredentialCreationOptions/mediation}} is not set to {{CredentialMediationRequirement/conditional}}, + verify that the [=UP=] bit of the [=flags=] in |authData| is set. 1. If the [=[RP]=] requires [=user verification=] for this registration, verify that the [=authData/flags/UV=] bit of the [=flags=] in |authData| is set.