Re: why is "Public key algorithm and encoding" 2 bytes long?

On 10/25/16  =JeffH wrote:
> in S 5.3.3 "Generating an Attestation Statement"
> {#generating-an-attestation-statement}, the "Public key algorithm
> and encoding" is described as..
> 
> Public key algorithm and encoding (16-bit big-endian value). Allowed
> values are:
> 
>     1. 0x0100. This is raw ... Elliptic Curve public key [SEC1] ...
> 
>     2. 0x0102.  Raw encoded RSA ... public key [RFC3447] ...
>           
> 
> questions:
> 
> 1. Why do we need to use two bytes here?
> 
> 2. Were there any particular reasons the values of 0x0100 and 0x0102
> were picked?
> 
> 3. This "Public key algorithm and encoding" does not seem to be used
> as a set of bit flags ... is there any reason we cannot use a single
> byte here, which would ostensibly have enough distinct values to
> represent whatever different PK key types and encodings evolve in the
> future?

Von: Vijay Bharadwaj said 6. Oktober 2016 10:57
> 
> This was inherited from FIDO I believe. It was in the initial
> submission of attestation formats. Rolf?

On 10/26/16, 4:05 PM, "Rolf Lindemann" <rlindemann@noknok.com> wrote:
> Yes, I think it was.

yeah, it was in packed attestation definition as originally submitted:

<https://www.w3.org/Submission/2015/SUBM-fido-key-attestation-20151120/#att
estation-rawdata-type-packed>


Absent explicit rationale for (2), I am guessing the first byte, 0x01, is
some sort of "version" (?), and the 2nd byte, 0x00 for EC and 0x02 for
RSA, is a bitmap denoting key type & sig algorithm? Rolf?

I can live with this, and if left unchanged we ought to document what it
actually means.

However, we are using an extra byte where we could just have a single byte
and assign meanings to particular values, eg..

  0x00: uncompressed EC pub key on curve p-256, sigs: ECDSA w/SHA-256
  0x01: reserved
  0x02: RSA pub key, sigs: RSASSA-PKCS1-v1_5 or RSASSA-PSS w/SHA-256
  0x03..FF: unassigned


thoughts?

=JeffH

Received on Thursday, 27 October 2016 17:40:56 UTC