[TITLE] [LEVEL]

32 | -------------------------------------------------------------------------------- /.bikeshed-include/logo.include: -------------------------------------------------------------------------------- 1 |

2 | -------------------------------------------------------------------------------- /.bikeshed-include/status-CR.include: -------------------------------------------------------------------------------- 1 |

2 | This section describes the status of this document at the time of its publication. Other 3 | documents may supersede this document. A list of current 4 | W3C publications and the latest revision of this 5 | technical report can be found in the 6 | W3C technical 7 | reports index at http://www.w3.org/TR/. 8 |

9 |

10 | For the Web Authentication specification to move to Proposed Recommendation we must show two independent, interoperable 11 | implementations of the Web Authentication API in browsers. We will also have multiple interoperable implementations of the AppID 12 | extension, validating the extensions framework. All other extensions are "at risk". If there are not multiple interoperable 13 | implementations, each may independently be removed or made informative at Proposed Recommendation. 14 |

15 |

16 | We have had two informal interoperability tests with implementations in three browsers. There is no preliminary implementation 17 | report at this time. 18 |

19 |

28 |

29 | Publication as a Working Draft does not imply endorsement by the 30 | W3C Membership. This is a draft document and may 31 | be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite 32 | this document as other than work in progress. 33 |

34 |

48 |

49 | This document is governed by the 1 March 2019 W3C Process Document. 50 |

51 | 52 |

[STATUSTEXT] 53 | -------------------------------------------------------------------------------- /.bikeshed-include/status-ED.include: -------------------------------------------------------------------------------- 1 |

9 |

18 |

19 | Publication as an Editors' Draft does not imply endorsement by the 20 | W3C Membership. This is a draft document and may 21 | be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite 22 | this document as other than work in progress. 23 |

24 |

38 |

39 | This document is governed by the 1 March 2019 W3C Process Document. 40 |

41 | 42 |

[STATUSTEXT] 43 | -------------------------------------------------------------------------------- /.bikeshed-include/status-WD.include: -------------------------------------------------------------------------------- 1 |

This section describes the status of this document at the time of 2 | its publication. A list of current W3C publications and the latest 3 | revision of this technical report can be found in the W3C technical reports index at 5 | https://www.w3.org/TR/.

6 |

15 |

16 | Publication as a Working Draft does not imply endorsement by the 17 | W3C Membership. This is a draft document and may 18 | be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite 19 | this document as other than work in progress. 20 |

21 |

35 |

36 | This document is governed by the 15 September 2020 W3C Process Document. 37 |

38 | 39 |

