Re: [EAT] [Rats] Attestation BoF charter updates?

["Smith, Ned" <[e-mail]>]

On 10/23/18, 12:04 PM, "Carl Wallace" <[e-mail]<mailto:[e-mail]>> wrote:

Inline..

From: "Smith, Ned" <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, October 23, 2018 at 2:49 PM
To: Carl Wallace <[e-mail]<mailto:[e-mail]>>, Jeremy O'Donoghue <[e-mail]<mailto:[e-mail]>>
Cc: Michael Richardson <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [EAT] [Rats] Attestation BoF charter updates?



On 10/23/18, 10:34 AM, "EAT on behalf of Carl Wallace" <[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> wrote:

<snip>

It would be interesting to understand your thinking a bit further. At one level it is fairly straightforward to define a claim whose value contains an X.509 certificate, but I suspect that binding may imply more than that.
[nms] It is also reasonable to consider an X.509 certificate as being an object that contains a set of claims (rather than the other way around).
[cw] Not if the goal is to prevent issuance of a certificate because provenance of a key cannot be confirmed. Having a self-issued cert contain claims is fine, but this does not obviate the need to bind to issuance protocols to inform CA issuance.
[nms] I wasn’t asserting that a certificate would be self-issued. This is why I think it makes sense to talk about a claimant. SP800-164 refers to this as either a ‘device owner’ or ‘information owner’. I’m OK with these terms too. The expectation is the device owner during manufacturing  (aka mfg’r) will know which trust relevant claims can be asserted. They could assert them by issuing a certificate containing the claims. The verifier/relying party trusts the mfg’r to be an authoritative source regarding how a device (but more precisely, how the root-of-trust) was made. If a key is created during mfg time and the mfg issues evidence (aka a certificate) of that, then it serves as provenance as long as the verifier / relying party trusts the manufacturer to correctly embed the key. Confirmation can be achieved via manual inspection of the manufacturing process. Nevertheless, the verifier is trusting the mfg to a certain degree.

[CW] You are referring to a certificate issued to the device by the manufacturer. I am referring to certifying keys generated by a hardware crypto module on the device once it is in the hands of a user.  I don't disagree the verifier must trust the manufacturer when verifying the attestation, I am suggesting that the verifier is a CA who will have plucked an attestation from a certificate management message and will, amongst other checks that need to be standardized, confirm the public key in the certificate request corresponds to a claim in the attestation.
[nms] Right. In order for the CA (verifier) to distinguish the certifying key is an ‘attestable key’ vs. a traditional CSR. The CA should look for a signature from the mfg cert over the CSR (certificate management message?) containing the generated public key. I’m still not seeing where there is a self-signed (issued) certificate in the equation.