Re: 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?

> 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?

> 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?

> 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?

Thanks.


>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]] On Behalf
>> Of Herzog, Jonathan - 0668 - MITLL
>> Sent: Friday, April 02, 2010 11:14 AM
>> To: [email protected]
>> 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
>> [email protected]
> 


-- 
Jonathan Herzog							voice:  (781) 981-2356
Technical Staff							fax:    (781) 981-7687
Cyber Systems and Technology Group		email:  [email protected]
MIT Lincoln Laboratory               			www:    http://www.ll.mit.edu/CST/
244 Wood Street    
Lexington, MA 02420-9185

_______________________________________________
smime mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/smime