Subject: [woes] meeting prep for Prague

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 18 Feb 2011 16:21:06 -0700

Folks, it would be nice to have a successful side meeting in Prague. (I
refuse to call it a "bar bof" unless there is an actual bar involved.)
Toward that end, I wonder if anyone on this list would be interested in
co-chairing the meeting. Ideally we'd have one person from the apps side
of the house and one person from the security side of the house. Even
more ideally, the persons who co-chair the meeting would have a strong
desire to moderate, but not get involved in, the discussion.

Any volunteers before we start contacting people directly? ;-)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Lucy Lynch <[email-masked]>
Date: Fri, 18 Feb 2011 15:25:39 -0800 (PST)

moderate but not get involved - that sounds like me.

how can I help?

- Lucy

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

_______________________________________________
woes mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/woes

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 19 Feb 2011 11:34:42 +0000

> refuse to call it a "bar bof" unless there is an actual bar involved.)

Well let's fix that then. Even if we start in a room, let's try do
that v. quickly and then get the active folks to a bar.

Speaking of progress though - what's the plan here?

As I understand it we're talking about a CMS equivalent in JSON
(which could also be described as an XMLDSIG/XMLENC equivalent in
JSON I guess).

Is that all or is there more that folks want to do, or do they even
want (all of) CMS-like functionality?

Would this work also face new/different constraints related to
algorithm implementations or not?

I'd hope we could see useful progress on the above prior to Prague,
thus giving us more time in the bar:-)

S.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 19 Feb 2011 10:17:11 -0800

> (which could also be described as an XMLDSIG/XMLENC equivalent in

I thought we might start from a clean slate. Make a JSON representation of:

- an encrypted object with all the metadata needed for someone else to 
decrypt it if they have the right key(s)

- a signed object with all the metadata needed for someone else to 
validate the signature if they have the right key(s), and to be able to 
pull out the signed part regardless

We should use CMS and PKIX as a guide to what would be useful, but with 
no intention to be "equivalent". And I think we can ignore XMLDSIG/XLENC 
because they are both less than CMS/PKIX and worse in some ways.

> want (all of) CMS-like functionality?

Good questions.

> algorithm implementations or not?

Hopefully not.

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 19 Feb 2011 11:33:22 -0800

> (which could also be described as an XMLDSIG/XMLENC equivalent in

Who is going to use this and for what?

What are some example scenarios.  For example, are these standalone objects or 
in-line with other things?  are sets of objects signed or each must be treated 
separately?

What are the operational constraints?  For example, PKIX is, ummm, a tad 
heavyweight.  Why is PKIX needed; or rather, what is the nature of the 
certifying that is needed?

Is authentication useful separately (ie, without) encryption?

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 19 Feb 2011 23:42:00 +0100

> Who is going to use this and for what?

People who aren't currently using CMS because it doesn't work for them.
So far, CMS is the only story IETF has in the area of object security.
I can't really recommend that we use CMS in, e.g., CoRE.

> What are some example scenarios.  For example, are these standalone objects or in-line with other things?  are sets of objects signed or each must be treated separately?

In a CoRE scenario, the most basic requirement is to transfer a single protected (signed/encrypted) resource representation.

> What are the operational constraints?  For example, PKIX is, ummm, a tad heavyweight.  Why is PKIX needed; or rather, what is the nature of the certifying that is needed?

In a CoRE scenario, we'd rather not use the full X.509 certificate machinery.

> Is authentication useful separately (ie, without) encryption?

Yes.  You don't always need confidentiality, but you generally do need integrity.

Gruesse, Carsten

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 19 Feb 2011 15:45:07 -0800

> I can't really recommend that we use CMS in, e.g., CoRE.

Why not? Is it "ASN.1 is too hard to parse, but we're sure JSON is just 
fine", or something else?

> In a CoRE scenario, we'd rather not use the full X.509 certificate

That is wise. However, if that's all you need, you could use CMS with 
non-PKIX certs, for example. OTOH, if CoRE is already using JSON for 
other things, then making it the object wrapper for security seems 
useful too.