[STATUSTEXT] 40 | -------------------------------------------------------------------------------- /.gitattributes: -------------------------------------------------------------------------------- 1 | ############################################################################### 2 | # SPECFIC OVERRIDES 3 | ############################################################################### 4 | *.bs text 5 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/config.yml: -------------------------------------------------------------------------------- 1 | 2 | blank_issues_enabled: false 3 | contact_links: 4 | - name: Passkeys Developer Discussions 5 | url: https://passkeys.dev/discuss 6 | about: A discussion forum for developer-related questions around implementing passkeys 7 | - name: FIDO2 Deployment or Implementation Question 8 | url: https://groups.google.com/a/fidoalliance.org/g/fido-dev 9 | about: Please use the FIDO-DEV list/group to ask questions about FIDO2 deployment and implementations 10 | - name: Report a bug in Google Chrome 11 | url: https://bugs.chromium.org/p/chromium/issues/wizard 12 | about: Report a WebAuthn-related bug in Google Chrome (Chromium) 13 | - name: Report a bug in Mozilla Firefox 14 | url: https://bugzilla.mozilla.org/home 15 | about: Report a WebAuthn-related bug in Mozilla Firefox (Gecko) 16 | - name: Report a bug in Apple Safari 17 | url: https://webkit.org/reporting-bugs/ 18 | about: Report a WebAuthn-related bug in Apple's Safari (WebKit) 19 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/editorial-change--.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: "Editorial Change" 3 | about: An editorial change is one that doesn't affect the behavior of the specification. If your proposed change would affect behavior, even if minor, please use the Technical Change issue. 4 | labels: ["type:editorial"] 5 | --- 6 | 7 | ## Proposed Change 8 | 9 | Describe your proposed change. If you have suggested text, please file a corresponding Pull Request. 10 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/technical-change--.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: "Technical Change" 3 | about: Proposal for a technical change to the WebAuthn specification 4 | labels: ["type:technical"] 5 | --- 6 | 7 | ## Proposed Change 8 | 9 | Describe your proposed change. If you have suggested text, please file a corresponding Pull Request. 10 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/use-case-feature--.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: "New Use Case or Feature" 3 | about: Proposal for the WebAuthn spec to support a new feature or address a new use case 4 | labels: ["stat:Discuss", "subtype:FeatureProposal"] 5 | --- 6 | 7 | ## Description 8 | 9 | Describe the feature and/or use case you'd like to see supported by the WebAuthn specification 10 | 11 | 12 | ## Related Links -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/wg-administrivia--.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: "Working Group Administrivia" 3 | about: Meeting planning, repo hygiene, W3C process, etc 4 | labels: ["type:process"] 5 | --- 6 | 7 | ## Description 8 | -------------------------------------------------------------------------------- /.github/pull_request_template.md: -------------------------------------------------------------------------------- 1 | Closes #??? 2 | 3 | 4 | 5 | The following tasks have been completed: 6 | 7 | - [ ] Modified Web platform tests ([link](https://github.com/web-platform-tests/wpt/)) 8 | 9 | Implementation commitment: 10 | 11 | - [ ] WebKit ([link to issue](https://bugs.webkit.org/)) 12 | - [ ] Chromium ([link to issue](https://issues.chromium.org/issues/new?component=1456855&template=0)) 13 | - [ ] Gecko ([link to issue](https://bugzilla.mozilla.org/home)) 14 | 15 | Documentation and checks 16 | 17 | - [ ] Affects privacy 18 | - [ ] Affects security 19 | - [ ] Updated explainer ([link](https://github.com/w3c/webauthn/wiki)) 20 | -------------------------------------------------------------------------------- /.github/workflows/build-validate-publish.yml: -------------------------------------------------------------------------------- 1 | name: CI 2 | on: 3 | pull_request: {} 4 | push: 5 | branches: [main] 6 | 7 | jobs: 8 | main: 9 | name: Build, Validate, and Publish 10 | runs-on: ubuntu-22.04 11 | steps: 12 | - uses: actions/checkout@v4 13 | - uses: w3c/spec-prod@v2 14 | with: 15 | GH_PAGES_BRANCH: gh-pages 16 | BUILD_FAIL_ON: nothing 17 | -------------------------------------------------------------------------------- /.github/workflows/check-test-vectors.yml: -------------------------------------------------------------------------------- 1 | name: Check test vectors 2 | on: 3 | pull_request: 4 | push: 5 | 6 | jobs: 7 | check-test-vectors: 8 | name: Ensure test vectors are up to date 9 | runs-on: ubuntu-22.04 10 | steps: 11 | - uses: actions/checkout@v4 12 | 13 | - uses: actions/setup-python@v5 14 | with: 15 | python-version: '3.13' 16 | 17 | - name: Check if test vectors are up to date 18 | run: | 19 | pip install poetry 20 | cd test-vectors 21 | ./inject-generated-content.sh --check 22 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | /bikeshed/ 2 | .vagrant/ 3 | index.html 4 | -------------------------------------------------------------------------------- /.pr-preview.json: -------------------------------------------------------------------------------- 1 | { 2 | "src_file": "index.bs", 3 | "type": "bikeshed", 4 | "params": { 5 | "force": 1 6 | } 7 | } 8 | -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | # Code of Conduct 2 | 3 | All documentation, code and communication under this repository are covered by the [W3C Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/). 4 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Web Authentication Working Group 2 | 3 | Contributions to this repository are intended to become part of Recommendation-track documents 4 | governed by the [W3C Patent Policy](http://www.w3.org/Consortium/Patent-Policy-20040205/) and 5 | [Document License](http://www.w3.org/Consortium/Legal/copyright-documents). To contribute, you must 6 | either participate in the relevant W3C Working Group or make a [non-member patent licensing 7 | commitment](https://www.w3.org/policies/process/#contributor-license). 8 | 9 | If you are a non-member but would like to contribute, simply open a Pull Request. 10 | The IPR bot will flag any need for commitment; get in touch with the 11 | [Staff Contact](https://www.w3.org/groups/wg/webauthn/) to confirm it. 12 | 13 | If you are not the sole contributor to a contribution (pull request), please identify all 14 | contributors in the pull request's body or in subsequent comments. 15 | 16 | To add a contributor (other than yourself, that's automatic), mark them one per line as follows: 17 | 18 | ``` 19 | +@github_username 20 | ``` 21 | 22 | If you added a contributor by mistake, you can remove them in a comment with: 23 | 24 | ``` 25 | -@github_username 26 | ``` 27 | 28 | If you are making a pull request on behalf of someone else but you had no part in designing the 29 | feature, you can remove yourself with the above syntax. 30 | 31 | 32 | ## Editorial conventions 33 | 34 | When editing the spec, please follow these editorial conventions. 35 | 36 | 37 | ### Text macros 38 | 39 | Where appropriate, use the 40 | [text macros defined near the beginning of the document](https://github.com/w3c/webauthn/blob/93193a1dcfddf6a6daa4726fafa4f556bff203ca/index.bs#L51-L60). 41 | For example, use `[TRUE]` to render `true` 42 | and use `[=[RP]=]` to render a linked reference to the term "Relying Party". 43 | 44 | 45 | ### Semantic line breaks 46 | 47 | Use [semantic line breaks][sembr]. 48 | To summarize, this means adding line breaks at semantically meaningful points, 49 | such as after punctuation, before subordinate clauses, etc. 50 | This makes changes easier to review and helps automatic conflict resolution, 51 | as small changes are more likely to affect only one or a few lines 52 | rather than an entire paragraph. 53 | For more examples and rationale, see: https://github.com/w3c/webauthn/issues/2045. 54 | 55 | Use semantic line breaks along these additional guidelines: 56 | 57 | - Do not change existing text just for the sake of introducing semantic line breaks. 58 | - When changing text that is not formatted with semantic line breaks, 59 | reformat changing lines to use semantic line breaks. 60 | Do not reformat unchanged neighboring lines to use semantic line breaks unless it's very few lines, 61 | or it otherwise helps readability, 62 | or it otherwise seems like a good idea. 63 | - When changing text that already uses semantic line breaks, 64 | add and remove semantic line breaks as appropriate but only as needed for the change. 65 | Do not break or join lines that would otherwise remain unchanged. 66 | - When adding new text, use semantic line breaks. 67 | - Take the [Semantic Line Breaks specification][sembr] as a set of guidelines, not a rigid set of rules. 68 | If a contributor proposes changes that clearly do not use semantic line breaks, 69 | inform or remind them of the convention and ask them to reformat, 70 | but respect their choice of where to place line breaks and do not "bikeshed" the details. 71 | The goal is to make the text easier to work with, not to enforce a style. 72 | - We do not set a hard line length limit, because of how much indentation and markup syntax we use. 73 | As a rule of thumb, aim for about 100 characters per line, 74 | or about 80 characters excluding indentation. 75 | Use good judgement of where to draw the line in each case. 76 | 77 | [sembr]: https://sembr.org/ 78 | -------------------------------------------------------------------------------- /LICENSE.md: -------------------------------------------------------------------------------- 1 | All documents in this Repository are licensed by contributors under the [W3C Document 2 | License](http://www.w3.org/Consortium/Legal/copyright-documents). 3 | -------------------------------------------------------------------------------- /PubStatus.md: -------------------------------------------------------------------------------- 1 | WG status may most easily be followed through our milestones: 2 | 3 | https://github.com/w3c/webauthn/milestones 4 | 5 | We published a Level 2 Recommendation 8 April 2021. Subsequent updates can be found in the working version of the document at: 6 | 7 | https://w3c.github.io/webauthn/ 8 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | 2 | # Web Authentication Specification 3 | 4 | This is the repository for the W3C WebAuthn Working Group, producing the draft **"Web Authentication"** specification. 5 | 6 | * [The editor's copy is available at https://w3c.github.io/webauthn/](https://w3c.github.io/webauthn/), or in the [`gh-pages` branch of this repository](https://github.com/w3c/webauthn/blob/gh-pages/index.html). 7 | - The current *offically published working-draft snapshot* [is here: https://www.w3.org/TR/webauthn/](https://www.w3.org/TR/webauthn/). 8 | * [The build history is available from the repo Actions tab](https://github.com/w3c/webauthn/actions) 9 | * [W3C WebAuthn Blog](https://www.w3.org/blog/webauthn/) 10 | * [Web platform tests repository](https://github.com/web-platform-tests/wpt/tree/master/webauthn) 11 | 12 | # Contributing 13 | 14 | To materially contribute to this specification, you must meet the requirements outlined in [CONTRIBUTING.md](/CONTRIBUTING.md). Also, before submitting feedback, please familiarize yourself with [our current issues list](https://github.com/w3c/webauthn/issues) and review the [mailing list discussion](https://lists.w3.org/Archives/Public/public-webauthn/). 15 | 16 | # Building the Draft 17 | 18 | Formatted HTML for the draft can be built using `bikeshed` (see below for instructions for `bikeshed` installation): 19 | 20 | ``` 21 | $ bikeshed spec 22 | ``` 23 | 24 | You may also want to use the `watch` functionality to automatically regenerate as you make changes: 25 | 26 | ``` 27 | $ bikeshed watch 28 | ``` 29 | 30 | # Bikeshed Installation and Setup 31 | 32 | See the full instructions at https://tabatkins.github.io/bikeshed/#installing. 33 | 34 | You will need to have the Python 3.7 or later installed. Once you do have Python 3.7 or later installed, to install Bikeshed itself, run the following: 35 | 36 | ``` 37 | pip3 install bikeshed && bikeshed update 38 | ``` 39 | 40 | When that is completed, Bikeshed should be installed, and the `bikeshed` command should work in your shell. 41 | 42 | # Continuous Integration & Branches 43 | 44 | https://w3c.github.io/webauthn/ is autopublished from the `gh-pages` branch on every push to the `main` branch, using https://github.com/w3c/webauthn/blob/main/.github/workflows/build-validate-publish.yml to configure the autopublishing behavior. 45 | 46 | # Creating a new Working Draft 47 | 48 | To build a new WD and upload it to the W3C publishing system: 49 | - Register as a W3C member and join the Web Authentication working group. Note down your W3C USERNAME and PASSWORD to use in the command below. If you don't remember either one, please go [here](https://www.w3.org/accounts/recover) to retrieve it. 50 | - Copy the url of the meeting minutes in which the working group decided to publish a new draft as the DECISION_URL to be used below 51 | - Make sure Bikeshed is installed locally (follow the Bikeshed Installation and Setup section above) 52 | - Go into the ./bikeshed directory and use git pull to update Bikeshed. 53 | - Run the following command to update Bikeshed's datafiles: 54 | ``` 55 | bikeshed update 56 | ``` 57 | - Edit the Bikeshed metadata to change the status from ED to WD (do not commit this change) 58 | - Ensure Bikeshed can compile without any error or warning by running through the following command: 59 | ``` 60 | bikeshed spec 61 | ``` 62 | - Build and upload the new draft with 63 | ``` 64 | bikeshed echidna --u USERNAME --p PASSWORD --d DECISION_URL 65 | ``` 66 | 67 | The command above will create a tarball of the HTML and images, and upload to Echidna, W3C's automated publishing system. The command should return a url, through which you can know whether you successfully publish the draft. Status of the request can also be tracked through the [Mailing List Archive](https://lists.w3.org/Archives/Public/public-tr-notifications/). You can also use W3C API [as described in the Echidna documentation](https://github.com/w3c/echidna/wiki/How-to-use-Echidna). Note that on Windows, this will give an error about failing to delete a temporary file because it is in use by a different process. This error is harmless; it happens after the submission has completed. 68 | 69 | If the publication through the process is unsuccessful, it's likely because of [Specberus](https://github.com/w3c/specberus), a spec compliance checker. Echidna automatically runs through Specberus and will reject the publication if any error is reported by Specberus. You can run your document through [Pubrules](https://www.w3.org/pubrules/) to understand why your document is rejected. You may modify either the index.bs file or the index.html file to ensure compliance. 70 | 71 | More often than not, you will discover the [Pubrules](https://www.w3.org/pubrules/) errors are due to bugs in either Bikeshed or Specberus. If so, you will have to modify the compiled index.html file to bypass Echidna and use the [manual process](https://github.com/w3c/echidna/wiki/How-to-use-Echidna) to publish. While you are editing the html file to avoid errors, you should also check to ensure the document still renders correctly. 72 | 73 | The [manual process](https://github.com/w3c/echidna/wiki/How-to-use-Echidna) requires you to first create a tar file. To create the tar file, you need to first copy the index.html file and rename the copied file as Overview.html. This is because Echidna doesn't recognize index.html. You can then use the following command to create a tar file: 74 | ``` 75 | tar -cvf WD.tar Overview.html image1 image2 image3 76 | ``` 77 | 78 | Then you can run the following command curl to publish to Echidna (use the command at the same directory as your tar file): 79 | ``` 80 | curl 'https://labs.w3.org/echidna/api/request' --user ':' -F "tar=@WD.tar" -F "decision=" 81 | ``` 82 | 83 | Feel free to contact your chair or any W3C staff when you are stuck. Overall info on echidna is here: https://github.com/w3c/echidna/wiki and here https://labs.w3.org/echidna/. 84 | 85 | # Taking meeting minutes 86 | 87 | * [Scribe instructions from the W3C Guidebook](https://www.w3.org/2008/04/scribe.html) 88 | * [Alternate instructions from the XML Security WG](https://www.w3.org/2008/xmlsec/Group/Scribe-Instructions.html) 89 | -------------------------------------------------------------------------------- /draft-hodges-webauthn-registries.txt: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | W3C WebAuthn Working Group J. Hodges 6 | Internet-Draft Google 7 | Intended status: Informational G. Mandyam 8 | Expires: December 3, 2020 Qualcomm Technologies Inc. 9 | M. Jones 10 | Microsoft 11 | June 1, 2020 12 | 13 | 14 | Registries for Web Authentication (WebAuthn) 15 | draft-hodges-webauthn-registries-10 16 | 17 | Abstract 18 | 19 | This specification defines IANA registries for W3C Web Authentication 20 | attestation statement format identifiers and extension identifiers. 21 | 22 | Note to Readers 23 | 24 | _RFC EDITOR: please remove this section before publication_ 25 | 26 | This is a work-in-progress. 27 | 28 | The issues list can be found at https://github.com/w3c/webauthn/ 29 | issues?q=is%3Aopen+is%3Aissue+label%3Aspec%3Awebauthn-registries [1]. 30 | 31 | The most recent _published_ draft revision is at 32 | https://tools.ietf.org/html/draft-hodges-webauthn-registries [2]. 33 | 34 | The editors' draft is at https://github.com/w3c/webauthn/blob/master/ 35 | draft-hodges-webauthn-registries.txt [3] 36 | 37 | Changes in the editors' draft, both proposed and incorporated, are 38 | listed at https://github.com/w3c/webauthn/ 39 | pulls?q=is%3Apr+label%3Aspec%3Awebauthn-registries [4] 40 | 41 | Status of This Memo 42 | 43 | This Internet-Draft is submitted in full conformance with the 44 | provisions of BCP 78 and BCP 79. 45 | 46 | Internet-Drafts are working documents of the Internet Engineering 47 | Task Force (IETF). Note that other groups may also distribute 48 | working documents as Internet-Drafts. The list of current Internet- 49 | Drafts is at https://datatracker.ietf.org/drafts/current/. 50 | 51 | Internet-Drafts are draft documents valid for a maximum of six months 52 | and may be updated, replaced, or obsoleted by other documents at any 53 | 54 | 55 | 56 | Hodges, et al. Expires December 3, 2020 [Page 1] 57 | 58 | Internet-DraftRegistries for Web Authentication (WebAuthn) June 2020 59 | 60 | 61 | time. It is inappropriate to use Internet-Drafts as reference 62 | material or to cite them other than as "work in progress." 63 | 64 | This Internet-Draft will expire on December 3, 2020. 65 | 66 | Copyright Notice 67 | 68 | Copyright (c) 2020 IETF Trust and the persons identified as the 69 | document authors. All rights reserved. 70 | 71 | This document is subject to BCP 78 and the IETF Trust's Legal 72 | Provisions Relating to IETF Documents 73 | (https://trustee.ietf.org/license-info) in effect on the date of 74 | publication of this document. Please review these documents 75 | carefully, as they describe your rights and restrictions with respect 76 | to this document. Code Components extracted from this document must 77 | include Simplified BSD License text as described in Section 4.e of 78 | the Trust Legal Provisions and are provided without warranty as 79 | described in the Simplified BSD License. 80 | 81 | Table of Contents 82 | 83 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 84 | 1.1. Requirements Notation and Conventions . . . . . . . . . . 3 85 | 2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 86 | 2.1. WebAuthn Attestation Statement Format Identifier Registry 3 87 | 2.1.1. Registering Attestation Statement Format Identifiers 4 88 | 2.1.2. Registration Request Processing . . . . . . . . . . . 5 89 | 2.1.3. Initial WebAuthn Attestation Statement Format 90 | Identifier Registry Values . . . . . . . . . . . . . 5 91 | 2.2. WebAuthn Extension Identifier Registry . . . . . . . . . 5 92 | 2.2.1. Registering Extension Identifiers . . . . . . . . . . 6 93 | 2.2.2. Registration Request Processing . . . . . . . . . . . 6 94 | 2.2.3. Initial WebAuthn Extension Identifier Registry Values 7 95 | 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 96 | 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 97 | 5. Document History . . . . . . . . . . . . . . . . . . . . . . 7 98 | 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 99 | 6.1. Normative References . . . . . . . . . . . . . . . . . . 9 100 | 6.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9 101 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 102 | 103 | 1. Introduction 104 | 105 | This specification establishes IANA registries for W3C Web 106 | Authentication [WebAuthn] attestation statement format identifiers 107 | and extension identifiers. The initial values for these registries 108 | 109 | 110 | 111 | 112 | Hodges, et al. Expires December 3, 2020 [Page 2] 113 | 114 | Internet-DraftRegistries for Web Authentication (WebAuthn) June 2020 115 | 116 | 117 | are in the IANA Considerations section of the [WebAuthn] 118 | specification. 119 | 120 | 1.1. Requirements Notation and Conventions 121 | 122 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 124 | "OPTIONAL" in this document are to be interpreted as described in BCP 125 | 14 [RFC2119] [RFC8174] when, and only when, they appear in all 126 | capitals, as shown here. 127 | 128 | 2. IANA Considerations 129 | 130 | This specification establishes two registries: 131 | 132 | o the "WebAuthn Attestation Statement Format Identifier" registry; 133 | see Section 2.1. 134 | o the "WebAuthn Extension Identifier" registry; see Section 2.2. 135 | 136 | [[ Per discussions in an email thread between the authors and IANA ( 137 | "[IANA #1154148]" ), it is requested that the registries be located 138 | at . RFC Editor - please 139 | delete this request after the registries have been created. ]] 140 | 141 | Any additional processes established by the expert(s) after the 142 | publication of this document will be recorded on the registry Web 143 | page at the expert(s)' discretion. 144 | 145 | 2.1. WebAuthn Attestation Statement Format Identifier Registry 146 | 147 | WebAuthn attestation statement format identifiers are strings whose 148 | semantic, syntactic, and string-matching criteria are specified in 149 | [WebAuthn] "Attestation Statement Format Identifiers" [5], along with 150 | the concepts of attestation and attestation statement formats. 151 | 152 | Registered attestation statement format identifiers are those that 153 | have been added to the registry by following the procedure in 154 | Section 2.1.1. 155 | 156 | Each attestation statement format identifier added to this registry 157 | MUST be unique amongst the set of registered attestation statement 158 | format identifiers. 159 | 160 | Registered attestation statement format identifiers MUST be a maximum 161 | of 32 octets in length and MUST consist only of printable ASCII 162 | [RFC20] characters, excluding backslash and doublequote, i.e., VCHAR 163 | as defined in [RFC5234] but without %x22 and %x5c. Attestation 164 | statement format identifiers are case sensitive and may not match 165 | 166 | 167 | 168 | Hodges, et al. Expires December 3, 2020 [Page 3] 169 | 170 | Internet-DraftRegistries for Web Authentication (WebAuthn) June 2020 171 | 172 | 173 | other registered identifiers in a case-insensitive manner unless the 174 | Designated Experts determine that there is a compelling reason to 175 | allow an exception. 176 | 177 | 2.1.1. Registering Attestation Statement Format Identifiers 178 | 179 | WebAuthn attestation statement format identifiers are registered 180 | using the Specification Required policy (see Section 4.6 of 181 | [RFC8126]). 182 | 183 | The WebAuthn attestation statement format identifiers registry is 184 | located at https://www.iana.org/assignments/webauthn [6]. 185 | Registration requests can be made by following the instructions 186 | located there, or by sending an e-mail to the webauthn-reg- 187 | review@ietf.org mailing list. 188 | 189 | Registration requests consist of at least the following information: 190 | 191 | o WebAuthn Attestation Statement Format Identifier: 192 | An identifier meeting the requirements given above in Section 2.1. 193 | o Description: 194 | A relatively short description of the attestation format. 195 | o Specification Document(s): 196 | Reference to the document or documents that specify the 197 | attestation statement format. 198 | o Change Controller: 199 | For Standards Track RFCs, list the "IETF". For others, give the 200 | name of the responsible party. Other details (e.g., postal 201 | address, email address, home page URI) may also be included. 202 | o Notes: 203 | [optional] 204 | 205 | Registrations MUST reference a freely available, stable 206 | specification, e.g., as described in Section 4.6 of [RFC8126]. This 207 | specification MUST include security and privacy considerations 208 | relevant to the attestation statement format. 209 | 210 | Note that WebAuthn attestation statement format identifiers can be 211 | registered by third parties (including the expert(s) themselves), if 212 | the expert(s) determine that an unregistered attestation statement 213 | format is widely deployed and not likely to be registered in a timely 214 | manner otherwise. Such registrations still are subject to the 215 | requirements defined, including the need to reference a 216 | specification. 217 | 218 | 219 | 220 | 221 | 222 | 223 | 224 | Hodges, et al. Expires December 3, 2020 [Page 4] 225 | 226 | Internet-DraftRegistries for Web Authentication (WebAuthn) June 2020 227 | 228 | 229 | 2.1.2. Registration Request Processing 230 | 231 | As noted in Section 2.1.1, WebAuthn attestation statement format 232 | identifiers are registered using the Specification Required policy. 233 | 234 | The expert(s) will clearly identify any issues that cause a 235 | registration to be refused, such as an incompletely specified 236 | attestation format. 237 | 238 | When a request is approved, the expert(s) will inform IANA, and the 239 | registration will be processed. The IESG is the arbiter of any 240 | objection. 241 | 242 | 2.1.3. Initial WebAuthn Attestation Statement Format Identifier 243 | Registry Values 244 | 245 | The initial values for the WebAuthn Attestation Statement Format 246 | Identifier Registry are to be populated from the values listed in 247 | "WebAuthn Attestation Statement Format Identifier Registrations" [7] 248 | of [WebAuthn]. Also, the Change Controller entry to be used for each 249 | of those registrations is: 250 | 251 | o Change Controller: W3C Web Authentication Working Group - 252 | public-webauthn@w3.org 253 | 254 | 2.2. WebAuthn Extension Identifier Registry 255 | 256 | WebAuthn extension identifiers are strings whose semantic, syntactic, 257 | and string-matching criteria are specified in [WebAuthn] "Extension 258 | Identifiers" [8]. 259 | 260 | Registered extension identifiers are those that have been added to 261 | the registry by following the procedure in Section 2.2.1. 262 | 263 | Each extension identifier added to this registry MUST be unique 264 | amongst the set of registered extension identifiers. 265 | 266 | Registered extension identifiers MUST be a maximum of 32 octets in 267 | length and MUST consist only of printable ASCII characters, excluding 268 | backslash and doublequote, i.e., VCHAR as defined in [RFC5234] but 269 | without %x22 and %x5c. Extension identifiers are case sensitive and 270 | may not match other registered identifiers in a case-insensitive 271 | manner unless the Designated Experts determine that there is a 272 | compelling reason to allow an exception. 273 | 274 | 275 | 276 | 277 | 278 | 279 | 280 | Hodges, et al. Expires December 3, 2020 [Page 5] 281 | 282 | Internet-DraftRegistries for Web Authentication (WebAuthn) June 2020 283 | 284 | 285 | 2.2.1. Registering Extension Identifiers 286 | 287 | WebAuthn extension identifiers registry are registered using the 288 | Specification Required policy (see Section 4.6 of [RFC8126]). 289 | 290 | The WebAuthn extension identifiers registry is located at 291 | https://www.iana.org/assignments/webauthn. Registration requests can 292 | be made by following the instructions located there, or by sending an 293 | e-mail to the webauthn-reg-review@ietf.org mailing list. 294 | 295 | Registration requests consist of at least the following information: 296 | 297 | o WebAuthn Extension Identifier: 298 | An identifier meeting the requirements given above in Section 2.2. 299 | o Description: 300 | A relatively short description of the extension. 301 | o Specification Document(s): 302 | Reference to the document or documents that specify the extension. 303 | o Change Controller: 304 | For Standards Track RFCs, list the "IETF". For others, give the 305 | name of the responsible party. Other details (e.g., postal 306 | address, email address, home page URI) may also be included. 307 | o Notes: 308 | [optional] 309 | 310 | Registrations MUST reference a freely available, stable 311 | specification, e.g., as described in Section 4.6 of [RFC8126]. This 312 | specification MUST include security and privacy considerations 313 | relevant to the extension. 314 | 315 | Note that WebAuthn extensions can be registered by third parties 316 | (including the expert(s) themselves), if the expert(s) determine that 317 | an unregistered extension is widely deployed and not likely to be 318 | registered in a timely manner otherwise. Such registrations still 319 | are subject to the requirements defined, including the need to 320 | reference a specification. 321 | 322 | 2.2.2. Registration Request Processing 323 | 324 | As noted in Section 2.2.1, WebAuthn extension identifiers are 325 | registered using the Specification Required policy. 326 | 327 | The expert(s) will clearly identify any issues that cause a 328 | registration to be refused, such as an incompletely specified 329 | extension. 330 | 331 | 332 | 333 | 334 | 335 | 336 | Hodges, et al. Expires December 3, 2020 [Page 6] 337 | 338 | Internet-DraftRegistries for Web Authentication (WebAuthn) June 2020 339 | 340 | 341 | When a request is approved, the expert(s) will inform IANA, and the 342 | registration will be processed. The IESG is the arbiter of any 343 | objection. 344 | 345 | 2.2.3. Initial WebAuthn Extension Identifier Registry Values 346 | 347 | The initial values for the WebAuthn Extension Identifier Registry are 348 | to be populated from the values listed in "WebAuthn Extension 349 | Identifier Registrations" [9] of [WebAuthn]. Also, the Change 350 | Controller entry to be used for each of those registrations is: 351 | 352 | o Change Controller: W3C Web Authentication Working Group - 353 | public-webauthn@w3.org 354 | 355 | 3. Security Considerations 356 | 357 | See [WebAuthn] for relevant security considerations. 358 | 359 | 4. Acknowledgements 360 | 361 | Thanks to Mark Nottingham for valuable comments and suggestions. 362 | Thanks to Kathleen Moriarty and Benjamin Kaduk for their Area 363 | Director sponsorship of this specification. Thanks to Amanda Baber, 364 | Sarah Banks, Alissa Cooper, Roman Danyliw, Murray Kucherawy, Paul 365 | Kyzivat, Barry Leiba, Hilarie Orman, Magnus Westerlund, and Robert 366 | Wilton for their reviews. 367 | 368 | 5. Document History 369 | 370 | [[ to be removed by the RFC Editor before publication as an RFC ]] 371 | 372 | -10 373 | 374 | o Changed IESG to IETF in Change Controller instructions, per 375 | suggestion by Magnus Westerlund. 376 | 377 | -09 378 | 379 | o Added Change Controller fields to registries, per suggestion by 380 | Magnus Westerlund. 381 | o Applied editorial suggestions by Amanda Baber, Murray Kucherawy, 382 | and Barry Leiba. 383 | 384 | -08 385 | 386 | o Addressed review feedback by Murray Kucherawy. 387 | o Added BCP 14 Requirements Notation and Conventions section. 388 | o Referenced RFC 20, which defines ASCII characters. 389 | 390 | 391 | 392 | Hodges, et al. Expires December 3, 2020 [Page 7] 393 | 394 | Internet-DraftRegistries for Web Authentication (WebAuthn) June 2020 395 | 396 | 397 | o Applied editorial cleanups. 398 | 399 | -07 400 | 401 | o Removed a duplicate URI listing pointed out by Hilarie Orman. 402 | 403 | -06 404 | 405 | o Addressed Gen-Art review comments by Paul Kyzivat by deleting text 406 | about designated experts defining additional registry fields. 407 | o Addressed Ops-Dir review comments by Sarah Banks by deleting text 408 | that duplicated requirements already specified in RFC 8126. 409 | o Addressed Security review comments by Hilarie Orman by deleting 410 | unnecessary text about attestation statement formats lacking 411 | complete specifications. 412 | o Replaced uses of the URL https://www.w3.org/TR/webauthn/ with 413 | https://www.w3.org/TR/2019/REC-webauthn-1-20190304/ so that the 414 | reference remains stable after the level 2 WebAuthn specification 415 | is published. 416 | 417 | -05 418 | 419 | o Updated to address the solicited IANA review comments, per 420 | discussions in an email thread between the authors and IANA ( 421 | "[IANA #1154148]" ). 422 | 423 | -04 424 | 425 | o Update per Benjamin Kaduk's further AD review: Remove 'final' wrt 426 | IESG arbitrating objections; Add explicit requirement for 427 | extension or attestation specs to include security and privacy 428 | considerations. 429 | o Update per IANA review: Move "IANA considerations section up in 430 | doc to encompass (former) sections 2 and 3. 431 | 432 | -03 433 | 434 | o Update per Benjamin Kaduk's AD review. Align with RFC 8288, 435 | rather than draft-nottingham-rfc5988bis. 436 | 437 | -02 438 | 439 | o Refresh now that the WebAuthn spec is at Recommendation (REC) 440 | maturity level. 441 | 442 | -01 443 | 444 | 445 | 446 | 447 | 448 | Hodges, et al. Expires December 3, 2020 [Page 8] 449 | 450 | Internet-DraftRegistries for Web Authentication (WebAuthn) June 2020 451 | 452 | 453 | o Refresh now that the WebAuthn Committee Recommendation (CR) draft 454 | is pending. 455 | 456 | -00 457 | 458 | o Initial version, based on draft-nottingham-rfc5988bis. 459 | 460 | 6. References 461 | 462 | 6.1. Normative References 463 | 464 | [RFC20] Cerf, V., "ASCII format for Network Interchange", STD 80, 465 | RFC 20, October 1969, 466 | . 467 | 468 | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 469 | Requirement Levels", BCP 14, RFC 2119, 470 | DOI 10.17487/RFC2119, March 1997, 471 | . 472 | 473 | [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 474 | Specifications: ABNF", STD 68, RFC 5234, 475 | DOI 10.17487/RFC5234, January 2008, 476 | . 477 | 478 | [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 479 | Writing an IANA Considerations Section in RFCs", BCP 26, 480 | RFC 8126, DOI 10.17487/RFC8126, June 2017, 481 | . 482 | 483 | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 484 | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 485 | May 2017, . 486 | 487 | [WebAuthn] 488 | Balfanz, D., Czeskis, A., Hodges, J., Jones, J., Jones, 489 | M., Kumar, A., Liao, A., Lindemann, R., and E. Lundberg, 490 | "Web Authentication: An API for accessing Public Key 491 | Credentials", World Wide Web Consortium 492 | (W3C) Recommendation, March 2019, 493 | . 494 | 495 | 6.2. URIs 496 | 497 | [1] https://github.com/w3c/webauthn/ 498 | issues?q=is%3Aopen+is%3Aissue+label%3Aspec%3Awebauthn-registries 499 | 500 | [2] https://tools.ietf.org/html/draft-hodges-webauthn-registries 501 | 502 | 503 | 504 | Hodges, et al. Expires December 3, 2020 [Page 9] 505 | 506 | Internet-DraftRegistries for Web Authentication (WebAuthn) June 2020 507 | 508 | 509 | [3] https://github.com/w3c/webauthn/blob/master/draft-hodges- 510 | webauthn-registries.txt 511 | 512 | [4] https://github.com/w3c/webauthn/ 513 | pulls?q=is%3Apr+label%3Aspec%3Awebauthn-registries 514 | 515 | [5] https://www.w3.org/TR/2019/REC-webauthn-1-20190304/#sctn-attstn- 516 | fmt-ids 517 | 518 | [6] https://www.iana.org/assignments/webauthn 519 | 520 | [7] https://www.w3.org/TR/2019/REC-webauthn-1-20190304/#sctn-att-fmt- 521 | reg 522 | 523 | [8] https://www.w3.org/TR/2019/REC-webauthn-1-20190304/#sctn- 524 | extension-id 525 | 526 | [9] https://www.w3.org/TR/2019/REC-webauthn-1-20190304/#sctn- 527 | extensions-reg 528 | 529 | Authors' Addresses 530 | 531 | Jeff Hodges 532 | Google 533 | 1600 Amphitheater Parkway 534 | Mountain View, California 94043 535 | US 536 | 537 | Email: jdhodges@google.com 538 | URI: https://kingsmountain.com/people/Jeff.Hodges/ 539 | 540 | 541 | Giridhar Mandyam 542 | Qualcomm Technologies Inc. 543 | 5775 Morehouse Drive 544 | San Diego, California 92121 545 | USA 546 | 547 | Phone: +1 858 651 7200 548 | Email: mandyam@qti.qualcomm.com 549 | 550 | 551 | Michael B. Jones 552 | Microsoft 553 | 554 | Email: mbj@microsoft.com 555 | URI: https://self-issued.info/ 556 | 557 | 558 | 559 | 560 | Hodges, et al. Expires December 3, 2020 [Page 10] 561 | -------------------------------------------------------------------------------- /draft-jones-webauthn-cose-algorithms.txt: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | WebAuthn Working Group M. Jones 6 | Internet-Draft Microsoft 7 | Intended status: Informational May 2, 2018 8 | Expires: November 3, 2018 9 | 10 | 11 | COSE Algorithms for Web Authentication (WebAuthn) 12 | draft-jones-webauthn-cose-algorithms-01 13 | 14 | Abstract 15 | 16 | The W3C Web Authentication (WebAuthn) specification uses COSE 17 | algorithm identifiers. This specification registers algorithms in 18 | the IANA "COSE Algorithms" registry that are used by WebAuthn that 19 | are not already registered. Also, they are registered in the IANA 20 | "JSON Web Signature and Encryption Algorithms" registry, when not 21 | already registered there. 22 | 23 | Status of This Memo 24 | 25 | This Internet-Draft is submitted in full conformance with the 26 | provisions of BCP 78 and BCP 79. 27 | 28 | Internet-Drafts are working documents of the Internet Engineering 29 | Task Force (IETF). Note that other groups may also distribute 30 | working documents as Internet-Drafts. The list of current Internet- 31 | Drafts is at https://datatracker.ietf.org/drafts/current/. 32 | 33 | Internet-Drafts are draft documents valid for a maximum of six months 34 | and may be updated, replaced, or obsoleted by other documents at any 35 | time. It is inappropriate to use Internet-Drafts as reference 36 | material or to cite them other than as "work in progress." 37 | 38 | This Internet-Draft will expire on November 3, 2018. 39 | 40 | Copyright Notice 41 | 42 | Copyright (c) 2018 IETF Trust and the persons identified as the 43 | document authors. All rights reserved. 44 | 45 | This document is subject to BCP 78 and the IETF Trust's Legal 46 | Provisions Relating to IETF Documents 47 | (https://trustee.ietf.org/license-info) in effect on the date of 48 | publication of this document. Please review these documents 49 | carefully, as they describe your rights and restrictions with respect 50 | to this document. Code Components extracted from this document must 51 | include Simplified BSD License text as described in Section 4.e of 52 | 53 | 54 | 55 | 56 | Jones Expires November 3, 2018 [Page 1] 57 | 58 | Internet-DraCOSE Algorithms for Web Authentication (WebAuthn) May 2018 59 | 60 | 61 | the Trust Legal Provisions and are provided without warranty as 62 | described in the Simplified BSD License. 63 | 64 | Table of Contents 65 | 66 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 | 1.1. Requirements Notation and Conventions . . . . . . . . . . 2 68 | 2. RSASSA-PKCS1-v1_5 Signature Algorithm . . . . . . . . . . . . 2 69 | 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 70 | 3.1. COSE Algorithms Registrations . . . . . . . . . . . . . . 3 71 | 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 72 | 4.1. RSA Key Size Security Considerations . . . . . . . . . . 4 73 | 4.2. RSASSA-PKCS1-v1_5 with SHA-2 Security Considerations . . 4 74 | 4.3. RSASSA-PKCS1-v1_5 with SHA-1 Security Considerations . . 4 75 | 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 | 5.1. Normative References . . . . . . . . . . . . . . . . . . 4 77 | 5.2. Informative References . . . . . . . . . . . . . . . . . 5 78 | Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5 79 | Document History . . . . . . . . . . . . . . . . . . . . . . . . 6 80 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 81 | 82 | 1. Introduction 83 | 84 | This specification defines how to use several algorithms with COSE 85 | [RFC8152] that are used by the W3C Web Authentication (WebAuthn) 86 | [WebAuthn] specification. These algorithms are registered in the 87 | IANA "COSE Algorithms" registry [IANA.COSE.Algorithms] and also in 88 | the IANA "JSON Web Signature and Encryption Algorithms" registry 89 | [IANA.JOSE.Algorithms], when not already registered there. 90 | 91 | 1.1. Requirements Notation and Conventions 92 | 93 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 95 | "OPTIONAL" in this document are to be interpreted as described in BCP 96 | 14 [RFC2119] [RFC8174] when, and only when, they appear in all 97 | capitals, as shown here. 98 | 99 | 2. RSASSA-PKCS1-v1_5 Signature Algorithm 100 | 101 | The RSASSA-PKCS1-v1_5 signature algorithm is defined in [RFC8017]. 102 | The RSASSA-PKCS1-v1_5 signature algorithm is parameterized with a 103 | hash function (h). 104 | 105 | A key of size 2048 bits or larger MUST be used with these algorithms. 106 | Implementations need to check that the key type is 'RSA' when 107 | creating or verifying a signature. 108 | 109 | 110 | 111 | 112 | Jones Expires November 3, 2018 [Page 2] 113 | 114 | Internet-DraCOSE Algorithms for Web Authentication (WebAuthn) May 2018 115 | 116 | 117 | The RSASSA-PKCS1-v1_5 algorithms specified in this document are in 118 | the following table. 119 | 120 | +-------+-------------------------+---------+-----------------------+ 121 | | Name | Value | Hash | Description | 122 | +-------+-------------------------+---------+-----------------------+ 123 | | RS256 | TBD (requested | SHA-256 | RSASSA-PKCS1-v1_5 w/ | 124 | | | assignment -257) | | SHA-256 | 125 | | RS384 | TBD (requested | SHA-384 | RSASSA-PKCS1-v1_5 w/ | 126 | | | assignment -258) | | SHA-384 | 127 | | RS512 | TBD (requested | SHA-512 | RSASSA-PKCS1-v1_5 w/ | 128 | | | assignment -259) | | SHA-512 | 129 | | RS1 | TBD (requested | SHA-1 | RSASSA-PKCS1-v1_5 w/ | 130 | | | assignment -65535) | | SHA-1 | 131 | +-------+-------------------------+---------+-----------------------+ 132 | 133 | Table 1: RSASSA-PKCS1-v1_5 Algorithm Values 134 | 135 | 3. IANA Considerations 136 | 137 | 3.1. COSE Algorithms Registrations 138 | 139 | This section registers the following values in the IANA "COSE 140 | Algorithms" registry [IANA.COSE.Algorithms]. 141 | 142 | o Name: RS256 143 | o Value: TBD (requested assignment -257) 144 | o Description: RSASSA-PKCS1-v1_5 w/ SHA-256 145 | o Reference: Section 2 of this document 146 | o Recommended: No 147 | 148 | o Name: RS384 149 | o Value: TBD (requested assignment -258) 150 | o Description: RSASSA-PKCS1-v1_5 w/ SHA-384 151 | o Reference: Section 2 of this document 152 | o Recommended: No 153 | 154 | o Name: RS512 155 | o Value: TBD (requested assignment -259) 156 | o Description: RSASSA-PKCS1-v1_5 w/ SHA-512 157 | o Reference: Section 2 of this document 158 | o Recommended: No 159 | 160 | o Name: RS1 161 | o Value: TBD (requested assignment -65535) 162 | o Description: RSASSA-PKCS1-v1_5 w/ SHA-1 163 | o Reference: Section 2 of this document 164 | o Recommended: Deprecated 165 | 166 | 167 | 168 | Jones Expires November 3, 2018 [Page 3] 169 | 170 | Internet-DraCOSE Algorithms for Web Authentication (WebAuthn) May 2018 171 | 172 | 173 | 4. Security Considerations 174 | 175 | 4.1. RSA Key Size Security Considerations 176 | 177 | The security considerations on key sizes for RSA algorithms from 178 | Section 6.1 of [RFC8230] also apply to the RSA algorithms in this 179 | specification. 180 | 181 | 4.2. RSASSA-PKCS1-v1_5 with SHA-2 Security Considerations 182 | 183 | The security considerations on the use of RSASSA-PKCS1-v1_5 with 184 | SHA-2 hash functions from Section 8.3 of [RFC7518] also apply to 185 | their use in this specification. For that reason, these algorithms 186 | are registered as being "Not Recommended". 187 | 188 | 4.3. RSASSA-PKCS1-v1_5 with SHA-1 Security Considerations 189 | 190 | The security considerations on the use of the SHA-1 hash function 191 | from [RFC6194] apply in this specification. For that reason, the 192 | "RS1" algorithm is registered as "Deprecated". It MUST NOT be used 193 | by COSE implementations. 194 | 195 | A COSE algorithm identifier for this algorithm is nonetheless being 196 | registered because deployed TPMs continue to use it, and therefore 197 | WebAuthn implementations need a COSE algorithm identifier for "RS1" 198 | when TPM attestations using this algorithm are being represented. 199 | 200 | 5. References 201 | 202 | 5.1. Normative References 203 | 204 | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 205 | Requirement Levels", BCP 14, RFC 2119, 206 | DOI 10.17487/RFC2119, March 1997, 207 | . 208 | 209 | [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 210 | Considerations for the SHA-0 and SHA-1 Message-Digest 211 | Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 212 | . 213 | 214 | [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 215 | Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 216 | October 2013, . 217 | 218 | [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 219 | Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 220 | 2015, . 221 | 222 | 223 | 224 | Jones Expires November 3, 2018 [Page 4] 225 | 226 | Internet-DraCOSE Algorithms for Web Authentication (WebAuthn) May 2018 227 | 228 | 229 | [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 230 | DOI 10.17487/RFC7518, May 2015, 231 | . 232 | 233 | [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 234 | "PKCS #1: RSA Cryptography Specifications Version 2.2", 235 | RFC 8017, DOI 10.17487/RFC8017, November 2016, 236 | . 237 | 238 | [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 239 | RFC 8152, DOI 10.17487/RFC8152, July 2017, 240 | . 241 | 242 | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 243 | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 244 | May 2017, . 245 | 246 | [RFC8230] Jones, M., "Using RSA Algorithms with CBOR Object Signing 247 | and Encryption (COSE) Messages", RFC 8230, 248 | DOI 10.17487/RFC8230, September 2017, 249 | . 250 | 251 | 5.2. Informative References 252 | 253 | [IANA.COSE.Algorithms] 254 | IANA, "COSE Algorithms", 255 | . 257 | 258 | [IANA.JOSE.Algorithms] 259 | IANA, "JSON Web Signature and Encryption Algorithms", 260 | . 262 | 263 | [WebAuthn] 264 | Balfanz, D., Czeskis, A., Hodges, J., Jones, J., Jones, 265 | M., Kumar, A., Liao, A., Lindemann, R., and E. Lundberg, 266 | "Web Authentication: An API for accessing Public Key 267 | Credentials", Candidate Recommendation, World Wide Web 268 | Consortium (W3C) Recommendation-track, March 2018, 269 | . 270 | 271 | Acknowledgements 272 | 273 | Thanks to John Fontana, Jeff Hodges, Tony Nadalin, Jim Schaad, Goeran 274 | Selander, Wendy Seltzer, Sean Turner, and Samuel Weiler for their 275 | roles in registering these algorithm identifiers. 276 | 277 | 278 | 279 | 280 | Jones Expires November 3, 2018 [Page 5] 281 | 282 | Internet-DraCOSE Algorithms for Web Authentication (WebAuthn) May 2018 283 | 284 | 285 | Document History 286 | 287 | [[ to be removed by the RFC Editor before publication as an RFC ]] 288 | 289 | -01 290 | 291 | o Updated the requested RS1 value from -262 to -65535 to match the 292 | temporary registration made on 2018-04-19. 293 | 294 | o Populated the Acknowledgements section. 295 | 296 | -00 297 | 298 | o Initial version. 299 | 300 | Author's Address 301 | 302 | Michael B. Jones 303 | Microsoft 304 | 305 | Email: mbj@microsoft.com 306 | URI: http://self-issued.info/ 307 | 308 | 309 | 310 | 311 | 312 | 313 | 314 | 315 | 316 | 317 | 318 | 319 | 320 | 321 | 322 | 323 | 324 | 325 | 326 | 327 | 328 | 329 | 330 | 331 | 332 | 333 | 334 | 335 | 336 | Jones Expires November 3, 2018 [Page 6] 337 | -------------------------------------------------------------------------------- /draft-jones-webauthn-cose-algorithms.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 18 | 19 | 20 | COSE Algorithms for Web Authentication (WebAuthn) 21 | 22 | 23 | Microsoft 24 |

