Re: [smime] draft-housley-ct-keypackage-receipt-n-error-00
"Jim Schaad" <ietf@augustcellars.com> Fri, 17 May 2013 17:46 UTC
Return-Path: <ietf@augustcellars.com>
X-Original-To: smime@ietfa.amsl.com
Delivered-To: smime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5474611E811B for <smime@ietfa.amsl.com>; Fri, 17 May 2013 10:46:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v+K7AlVzGUDP for <smime@ietfa.amsl.com>; Fri, 17 May 2013 10:46:49 -0700 (PDT)
Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id B09C111E8114 for <smime@ietf.org>; Fri, 17 May 2013 10:46:47 -0700 (PDT)
Received: from Philemon (unknown [88.214.187.239]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 968ED38F00; Fri, 17 May 2013 10:46:46 -0700 (PDT)
From: Jim Schaad <ietf@augustcellars.com>
To: 'Russ Housley' <housley@vigilsec.com>
References: <20130418151254.13949.52367.idtracker@ietfa.amsl.com> <50816A63-E208-449A-977A-9F31544C9222@vigilsec.com> <00fc01ce3d61$0055ad20$01010760$@augustcellars.com> <708EAE82-3FC4-4979-A72C-30EA52DE26C0@vigilsec.com> <022901ce4770$48a51250$d9ef36f0$@augustcellars.com> <171566A4-63B6-4547-B462-2A75B9DD4D36@vigilsec.com>
In-Reply-To: <171566A4-63B6-4547-B462-2A75B9DD4D36@vigilsec.com>
Date: Fri, 17 May 2013 18:45:56 +0100
Message-ID: <069201ce5326$6488c270$2d9a4750$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJXqOTs93H7Sx2qVjApye56zgIYjwLwaxZ6ArtIz18BXIWQUQJOCNs6AocqbsmXmAxw0A==
Content-Language: en-us
Cc: 'IETF SMIME' <smime@ietf.org>
Subject: Re: [smime] draft-housley-ct-keypackage-receipt-n-error-00
X-BeenThere: smime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SMIME Working Group <smime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/smime>, <mailto:smime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/smime>
List-Post: <mailto:smime@ietf.org>
List-Help: <mailto:smime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/smime>, <mailto:smime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 May 2013 17:46:55 -0000
The use of things such as CONTENT-TYPE are already pushing you to the point of needing an '88 ASN.1 module in the event that is a requirement. The addition of the SIR-ENTITY-NAME class does not change anything from the current world. As such I do not believe that this is a change that would affect a decision on providing an '88 module. One would use a parameterized class definition if one believe that the class would be used in multiple locations with different sets of parameters. Thus it makes sense in the case of CMS to define a single class and type for signed attributes, unsigned attributes, authenticated attributes, unauthenticated attributes as a parameterized set. The same basic type structure is used in each of these locations but with a different set of possible values that can go into each location. One would use a global/fixed name set in the event that something is used in exactly one location and there is no reason to expect that it would be imported into a different module and used with a different set of possible values. Thus we use a single global set in the update to 5272 for the definition of Cmc-Control-Set. I would say that if you expect this to be used in a different document then using a parameter makes sense. Otherwise I would use a fixed object set in this location. Jim > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com] > Sent: Friday, May 17, 2013 2:34 PM > To: Jim Schaad > Cc: 'IETF SMIME' > Subject: Re: [smime] draft-housley-ct-keypackage-receipt-n-error-00 > > Jim: > > >>> 3. Should you define a relationship for relating nameType and > >>> nameValue information? Automated packages would find it useful, it > >>> also makes the fact that you are use Name rather than possibly > >>> GeneralName explicit in the module. > >> > >> I am not totally sure what you are suggesting. Let me know if I got > >> it > > right. > >> > >> SIR-ENTITY-NAME ::= CLASS { > >> &SIRNameType OBJECT IDENTIFIER UNIQUE, > >> &SIRNameValue > >> } WITH SYNTAX { > >> SYNTAX &SIRNameValue IDENTIFIED BY &SIRNameType } > >> > >> SIRNames{SIR-ENTITY-NAME:SIRNameSet} ::= > >> SEQUENCE SIZE (1..MAX) OF SIRName{{SIRNameSet}} > >> > >> SIRName{SIR-ENTITY-NAME:SIRNameSet} ::= SEQUENCE { > >> sirNameType SIR-ENTITY-NAME.&SIRNameType({SIRNameSet}), > >> sirNameValue OCTET STRING (CONTAINING > >> > > SIR-ENTITY-NAME.&SIRNameValue({SIRNameSet}{@sirNameType})) > > > > Yes that looks correct. You could use a fixed name set if you wanted > > to rather than having it be a parameter. This would depend on how you > > are planning to use it. > > I have not made this change yet. It seems I would need a '88 and an '02 > module. > > I'd appreciate advice on the fixed name set vs. the parameter. > > Russ
- [smime] draft-housley-ct-keypackage-receipt-n-err… Russ Housley
- Re: [smime] draft-housley-ct-keypackage-receipt-n… Jim Schaad
- Re: [smime] draft-housley-ct-keypackage-receipt-n… Russ Housley
- Re: [smime] draft-housley-ct-keypackage-receipt-n… Jim Schaad
- Re: [smime] draft-housley-ct-keypackage-receipt-n… Russ Housley
- Re: [smime] draft-housley-ct-keypackage-receipt-n… Russ Housley
- Re: [smime] draft-housley-ct-keypackage-receipt-n… Jim Schaad
- Re: [smime] draft-housley-ct-keypackage-receipt-n… Jim Schaad