Re: [Rats] [lamps] [EXTERNAL] Re: PKIX Attestation design group meeting notes 2024-01-29

[Mike Ounsworth <[e-mail]>]

Hi Carl,

 

Sorry for being unclear.

 

No, there’s nothing wrong with 5.1.3.

 

I am proposing to not merge Hannes’ PR

 

https://github.com/lamps-wg/csr-attestation/pull/83

 

---

Mike Ounsworth

 

From: Carl Wallace <[e-mail]> 
Sent: Tuesday, January 30, 2024 11:07 AM
To: Mike Ounsworth <[e-mail]>; Thomas Fossati <[e-mail]>; Monty Wiseman <[e-mail]>; Hannes Tschofenig <[e-mail]>
Cc: LAMPS <[e-mail]>; [e-mail]
Subject: Re: [lamps] [EXTERNAL] Re: [Rats] PKIX Attestation design group meeting notes 2024-01-29

 

Are you suggesting to drop Section 5. 1. 3? What then would be supported? Attestation type agility is not something new (so there’s no scope creep in that regard). From: Spasm <spasm-bounces@ ietf. org> on behalf of Mike Ounsworth <Mike. Ounsworth=40entrust. com@ dmarc. ietf. org>Date:  



Are you suggesting to drop Section 5.1.3? What then would be supported? Attestation type agility is not something new (so there’s no scope creep in that regard).

 

From: Spasm <[e-mail] <mailto:[e-mail]> > on behalf of Mike Ounsworth <Mike.Ounsworth=[e-mail] <mailto:Mike.Ounsworth=[e-mail]> >
Date: Tuesday, January 30, 2024 at 11:23 AM
To: Thomas Fossati <[e-mail] <mailto:[e-mail]> >, Mike Ounsworth <Mike.Ounsworth=[e-mail] <mailto:Mike.Ounsworth=[e-mail]> >, Monty Wiseman <[e-mail] <mailto:[e-mail]> >, Hannes Tschofenig <[e-mail] <mailto:[e-mail]> >
Cc: LAMPS <[e-mail] <mailto:[e-mail]> >, "[e-mail] <mailto:[e-mail]> " <[e-mail] <mailto:[e-mail]> >
Subject: Re: [lamps] [EXTERNAL] Re: [Rats] PKIX Attestation design group meeting notes 2024-01-29

 

Thanks Thomas.

 

My SCOPE CREEP ALARM is going off.

 

 <mailto:[e-mail]> @Hannes Tschofenig,  <mailto:[e-mail]> @Monty Wiseman I am starting to think that we should pull the Attestation Type OIDs Registry stuff out of the CSR Attestation draft so that this draft is not slowed down by ballooning scope creep around defining this registry (you should read this as: this is good work, but the CA industry really really really needs the CSR attribute ASAP, like last summer. Please no more delays to add more content.)

 

---

Mike Ounsworth

 

From: RATS <[e-mail] <mailto:[e-mail]> > On Behalf Of Thomas Fossati
Sent: Tuesday, January 30, 2024 4:13 AM
To: Mike Ounsworth <Mike.Ounsworth=[e-mail] <mailto:Mike.Ounsworth=[e-mail]> >
Cc: LAMPS <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> ; Monty Wiseman <[e-mail] <mailto:[e-mail]> >
Subject: [EXTERNAL] Re: [Rats] PKIX Attestation design group meeting notes 2024-01-29

 

Hi Mike, Thank you for the updates! On Mon, 29 Jan 2024 at 19: 49, Mike Ounsworth <Mike. Ounsworth=40entrust. com@ dmarc. ietf. org> wrote: > > Discussed at some length the OID references registry > https: //urldefense. com/v3/__https: //github. com/lamps-wg/csr-attestation/pull/83__;!!FJ-Y8qCqXTj2!dw3KcjFkaRrAENM73hM3HC0BGs2k-EW4ON9N8UuB9bMrL0HyoVB_NzcNeYOQcJxIpdB6UTWR46oKScNNvlh36h8Lf56uaQ$ 

 

Hi Mike,
 
Thank you for the updates!
 
On Mon, 29 Jan 2024 at 19:49, Mike Ounsworth
<Mike.Ounsworth=[e-mail] <mailto:Mike.Ounsworth=[e-mail]> > wrote:
> 
> Discussed at some length the OID references registry
> https://urldefense.com/v3/__https://github.com/lamps-wg/csr-attestation/pull/83__;!!FJ-Y8qCqXTj2!dw3KcjFkaRrAENM73hM3HC0BGs2k-EW4ON9N8UuB9bMrL0HyoVB_NzcNeYOQcJxIpdB6UTWR46oKScNNvlh36h8Lf56uaQ$ <https://urldefense.com/v3/__https:/github.com/lamps-wg/csr-attestation/pull/83__;!!FJ-Y8qCqXTj2!dw3KcjFkaRrAENM73hM3HC0BGs2k-EW4ON9N8UuB9bMrL0HyoVB_NzcNeYOQcJxIpdB6UTWR46oKScNNvlh36h8Lf56uaQ$> 
> 
> Basically, implementors writing Relying Parties against this spec will ask "Ok, but where can I find a list of all the OIDs that I can expect to see show up in EvidenceStatement.type?".
> 
> So this document will instruct IANA to create a new registry that is a collection of, and references to, Attestation Evidence format OIDs that have been registered elsewhere. The proposed format for the table is:
> 
> | OID              | Description                | Reference(s)   | Change Controller |
> |------------------|----------------------------|----------------|-------------------|
> | 2 23 133 5 4 10  | DICE Evidence              | {{TCGDICE1.1}} |  TCG              |
> | 2 23 133 5 4 9   | Conceptual Message Wrapper | {{TCGDICE1.1}} |  TCG              |
 
Regarding this point.  I think this is a *very* useful addition.  So
useful that I am wondering whether the new registry's scope could be
extended to cover all typing information related to attestation
messages, including OID, media types, CoAP C-F, CBOR tags, etc., to
make this a one-stop shop for everything attestation.  I am not sure
if there is a precedent for a "meta registry" like this in IANA, but I
think it is worth exploring the possibility.
 
cheers, t
 
_______________________________________________
RATS mailing list
[e-mail] <mailto:[e-mail]> 
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/rats__;!!FJ-Y8qCqXTj2!dw3KcjFkaRrAENM73hM3HC0BGs2k-EW4ON9N8UuB9bMrL0HyoVB_NzcNeYOQcJxIpdB6UTWR46oKScNNvlh36h_mfYtDRw$ <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/rats__;!!FJ-Y8qCqXTj2!dw3KcjFkaRrAENM73hM3HC0BGs2k-EW4ON9N8UuB9bMrL0HyoVB_NzcNeYOQcJxIpdB6UTWR46oKScNNvlh36h_mfYtDRw$> 

_______________________________________________ Spasm mailing list [e-mail] <mailto:[e-mail]>  https://www.ietf.org/mailman/listinfo/spasm <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!YNZe9tM1kWcoQHpz-LECG-BMqj9z0ddx-7GDGHmSj2Q2vokpN54Zhf0FP5snlZHC1ciDo0Ri7SBIe9TLhYv2w79O$>