25 | mbj@microsoft.com 26 | http://self-issued.info/ 27 |

28 | 29 | 30 | 31 | 32 | Security 33 | WebAuthn Working Group 34 | 35 | Cryptography 36 | Digital Signature 37 | Encryption 38 | Internet-Draft 39 | 40 | 41 | 42 | The W3C Web Authentication (WebAuthn) specification uses COSE algorithm identifiers. 43 | This specification registers algorithms in the IANA "COSE Algorithms" registry 44 | that are used by WebAuthn that are not already registered. 45 | Also, they are registered in the IANA "JSON Web Signature and Encryption Algorithms" registry, 46 | when not already registered there. 47 | 48 | 49 | 50 | 51 |

72 |

73 | 74 |

75 | 76 | The RSASSA-PKCS1-v1_5 signature algorithm is defined in . 77 | The RSASSA-PKCS1-v1_5 signature algorithm is parameterized with a hash function (h). 78 | 79 | 80 | A key of size 2048 bits or larger MUST be used with these algorithms. 81 | Implementations need to check that the key type is 'RSA' when creating or verifying a signature. 82 | 83 | 84 | The RSASSA-PKCS1-v1_5 algorithms specified in this document are in the following table. 85 | 86 | 87 | Name 88 | Value 89 | Hash 90 | Description 91 | 92 | RS256 93 | TBD (requested assignment -257) 94 | SHA-256 95 | RSASSA-PKCS1-v1_5 w/ SHA-256 96 | 97 | RS384 98 | TBD (requested assignment -258) 99 | SHA-384 100 | RSASSA-PKCS1-v1_5 w/ SHA-384 101 | 102 | RS512 103 | TBD (requested assignment -259) 104 | SHA-512 105 | RSASSA-PKCS1-v1_5 w/ SHA-512 106 | 107 | RS1 108 | TBD (requested assignment -65535) 109 | SHA-1 110 | RSASSA-PKCS1-v1_5 w/ SHA-1 111 | 112 | 113 |

