Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Signature field clarification in attestation statement #805

Merged
merged 13 commits into from
Feb 21, 2018
30 changes: 30 additions & 0 deletions index.bs
Original file line number Diff line number Diff line change
Expand Up @@ -2797,6 +2797,35 @@ the [=authenticator=] MUST:
attStmtTemplate .within $$attStmtType
```

### Signature Formats for Packed Attestation, FIDO U2F Attestation, and Assertion Signatures ### {#signature-attestation-types}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would more clearly explain that with respect to [=assertion signatures=] that this is for assertions produced using the three listed signature algorithms.

what about any of the other COSE sig algorithms ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They will refer to COSE document.

- For COSEAlgorithmIdentifier -7 (ES256), and other ECDSA-based algorithms,
a signature value is encoded as an ASN.1 DER Ecdsa-Sig-Value, as defined in [[RFC3279]] section 2.2.3.

```
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it appears that the below example is ASN.1-wrapped. If so, I would move it up above the Note: (presently above), because having it down here is confusing -- i was expecting a "raw" fixed-length example to go with the Note.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moved.

Example:
30 44 ; SEQUENCE (68 Bytes)
02 20 ; INTEGER (32 Bytes)
| 3d 46 28 7b 8c 6e 8c 8c 26 1c 1b 88 f2 73 b0 9a
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(There are | symbols at the start of these two lines, but not below.)

| 32 a6 cf 28 09 fd 6e 30 d5 a7 9f 26 37 00 8f 54
02 20 ; INTEGER (32 Bytes)
| 4e 72 23 6e a3 90 a9 a1 7b cf 5f 7a 09 d6 3a b2
| 17 6c 92 bb 8e 36 c0 41 98 a2 7b 90 9b 6e 8f 13
```

Note: As CTAP1/U2F devices are already producing signatures values in this format, CTAP2
devices will also produce signatures values in same format, for consistency reasons.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Change "same format" to "the same format"

It is recommended that any new attestation formats defined not use ASN.1 encodings,
but instead represent signatures as equivalent fixed-length byte arrays without internal structure,
using the same representations as used by COSE signatures as defined in [[!RFC8152]] and [[!RFC8230]].

- For COSEAlgorithmIdentifier -257 (RS256), `sig` contains the signature generated using the
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAICT the sig values produced by [[RFC8017]] sections 8.1.1 and 8.2.1 are not ASN.1-wrapped. If that is correct, would a Note: to that effect be helpful to readers here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure.

RSASSA-PKCS1-v1_5 signature scheme defined in section 8.2.1 in [[RFC8017]] with SHA-256 as the hash function.
The signature is not ASN.1 wrapped.

- For COSEAlgorithmIdentifier -37 (PS256), `sig` contains the signature generated using the
RSASSA-PSS signature scheme defined in section 8.1.1 in [[RFC8017]] with SHA-256 as the hash function.
The signature is not ASN.1 wrapped.

# [=[RP]=] Operations # {#rp-operations}

Upon successful execution of {{CredentialsContainer/create()}} or {{CredentialsContainer/get()}}, the [=[RP]=]'s script receives
Expand Down Expand Up @@ -4969,5 +4998,6 @@ for their contributions as our W3C Team Contacts.
"href": "https://www.internet2.edu/media/medialibrary/2013/09/04/internet2-mace-dir-eduperson-200604.html",
"date": "May 15, 2007"
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

need a comma here to get spec to build properly


Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

neither of the below references are cited in the above prose re "COSEAlgorithmIdentifier -7 (ES256)", so am wondering why they are here? Yes, tokbind-protocol cites them, but we are instead citing [[RFC3279]] which seems to obviate citing the former two refs.

seems like we can either cite [[RFC3279]] or do it like tokbind and cite the below. I suppose either works for me.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removing.

}
</pre>