Subject: Re: [smime] New ID of potential interest

From: "Herzog, Jonathan - 0668 - MITLL" <[email-masked]>
Date: Tue, 3 Aug 2010 15:42:17 -0400

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

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

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 10 Aug 2010 13:12:24 -0700

> From: Herzog, Jonathan - 0668 - MITLL [mailto:[email-masked]]
> Sent: Tuesday, August 03, 2010 12:42 PM
> To: Jim Schaad
> Cc: Khazan, Roger - 0668 - MITLL; [email-masked]
> 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.
> 
> 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.

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

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.

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

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

> >> We welcome all comments and reviews.
voice:  (781) 981-
> 2356
> Technical Staff							fax:
(781) 981-
> 7687

---

From: "Herzog, Jonathan - 0668 - MITLL" <[email-masked]>
Date: Thu, 12 Aug 2010 12:27:38 -0400

> one node.  This means that the tree is smaller as is the encoded attribute.

Makes sense. I'll change it.

> smaller and faster for all clients to evaluate.

I'll make that clear in the document.

> the future and how should existing clients deal with such items?

Ah, I see what you are asking. Good question. We'd like keep this as extensible as possible, and so what you say makes sense. But I don't immediately see what it means to 'handle gracefully' the case where one doesn't know how to interpret a set. For example, what would it mean to 'handle gracefully' the case where the set is 

  Intersection of (set A) and (X)

when you don't know how to interpret X? I suspect the answer depends on the intended use of this attribute, which can differ from setting to setting.

Given that we can't define what it means to 'handle gracefully' the case where current implementations encounter future extensions, I don't think we should require it in the spec. But at the same time, we don't want to rule out future extensions. Here's an alternate idea: what if we were to include a version number in this attribute? Then we could simply increment this version-number when we extend the attribute. Also, implementations would be able to tell right away whether or not they would understand the set-representation of the attribute. They would then either process the attribute to get the so-represented set, or gracefully handle the attribute as they would a completely unfamiliar attribute. 

> or is this to be evaluated and this later applied to a set of certificates.

I'm not sure what you mean, but I don't envision that a public key would be included in a set-definition between creation and certification. That is, by the time a public key gets to the point where it will be used in a set definition, then one of the two following statements is true:

1) It has already been put in a certificate, and therefore can be referenced by issuer/serial number, or
2) It is an ephemeral/anonymous key, and will *never* be embedded in a certificate.

If this is a reasonable assumption, then we might simply wave the problem away by specifying that it is invalid to refer to a key using the SubjectPublicKeyInfo form when it could also be referenced using the IssuerAndSerialNumber form. But I'm not sure that the underlying assumption is valid...

I'm trying to think of how this might come up. Suppose that the same key were referred to in two different ways-- once using IssuerAndSerialNumber (the 'I' form), and once as SubjectPublicKeyInfo (the 'S' form). Lets further suppose that implementations believed that the two forms referred to two different keys. Then how could things go wrong?

* They could mis-count the number of elements in a set. They could count the key twice, for example, believing there to be one more person/key in the set than there really is.

* They can also over-count the number of elements in the set if they encounter the form "{I} SetDiff {S}". This set should be empty, but the implementation may believe that it is actually equivalent to the set {I}. 

* Then again, they might undercount the number of elements in a set if they encounter the form "{I} Intersection {S}". This set actually contains the key in question, but might be mistaken for empty.

I think what I will propose is that when creating a SetKey attribute, implementations that wish to name a certified key SHOULD use the issuer and serial number form. However, implementations that receive and process a SetKey attribute SHOULD NOT regard different names as always indicating different keys.  And that I add a section to the document explaining these pitfalls.

> thus the question is moot.

For our intended usage, it is the case that a given community would use only one way to refer to a certificate.

> later be mapped to the same individual.

Will do.

While you chew on this, I'll go ahead and make the changes described above and send the new version to you.

Thanks for your comments.

---

From: "Herzog, Jonathan - 0668 - MITLL" <[email-masked]>
Date: Thu, 12 Aug 2010 15:14:03 -0400

> While you chew on this, I'll go ahead and make the changes described above and send the new version to you.

New version attached.

Thanks.