114 | 115 |

116 | 117 |

118 | 119 | This section registers the following values in the 120 | IANA "COSE Algorithms" registry . 121 | 122 | 123 | 124 | 125 | 126 | Name: RS256 127 | 128 | 129 | Value: TBD (requested assignment -257) 130 | 131 | 132 | Description: RSASSA-PKCS1-v1_5 w/ SHA-256 133 | 134 | 135 | Reference: of this document 136 | 137 | 138 | Recommended: No 139 | 140 | 141 | 142 | 143 | 144 | 145 | Name: RS384 146 | 147 | 148 | Value: TBD (requested assignment -258) 149 | 150 | 151 | Description: RSASSA-PKCS1-v1_5 w/ SHA-384 152 | 153 | 154 | Reference: of this document 155 | 156 | 157 | Recommended: No 158 | 159 | 160 | 161 | 162 | 163 | 164 | Name: RS512 165 | 166 | 167 | Value: TBD (requested assignment -259) 168 | 169 | 170 | Description: RSASSA-PKCS1-v1_5 w/ SHA-512 171 | 172 | 173 | Reference: of this document 174 | 175 | 176 | Recommended: No 177 | 178 | 179 | 180 | 181 | 182 | 183 | Name: RS1 184 | 185 | 186 | Value: TBD (requested assignment -65535) 187 | 188 | 189 | Description: RSASSA-PKCS1-v1_5 w/ SHA-1 190 | 191 | 192 | Reference: of this document 193 | 194 | 195 | Recommended: Deprecated 196 | 197 | 198 | 199 | 200 |

201 | 202 |

203 | 204 |

205 | 206 |

207 | 208 | The security considerations on key sizes for RSA algorithms 209 | from Section 6.1 of also apply to the RSA algorithms 210 | in this specification. 211 | 212 |

213 | 214 |

215 | 216 | The security considerations on the use of RSASSA-PKCS1-v1_5 with SHA-2 hash functions 217 | from Section 8.3 of also apply to their use 218 | in this specification. 219 | For that reason, these algorithms are registered as being "Not Recommended". 220 | 221 |

222 | 223 |

237 | 238 |

239 | 240 | 241 | 242 | 243 | 244 | 245 | 246 | 247 | 248 | 249 | 250 | 251 | 252 | 253 | 254 | 255 | 256 | 257 | 258 | 259 | 260 | 261 | Web Authentication: An API for accessing Public Key Credentials 262 | 263 | Google 264 |

265 | balfanz@google.com 266 |

267 | 268 | 269 | 270 | Google 271 |

272 | aczeskis@google.com 273 |

274 | 275 | 276 | 277 | PayPal 278 |

279 | Jeff.Hodges@paypal.com 280 |

281 | 282 | 283 | 284 | Mozilla 285 |

286 | jc@mozilla.com 287 |

288 | 289 | 290 | 291 | Microsoft 292 |

293 | mbj@microsoft.com 294 | http://self-issued.info/ 295 |

296 | 297 | 298 | 299 | Microsoft 300 |

301 | akshayku@microsoft.com 302 |

303 | 304 | 305 | 306 | Microsoft 307 |

308 | huliao@microsoft.com 309 |

310 | 311 | 312 | 313 | Nok Nok Labs 314 |

315 | rolf@noknok.com 316 |

317 | 318 | 319 | 320 | Yubico 321 |

322 | emil@yubico.com 323 |

324 | 325 | 326 | 327 | 328 | 329 | 330 | 331 | 332 | 333 | 334 | 335 | COSE Algorithms 336 | 337 | IANA 338 | 339 | 340 | 341 | 342 | 343 | 344 | 345 | JSON Web Signature and Encryption Algorithms 346 | 347 | IANA 348 | 349 | 350 | 351 | 352 | 353 | 354 | 355 |

371 | 372 |

373 | 374 | [[ to be removed by the RFC Editor before publication as an RFC ]] 375 | 376 | 377 | 378 | -01 379 | 380 | 381 | Updated the requested RS1 value from -262 to -65535 382 | to match the temporary registration made on 2018-04-19. 383 | 384 | 385 | Populated the Acknowledgements section. 386 | 387 | 388 | 389 | 390 | 391 | -00 392 | 393 | 394 | Initial version. 395 | 396 | 397 | 398 | 399 |

