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

[Carl Wallace <[e-mail]>]

Inline..

From:  "Smith, Ned" <[e-mail]>
Date:  Tuesday, October 23, 2018 at 2:49 PM
To:  Carl Wallace <[e-mail]>, Jeremy O'Donoghue
<[e-mail]>
Cc:  Michael Richardson <[e-mail]>, "[e-mail]"
<[e-mail]>, "[e-mail]" <[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]
> on behalf of [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.