fix #610 privacy CA now known as attestation CA #762
Conversation
equalsJeffH
added
type:editorial
subtype:impl-cons
privacy-tracker
equalsJeffH
requested review from
agl,
balfanz,
jcjones,
emlun,
rlin1,
selfissued and
akshayku
index.bs
Outdated
| :: In this case, an [=authenticator=] is based on a Trusted Platform Module (TPM) and holds an authenticator-specific | ||
| "endorsement key" (EK). This key is used to securely communicate with a trusted third party, the [=Attestation CA=] | ||
| [[!TCG-CMCProfile-AIKCertEnroll]] (formerly known as a "Privacy CA"). The [=authenticator=] can generate multiple | ||
| attestation identity key pairs (AIK) and requests an [=Attestation CA=] to issue an attestation identity certificate (AIK) |
There was a problem hiding this comment.
Should the latter AIK here be AIC?
There was a problem hiding this comment.
"AIC" is not used in [[!TCG-CMCProfile-AIKCertEnroll]], so I'm thinking not....
There was a problem hiding this comment.
Ok, I just wanted to thought it looked strange that the same acronym was used for two different things.
There was a problem hiding this comment.
thx, you did identify a problem -- should be using term "AIK certificate" here.
index.bs
Outdated
| [[!TCG-CMCProfile-AIKCertEnroll]] (formerly known as a "Privacy CA"). The [=authenticator=] can generate multiple | ||
| attestation identity key pairs (AIK) and requests an [=Attestation CA=] to issue an attestation identity certificate (AIK) | ||
| for each. Using this approach, such an [=authenticator=] can limit the exposure of the EK (which is a global correlation | ||
| handle) to Attestation CA(s). AIKs can be requested for each [=authenticator=]-generated [=public key credential=] |
There was a problem hiding this comment.
I am thinking usage of AIK here is nominally correct.
index.bs
Outdated
| @@ -1746,14 +1746,15 @@ during credential generation. | |||
| * <dfn>none</dfn> - indicates that the [=[RP]=] is not interested in [=authenticator=] [=attestation=]. | |||
| The client MAY replace the [=AAGUID=] and [=attestation statement=] generated | |||
| by the authenticator with meaningless client-generated values. For example, in order to avoid having to obtain | |||
| [=user consent=] to relay uniquely identifying information to the [=[RP]=], or to save a roundtrip to a Privacy CA. | |||
| [=user consent=] to relay uniquely identifying information to the [=[RP]=], or to save a roundtrip to a | |||
There was a problem hiding this comment.
fixed, see 0cbccd0
|
It looks like the CI build didn't run... is Anonymization CA defined anywhere? I don't see it. |
see https://github.com/w3c/webauthn/pull/762/files#diff-ec9cfa5f3f35ec1f84feb2e59686c34dR4448
it appears it was that "used only once" thx for headzup :) |
|
bummer.
I don't know what's going.....wait... https://www.specref.org/?q=TCG-CMCProfile-AIKCertEnroll ....shows that the reference is in specref.org...so i think this error is a hint that we need to update our cached repo-side build stuff such that we have the latest specref data ? @jcjones ? :) |
|
@equalsJeffH: I've updated the spec-data, but to tell in the PR we'd need to rebase the PR, which I can't do from this interface. |
|
it would be nice to get an OK from Chrome folk (before merging) since I invented the "anonymization CA" name for the entity they have so far been refering to as a "Privacy CA" (which would end up being confusing since that name was originally used by TCG specs for an entity that behaves somewhat differently and now is itself renamed to "Attestation CA") |
|
If we end up using a privacy CA, we're probably going to call it a privacy CA irrespective of whatever is in the spec. I think the term is pretty well established for "thing that checks a specific certificate and issues a general one saying that it checked it". I don't see that we need another term for the same thing. |
|
@agl wrote:
Thx, understood. I prefer to keep these terms separate (i.e., clearly delineated) in the spec, and y'all can call such functionality whatever you want, if it is materialized. |
|
Agreed. I think this is ready to merge. |
fixes #610
[ in case anyone noticed (unlikely, I realize): the branch name this PR is based on is incorrect, it should be
jeffh-fix-610-privacy-ca-cites, but oh well it is not. too much trouble to change it at this point...]Preview | Diff