Re: [Rats] draft-ounsworth-rats-x509-evidence-00

[Carl Wallace <[e-mail]>]

Inline...

On 11/9/23, 9:05 AM, "Henk Birkholz" <[e-mail] <mailto:[e-mail]>> wrote:


Hi Carl,


my individual opinion:


1.) I am obviously leaning towards one document and less text 
referencing/cloning. Splitting documents would just create a more 
confusing spread of documents, I think. The combined content will remain 
the same. If the WGs really want one document that does one half in 
LAMPS and one document that does the other half in RATS... okay.

[CW] One document seems fine to me as well.

2.) We most poselutely must sync semantics across any "bow-tie formats" 
(or documents split across WGs).

[CW] I agree with that.

> There was an exchange between Mike and Laurence during the presentation yesterday that highlights a potential difference of opinion between I-D author(s) and participants in the working group that could impact the adoption question.


What was that about again? Carl, could you help me here, please?

[CW] It was about syncing claims across formats: https://youtu.be/JEtscCiEcfQ?t=5804. Immediately before that point referenced in the link, Dave gave thumbs up to keeping claims sync'ed, which I think there will be broad agreement for in the WG. Understanding how a third format will be managed seems like an adoption consideration.



Viele Grüße,


Henk


p.s. to Brendan's point: SUIT is build as a modern set of building 
blocks that will work elegantly for years to come and is luckily is not 
burdened with the esoteric laden history that are X.509 extensions. 
Evidence Attributes for X.509 artifacts still make sense as it will take 
some time before these requirements go away.

[CW] I get that ASN.1 will be around for a while and that new ASN.1 is appropriate for intersection points. While I don't share the opinion that an OCTET STRING in an extension is such an intersection point, I am not objecting to providing ASN.1 definitions. 


On 09.11.23 14:45, Carl Wallace wrote:
> 
> On 11/9/23, 8:09 AM, "RATS on behalf of Henk Birkholz" <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>> on behalf of [e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
> 
> 
> I think this discussion is mood as was pointed out in the meeting
> already. Please see:
> 
> 
> https://www.rfc-editor.org/rfc/rfc9334.html#figure-9 <https://www.rfc-editor.org/rfc/rfc9334.html#figure-9> <https://www.rfc-editor.org/rfc/rfc9334.html#figure-9> <https://www.rfc-editor.org/rfc/rfc9334.html#figure-9&gt;>
> 
> [CW] I don't think that diagram renders this discussion moot. X.509 certificate-based attestations have existed since before RATS (and before we called attestation evidence). There's not even much question about potential for including claims in an X.509 certificate within current RATS documents (see section C.3 of EAT). I think the questions are: 1) do we want to provide ASN.1 definitions for claims and 2) do we want to keep claim definitions (roughly) in sync across ASN.1/CBOR/JSON. Re: 1), there's seems to be general acceptance of defining claims in ASN.1 for the most part (though no one really answered Brendan's question regarding why ASN.1 was disallowed for SUIT but is allowed here). Question 2) needs some more discussion. There was an exchange between Mike and Laurence during the presentation yesterday that highlights a potential difference of opinion between I-D author(s) and participants in the working group that could impact the adoption question.
> 
> On 09.11.23 14:05, [e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>> wrote:
>> Hi Laurence,
>>
>> The charter says:
>>
>> “
>>
>> Standardize data models that implement and secure the defined
>> information model (e.g., CBOR Web Token structures [RFC8392
>> <https://datatracker.ietf.org/doc/rfc8392/> <https://datatracker.ietf.org/doc/rfc8392/&gt;> <https://datatracker.ietf.org/doc/rfc8392/&gt;> <https://datatracker.ietf.org/doc/rfc8392/&amp;gt;&gt;>], JSON Web Token structures
>> [RFC7519 <https://datatracker.ietf.org/doc/rfc7519/> <https://datatracker.ietf.org/doc/rfc7519/&gt;> <https://datatracker.ietf.org/doc/rfc7519/&gt;> <https://datatracker.ietf.org/doc/rfc7519/&amp;gt;&gt;>]).
>>
>> “
>>
>> CWT and JWT are mentioned as examples. The group already works on
>> another evidence format, namely the TPM-based stuff.
>>
>> I would say that the document fits nicely within the scope of the charter.
>>
>> Regarding the document split. I am open to discussions about your
>> suggestion, which assumes adoption in the group.
>>
>> Ciao
>>
>> Hannes
>>
>> *From:*RATS <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> *On Behalf Of *lgl island-resort.com
>> *Sent:* Donnerstag, 9. November 2023 13:59
>> *To:* rats <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>
>> *Subject:* [Rats] draft-ounsworth-rats-x509-evidence-00
>>
>> I think it might be better to split this into two drafts.
>>
>> First, define how to put CWT/JWT claims into ASN.1 and make an X.509
>> attestation token.
>>
>> Second, define the FIPS and CC status claims for CBOR, JSON and ASN.1.
>>
>> I wish we didn’t have to do the first, but understand that we might.
>> Note that the RATS charter says we work on CBOR and JSON. There was a
>> little discussion about ASN.1 back in the early days and we certainly
>> put it off back then. There was also YANG discussion. Search the RATS
>> mail archive for ASN.1.
>>
>> I’m much more interested in the FIPS and CC status claims. I would like
>> to define them for CBOR, JSON and ASN.1. If they are booleans this is
>> trivial. The would get registered in the CWT and JWT IANA registries.
>>
>> One of the reasons I’d like to define them for CBOR and JSON is so
>> there’s a known and accepted way to translate their ASN.1 claims into JSON.
>>
>> Also, the X.509 definition should be for Attestation Results as well as
>> Evidence. There’s no reason to restrict it and there’s no work to allow
>> use as Attestation Results.
>>
>> LL
>>
>> (sent incorrectly the first time only to the rats-chairs; meant it for
>> the list)
>>
>>
>> _______________________________________________
>> RATS mailing list
>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
>> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats> <https://www.ietf.org/mailman/listinfo/rats> <https://www.ietf.org/mailman/listinfo/rats&gt;>
> 
> 
> _______________________________________________
> RATS mailing list
> [e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats> <https://www.ietf.org/mailman/listinfo/rats> <https://www.ietf.org/mailman/listinfo/rats&gt;>
> 
> 
> 
>