-----Original Message-----
From: Herzog, Jonathan - 0668 - MITLL
[mailto:jherzog(_at_)ll(_dot_)mit(_dot_)edu]
Sent: Tuesday, August 03, 2010 12:42 PM
To: Jim Schaad
Cc: Khazan, Roger - 0668 - MITLL; smime(_at_)ietf(_dot_)org
Subject: Re: [smime] New ID of potential interest
Again with the four-month delay in replying. We apologize again, but do
want to follow
up on your suggestions below.
On Apr 10, 2010, at 9:07 PM, Jim Schaad wrote:
A couple of questions and comments on this document
1. Is there a reason not to make the sequence require at least two
elements
for a union and an intersection?
No, there is no reason. And the ASN.1 module can be easily changed to
enforce the
presence of at least two elements in the sequence. But what are the pros
and cons of
doing so? Will anything be gained by requiring that unions and
intersections have at
least two elements?
I see no down side to make this requirement - it avoids the need to parse
and evaluate a node in the tree that contains a union or an intersection of
one node. This means that the tree is smaller as is the encoded attribute.
2. For 'union' and 'intersection' I would prefer "This sequence MUST be
non-empty." To be rendered as "The sequence of SetKeyParticipentSet
values
MUST be non-empty." The first time I read this I mixed up the ASN.1
sequence with the contents of the result of the union.
Good point. Thanks.
3. Given that we are discussion SETs. Are there any reasons not to
impose
some restrictions on those who create SetKetParticipentSet values so
that
they are not every empty? Thus an intersection SHOULD NOT result in an
empty result
I fear that might turn out to be an onerous run-time requirement. These
sets might be
represented by community-identifiers, remember. If we wish to enforce that
intersections be non-empty (for example) then we are requiring that
someone go chase
down the membership-lists of all communities. That may be an undesirable
run-time
requirement for some settings.
Also, that requirement may not be well-defined, if these communities
change. A set may
be non-empty when generated, but become empty later as come component
communities
change their membership.
But let me ask: what is gained by requiring that generated SETs be
non-empty?
So yes there is a good reason not to require this is the leaf nodes can be
dynamic. If they are static then doing a pre-evaluation would make things
smaller and faster for all clients to evaluate.
4. Are there any locations (such as SetMember) where you one should
explicitly state that this field may be expanded at a later date with
additional values that may need to be recognized as being present, even
if
they are not evaluated.
I'm not sure what you mean here. Can you rephrase?
Are you ever going to want to add additional, currently unknown, items to
the structure SetMember? If so do you want to require that they be handled
gracefully by people written to the current specification? Similarly are
you ever going to want to add new operations to the SetKeyParticapantSet in
the future and how should existing clients deal with such items?
5. When doing an intersection, does none need to understand the value
of
SetMember, or can the evaluation be done on the ASN.1 encoding of the
SetMember. Specifically would one need to understand that a
certificate
containing a specific public key be identified EITHER by the pub key
info or
by the issuer/serial?
That's a very good question. I hadn't thought about it. Do you have any
suggestions?
So the first question that comes up is whether you are expecting this to be
evaluated in the context of a specific certificate (or set of certificates)
or is this to be evaluated and this later applied to a set of certificates.
In the second case one cannot say that an issuer serial number and a public
key info refer to the same certificate. Part of the question can be
addressed as a security consideration and part by expected usage. That is a
single community might only use a single way of identifying certificates and
thus the question is moot.
You might also have some problems from Alexy if you refer to things as
names, but you don't use a name form to store them in. You might be better
using groupId rather than groupName (same with participantName). Note that
you don't currently seem to expect that you can get from a participantName
to a certificate to check for matches so the best rule might be that
different name forms are treated as different identifiers even if they can
later be mapped to the same individual.
Thanks.
-----Original Message-----
From: smime-bounces(_at_)ietf(_dot_)org
[mailto:smime-bounces(_at_)ietf(_dot_)org] On Behalf
Of Herzog, Jonathan - 0668 - MITLL
Sent: Friday, April 02, 2010 11:14 AM
To: smime(_at_)ietf(_dot_)org
Cc: Khazan, Roger - 0668 - MITLL
Subject: [smime] New ID of potential interest
I would like to inform the SMIME working group of a newly-submitted
Internet Draft that may be of interest:
A set-key attribute for symmetric-key packages draft-herzog-setkey-00
Abstract
A set-key is a symmetric key (or set of keys) associated with an
immutable set of participants. This document defines a set-key
attribute for use in the CMS-based symmetric-key package structure
defined in in RFC XXXX. {{{ RFC Editor, please replace XXXX with the
number assigned to draft-ietf-keyprov-symmetrickeyformat when it is
published. }}}
https://datatracker.ietf.org/doc/draft-herzog-setkey/
We welcome all comments and reviews.
Thank you.
--
Jonathan Herzog
Technical Staff, MIT Lincoln Laboratory
jherzog(_at_)ll(_dot_)mit(_dot_)edu
--
Jonathan Herzog
voice: (781) 981-
2356
Technical Staff fax:
(781) 981-
7687
Cyber Systems and Technology Group email:
jherzog(_at_)ll(_dot_)mit(_dot_)edu
MIT Lincoln Laboratory www:
http://www.ll.mit.edu/CST/
244 Wood Street
Lexington, MA 02420-9185
_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime