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

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