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

Carl Wallace <carl@redhoundsoftware.com> Wed, 24 October 2018 16:45 UTC

Return-Path: <carl@redhoundsoftware.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 0D232130E01 for <eat@ietfa.amsl.com>; Wed, 24 Oct 2018 09:45:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.com
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 CMhZPs_oBQfF for <eat@ietfa.amsl.com>; Wed, 24 Oct 2018 09:45:34 -0700 (PDT)
Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 986B8126F72 for <eat@ietf.org>; Wed, 24 Oct 2018 09:45:34 -0700 (PDT)
Received: by mail-qk1-x732.google.com with SMTP id 131so1019984qkd.4 for <eat@ietf.org>; Wed, 24 Oct 2018 09:45:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=Vcoztq+of6qOwz38a5RqxCsJl7RkwjnQvKge6zvjILo=; b=PffOOEcI0lmoyscE4OgwHCenefb8b23kfWvgW4J1tBwK2CEJoQbW/IE5zTQWS+32RU kejyaqWaNrlDvNa6canCSfi6mII8Ls1oHhVbTWVliiGcbsQRY56jT0WisXySi3dPDHko x1dUTRJgfrYqSXrTODq98ZUogdUnex7FeQ7E4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=Vcoztq+of6qOwz38a5RqxCsJl7RkwjnQvKge6zvjILo=; b=hi2Ri/i6cWMGuBwI7eYdIoSYjA5CGtehiXPzO5A8bAyQJVqhpMH61nMDlKWSDnLOLb 6aRj8c+zAUg/4Y2nTCALUp1FyKYDF3OSV+pKNRhtiKfLVTusII1ARB4lHpzpgG+7gJS3 CgJyl3sVdLoH0P00KfgBSGAL3SJJ4uI4D16eAmzfftGWVfsdxGF7W3PvCAOJYp+mOcml Mf4yMmUqlEC/BLcor4p5DOuW/1tpabGq3Iy+H5HxylQ3nLW36wh+9GhjbWv9UwAxkM2G TyyOPm8cXQWR+9hNk6PGSk2TPgV6qTsBKk4cGWuzgQg6+04M05QDZXTGzvG01qxLy9/v TzZg==
X-Gm-Message-State: AGRZ1gJGTleSi2i0mznRt1GiQBpnPs3VUUED2ItVGEfBIBCFcEHuDHQD 7eULs477MB5mrG/0lxYYQMDyzw==
X-Google-Smtp-Source: AJdET5eKhRoGefgichNwUS/qkpkGhHpSKnhZ6EtROxzfKNbIW+svIzhW+7Ln49tXzIStXZqlVr/5fw==
X-Received: by 2002:a37:8282:: with SMTP id e124-v6mr3149721qkd.76.1540399533522; Wed, 24 Oct 2018 09:45:33 -0700 (PDT)
Received: from [192.168.2.27] (pool-108-28-91-61.washdc.fios.verizon.net. [108.28.91.61]) by smtp.googlemail.com with ESMTPSA id x1-v6sm4783291qkx.93.2018.10.24.09.45.28 (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 24 Oct 2018 09:45:32 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.7.6.170621
Date: Wed, 24 Oct 2018 12:45:22 -0400
From: Carl Wallace <carl@redhoundsoftware.com>
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, Jeremy O'Donoghue <jodonogh@qti.qualcomm.com>
CC: Michael Richardson <mcr+ietf@sandelman.ca>, "Smith, Ned" <ned.smith@intel.com>, "eat@ietf.org" <eat@ietf.org>, "rats@ietf.org" <rats@ietf.org>
Message-ID: <D7F619D9.C3FAF%carl@redhoundsoftware.com>
Thread-Topic: [Rats] [EAT] Attestation BoF charter updates?
References: <D7F4B1E4.C3BF8%carl@redhoundsoftware.com> <D0C08E47-DBB6-4AAD-95EF-F952155D3152@qti.qualcomm.com> <581DD29C-85D9-4BD8-A0EE-41761ED773B4@intel.com> <D7F4D350.C3CFF%carl@redhoundsoftware.com> <FFA0BB14-48AB-45CE-8D7A-53D43821FC7D@intel.com> <D7F4E84F.C3D97%carl@redhoundsoftware.com> <FCF1711D-4936-4D35-A75D-84B88C076151@intel.com> <D7F4F54C.C3DB8%carl@redhoundsoftware.com> <8340B1B8-775D-4932-B432-29B715A3B45D@qti.qualcomm.com> <D4F3DF93-D63F-4254-8014-9039B856B760@sit.fraunhofer.de> <91CD33FE-A023-464F-A49F-04B38A2A6274@qti.qualcomm.com> <543135F2-9D4F-4411-A561-21B4751EBE26@sit.fraunhofer.de>
In-Reply-To: <543135F2-9D4F-4411-A561-21B4751EBE26@sit.fraunhofer.de>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3623229932_19512313"
Archived-At: <https://mailarchive.ietf.org/arch/msg/eat/31D_ZGAq7vGa3jvaerFOIl3EzxU>
Subject: Re: [EAT] [Rats] Attestation BoF charter updates?
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: Wed, 24 Oct 2018 16:45:37 -0000

Not sure I follow.

From:  RATS <rats-bounces@ietf.org>; on behalf of Henk Birkholz
<henk.birkholz@sit.fraunhofer.de>;
Date:  Wednesday, October 24, 2018 at 12:42 PM
To:  Jeremy O'Donoghue <jodonogh@qti.qualcomm.com>;
Cc:  Michael Richardson <mcr+ietf@sandelman.ca>;, "Smith, Ned"
<ned.smith@intel.com>;, Carl Wallace <carl@redhoundsoftware.com>;,
"eat@ietf.org"; <eat@ietf.org>;, "rats@ietf.org"; <rats@ietf.org>;
Subject:  Re: [Rats] [EAT]     Attestation BoF charter updates?

> It is in the current charter text, because I think your answer in the quote
> below is well met.
> 
> "ASN.1 is already player for a number of attestation formats. Any reason to
> exclude it?
> 
> None I can technically justify."
> 
> However, even boiling of the ocean is subject to phasing - and the ASN.1
> related wording is not intended to be a loophole ;-)
> 
> Viele Grüße,
> 
> Henk
> 
> 
> 
> On October 24, 2018 6:32:15 PM GMT+02:00, Jeremy O'Donoghue
> <jodonogh@qti.qualcomm.com>; wrote:
>> I think you already have text which keeps this scenario in scope in the
>> latest draft (the bit about ASN.1 interoperability). From my perspective this
>> is enough for now.
>> 
>> Jeremy
>> 
>>> On 24 Oct 2018, at 17:27, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>;
>>> wrote:
>>> 
>>> Please all keep in mind that we are intending to cut work items into phases.
>>> While we are starting to agree more than we disagree, I think, we should
>>> continue to pay attention to scoping, please. Not now does not mean never!
>>> 
>>> Viele Grüße,
>>> 
>>> Henk
>>> 
>>> On October 24, 2018 2:46:21 PM GMT+02:00, Jeremy O'Donoghue
>>> <jodonogh@qti.qualcomm.com>; wrote:
>>>> I have the following understanding (possibly misunderstood) from this
>>>> thread: 
>>>> 
>>>> * It is desirable to have syntax for incorporating sets of Claims in
>>>> structures that are defined in ASN.1. At the surface level this may be
>>>> straightforward because claims are essentially (key, value) pairs - the key
>>>> potentially being implicit in some cases, but there could be important
>>>> semantic differences in the meaning of signing in Attestation formats vs
>>>> legacy formats, and there may be challenges in mapping some CBOR or JSON
>>>> constructions to ASN.1.
>>>> * The main use-case under discussion is to address mechanisms to enable an
>>>> attestation to be presented to a CA in the context of a certificate request
>>>> protocol. If I have correctly understood this, it means that a direct
>>>> mapping of the Claims in an attestation to an X.509 certificate is a
>>>> non-goal as the CA would be responsible for correctly interpreting the
>>>> semantics of the Claims and incorporating them into an issued certificate
>>>> in ways that make sense in the X.509 world.
>>>> 
>>>> I think we need to take care to limit the scope of work items in this area
>>>> as there exists a considerable existing body of specifications in this
>>>> area. Girl has mentioned ACME, and Carl mentioned SCEP, for which a new
>>>> version appears to be nearing publication.
>>>> 
>>>> My suggestion is that it should be in scope to define a syntax for
>>>> describing attestations which which could be transported via certificate
>>>> request protocols such as ACME and SCEP, but that the question of how the
>>>> semantics of attestations are managed  in their use-cases is a question for
>>>> the WGs owning those specifications.
>>>> 
>>>> Looking at the current SCEP draft
>>>> <https://datatracker.ietf.org/doc/draft-gutmann-scep/?include_text=1> , it
>>>> might be sufficient for the CRIAttributes definition (from RFC2986) to
>>>> include the ASN.1 encoding of an attestation. ACME seems to encode the CSR
>>>> in RFC2986 for as well, so this might be workable.
>>>> 
>>>> In terms of the charter text (which is what is really in scope here) we
>>>> could add text to the WG description indicating that the WG will work with
>>>> relevant WGs to identify where attestations may be useful in PKI
>>>> infrastructures. I think the existing charter text already covers the
>>>> possibility of defining Claims to enable transport of an X.509 certificate
>>>> as part of an attestation.
>>>> 
>>>> Please let me know if I have misunderstood. I will be posting an update to
>>>> the text shortly which I believe covers this.
>>>> 
>>>> Jeremy
>>>> 
>>>>> On 23 Oct 2018, at 20:57, Carl Wallace <carl@redhoundsoftware.com>; wrote:
>>>>> 
>>>>> <snip>
>>>>>> [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.
>>>>> This began with request to codify binding to certificate request
>>>>> protocols, not for a self signed certificate.
>>>>>> 
>>>> 
>>> 
>>> -- 
>>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>> 
> 
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> _______________________________________________ RATS mailing list
> RATS@ietf.org https://www.ietf.org/mailman/listinfo/rats