400 | 401 | 402 | 403 | -------------------------------------------------------------------------------- /draft-jones-webauthn-secp256k1.txt: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | WebAuthn Working Group M. Jones 6 | Internet-Draft Microsoft 7 | Intended status: Informational May 30, 2018 8 | Expires: December 1, 2018 9 | 10 | 11 | Using secp256k1 with JOSE and COSE 12 | draft-jones-webauthn-secp256k1-00 13 | 14 | Abstract 15 | 16 | This specification defines algorithm encodings and representations 17 | enabling the Standards for Efficient Cryptography Group (SECG) 18 | elliptic curve "secp256k1" to be used for JSON Object Signing and 19 | Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) 20 | messages. 21 | 22 | Status of This Memo 23 | 24 | This Internet-Draft is submitted in full conformance with the 25 | provisions of BCP 78 and BCP 79. 26 | 27 | Internet-Drafts are working documents of the Internet Engineering 28 | Task Force (IETF). Note that other groups may also distribute 29 | working documents as Internet-Drafts. The list of current Internet- 30 | Drafts is at https://datatracker.ietf.org/drafts/current/. 31 | 32 | Internet-Drafts are draft documents valid for a maximum of six months 33 | and may be updated, replaced, or obsoleted by other documents at any 34 | time. It is inappropriate to use Internet-Drafts as reference 35 | material or to cite them other than as "work in progress." 36 | 37 | This Internet-Draft will expire on December 1, 2018. 38 | 39 | Copyright Notice 40 | 41 | Copyright (c) 2018 IETF Trust and the persons identified as the 42 | document authors. All rights reserved. 43 | 44 | This document is subject to BCP 78 and the IETF Trust's Legal 45 | Provisions Relating to IETF Documents 46 | (https://trustee.ietf.org/license-info) in effect on the date of 47 | publication of this document. Please review these documents 48 | carefully, as they describe your rights and restrictions with respect 49 | to this document. Code Components extracted from this document must 50 | include Simplified BSD License text as described in Section 4.e of 51 | the Trust Legal Provisions and are provided without warranty as 52 | described in the Simplified BSD License. 53 | 54 | 55 | 56 | Jones Expires December 1, 2018 [Page 1] 57 | 58 | Internet-Draft Using secp256k1 with JOSE and COSE May 2018 59 | 60 | 61 | Table of Contents 62 | 63 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 | 1.1. Requirements Notation and Conventions . . . . . . . . . . 2 65 | 2. JOSE and COSE secp256k1 Curve Key Representations . . . . . . 2 66 | 3. ECDSA Signature with secp256k1 Curve . . . . . . . . . . . . 3 67 | 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 68 | 4.1. JSON Web Key Elliptic Curve Registration . . . . . . . . 3 69 | 4.2. JOSE Algorithm Registration . . . . . . . . . . . . . . . 3 70 | 4.3. COSE Elliptic Curves Registration . . . . . . . . . . . . 4 71 | 4.4. COSE Algorithm Registration . . . . . . . . . . . . . . . 4 72 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 73 | 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 | 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 75 | 6.2. Informative References . . . . . . . . . . . . . . . . . 5 76 | Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6 77 | Document History . . . . . . . . . . . . . . . . . . . . . . . . 6 78 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 79 | 80 | 1. Introduction 81 | 82 | This specification defines algorithm encodings and representations 83 | enabling the Standards for Efficient Cryptography Group (SECG) 84 | elliptic curve "secp256k1" [SEC2] to be used for JSON Object Signing 85 | and Encryption (JOSE) [RFC7515] and CBOR Object Signing and 86 | Encryption (COSE) [RFC8152] messages. The elliptic curve and 87 | associated algorithm are registered in appropriate IANA JOSE and COSE 88 | registries. 89 | 90 | 1.1. Requirements Notation and Conventions 91 | 92 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 94 | "OPTIONAL" in this document are to be interpreted as described in BCP 95 | 14 [RFC2119] [RFC8174] when, and only when, they appear in all 96 | capitals, as shown here. 97 | 98 | 2. JOSE and COSE secp256k1 Curve Key Representations 99 | 100 | The Standards for Efficient Cryptography Group (SECG) elliptic curve 101 | "secp256k1" [SEC2] is represented in a JSON Web Key (JWK) [RFC7517] 102 | using these values: 103 | 104 | o "kty": "EC" 105 | o "crv": "P-256K" 106 | 107 | plus "x" and "y" values to represent the curve point for the key. 108 | Other optional values such as "alg" MAY also be present. 109 | 110 | 111 | 112 | Jones Expires December 1, 2018 [Page 2] 113 | 114 | Internet-Draft Using secp256k1 with JOSE and COSE May 2018 115 | 116 | 117 | It is represented in a COSE_Key [RFC8152] using these values: 118 | 119 | o "kty" (1): "EC2" (2) 120 | o "crv" (-1): "P-256K" (TBD - requested assignment 8) 121 | 122 | plus "x" (-2) and "y" (-3) values to represent the curve point for 123 | the key. Other optional values such as "alg" (3) MAY also be 124 | present. 125 | 126 | 3. ECDSA Signature with secp256k1 Curve 127 | 128 | The ECDSA signature algorithm is defined in [DSS]. Implementations 129 | need to check that the key type is "EC" for JOSE or "EC2" (2) for 130 | COSE when creating or verifying a signature. 131 | 132 | The ECDSA algorithm specified in this document is: 133 | 134 | +--------------+---------------------------+------------------------+ 135 | | JOSE Alg | COSE Alg Value | Description | 136 | | Name | | | 137 | +--------------+---------------------------+------------------------+ 138 | | ES256K | TBD (requested assignment | ECDSA w/ secp256k1 | 139 | | | -43) | Curve | 140 | +--------------+---------------------------+------------------------+ 141 | 142 | Table 1: ECDSA Algorithm Values 143 | 144 | 4. IANA Considerations 145 | 146 | 4.1. JSON Web Key Elliptic Curve Registration 147 | 148 | This section registers the following value in the IANA "JSON Web Key 149 | Elliptic Curve" registry [IANA.JOSE.Curves]. 150 | 151 | o Curve Name: P-256K 152 | o Curve Description: SECG secp256k1 Curve 153 | o JOSE Implementation Requirements: Optional 154 | o Change Controller: IESG 155 | o Specification Document(s): Section 2 of [[ this specification ]] 156 | 157 | 4.2. JOSE Algorithm Registration 158 | 159 | This section registers the following value in the IANA "JSON Web 160 | Signature and Encryption Algorithms" registry [IANA.JOSE.Algorithms]. 161 | 162 | o Algorithm Name: ES256K 163 | o Algorithm Description: ECDSA w/ secp256k1 Curve 164 | o Algorithm Usage Locations: alg 165 | 166 | 167 | 168 | Jones Expires December 1, 2018 [Page 3] 169 | 170 | Internet-Draft Using secp256k1 with JOSE and COSE May 2018 171 | 172 | 173 | o JOSE Implementation Requirements: Optional 174 | o Change Controller: IESG 175 | o Reference: Section 3 of [[ this specification ]] 176 | o Algorithm Analysis Document(s): [SEC2] 177 | 178 | 4.3. COSE Elliptic Curves Registration 179 | 180 | This section registers the following value in the IANA "COSE Elliptic 181 | Curves" registry [IANA.COSE.Curves]. 182 | 183 | o Name: P-256K 184 | o Value: TBD (requested assignment 8) 185 | o Key Type: EC2 186 | o Description: SECG secp256k1 Curve 187 | o Change Controller: IESG 188 | o Reference: Section 2 of [[ this specification ]] 189 | o Recommended: Yes 190 | 191 | 4.4. COSE Algorithm Registration 192 | 193 | This section registers the following value in the IANA "COSE 194 | Algorithms" registry [IANA.COSE.Algorithms]. 195 | 196 | o Name: ES256K 197 | o Value: TBD (requested assignment -43) 198 | o Description: ECDSA w/ secp256k1 Curve 199 | o Reference: Section 3 of this document 200 | o Recommended: Yes 201 | 202 | 5. Security Considerations 203 | 204 | Care should be taken that a secp256k1 key not be mistaken for a P-256 205 | key, given that their representations are the same except for the 206 | "crv" value. 207 | 208 | The procedures and security considerations described in the [SEC1], 209 | [SEC2], and [DSS] specifications apply to implementations of this 210 | specification. 211 | 212 | 6. References 213 | 214 | 6.1. Normative References 215 | 216 | [DSS] National Institute of Standards and Technology (NIST), 217 | "Digital Signature Standard (DSS)", FIPS PUB 186-4, July 218 | 2013, . 220 | 221 | 222 | 223 | 224 | Jones Expires December 1, 2018 [Page 4] 225 | 226 | Internet-Draft Using secp256k1 with JOSE and COSE May 2018 227 | 228 | 229 | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 230 | Requirement Levels", BCP 14, RFC 2119, 231 | DOI 10.17487/RFC2119, March 1997, 232 | . 233 | 234 | [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 235 | Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 236 | 2015, . 237 | 238 | [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 239 | DOI 10.17487/RFC7517, May 2015, 240 | . 241 | 242 | [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 243 | RFC 8152, DOI 10.17487/RFC8152, July 2017, 244 | . 245 | 246 | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 247 | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 248 | May 2017, . 249 | 250 | [SEC1] Standards for Efficient Cryptography Group, "SEC 1: 251 | Elliptic Curve Cryptography", Version 2.0, May 2009, 252 | . 253 | 254 | [SEC2] Standards for Efficient Cryptography Group, "SEC 2: 255 | Recommended Elliptic Curve Domain Parameters", 256 | Version 2.0, January 2010, 257 | . 258 | 259 | 6.2. Informative References 260 | 261 | [IANA.COSE.Algorithms] 262 | IANA, "COSE Algorithms", 263 | . 265 | 266 | [IANA.COSE.Curves] 267 | IANA, "COSE Elliptic Curves", 268 | . 270 | 271 | [IANA.JOSE.Algorithms] 272 | IANA, "JSON Web Signature and Encryption Algorithms", 273 | . 275 | 276 | 277 | 278 | 279 | 280 | Jones Expires December 1, 2018 [Page 5] 281 | 282 | Internet-Draft Using secp256k1 with JOSE and COSE May 2018 283 | 284 | 285 | [IANA.JOSE.Curves] 286 | IANA, "JSON Web Key Elliptic Curve", 287 | . 289 | 290 | Acknowledgements 291 | 292 | TBD 293 | 294 | Document History 295 | 296 | [[ to be removed by the RFC Editor before publication as an RFC ]] 297 | 298 | -00 299 | 300 | o Initial version. 301 | 302 | Author's Address 303 | 304 | Michael B. Jones 305 | Microsoft 306 | 307 | Email: mbj@microsoft.com 308 | URI: http://self-issued.info/ 309 | 310 | 311 | 312 | 313 | 314 | 315 | 316 | 317 | 318 | 319 | 320 | 321 | 322 | 323 | 324 | 325 | 326 | 327 | 328 | 329 | 330 | 331 | 332 | 333 | 334 | 335 | 336 | Jones Expires December 1, 2018 [Page 6] 337 | -------------------------------------------------------------------------------- /draft-jones-webauthn-secp256k1.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 18 | 19 | 20 | Using secp256k1 with JOSE and COSE 21 | 22 | 23 | Microsoft 24 |

25 | mbj@microsoft.com 26 | http://self-issued.info/ 27 |

28 | 29 | 30 | 31 | 32 | Security 33 | WebAuthn Working Group 34 | 35 | Cryptography 36 | Digital Signature 37 | Encryption 38 | Internet-Draft 39 | 40 | 41 | 42 | This specification defines algorithm encodings and representations enabling the 43 | Standards for Efficient Cryptography Group (SECG) elliptic curve "secp256k1" to be used for 44 | JSON Object Signing and Encryption (JOSE) and 45 | CBOR Object Signing and Encryption (COSE) messages. 46 | 47 | 48 | 49 | 50 |

70 |

71 | 72 |

73 | 74 | The Standards for Efficient Cryptography Group (SECG) elliptic curve 75 | "secp256k1" is represented in 76 | a JSON Web Key (JWK) using these values: 77 | 78 | 79 | 80 | 81 | kty: EC 82 | crv: P-256K 83 | 84 | 85 | 86 | 87 | plus x and y values 88 | to represent the curve point for the key. 89 | Other optional values such as alg MAY also be present. 90 | 91 | 92 | It is represented in a COSE_Key using these values: 93 | 94 | 95 | 96 | 97 | kty (1): EC2 (2) 98 | crv (-1): P-256K (TBD - requested assignment 8) 99 | 100 | 101 | 102 | 103 | plus x (-2) and y (-3) values 104 | to represent the curve point for the key. 105 | Other optional values such as alg (3) MAY also be present. 106 | 107 |

108 | 109 |

110 | 111 | The ECDSA signature algorithm is defined in . 112 | Implementations need to check that the key type is EC for JOSE or 113 | EC2 (2) for COSE when creating or verifying a signature. 114 | 115 | 116 | The ECDSA algorithm specified in this document is: 117 | 118 | 119 | JOSE Alg Name 120 | COSE Alg Value 121 | Description 122 | 123 | ES256K 124 | TBD (requested assignment -43) 125 | ECDSA w/ secp256k1 Curve 126 | 127 | 128 |

129 | 130 |

131 | 132 |

133 | 134 | This section registers the following value in the 135 | IANA "JSON Web Key Elliptic Curve" registry . 136 | 137 | 138 | 139 | 140 | 141 | Curve Name: P-256K 142 | 143 | 144 | Curve Description: SECG secp256k1 Curve 145 | 146 | 147 | JOSE Implementation Requirements: Optional 148 | 149 | 150 | Change Controller: IESG 151 | 152 | 153 | Specification Document(s): of [[ this specification ]] 154 | 155 | 156 | 157 | 158 |

159 | 160 |

161 | 162 | This section registers the following value in the 163 | IANA "JSON Web Signature and Encryption Algorithms" registry . 164 | 165 | 166 | 167 | 168 | 169 | Algorithm Name: ES256K 170 | 171 | 172 | Algorithm Description: ECDSA w/ secp256k1 Curve 173 | 174 | 175 | Algorithm Usage Locations: alg 176 | 177 | 178 | JOSE Implementation Requirements: Optional 179 | 180 | 181 | Change Controller: IESG 182 | 183 | 184 | Reference: of [[ this specification ]] 185 | 186 | 187 | Algorithm Analysis Document(s): 188 | 189 | 190 | 191 | 192 |

193 | 194 |

195 | 196 | This section registers the following value in the 197 | IANA "COSE Elliptic Curves" registry . 198 | 199 | 200 | 201 | 202 | 203 | Name: P-256K 204 | 205 | 206 | Value: TBD (requested assignment 8) 207 | 208 | 209 | Key Type: EC2 210 | 211 | 212 | Description: SECG secp256k1 Curve 213 | 214 | 215 | Change Controller: IESG 216 | 217 | 218 | Reference: of [[ this specification ]] 219 | 220 | 221 | Recommended: Yes 222 | 223 | 224 | 225 | 226 |

227 | 228 |

229 | 230 | This section registers the following value in the 231 | IANA "COSE Algorithms" registry . 232 | 233 | 234 | 235 | 236 | 237 | Name: ES256K 238 | 239 | 240 | Value: TBD (requested assignment -43) 241 | 242 | 243 | Description: ECDSA w/ secp256k1 Curve 244 | 245 | 246 | Reference: of this document 247 | 248 | 249 | Recommended: Yes 250 | 251 | 252 | 253 | 254 |

255 | 256 |

257 | 258 |

259 | 260 | Care should be taken that a secp256k1 key not be mistaken for a P-256 key, 261 | given that their representations are the same 262 | except for the crv value. 263 | 264 | 265 | The procedures and security considerations described in the 266 | , , and 267 | specifications apply to implementations of this specification. 268 | 269 |

270 | 271 | 272 | 273 | 274 | 275 | 276 | 277 | 278 | 279 | 280 | 281 | 282 | 283 | 284 | Digital Signature Standard (DSS) 285 | 286 | 287 | National Institute of Standards and 288 | Technology (NIST) 289 | 290 | 291 | 292 | 293 | 294 | 295 | 296 | 297 | 298 | SEC 1: Elliptic Curve Cryptography 299 | 300 | Standards for Efficient Cryptography Group 301 | 302 | 303 | 304 | 305 | 306 | 307 | 308 | 309 | SEC 2: Recommended Elliptic Curve Domain Parameters 310 | 311 | Standards for Efficient Cryptography Group 312 | 313 | 314 | 315 | 316 | 317 | 318 | 319 | 320 | 321 | 322 | 323 | 324 | JSON Web Signature and Encryption Algorithms 325 | 326 | IANA 327 | 328 | 329 | 330 | 331 | 332 | 333 | 334 | JSON Web Key Elliptic Curve 335 | 336 | IANA 337 | 338 | 339 | 340 | 341 | 342 | 343 | 344 | COSE Algorithms 345 | 346 | IANA 347 | 348 | 349 | 350 | 351 | 352 | 353 | 354 | COSE Elliptic Curves 355 | 356 | IANA 357 | 358 | 359 | 360 | 361 | 362 | 363 | 364 |

365 | 366 | TBD 367 | 368 |

369 | 370 |

371 | 372 | [[ to be removed by the RFC Editor before publication as an RFC ]] 373 | 374 | 375 | 376 | -00 377 | 378 | 379 | Initial version. 380 | 381 | 382 | 383 | 384 |

