Proposed TAP #9 - Mandatory metadata signing schemes

[heartsucker]

Addresses issues covered in the conversation here: theupdateframework/python-tuf#425

[vladimir-v-diaz]

The "signature" entry should be "sig"
See section 4.2 of the specification and example metadata.

[vladimir-v-diaz]

Can you provide a reference to one of these audits, if possible? It will be helpful to the
reader.

I know of one audit that is available online for review: https://github.com/docker/notary/blob/master/docs/resources/ncc_docker_notary_audit_2015_07_31.pdf

[heartsucker]

I'll ask tomorrow in the office. I'm not sure what of our report we can share.

[heartsucker]

We can't release the doc at the moment, but the relevant excerpt was placed into the TAP.

[vladimir-v-diaz]

typo: "methods" should be "method."

[vladimir-v-diaz]

In the following example, assume that a developer has access to the same RSA key.

What if the "keys" entry was formatted as follows?

"keys": {
  "0bde74244f238cd6d4e3839d35a5b248d6cde5759b760ebdbee45a386109a41a": {
    "keytype": "rsa",
    "scheme": "rsa-pkcs1-1.5",
    "keyval": {
        "public": "-----BEGIN PUBLIC KEY-----<etc>"
    },
{
  "349838deff9a9a9...": {
    "keytype": "rsa",
    "scheme": "rsassa-pss-sha256",
    "keyval": {
        "public": "-----BEGIN PUBLIC KEY-----<etc>"
    },
  },
  ...

And the "signatures" entry could list multiple signing keys like so:

{
  "signatures": [
     {
       "keyid": "349838deff9a9a9...",
       "sig": "fce1a97b55076065c7dc7c78fb0206d5dd87db817ccc7bcf83c3cdf..."
     },
     {
       "keyid": "0bde74244f238cd6d4e3839d35a5b248d6cde5759b760ebdbee45a386109a41a",
       "sig": "5764debfaaaacde343..."
     }
  ],
  "signed": {
    ...
  }
}

[vladimir-v-diaz]

Note that I edited my previous comment to change the "sig" listed by the "0bde7..." key, which should differ from the one provided by the "3498..." key.

[heartsucker]

I have addressed this in the latest commit.

[endophage]

I would stick with the original solution. The RSA keys themselves are likely to be bulk of the data inside a root.json so not duplicating them seems beneficial.

[vladimir-v-diaz]

Not that I'm in favor of this view, but I suppose a key in this case would be the KEYID entries in "keys." In other words, there are two unique keys in the example above: one rsa key + 2 different signing schemes.

However, I admit that this can potentially be a source of confusion to users, who are likely to view a " real key" by its keytype, and not keytype + signing scheme.

[heartsucker]

It would still need the check against the "real key ID" because the whole point of thresholds is that N entities sign the key, and allowing a single key to do multiple signatures means that an entity could provide all the signatures needed. For example:

Key with key ID sha256(cjson(encoded)) = 123 has been placed in the metadata for the targets role with signing schemes A, B, and C. The new key IDs done via sha256(cjson(scheme || encoded)) would be 456, abc, and def. If the targets role has threshold = 3, then the single key 123 could sign it 3 times using "keys" 456, abc, and def. To avoid this, we'd have to check that the sha256(cjson(endcoded)) of each signature is unique which seems like an overly complicated step.

[vladimir-v-diaz]

That's correct. This point was raised in issue #425 and I was under the impression that @JustinCappos views "keys" 456, abc, and def as unique, even though they all use the same 123 key.

[vladimir-v-diaz]

Link to discussion:
theupdateframework/python-tuf#425 (comment)

[vladimir-v-diaz]

We support the removal of a "method" entry, but might need further tweaks or comment on how we specify keys and their signing methods. Merging TAP 9 now that it has a TAP number!

[vladimir-v-diaz]

TAPs that have been assigned a TAP number will now be merged into the "master" branch. This does not mean that the merged TAP has been accepted, only that the proposed change (with potential tweaks) is likely to be incorporated into TUF.

We'll likely continue to comment on the pull request after it's been closed, so that we can easily comment on specific lines of the TAP.

Thanks for submitting TAP 9!

[JustinCappos]

On Fri, May 19, 2017 at 11:22 AM, Vladimir Diaz ***@***.***> wrote: TAPs that have been assigned a TAP number will now be merged into the "master" branch. This does not mean that the merged TAP has been accepted, only that the proposed change (with potential tweaks) is likely to be incorporated into TUF.

I would say instead that merging a TAP means it is worth having a permanent / fixed TAP number to point to this discussion. Moving from 'draft' to 'accepted' status is what means it is likely to be merged with tweaks.

[JustinCappos]

@endophage: I'd love to have your thoughts on this TAP.

[endophage]

@JustinCappos I'd like to think that every client matches the signing scheme against the key type regardless of where those pieces of data are located so the premise for this issue seems to be "in a poorly implemented client ..." which isn't the strongest of reasons.

That said, I have no issues with the change and agree that it increases this aspect of security in those poorly implemented clients.

[JustinCappos]

Okay, does anyone else have a thought / concern? Any objections with moving this to accepted?