Re: [EAT] [Rats] Attestation BoF charter updates? - Program of Work section

"Smith, Ned" <ned.smith@intel.com> Fri, 26 October 2018 00:22 UTC

Return-Path: <ned.smith@intel.com>
X-Original-To: eat@ietfa.amsl.com
Delivered-To: eat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6C01130E13; Thu, 25 Oct 2018 17:22:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AEXxlgfJ35uz; Thu, 25 Oct 2018 17:22:10 -0700 (PDT)
Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 320AD130E1A; Thu, 25 Oct 2018 17:22:10 -0700 (PDT)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Oct 2018 17:22:09 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.54,426,1534834800"; d="scan'208";a="95098995"
Received: from orsmsx110.amr.corp.intel.com ([10.22.240.8]) by orsmga003.jf.intel.com with ESMTP; 25 Oct 2018 17:22:09 -0700
Received: from orsmsx109.amr.corp.intel.com ([169.254.11.251]) by ORSMSX110.amr.corp.intel.com ([169.254.10.20]) with mapi id 14.03.0319.002; Thu, 25 Oct 2018 17:22:08 -0700
From: "Smith, Ned" <ned.smith@intel.com>
To: Carl Wallace <carl@redhoundsoftware.com>, Laurence Lundblade <lgl@island-resort.com>
CC: "Eric Voit (evoit)" <evoit@cisco.com>, Jeremy O'Donoghue <jodonogh@qti.qualcomm.com>, "eat@ietf.org" <eat@ietf.org>, "Michael Richardson" <mcr+ietf@sandelman.ca>, "rats@ietf.org" <rats@ietf.org>, "Henk Birkholz" <henk.birkholz@sit.fraunhofer.de>
Thread-Topic: [EAT] [Rats] Attestation BoF charter updates? - Program of Work section
Thread-Index: AQHUbGypHLAw4V05zku/ro+eJdOFdKUwhR6AgAAkEwA=
Date: Fri, 26 Oct 2018 00:22:08 +0000
Message-ID: <AF8EF7CD-9024-4BD6-B6B7-03327F9EA0F9@intel.com>
References: <0199DB00-E76E-4664-BE02-E2AF4F4B6AEC@intel.com> <526BB5AC-60A8-4CD3-95F4-39F210E4D2FB@island-resort.com> <D7F73FD8.C4179%carl@redhoundsoftware.com> <662EFF28-BC29-4C1F-BB00-086D449D6F0A@island-resort.com> <D7F74EE1.C41A5%carl@redhoundsoftware.com>
In-Reply-To: <D7F74EE1.C41A5%carl@redhoundsoftware.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.3.181015
x-originating-ip: [10.255.68.37]
Content-Type: text/plain; charset="utf-8"
Content-ID: <F43F90E21F72074D81B656C01761A86E@intel.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/eat/bdvwuEAAJ6wy_Yn8Gm75PBMh-34>
Subject: Re: [EAT] [Rats] Attestation BoF charter updates? - Program of Work section
X-BeenThere: eat@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: EAT - Entity Attestation Token <eat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eat>, <mailto:eat-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/eat/>
List-Post: <mailto:eat@ietf.org>
List-Help: <mailto:eat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eat>, <mailto:eat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Oct 2018 00:22:19 -0000

I expect a common attestation scenario can be characterized as an X.509 certificate chain having an EE certificate whose private key owner signs a document containing claims. The document could be expressed in any of the formats being discussed here. Use case context may play a role in determining which document format is appropriate, and I don't believe it is necessarily the objective of the charter to promote a philosophical bias toward any particular format, though it does make sense for the WG and charter to set some priorities - trying not to boil the ocean. 

There seems to be use case context (at least by the participants in the BOF) for 3 maybe 4 formats where ASN.1 appears to be the one on the edge (CBOR, JSON, YANG being the other less debated formats). ASN.1 isn't itself a cryptographic document format (IMO); for that we need to turn to something like CMS or X.509. 

A second, likely to be popular attestation scenario, can be characterized as an X.509 certificate chain having and EE certificate containing claims in an extension (or leverages some other extensibility capability described by RFC5280). In this scenario, it seems reasonable for the WG to have an ASN.1 description of the normative set of claims to avoid other organizations coming up with slight (but semantically similar) variants. 

If there is a use case for CMS, RFC5755 (attribute certs) or something else that describes a cryptographic document expressed in ASN.1, then it is a small / possibly inconsequential step required to include the ASN.1 formatted claims into one of these other document structures. 

Conceptually, the 'document' consists of a claims part and a signature part. The claim part could be expressed in one format (e.g. CBOR) while the signature part expressed in a different format (e.g. JWT). Given that perspective we can make lists of format types for claims and another for signed documents.
E.g.
Claims format possibilities:
	- CBOR, JSON, YANG, ASN.1

