W3C home > Mailing lists > Public > public-webauthn@w3.org > October 2016

[webauthn] detail-level issues in signature format, attestation format(s), attestation statement

From: =JeffH via GitHub <sysbot+gh@w3.org>
Date: Mon, 17 Oct 2016 18:14:09 +0000
To: public-webauthn@w3.org
Message-ID: <issues.opened-183487783-1476728047-sysbot+gh@w3.org>
equalsJeffH has just created a new issue for 
https://github.com/w3c/webauthn:

== detail-level issues in signature format, attestation format(s), 
attestation statement ==
There's various detail-level issues in the signature format, 
attestation format(s), attestation statement sections. Here's at least
 some of them..

1)  the term `DAA root key` is not defined.

2)  `authenticatorData` aka "authenticator data" -- is inconsistently 
named in both latter fashions. Plus, its data structure fields are not
 clearly named.

3)  `attestation data` -- this data structure is not formally named 
(ie no `<dfn>` for it). Plus its fields are not clearly named. 

4)  `daaKey` is not defined/described in the **Syntax** subsections of
 {#packed-attestation} nor {#tpm-attestation}

5)  **Verification procedure** for {#packed-attestation}  does not 
stipulate behavior if both `x5c` and `daaKey` are present  (throw 
error?)

6)  **Verification procedure** for {#tpm-attestation} does not 
stipulate behavior if both `x5c` and `daaKey` are present, or if 
neither are present  (throw error?)


Issues (2) & (3) lead to trying to denote items in the data structure 
with imprecise names such as: 
`ScopedCredentialInfo.attestation.authenticatorData."Attestation 
data"."public key"`

One way of addressing (2) & (3) is to employ ABNF to formally define 
both `authenticatorData` and "Attestation data", like so..

<pre>
;--------  Authenticator Data ----------


authenticatorData = rpIdHash flags signCount [attData] [extData]


rpIdHash                = 32OCTET       ; 32 octets


flags                   = TUP RFU AT ED ; 1 octet

        TUP             = BIT   ; Test of User Presence

        RFU             = 5BIT  ; Reserved for Future Use

        AT              = BIT   ; ATtestation data present

        ED              = BIT   ; Extension Data present


signCount               = 4OCTET        ; 4 octets




;--------  Attestation Data ----------


attData         = AAGUID credIDLen credID pkAlg uauthPkLen uauthPk


AAGUID          = 16OCTET       ; 16 octets

credIDLen       = 2OCTET        ; 2 octets

credID          = < sequence of credIDLen octets >

pkAlg           = EC / RSA      ; public key alg & encoding

        EC      = %x0100        ; ANSI X9.62 formatted EC public key

        RSA     = %x0102        ; RSA PKCS1 or RSASSA-PSS public key

uauthPkLen      = 2OCTET        ; 2 octets

uauthPk         = < sequence of uauthPkLen octets >


;--------  Extension Data ----------


extData         = < CBOR [RFC7049] map with extension identifiers 
                    as keys, and extension authenticator data values
                    as values >

;-----------------------------------
</pre>

A second way is to add a "name" column to the existing 
`authenticatorData` and "Attestation data" tables. 

A third way is to do 2nd way as well as use ABNF within the tables to 
formally define the data fields and their relationships. 


Please view or discuss this issue at 
https://github.com/w3c/webauthn/issues/233 using your GitHub account
Received on Monday, 17 October 2016 18:14:16 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 07:26:23 UTC