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
54 changes: 54 additions & 0 deletions index.bs
Original file line number Diff line number Diff line change
Expand Up @@ -2789,6 +2789,50 @@ the [=authenticator=] MUST:
attStmtTemplate .within $$attStmtType
```

### Signature Formats ### {#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.

Please make this title more specific clearly restrict its scope to only the kinds of signatures that it applies to. Right now it reads like it applies to all signatures.

For instance, the new title could be "Signature Formats for Packed Attestations and Assertion Signatures" (if that's the correct scoping).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Changed to added FIDO-U2F attestation format also.

- For COSEAlgorithmIdentifier -7 (ES256), `sig` contains a pair of 32-byte integers,
Copy link
Contributor

Choose a reason for hiding this comment

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

The r and s values might not be 32 bytes long in this encoding, and I think the reference for the encoding is RFC 3278 section 3.3.2. So I've say something like:

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

(Then drop the added reference to X9.62.)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks

R followed by S, generated with ECDSA using Curve P-256 and SHA256 encoded as
ASN.1 DER format defined in [[ANSI.X9-62.2005]] and [[FIPS.186-4.2013]].

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

Choose a reason for hiding this comment

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

Change "in same format for consistency" to "in same format, for consistency reasons"

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Changed.

newer attestation formats MUST use COSE_KEY signature formats as defined in
Copy link
Contributor

Choose a reason for hiding this comment

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

Change "newer attestation formats MUST use COSE_KEY signature formats" to "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"

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Changed

[[IANA-COSE-ALGS-REG]].
Copy link
Contributor

Choose a reason for hiding this comment

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

Change [[IANA-COSE-ALGS-REG]] to [[!RFC8152]].


```
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 (44 Bytes)
Copy link
Contributor

Choose a reason for hiding this comment

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

The lengths in the comments here are in hex (i.e. "44 Bytes" is 0x44 bytes). But typically such numbers are in base 10.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah.. Yeah, I was using my certutil tool. Will fix it.

02 20 ; INTEGER (20 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 (20 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
```
- 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 [[RFC8017]] with SHA256 as the hash function.
Copy link
Contributor

Choose a reason for hiding this comment

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

Add a section number reference within RFC 8017 and say that you're including (or not including) the ASN.1 wrapper for the signature. Just saying RFC 8017 is ambiguous, because it defines both the raw signature bytes and an ASN.1 wrapper for those bytes.

Copy link
Contributor

Choose a reason for hiding this comment

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

(Referencing the section is a good idea in any case, but I don't believe that there is an ASN.1-based format for an RSA signature.)

```
Example:
87 38 c6 f7 7d 53 3a 7e 73 27 2e 4b 9d 45 c7 19
Copy link
Contributor

Choose a reason for hiding this comment

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

This example is just 2,048 random bits, right? Dunno how helpful that is :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah.. Not helpful. Lets remove that.

af 83 e2 ce ff 75 23 9d 24 5c 05 56 9e 66 a7 c5
d5 a3 b8 5c 6c cc bc d0 b9 04 55 bb 51 57 ba 34
5c 87 34 21 55 d2 ef 8b 28 9a cf ec 08 e6 8d 7d
84 57 1b 70 1c da 45 ca 23 0a b7 10 7a 06 29 07
61 bd e6 55 99 4d 86 f3 f0 8d ac 10 3d 13 5b 61
81 2d 88 82 f8 e9 02 0e 71 58 7a f5 f7 f0 61 95
9d f5 d9 35 54 48 7e 1c 3c 04 dc 9a f5 5a 04 b2
98 59 51 11 d5 2f 38 ac 55 96 50 7f 1e 06 8c 11
eb 77 19 03 ff b8 15 56 14 4e a7 77 be 22 90 c5
87 6d 34 7f 74 1b 7f 9a 63 6f e1 13 dd 4c 64 c0
0e d4 13 23 07 f2 a6 cf ee 79 f2 36 d8 47 76 ee
83 14 b9 28 15 61 73 69 af 62 cd 4e 2b 1f 54 2b
02 49 fe 60 d5 bc 00 7d 83 19 de 61 fe 7e 7b c0
09 24 2c 13 0b af 30 16 a5 0f 75 ef 99 5f 9b f7
ed b0 a6 36 74 0e 90 dc 52 3b 4b 7d c5 eb f8 19
```
- For COSEAlgorithmIdentifier -37 (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.

s/RS256/PS256/

Copy link
Contributor Author

Choose a reason for hiding this comment

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

oops. thanks.

RSASSA-PSS signature scheme defined in [[RFC8017]] with SHA256 as the hash function.
Copy link
Contributor

Choose a reason for hiding this comment

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

Add a section number reference within RFC 8017 and say that you're including (or not including) the ASN.1 wrapper for the signature. Just saying RFC 8017 is ambiguous, because it defines both the raw signature bytes and an ASN.1 wrapper for those bytes.


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

Upon successful execution of {{CredentialsContainer/create()}} or {{CredentialsContainer/get()}}, the [=[RP]=]'s script receives
Expand Down Expand Up @@ -4963,5 +5007,15 @@ 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.

"ANSI.X9-62.2005": {
"title": "Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA), ANSI X9.62-2005",
"date": "November 2005"
}
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


"FIPS.186-4.2013": {
"publisher": ["National Institute of Standards and Technology"],
"title": , "Digital Signature Standard (DSS), FIPS 186-4, 2013"
}
}
</pre>