Cryptographic document format possibilities:
	- CWT, JWT, YANG(?), CMS, X.509 Cert (RFC5280), Attr Cert (RFC5755)

The charter / WG could set different priorities for each list. It could also set priority for, and/or limit, cross-format enveloping (e.g. JSON Claim inside a YANG cryptographic document etc).

A third, possibly likely attestation scenario might do away with the X.509 certificate chain favoring for example a signed-document-only model or possibly an alternative certificate chain using CWT? I don't know if anyone is strongly advocating use cases in this third scenario. If not, it makes sense to leave it out of the charter for now. 

-Ned

On 10/25/18, 8:06 AM, "Carl Wallace" <carl@redhoundsoftware.com>; wrote:

    
    
    On 10/25/18, 10:11 AM, "Laurence Lundblade" <lgl@island-resort.com>; wrote:
    
    >
    >> On Oct 25, 2018, at 8:47 PM, Carl Wallace <carl@redhoundsoftware.com>;
    >>wrote:
    >> 
    >> 
    >> On 10/25/18, 9:15 AM, "RATS on behalf of Laurence Lundblade"
    >> <rats-bounces@ietf.org on behalf of lgl@island-resort.com>; wrote:
    >> 
    >>> <snip>
    >>> 
    >>> So I am making some argument against ASN.1 and anything beyond JSON and
    >>> CBOR.  The more formats there are the more work the relying parties
    >>>will
    >>> have to do and of course some won’t implement all the formats and then
    >>> we’ll have less interop.
    >> 
    >> [CW] At least where the claims are related to cryptographic keys, ASN.1
    >>is
    >> likely unavoidable as it's part of the environment. Avoiding it is not
    >> likely to help interop.
    >
    >
    >For an attestation in the vein of EAT you have a series of claims that
    >are signed. The sane thing to do is pick one format and apply it all the
    >way through. The claims are in JOSE format and you sign with JWT. The
    >claims are in CBOR and you sign with COSE. The claims are ASN.1 and you
    >sign in CMS.
    [CW] It may shake out such that the claims I care about could be ASN.1
    from top to bottom but I doubt it. Mixing formats doesn't seem like a
    problem. Base64 encodings of DER encoded structures are quite common in
    XML and JSON, for example. Including COSE or JOSE structure as an
    attribute in an ASN.1 structure seems fine too.
    > 
    >
    >It would be possible to have something like a PKCS10 CSR stuffed into a
    >CBOR byte string in a CBOR/COSE format attestation, but the overall
    >format of the attestation is CBOR/COSE. Maybe this is what you are after?
    
    [CW] Not exactly. The CSR would contain a mix of data that is originated
    by/protected by a hardware component and data that is external (e.g.,
    challenge password). It's not clear to me orchestrating including the P10
    in the attestation is the right path. Including a signed claim about key
    provenance in a standard cert request seems sufficient and easy enough.
    >
    >Agreed that we might actually have to do this since there is no CBOR
    >format CSR (yet).
    
    [CW] Not sure why that would be required. There was earlier mention of not
    boiling the ocean, trying to recast everything as CBOR doesn't seem wise.
    > 
    >
    >I can also see having to use X.509 for establishing trust in signing keys
    >since there is no CBOR format for certificates (yet). Jim Schaad was
    >working on extensions to COSE for this.
    >
    >Any other examples?
    
    [CW] I shared a pile of examples via GitHub some weeks back -
    https://github.com/Purebred/SampleAttestations. I will add Pixel 3
    artifacts soon. I am not suggesting these as a basis for standardization,
    but as illustrative of how attestations are used in certificate requests
    in some environments. At present, w.r.t. demonstrating key provenance, we
    are using:
    	- Android attestations (X.509 certificates that chain to a specific root
    represented as a certs-only SignedData),
    	- Yubikey attestations (X.509 certificates that chain to a specific
    rootrepresented as a certs-only SignedData) and
    	- Surface Pro TPM attestations (CMC requests that wrap a mix of TCG and
    Microsoft structures).
    
    [CW] Each of these is attached to a SCEP request as an attribute. The
    attestations are verified and the public key from the attestation is
    compared to the public key in the SCEP request. We have another variant
    that does use CBOR for some claims. In that case the Google attestation
    certificate is included in the CBOR similar to your description above but
    the CBOR layer isn't demonstrating key provenance in this case. SCEP, CMC
    and EST all use similar attributes. It is not unlikely that a single spec
    defining one or more attributes to convey attestations could be shared by
    all three. 
    > 
    >
    >I would hope we can avoid CMS and creating ASN.1 syntax for every claim
    >we define.
    
    [CW] I can't imagine this would be necessary.
    >
    >LL
    >
    >