385 | 386 | 387 | 388 | -------------------------------------------------------------------------------- /images/fido-attestation-structures.svg: -------------------------------------------------------------------------------- 1 | 130 | -------------------------------------------------------------------------------- /images/fido-signature-formats-figure1.svg: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /images/fido-signature-formats-figure2.svg: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /images/string-truncation.svg: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /images/webauthn-authentication-flow-01.svg: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /images/webauthn-registration-flow-01.svg: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /manifest.txt: -------------------------------------------------------------------------------- 1 | index.html 2 | images/fido-signature-formats-figure2.svg 3 | images/webauthn-authentication-flow-01.svg 4 | images/webauthn-registration-flow-01.svg 5 | images/fido-attestation-structures.svg 6 | images/fido-signature-formats-figure1.svg 7 | images/string-truncation.svg 8 | -------------------------------------------------------------------------------- /meetings/2016-03-04-F2F.md: -------------------------------------------------------------------------------- 1 | Prelminary Agenda for WebAuthn F2F, 4 March 2016 2 | 3 | - Intros around the table 4 | - Intro to W3C; Intro to FIDO 5 | - Charter scope 6 | - Technical overview of the specs 7 | 8 | - WG Adoption of the Submission drafts: editors, work-mode (github pull requests, issue resolution, decision process), timeline to FPWDs 9 | 10 | - Privacy and security considerations 11 | - Liaisons (IETF, W3C, FIDO, and other groups) 12 | - Other participants who should be here, globally 13 | 14 | - Any initial issues? 15 | - Further use cases/requirements? 16 | 17 | Minutes: https://www.w3.org/2016/03/04-webauthn-minutes.html 18 | -------------------------------------------------------------------------------- /meetings/2016-05-13-Berlin-f2f.md: -------------------------------------------------------------------------------- 1 | # WebAuthentication F2F 2 | 3 | 13 May 2016, Berlin, DE (all times local to Berlin, UTC+1) 4 | 5 | hosted by Microsoft, [Unter den Linden 17](https://www.microsoft.com/de-de/berlin/unter-den-linden-17/) 6 | 7 | ## 09:00-10:30 8 | * Welcome 9 | * Intros 10 | * Review of status 11 | * Review of open FPWD issues 12 | 13 | ## 10:30-11:00 Break 14 | 15 | ## 11:00-12:00 16 | * Discussion of remaining FPWD issues (goal: get all editor-ready) 17 | 18 | ## 12:00-13:00 Break 19 | 20 | ## 13:00-14:30 21 | * Finalize FPWD timeline (incl. review / dependencies) 22 | * Triage of SPWD issues 23 | 24 | ## 14:30-15:00 Break 25 | 26 | ## 15:00-17:00 27 | * SPWD issue discussion 28 | * Discussion of TPAC F2F 29 | * Wrap-up 30 | 31 | -------------------------------------------------------------------------------- /test-vectors/README.md: -------------------------------------------------------------------------------- 1 | Scripts for generating WebAuthn test vectors 2 | === 3 | 4 | This directory hosts scripts for generating test vectors to include in the Web Authentication spec. 5 | 6 | 7 | Usage 8 | --- 9 | 10 | Use the script `inject-generated-content.sh` to generate and inject the content into `../index.bs`: 11 | 12 | ```sh 13 | $ cd test-vectors 14 | $ ./inject-generated-content.sh 15 | ``` 16 | 17 | If run with `--check`, the script will return a nonzero exit code if it results in any changes to `../index.bs`: 18 | 19 | ```sh 20 | $ ./inject-generated-content.sh --check 21 | ``` 22 | 23 | Alternatively, you can run the content generation scripts manually: 24 | 25 | ```sh 26 | $ poetry install 27 | $ poetry run python webauthn-test-vectors.py 28 | $ poetry run python webauthn-prf-test-vectors.py 29 | ``` 30 | 31 | Then paste the script outputs into the respective relevant part of `index.bs`. 32 | -------------------------------------------------------------------------------- /test-vectors/inject-generated-content.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | # Exit on error 4 | set -e 5 | 6 | 7 | inject() { 8 | SCRIPT="$1" 9 | BLOCK_TAG="GENERATED CONTENT: Use test-vectors\/${SCRIPT}" 10 | 11 | # Print everything before the generated content block 12 | sed "//,\$d" < ../index.bs > index.bs.new 13 | 14 | # Print the generated content block 15 | poetry run python "${SCRIPT}" >> index.bs.new 16 | 17 | # Print everything after the generated content block 18 | sed "0,//d" < ../index.bs >> index.bs.new 19 | 20 | mv index.bs.new ../index.bs 21 | } 22 | 23 | if [[ "$1" == "--check" ]]; then 24 | if ! git diff --exit-code --stat -- ../index.bs; then 25 | echo "Cannot check if test vectors are up to date. Please commit or revert changes to index.bs first." 26 | exit 1 27 | fi 28 | fi 29 | 30 | poetry install 31 | inject webauthn-test-vectors.py 32 | inject webauthn-prf-test-vectors.py 33 | 34 | if [[ "$1" == "--check" ]]; then 35 | if git diff --exit-code --stat -- ../index.bs; then 36 | echo "Generated content is up to date." 37 | else 38 | echo "Generated content is up not to date. Please run test-vectors/inject-generated-content.sh and commit the results." 39 | exit 1 40 | fi 41 | fi 42 | -------------------------------------------------------------------------------- /test-vectors/poetry.lock: -------------------------------------------------------------------------------- 1 | # This file is automatically @generated by Poetry 2.1.2 and should not be changed by hand. 2 | 3 | [[package]] 4 | name = "asn1" 5 | version = "3.0.1" 6 | description = "Python-ASN1 is a simple ASN.1 encoder and decoder for Python 2.7+ and 3.5+." 7 | optional = false 8 | python-versions = "*" 9 | groups = ["main"] 10 | files = [ 11 | {file = "asn1-3.0.1-py2.py3-none-any.whl", hash = "sha256:733a460de22904640ddecf8a95f2f4005adf3623a1c51e48428a7aa2bd493cd0"}, 12 | {file = "asn1-3.0.1.tar.gz", hash = "sha256:ff96b971ddc276a479c66efd67a91d3d83e4a45425f1f657833ed399eab7fc45"}, 13 | ] 14 | 15 | [package.dependencies] 16 | enum-compat = "*" 17 | 18 | [[package]] 19 | name = "cffi" 20 | version = "1.17.1" 21 | description = "Foreign Function Interface for Python calling C code." 22 | optional = false 23 | python-versions = ">=3.8" 24 | groups = ["main"] 25 | markers = "platform_python_implementation != \"PyPy\"" 26 | files = [ 27 | {file = "cffi-1.17.1-cp310-cp310-macosx_10_9_x86_64.whl", hash = "sha256:df8b1c11f177bc2313ec4b2d46baec87a5f3e71fc8b45dab2ee7cae86d9aba14"}, 28 | {file = "cffi-1.17.1-cp310-cp310-macosx_11_0_arm64.whl", hash = "sha256:8f2cdc858323644ab277e9bb925ad72ae0e67f69e804f4898c070998d50b1a67"}, 29 | {file = "cffi-1.17.1-cp310-cp310-manylinux_2_12_i686.manylinux2010_i686.manylinux_2_17_i686.manylinux2014_i686.whl", hash = "sha256:edae79245293e15384b51f88b00613ba9f7198016a5948b5dddf4917d4d26382"}, 30 | {file = "cffi-1.17.1-cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:45398b671ac6d70e67da8e4224a065cec6a93541bb7aebe1b198a61b58c7b702"}, 31 | {file = "cffi-1.17.1-cp310-cp310-manylinux_2_17_ppc64le.manylinux2014_ppc64le.whl", hash = "sha256:ad9413ccdeda48c5afdae7e4fa2192157e991ff761e7ab8fdd8926f40b160cc3"}, 32 | {file = "cffi-1.17.1-cp310-cp310-manylinux_2_17_s390x.manylinux2014_s390x.whl", hash = "sha256:5da5719280082ac6bd9aa7becb3938dc9f9cbd57fac7d2871717b1feb0902ab6"}, 33 | {file = "cffi-1.17.1-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:2bb1a08b8008b281856e5971307cc386a8e9c5b625ac297e853d36da6efe9c17"}, 34 | {file = "cffi-1.17.1-cp310-cp310-musllinux_1_1_aarch64.whl", hash = "sha256:045d61c734659cc045141be4bae381a41d89b741f795af1dd018bfb532fd0df8"}, 35 | {file = "cffi-1.17.1-cp310-cp310-musllinux_1_1_i686.whl", hash = "sha256:6883e737d7d9e4899a8a695e00ec36bd4e5e4f18fabe0aca0efe0a4b44cdb13e"}, 36 | {file = "cffi-1.17.1-cp310-cp310-musllinux_1_1_x86_64.whl", hash = "sha256:6b8b4a92e1c65048ff98cfe1f735ef8f1ceb72e3d5f0c25fdb12087a23da22be"}, 37 | {file = "cffi-1.17.1-cp310-cp310-win32.whl", hash = "sha256:c9c3d058ebabb74db66e431095118094d06abf53284d9c81f27300d0e0d8bc7c"}, 38 | {file = "cffi-1.17.1-cp310-cp310-win_amd64.whl", hash = "sha256:0f048dcf80db46f0098ccac01132761580d28e28bc0f78ae0d58048063317e15"}, 39 | {file = "cffi-1.17.1-cp311-cp311-macosx_10_9_x86_64.whl", hash = "sha256:a45e3c6913c5b87b3ff120dcdc03f6131fa0065027d0ed7ee6190736a74cd401"}, 40 | {file = "cffi-1.17.1-cp311-cp311-macosx_11_0_arm64.whl", hash = "sha256:30c5e0cb5ae493c04c8b42916e52ca38079f1b235c2f8ae5f4527b963c401caf"}, 41 | {file = "cffi-1.17.1-cp311-cp311-manylinux_2_12_i686.manylinux2010_i686.manylinux_2_17_i686.manylinux2014_i686.whl", hash = "sha256:f75c7ab1f9e4aca5414ed4d8e5c0e303a34f4421f8a0d47a4d019ceff0ab6af4"}, 42 | {file = "cffi-1.17.1-cp311-cp311-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:a1ed2dd2972641495a3ec98445e09766f077aee98a1c896dcb4ad0d303628e41"}, 43 | {file = "cffi-1.17.1-cp311-cp311-manylinux_2_17_ppc64le.manylinux2014_ppc64le.whl", hash = "sha256:46bf43160c1a35f7ec506d254e5c890f3c03648a4dbac12d624e4490a7046cd1"}, 44 | {file = "cffi-1.17.1-cp311-cp311-manylinux_2_17_s390x.manylinux2014_s390x.whl", hash = "sha256:a24ed04c8ffd54b0729c07cee15a81d964e6fee0e3d4d342a27b020d22959dc6"}, 45 | {file = "cffi-1.17.1-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:610faea79c43e44c71e1ec53a554553fa22321b65fae24889706c0a84d4ad86d"}, 46 | {file = "cffi-1.17.1-cp311-cp311-musllinux_1_1_aarch64.whl", hash = "sha256:a9b15d491f3ad5d692e11f6b71f7857e7835eb677955c00cc0aefcd0669adaf6"}, 47 | {file = "cffi-1.17.1-cp311-cp311-musllinux_1_1_i686.whl", hash = "sha256:de2ea4b5833625383e464549fec1bc395c1bdeeb5f25c4a3a82b5a8c756ec22f"}, 48 | {file = "cffi-1.17.1-cp311-cp311-musllinux_1_1_x86_64.whl", hash = "sha256:fc48c783f9c87e60831201f2cce7f3b2e4846bf4d8728eabe54d60700b318a0b"}, 49 | {file = "cffi-1.17.1-cp311-cp311-win32.whl", hash = "sha256:85a950a4ac9c359340d5963966e3e0a94a676bd6245a4b55bc43949eee26a655"}, 50 | {file = "cffi-1.17.1-cp311-cp311-win_amd64.whl", hash = "sha256:caaf0640ef5f5517f49bc275eca1406b0ffa6aa184892812030f04c2abf589a0"}, 51 | {file = "cffi-1.17.1-cp312-cp312-macosx_10_9_x86_64.whl", hash = "sha256:805b4371bf7197c329fcb3ead37e710d1bca9da5d583f5073b799d5c5bd1eee4"}, 52 | {file = "cffi-1.17.1-cp312-cp312-macosx_11_0_arm64.whl", hash = "sha256:733e99bc2df47476e3848417c5a4540522f234dfd4ef3ab7fafdf555b082ec0c"}, 53 | {file = "cffi-1.17.1-cp312-cp312-manylinux_2_12_i686.manylinux2010_i686.manylinux_2_17_i686.manylinux2014_i686.whl", hash = "sha256:1257bdabf294dceb59f5e70c64a3e2f462c30c7ad68092d01bbbfb1c16b1ba36"}, 54 | {file = "cffi-1.17.1-cp312-cp312-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:da95af8214998d77a98cc14e3a3bd00aa191526343078b530ceb0bd710fb48a5"}, 55 | {file = "cffi-1.17.1-cp312-cp312-manylinux_2_17_ppc64le.manylinux2014_ppc64le.whl", hash = "sha256:d63afe322132c194cf832bfec0dc69a99fb9bb6bbd550f161a49e9e855cc78ff"}, 56 | {file = "cffi-1.17.1-cp312-cp312-manylinux_2_17_s390x.manylinux2014_s390x.whl", hash = "sha256:f79fc4fc25f1c8698ff97788206bb3c2598949bfe0fef03d299eb1b5356ada99"}, 57 | {file = "cffi-1.17.1-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:b62ce867176a75d03a665bad002af8e6d54644fad99a3c70905c543130e39d93"}, 58 | {file = "cffi-1.17.1-cp312-cp312-musllinux_1_1_aarch64.whl", hash = "sha256:386c8bf53c502fff58903061338ce4f4950cbdcb23e2902d86c0f722b786bbe3"}, 59 | {file = "cffi-1.17.1-cp312-cp312-musllinux_1_1_x86_64.whl", hash = "sha256:4ceb10419a9adf4460ea14cfd6bc43d08701f0835e979bf821052f1805850fe8"}, 60 | {file = "cffi-1.17.1-cp312-cp312-win32.whl", hash = "sha256:a08d7e755f8ed21095a310a693525137cfe756ce62d066e53f502a83dc550f65"}, 61 | {file = "cffi-1.17.1-cp312-cp312-win_amd64.whl", hash = "sha256:51392eae71afec0d0c8fb1a53b204dbb3bcabcb3c9b807eedf3e1e6ccf2de903"}, 62 | {file = "cffi-1.17.1-cp313-cp313-macosx_10_13_x86_64.whl", hash = "sha256:f3a2b4222ce6b60e2e8b337bb9596923045681d71e5a082783484d845390938e"}, 63 | {file = "cffi-1.17.1-cp313-cp313-macosx_11_0_arm64.whl", hash = "sha256:0984a4925a435b1da406122d4d7968dd861c1385afe3b45ba82b750f229811e2"}, 64 | {file = "cffi-1.17.1-cp313-cp313-manylinux_2_12_i686.manylinux2010_i686.manylinux_2_17_i686.manylinux2014_i686.whl", hash = "sha256:d01b12eeeb4427d3110de311e1774046ad344f5b1a7403101878976ecd7a10f3"}, 65 | {file = "cffi-1.17.1-cp313-cp313-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:706510fe141c86a69c8ddc029c7910003a17353970cff3b904ff0686a5927683"}, 66 | {file = "cffi-1.17.1-cp313-cp313-manylinux_2_17_ppc64le.manylinux2014_ppc64le.whl", hash = "sha256:de55b766c7aa2e2a3092c51e0483d700341182f08e67c63630d5b6f200bb28e5"}, 67 | {file = "cffi-1.17.1-cp313-cp313-manylinux_2_17_s390x.manylinux2014_s390x.whl", hash = "sha256:c59d6e989d07460165cc5ad3c61f9fd8f1b4796eacbd81cee78957842b834af4"}, 68 | {file = "cffi-1.17.1-cp313-cp313-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:dd398dbc6773384a17fe0d3e7eeb8d1a21c2200473ee6806bb5e6a8e62bb73dd"}, 69 | {file = "cffi-1.17.1-cp313-cp313-musllinux_1_1_aarch64.whl", hash = "sha256:3edc8d958eb099c634dace3c7e16560ae474aa3803a5df240542b305d14e14ed"}, 70 | {file = "cffi-1.17.1-cp313-cp313-musllinux_1_1_x86_64.whl", hash = "sha256:72e72408cad3d5419375fc87d289076ee319835bdfa2caad331e377589aebba9"}, 71 | {file = "cffi-1.17.1-cp313-cp313-win32.whl", hash = "sha256:e03eab0a8677fa80d646b5ddece1cbeaf556c313dcfac435ba11f107ba117b5d"}, 72 | {file = "cffi-1.17.1-cp313-cp313-win_amd64.whl", hash = "sha256:f6a16c31041f09ead72d69f583767292f750d24913dadacf5756b966aacb3f1a"}, 73 | {file = "cffi-1.17.1-cp38-cp38-macosx_10_9_x86_64.whl", hash = "sha256:636062ea65bd0195bc012fea9321aca499c0504409f413dc88af450b57ffd03b"}, 74 | {file = "cffi-1.17.1-cp38-cp38-manylinux_2_12_i686.manylinux2010_i686.manylinux_2_17_i686.manylinux2014_i686.whl", hash = "sha256:c7eac2ef9b63c79431bc4b25f1cd649d7f061a28808cbc6c47b534bd789ef964"}, 75 | {file = "cffi-1.17.1-cp38-cp38-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:e221cf152cff04059d011ee126477f0d9588303eb57e88923578ace7baad17f9"}, 76 | {file = "cffi-1.17.1-cp38-cp38-manylinux_2_17_ppc64le.manylinux2014_ppc64le.whl", hash = "sha256:31000ec67d4221a71bd3f67df918b1f88f676f1c3b535a7eb473255fdc0b83fc"}, 77 | {file = "cffi-1.17.1-cp38-cp38-manylinux_2_17_s390x.manylinux2014_s390x.whl", hash = "sha256:6f17be4345073b0a7b8ea599688f692ac3ef23ce28e5df79c04de519dbc4912c"}, 78 | {file = "cffi-1.17.1-cp38-cp38-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:0e2b1fac190ae3ebfe37b979cc1ce69c81f4e4fe5746bb401dca63a9062cdaf1"}, 79 | {file = "cffi-1.17.1-cp38-cp38-win32.whl", hash = "sha256:7596d6620d3fa590f677e9ee430df2958d2d6d6de2feeae5b20e82c00b76fbf8"}, 80 | {file = "cffi-1.17.1-cp38-cp38-win_amd64.whl", hash = "sha256:78122be759c3f8a014ce010908ae03364d00a1f81ab5c7f4a7a5120607ea56e1"}, 81 | {file = "cffi-1.17.1-cp39-cp39-macosx_10_9_x86_64.whl", hash = "sha256:b2ab587605f4ba0bf81dc0cb08a41bd1c0a5906bd59243d56bad7668a6fc6c16"}, 82 | {file = "cffi-1.17.1-cp39-cp39-macosx_11_0_arm64.whl", hash = "sha256:28b16024becceed8c6dfbc75629e27788d8a3f9030691a1dbf9821a128b22c36"}, 83 | {file = "cffi-1.17.1-cp39-cp39-manylinux_2_12_i686.manylinux2010_i686.manylinux_2_17_i686.manylinux2014_i686.whl", hash = "sha256:1d599671f396c4723d016dbddb72fe8e0397082b0a77a4fab8028923bec050e8"}, 84 | {file = "cffi-1.17.1-cp39-cp39-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:ca74b8dbe6e8e8263c0ffd60277de77dcee6c837a3d0881d8c1ead7268c9e576"}, 85 | {file = "cffi-1.17.1-cp39-cp39-manylinux_2_17_ppc64le.manylinux2014_ppc64le.whl", hash = "sha256:f7f5baafcc48261359e14bcd6d9bff6d4b28d9103847c9e136694cb0501aef87"}, 86 | {file = "cffi-1.17.1-cp39-cp39-manylinux_2_17_s390x.manylinux2014_s390x.whl", hash = "sha256:98e3969bcff97cae1b2def8ba499ea3d6f31ddfdb7635374834cf89a1a08ecf0"}, 87 | {file = "cffi-1.17.1-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:cdf5ce3acdfd1661132f2a9c19cac174758dc2352bfe37d98aa7512c6b7178b3"}, 88 | {file = "cffi-1.17.1-cp39-cp39-musllinux_1_1_aarch64.whl", hash = "sha256:9755e4345d1ec879e3849e62222a18c7174d65a6a92d5b346b1863912168b595"}, 89 | {file = "cffi-1.17.1-cp39-cp39-musllinux_1_1_i686.whl", hash = "sha256:f1e22e8c4419538cb197e4dd60acc919d7696e5ef98ee4da4e01d3f8cfa4cc5a"}, 90 | {file = "cffi-1.17.1-cp39-cp39-musllinux_1_1_x86_64.whl", hash = "sha256:c03e868a0b3bc35839ba98e74211ed2b05d2119be4e8a0f224fba9384f1fe02e"}, 91 | {file = "cffi-1.17.1-cp39-cp39-win32.whl", hash = "sha256:e31ae45bc2e29f6b2abd0de1cc3b9d5205aa847cafaecb8af1476a609a2f6eb7"}, 92 | {file = "cffi-1.17.1-cp39-cp39-win_amd64.whl", hash = "sha256:d016c76bdd850f3c626af19b0542c9677ba156e4ee4fccfdd7848803533ef662"}, 93 | {file = "cffi-1.17.1.tar.gz", hash = "sha256:1c39c6016c32bc48dd54561950ebd6836e1670f2ae46128f67cf49e789c52824"}, 94 | ] 95 | 96 | [package.dependencies] 97 | pycparser = "*" 98 | 99 | [[package]] 100 | name = "cryptography" 101 | version = "44.0.3" 102 | description = "cryptography is a package which provides cryptographic recipes and primitives to Python developers." 103 | optional = false 104 | python-versions = "!=3.9.0,!=3.9.1,>=3.7" 105 | groups = ["main"] 106 | files = [ 107 | {file = "cryptography-44.0.3-cp37-abi3-macosx_10_9_universal2.whl", hash = "sha256:962bc30480a08d133e631e8dfd4783ab71cc9e33d5d7c1e192f0b7c06397bb88"}, 108 | {file = "cryptography-44.0.3-cp37-abi3-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:4ffc61e8f3bf5b60346d89cd3d37231019c17a081208dfbbd6e1605ba03fa137"}, 109 | {file = "cryptography-44.0.3-cp37-abi3-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:58968d331425a6f9eedcee087f77fd3c927c88f55368f43ff7e0a19891f2642c"}, 110 | {file = "cryptography-44.0.3-cp37-abi3-manylinux_2_28_aarch64.whl", hash = "sha256:e28d62e59a4dbd1d22e747f57d4f00c459af22181f0b2f787ea83f5a876d7c76"}, 111 | {file = "cryptography-44.0.3-cp37-abi3-manylinux_2_28_armv7l.manylinux_2_31_armv7l.whl", hash = "sha256:af653022a0c25ef2e3ffb2c673a50e5a0d02fecc41608f4954176f1933b12359"}, 112 | {file = "cryptography-44.0.3-cp37-abi3-manylinux_2_28_x86_64.whl", hash = "sha256:157f1f3b8d941c2bd8f3ffee0af9b049c9665c39d3da9db2dc338feca5e98a43"}, 113 | {file = "cryptography-44.0.3-cp37-abi3-manylinux_2_34_aarch64.whl", hash = "sha256:c6cd67722619e4d55fdb42ead64ed8843d64638e9c07f4011163e46bc512cf01"}, 114 | {file = "cryptography-44.0.3-cp37-abi3-manylinux_2_34_x86_64.whl", hash = "sha256:b424563394c369a804ecbee9b06dfb34997f19d00b3518e39f83a5642618397d"}, 115 | {file = "cryptography-44.0.3-cp37-abi3-musllinux_1_2_aarch64.whl", hash = "sha256:c91fc8e8fd78af553f98bc7f2a1d8db977334e4eea302a4bfd75b9461c2d8904"}, 116 | {file = "cryptography-44.0.3-cp37-abi3-musllinux_1_2_x86_64.whl", hash = "sha256:25cd194c39fa5a0aa4169125ee27d1172097857b27109a45fadc59653ec06f44"}, 117 | {file = "cryptography-44.0.3-cp37-abi3-win32.whl", hash = "sha256:3be3f649d91cb182c3a6bd336de8b61a0a71965bd13d1a04a0e15b39c3d5809d"}, 118 | {file = "cryptography-44.0.3-cp37-abi3-win_amd64.whl", hash = "sha256:3883076d5c4cc56dbef0b898a74eb6992fdac29a7b9013870b34efe4ddb39a0d"}, 119 | {file = "cryptography-44.0.3-cp39-abi3-macosx_10_9_universal2.whl", hash = "sha256:5639c2b16764c6f76eedf722dbad9a0914960d3489c0cc38694ddf9464f1bb2f"}, 120 | {file = "cryptography-44.0.3-cp39-abi3-manylinux_2_17_aarch64.manylinux2014_aarch64.whl", hash = "sha256:f3ffef566ac88f75967d7abd852ed5f182da252d23fac11b4766da3957766759"}, 121 | {file = "cryptography-44.0.3-cp39-abi3-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:192ed30fac1728f7587c6f4613c29c584abdc565d7417c13904708db10206645"}, 122 | {file = "cryptography-44.0.3-cp39-abi3-manylinux_2_28_aarch64.whl", hash = "sha256:7d5fe7195c27c32a64955740b949070f21cba664604291c298518d2e255931d2"}, 123 | {file = "cryptography-44.0.3-cp39-abi3-manylinux_2_28_armv7l.manylinux_2_31_armv7l.whl", hash = "sha256:3f07943aa4d7dad689e3bb1638ddc4944cc5e0921e3c227486daae0e31a05e54"}, 124 | {file = "cryptography-44.0.3-cp39-abi3-manylinux_2_28_x86_64.whl", hash = "sha256:cb90f60e03d563ca2445099edf605c16ed1d5b15182d21831f58460c48bffb93"}, 125 | {file = "cryptography-44.0.3-cp39-abi3-manylinux_2_34_aarch64.whl", hash = "sha256:ab0b005721cc0039e885ac3503825661bd9810b15d4f374e473f8c89b7d5460c"}, 126 | {file = "cryptography-44.0.3-cp39-abi3-manylinux_2_34_x86_64.whl", hash = "sha256:3bb0847e6363c037df8f6ede57d88eaf3410ca2267fb12275370a76f85786a6f"}, 127 | {file = "cryptography-44.0.3-cp39-abi3-musllinux_1_2_aarch64.whl", hash = "sha256:b0cc66c74c797e1db750aaa842ad5b8b78e14805a9b5d1348dc603612d3e3ff5"}, 128 | {file = "cryptography-44.0.3-cp39-abi3-musllinux_1_2_x86_64.whl", hash = "sha256:6866df152b581f9429020320e5eb9794c8780e90f7ccb021940d7f50ee00ae0b"}, 129 | {file = "cryptography-44.0.3-cp39-abi3-win32.whl", hash = "sha256:c138abae3a12a94c75c10499f1cbae81294a6f983b3af066390adee73f433028"}, 130 | {file = "cryptography-44.0.3-cp39-abi3-win_amd64.whl", hash = "sha256:5d186f32e52e66994dce4f766884bcb9c68b8da62d61d9d215bfe5fb56d21334"}, 131 | {file = "cryptography-44.0.3-pp310-pypy310_pp73-macosx_10_9_x86_64.whl", hash = "sha256:cad399780053fb383dc067475135e41c9fe7d901a97dd5d9c5dfb5611afc0d7d"}, 132 | {file = "cryptography-44.0.3-pp310-pypy310_pp73-manylinux_2_28_aarch64.whl", hash = "sha256:21a83f6f35b9cc656d71b5de8d519f566df01e660ac2578805ab245ffd8523f8"}, 133 | {file = "cryptography-44.0.3-pp310-pypy310_pp73-manylinux_2_28_x86_64.whl", hash = "sha256:fc3c9babc1e1faefd62704bb46a69f359a9819eb0292e40df3fb6e3574715cd4"}, 134 | {file = "cryptography-44.0.3-pp310-pypy310_pp73-manylinux_2_34_aarch64.whl", hash = "sha256:e909df4053064a97f1e6565153ff8bb389af12c5c8d29c343308760890560aff"}, 135 | {file = "cryptography-44.0.3-pp310-pypy310_pp73-manylinux_2_34_x86_64.whl", hash = "sha256:dad80b45c22e05b259e33ddd458e9e2ba099c86ccf4e88db7bbab4b747b18d06"}, 136 | {file = "cryptography-44.0.3-pp310-pypy310_pp73-win_amd64.whl", hash = "sha256:479d92908277bed6e1a1c69b277734a7771c2b78633c224445b5c60a9f4bc1d9"}, 137 | {file = "cryptography-44.0.3-pp311-pypy311_pp73-macosx_10_9_x86_64.whl", hash = "sha256:896530bc9107b226f265effa7ef3f21270f18a2026bc09fed1ebd7b66ddf6375"}, 138 | {file = "cryptography-44.0.3-pp311-pypy311_pp73-manylinux_2_28_aarch64.whl", hash = "sha256:9b4d4a5dbee05a2c390bf212e78b99434efec37b17a4bff42f50285c5c8c9647"}, 139 | {file = "cryptography-44.0.3-pp311-pypy311_pp73-manylinux_2_28_x86_64.whl", hash = "sha256:02f55fb4f8b79c1221b0961488eaae21015b69b210e18c386b69de182ebb1259"}, 140 | {file = "cryptography-44.0.3-pp311-pypy311_pp73-manylinux_2_34_aarch64.whl", hash = "sha256:dd3db61b8fe5be220eee484a17233287d0be6932d056cf5738225b9c05ef4fff"}, 141 | {file = "cryptography-44.0.3-pp311-pypy311_pp73-manylinux_2_34_x86_64.whl", hash = "sha256:978631ec51a6bbc0b7e58f23b68a8ce9e5f09721940933e9c217068388789fe5"}, 142 | {file = "cryptography-44.0.3-pp311-pypy311_pp73-win_amd64.whl", hash = "sha256:5d20cc348cca3a8aa7312f42ab953a56e15323800ca3ab0706b8cd452a3a056c"}, 143 | {file = "cryptography-44.0.3.tar.gz", hash = "sha256:fe19d8bc5536a91a24a8133328880a41831b6c5df54599a8417b62fe015d3053"}, 144 | ] 145 | 146 | [package.dependencies] 147 | cffi = {version = ">=1.12", markers = "platform_python_implementation != \"PyPy\""} 148 | 149 | [package.extras] 150 | docs = ["sphinx (>=5.3.0)", "sphinx-rtd-theme (>=3.0.0) ; python_version >= \"3.8\""] 151 | docstest = ["pyenchant (>=3)", "readme-renderer (>=30.0)", "sphinxcontrib-spelling (>=7.3.1)"] 152 | nox = ["nox (>=2024.4.15)", "nox[uv] (>=2024.3.2) ; python_version >= \"3.8\""] 153 | pep8test = ["check-sdist ; python_version >= \"3.8\"", "click (>=8.0.1)", "mypy (>=1.4)", "ruff (>=0.3.6)"] 154 | sdist = ["build (>=1.0.0)"] 155 | ssh = ["bcrypt (>=3.1.5)"] 156 | test = ["certifi (>=2024)", "cryptography-vectors (==44.0.3)", "pretend (>=0.7)", "pytest (>=7.4.0)", "pytest-benchmark (>=4.0)", "pytest-cov (>=2.10.1)", "pytest-xdist (>=3.5.0)"] 157 | test-randomorder = ["pytest-randomly"] 158 | 159 | [[package]] 160 | name = "enum-compat" 161 | version = "0.0.3" 162 | description = "enum/enum34 compatibility package" 163 | optional = false 164 | python-versions = "*" 165 | groups = ["main"] 166 | files = [ 167 | {file = "enum-compat-0.0.3.tar.gz", hash = "sha256:3677daabed56a6f724451d585662253d8fb4e5569845aafa8bb0da36b1a8751e"}, 168 | {file = "enum_compat-0.0.3-py3-none-any.whl", hash = "sha256:88091b617c7fc3bbbceae50db5958023c48dc40b50520005aa3bf27f8f7ea157"}, 169 | ] 170 | 171 | [[package]] 172 | name = "fido2" 173 | version = "2.0.0" 174 | description = "FIDO2/WebAuthn library for implementing clients and servers." 175 | optional = false 176 | python-versions = "<4,>=3.10" 177 | groups = ["main"] 178 | files = [ 179 | {file = "fido2-2.0.0-py3-none-any.whl", hash = "sha256:685f54a50a57e019c6156e2dd699802a603e3abf70bab334f26affdd4fb8d4f7"}, 180 | {file = "fido2-2.0.0.tar.gz", hash = "sha256:3061cd05e73b3a0ef6afc3b803d57c826aa2d6a9732d16abd7277361f58e7964"}, 181 | ] 182 | 183 | [package.dependencies] 184 | cryptography = ">=2.6,<35 || >35,<48" 185 | 186 | [package.extras] 187 | pcsc = ["pyscard (>=1.9,<3)"] 188 | 189 | [[package]] 190 | name = "pycparser" 191 | version = "2.22" 192 | description = "C parser in Python" 193 | optional = false 194 | python-versions = ">=3.8" 195 | groups = ["main"] 196 | markers = "platform_python_implementation != \"PyPy\"" 197 | files = [ 198 | {file = "pycparser-2.22-py3-none-any.whl", hash = "sha256:c3702b6d3dd8c7abc1afa565d7e63d53a1d0bd86cdc24edd75470f4de499cfcc"}, 199 | {file = "pycparser-2.22.tar.gz", hash = "sha256:491c8be9c040f5390f5bf44a5b07752bd07f56edf992381b05c701439eec10f6"}, 200 | ] 201 | 202 | [metadata] 203 | lock-version = "2.1" 204 | python-versions = ">=3.10, <4" 205 | content-hash = "82c384fbe6fc3e748cd706aece5157bf0b1de9eaae6e29058a874dc18d8c6b0b" 206 | -------------------------------------------------------------------------------- /test-vectors/pyproject.toml: -------------------------------------------------------------------------------- 1 | [project] 2 | name = "webauthn-test-vectors" 3 | description = "Scripts for generating WebAuthn test vectors" 4 | requires-python = ">=3.10, <4" 5 | 6 | [tool.poetry] 7 | package-mode = false 8 | 9 | [tool.poetry.dependencies] 10 | asn1 = "^3.0.1" 11 | cryptography = "^44.0.3" 12 | fido2 = "^2.0.0" 13 | 14 | [build-system] 15 | requires = ["poetry-core>=2.0"] 16 | build-backend = "poetry.core.masonry.api" 17 | -------------------------------------------------------------------------------- /test-vectors/webauthn-prf-test-vectors.py: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env python3 2 | 3 | from cryptography.hazmat.primitives import ciphers, hashes, hmac 4 | from cryptography.hazmat.primitives.asymmetric import ec 5 | from cryptography.hazmat.primitives.kdf.hkdf import HKDF 6 | from cryptography.hazmat.primitives.serialization import Encoding, PublicFormat 7 | from fido2 import cbor 8 | from fido2.utils import sha256 9 | 10 | 11 | def prng(seed, i): 12 | return sha256(seed + bytes([i])) 13 | 14 | def hmac_sha256(key, message): 15 | h = hmac.HMAC(key, hashes.SHA256()) 16 | h.update(message) 17 | return h.finalize() 18 | 19 | def hkdf_sha256(salt, ikm, L, info): 20 | return HKDF(algorithm=hashes.SHA256(), length=L, salt=salt, info=info).derive(ikm) 21 | 22 | 23 | class PinProtocolV1: 24 | def ecdh(self, privateKey, peerPublicKey): 25 | Z = privateKey.exchange(ec.ECDH(), peerPublicKey) 26 | return self.kdf(Z) 27 | 28 | def kdf(self, Z): 29 | return sha256(Z) 30 | 31 | def encapsulate(self, privateKey, peerPublicKey): 32 | return privateKey.public_key(), self.ecdh(privateKey, peerPublicKey) 33 | 34 | def decapsulate(self, privateKey, peerPublicKey): 35 | return self.ecdh(privateKey, peerPublicKey) 36 | 37 | def encrypt(self, key, demPlaintext, iv): 38 | k = key 39 | iv = bytes([0] * 16) 40 | c = ciphers.Cipher(ciphers.algorithms.AES256(k), ciphers.modes.CBC(iv)).encryptor() 41 | return (c.update(demPlaintext) + c.finalize()) 42 | 43 | def decrypt(self, key, ciphertext): 44 | k = key 45 | iv = bytes([0] * 16) 46 | ct = ciphertext 47 | c = ciphers.Cipher(ciphers.algorithms.AES256(k), ciphers.modes.CBC(iv)).decryptor() 48 | return c.update(ct) + c.finalize() 49 | 50 | 51 | class PinProtocolV2(PinProtocolV1): 52 | def encrypt(self, key, demPlaintext, iv): 53 | k = key[32:] 54 | c = ciphers.Cipher(ciphers.algorithms.AES256(k), ciphers.modes.CBC(iv)).encryptor() 55 | return iv + (c.update(demPlaintext) + c.finalize()) 56 | 57 | def decrypt(self, key, ciphertext): 58 | k = key[32:] 59 | iv = ciphertext[:16] 60 | ct = ciphertext[16:] 61 | c = ciphers.Cipher(ciphers.algorithms.AES256(k), ciphers.modes.CBC(iv)).decryptor() 62 | return c.update(ct) + c.finalize() 63 | 64 | def kdf(self, Z): 65 | return (hkdf_sha256(salt=bytes([0] * 32), ikm=Z, L=32, info=b'CTAP2 HMAC key') 66 | + hkdf_sha256(salt=bytes([0] * 32), ikm=Z, L=32, info=b'CTAP2 AES key')) 67 | 68 | 69 | def tohex(b): 70 | if isinstance(b, int): 71 | return tohex(bytes([b])) 72 | else: 73 | return b.hex() if b is not None else "DELETE" 74 | 75 | 76 | def setup_test_vectors(seed, plat_prik_idx, authnr_prik_idx, cred_random_idx): 77 | plat_prik_raw = prng(seed, plat_prik_idx) 78 | authnr_prik_raw = prng(seed, authnr_prik_idx) 79 | authnr_prik = ec.derive_private_key(int.from_bytes(authnr_prik_raw, 'big'), ec.SECP256R1()) 80 | plat_prik = ec.derive_private_key(int.from_bytes(plat_prik_raw, 'big'), ec.SECP256R1()) 81 | authnr_pub_raw = authnr_prik.public_key().public_bytes(Encoding.X962, PublicFormat.UncompressedPoint) 82 | cred_random = prng(seed, cred_random_idx) 83 | 84 | print(f"""#### CTAP2 `hmac-secret` extension #### {{#test-vectors-extensions-prf-ctap}} 85 | 86 | The following examples may be used to test [=[WAC]=] implementations 87 | of how the [=prf=] extension uses the [[FIDO-CTAP]] `hmac-secret` extension. 88 | The examples are given in CDDL [[RFC8610]] notation. 89 | The examples are not exhaustive. 90 | 91 | - The following shared definitions are used in all subsequent examples: 92 | 93 | 94 | ; Given input parameters: 95 | platform_key_agreement_private_key = 0x{tohex(plat_prik_raw)} 96 | authenticator_key_agreement_public_key = {{ 97 | 1: 2, 98 | 3: -25, 99 | -1: 1, 100 | -2: h'{tohex(authnr_pub_raw[1:1+32])}', 101 | -3: h'{tohex(authnr_pub_raw[1+32:1+32+32])}', 102 | }} 103 | authenticator_cred_random = h'{tohex(cred_random)}' 104 | 105 | 106 | The {{{{AuthenticationExtensionsPRFValues/first}}}} and {{{{AuthenticationExtensionsPRFValues/second}}}} inputs 107 | are mapped in the examples as `prf_eval_first` and `prf_eval_second`, respectively. 108 | The `prf_results_first` and `prf_results_second` values in the examples 109 | are mapped to the 110 | {{{{AuthenticationExtensionsPRFOutputs/results}}}}.{{{{AuthenticationExtensionsPRFValues/first}}}} 111 | and {{{{AuthenticationExtensionsPRFOutputs/results}}}}.{{{{AuthenticationExtensionsPRFValues/second}}}} 112 | outputs, respectively. 113 | """) 114 | 115 | return cred_random, plat_prik_raw, authnr_prik_raw 116 | 117 | 118 | def generate_test_vector( 119 | description, 120 | pinpr, 121 | cred_random, 122 | plat_prik_raw, 123 | authnr_prik_raw, 124 | prf_eval_first, 125 | prf_eval_second, 126 | iv_salt, 127 | iv_output, 128 | ): 129 | authnr_prik = ec.derive_private_key(int.from_bytes(authnr_prik_raw, 'big'), ec.SECP256R1()) 130 | plat_prik = ec.derive_private_key(int.from_bytes(plat_prik_raw, 'big'), ec.SECP256R1()) 131 | _, shared_secret = pinpr.encapsulate(authnr_prik, plat_prik.public_key()) 132 | 133 | salt1 = sha256(b'WebAuthn PRF' + bytes([0x00]) + prf_eval_first) 134 | salt2 = sha256(b'WebAuthn PRF' + bytes([0x00]) + prf_eval_second) if prf_eval_second is not None else None 135 | salt_enc = pinpr.encrypt(shared_secret, salt1 + (salt2 or b''), iv_salt) 136 | assert pinpr.decrypt(shared_secret, salt_enc) == salt1 + (salt2 or b'') 137 | 138 | output1 = hmac_sha256(cred_random, salt1) 139 | output2 = hmac_sha256(cred_random, salt2) if salt2 is not None else None 140 | output_enc = pinpr.encrypt(shared_secret, output1 + (output2 or b''), iv_output) 141 | 142 | prf_results_both = pinpr.decrypt(shared_secret, output_enc) 143 | prf_results_first = prf_results_both[0:32] 144 | prf_results_second = prf_results_both[32:] if len(prf_results_both) > 32 else None 145 | 146 | assert prf_results_first == output1 147 | assert prf_results_second == output2 148 | 149 | output = f""" 150 | 151 | ; Inputs from Relying Party: 152 | prf_eval_first = h'{tohex(prf_eval_first)}' 153 | prf_eval_second = h'{tohex(prf_eval_second)}' 154 | 155 | ; Client computes: 156 | shared_secret = h'{tohex(shared_secret)}' 157 | salt1 = h'{tohex(salt1)}' 158 | salt2 = h'{tohex(salt2)}' 159 | salt_enc = h'{tohex(salt_enc)}' 160 | 161 | ; Authenticator computes: 162 | output1 = h'{tohex(output1)}' 163 | output2 = h'{tohex(output2)}' 164 | output_enc = h'{tohex(output_enc)}' 165 | 166 | ; Client decrypts: 167 | prf_results_first = h'{tohex(prf_results_first)}' 168 | prf_results_second = h'{tohex(prf_results_second)}' 169 | 170 | """.strip() 171 | output = "\n".join(( " " + l.strip()).rstrip() for l in output.splitlines() if "DELETE" not in l) 172 | print(f"- {description}:") 173 | print() 174 | print(output) 175 | print() 176 | 177 | 178 | print("") 179 | 180 | seed = b'WebAuthn PRF test vectors' 181 | prf_eval_first = seed+bytes([0x02]) 182 | prf_eval_second = seed+bytes([0x03]) 183 | plat_prik_idx=0x04 184 | authnr_prik_idx=0x05 185 | cred_random_idx=0x06 186 | cred_random, plat_prik_raw, authnr_prik_raw = setup_test_vectors(seed, plat_prik_idx, authnr_prik_idx, cred_random_idx) 187 | iv_salt_idx_single_pp2 = 0x07 188 | iv_output_idx_single_pp2 = 0x09 189 | iv_salt_idx_two_pp2 = 0x08 190 | iv_output_idx_two_pp2 = 0x0a 191 | 192 | generate_test_vector( 193 | "Single input case using PIN protocol 2", 194 | PinProtocolV2(), 195 | cred_random, plat_prik_raw, authnr_prik_raw, 196 | prf_eval_first=prf_eval_first, 197 | prf_eval_second=None, 198 | iv_salt=prng(seed, iv_salt_idx_single_pp2)[:16], 199 | iv_output=prng(seed, iv_output_idx_single_pp2)[:16], 200 | ) 201 | 202 | generate_test_vector( 203 | "Two input case using PIN protocol 2", 204 | PinProtocolV2(), 205 | cred_random, plat_prik_raw, authnr_prik_raw, 206 | prf_eval_first=prf_eval_first, 207 | prf_eval_second=prf_eval_second, 208 | iv_salt=prng(seed, iv_salt_idx_two_pp2)[:16], 209 | iv_output=prng(seed, iv_output_idx_two_pp2)[:16], 210 | ) 211 | 212 | generate_test_vector( 213 | "Single input case using PIN protocol 1", 214 | PinProtocolV1(), 215 | cred_random, plat_prik_raw, authnr_prik_raw, 216 | prf_eval_first=prf_eval_first, 217 | prf_eval_second=None, 218 | iv_salt=None, 219 | iv_output=None, 220 | ) 221 | 222 | print(f"""Inputs and pseudo-random values used in this section were generated as follows: 223 | 224 | - seed = UTF-8("{seed.decode("utf-8")}") 225 | - prf_eval_first = seed || 0x{tohex(prf_eval_first.removeprefix(seed))} 226 | - prf_eval_second = seed || 0x{tohex(prf_eval_second.removeprefix(seed))} 227 | - platform_key_agreement_private_key = SHA-256(seed || 0x{tohex(plat_prik_idx)}) 228 | - authenticator_key_agreement_public_key = P256-Public-Key(sk) 229 | where sk = SHA-256(seed || 0x{tohex(authnr_prik_idx)}) 230 | - authenticator_cred_random = SHA-256(seed || 0x{tohex(cred_random_idx)}) 231 | - `iv` in single-input `salt_enc` with PIN protocol 2: Truncated SHA-256(seed || 0x{tohex(iv_salt_idx_single_pp2)}) 232 | - `iv` in two-input `salt_enc` with PIN protocol 2: Truncated SHA-256(seed || 0x{tohex(iv_salt_idx_two_pp2)}) 233 | - `iv` in single-input `output_enc` with PIN protocol 2: Truncated SHA-256(seed || 0x{tohex(iv_output_idx_single_pp2)}) 234 | - `iv` in two-input `output_enc` with PIN protocol 2: Truncated SHA-256(seed || 0x{tohex(iv_output_idx_two_pp2)}) 235 | """) 236 | -------------------------------------------------------------------------------- /w3c.json: -------------------------------------------------------------------------------- 1 | { 2 | "group": [ 3 | "87227" 4 | ], 5 | "contacts": [ 6 | "weiler", 7 | "wseltzer" 8 | ], 9 | "shortName": "webauthn", 10 | "repo-type": "rec-track" 11 | } --------------------------------------------------------------------------------

[TITLE] [LEVEL]

[LONGSTATUS], 16 | [DATE]

Status of this document