From housley@vigilsec.com Thu May 2 07:08:02 2013 Return-Path: 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 5E58521F8432 for ; Thu, 2 May 2013 07:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 0eOVXR1XQu5W for ; Thu, 2 May 2013 07:07:56 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id CCD4221F842B for ; Thu, 2 May 2013 07:07:55 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id BCFFAF24081; Thu, 2 May 2013 10:08:16 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id DN1Ei4QGH5q7; Thu, 2 May 2013 10:07:38 -0400 (EDT) Received: from [192.168.2.102] (pool-96-241-221-210.washdc.fios.verizon.net [96.241.221.210]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 56063F2407C; Thu, 2 May 2013 10:08:15 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <00fc01ce3d61$0055ad20$01010760$@augustcellars.com> Date: Thu, 2 May 2013 10:07:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <708EAE82-3FC4-4979-A72C-30EA52DE26C0@vigilsec.com> References: <20130418151254.13949.52367.idtracker@ietfa.amsl.com> <50816A63-E208-449A-977A-9F31544C9222@vigilsec.com> <00fc01ce3d61$0055ad20$01010760$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1085) Cc: 'IETF SMIME' 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 14:08:02 -0000 Jim: Thank you for the review. > 1. What is SIR - not defined Source Intermediary Recipient (SIR) entity name > 2. Is it your expectation that name types which do not have ASN.1 = values > are going to be created? If not then why is there an OCTET STRING = wrapper > for nameValue. This choice should be justified in the document. The nameValue is an OCTET STRING, which allows the canonical form of any = name to be carried. Two names of the same type are considered equal if = the octet strings are the same length and contain the same string of = octets. > 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 ::=3D CLASS { &SIRNameType OBJECT IDENTIFIER UNIQUE, &SIRNameValue } WITH SYNTAX { SYNTAX &SIRNameValue IDENTIFIED BY &SIRNameType } SIRNames{SIR-ENTITY-NAME:SIRNameSet} ::=3D SEQUENCE SIZE (1..MAX) OF SIRName{{SIRNameSet}} SIRName{SIR-ENTITY-NAME:SIRNameSet} ::=3D SEQUENCE { sirNameType SIR-ENTITY-NAME.&SIRNameType({SIRNameSet}), sirNameValue OCTET STRING (CONTAINING = SIR-ENTITY-NAME.&SIRNameValue({SIRNameSet}{@sirNameType})) > 4. You should probably give a reference to where signed, = authenticated and > content attributes are found. I am familiar with the first two since = I do a > lot of CMS work, however the last one really needs to be tied to an = RFC and > a specific content type. This attribute can appear as a signed, authenticated, and content = attribute. Signed attributes are carried in the CMS Signed-data content = type described in Section 5 of [RFC5652]. Authenticated attributes are = carried in the CMS Authenticated-data content type described in Section = 9 of [RFC5652] or in the CMS Authenticated-enveloped-data content type = described in Section 2 of [RFC5083]. Content attributes are carried in = the Content-with-attributes content type described in Section 3 of = [RFC4073]. > 5. Can the key package identifier and receipt request attribute have > multiple values or is a single value attribute? Even though the ATTRIBUTE syntax is defined as a SET OF AttributeValue, = a key-package-identifier-and-receipt-request attribute MUST have a = single attribute value; zero or multiple instances of AttributeValue are = not permitted. > 6. We can rehash this discussion. First I don't see any reason for > incrementing the version number unless you are going to re-assign the = same > OID for the new structure as you did for the old one. If a new OID is = used > there is more than enough information to distinguish between the two > different structures. Second, I am not a fan of assigning version = numbers > to these structures because they do not help any encoding/decoding = systems. > The structure will be encoded or decoded based on the ASN and not on = the > version number. I'd rather not rehash this discussion, Instead, I'd like to follow the = convention used in CMS. > 7. What is the purpose of the (1..MAX) on the definition of = KeyPkgVersion. > Are you just trying to say that it cannot be a negative value? It = would be > more helpful if you used a smaller version such as 2^32-1 so that a = compiler > would know that it fit into an int32 value. I would also note that = this is > a change from the old definition of the field in RFC 6031 Yes, the reader is warned that this definition is different. This is = also a reason not to import the definition: -- Revised definition of KeyPkgVersion from [RFC6031] KeyPkgVersion ::=3D INTEGER { v1(1), v2(2) } (1 .. MAX) I think a maximum of 65535 is very safe. > 8. Is there a requirement that systems should accept > KeyPkgIdentifier.attribute values that they do not understand as it = can be > reflected in the receipt without having to decode it? As with all CMS processing, unrecognized attributes are ignored. I'm = not sure this needs to be repeated further. It comes up here: * badUnsignedAttrs is used to indicate that the unsignedAttrs within SignerInfo contains one or more attributes. Since unrecognized attributes are ignored, this error code is used when the object identifier for the attribute is recognized, but the value is malformed or internally inconsistent. =20 > 9. Why is there a requirement that the content types have to be = encoded > using the DER rules? This is not a general requirement imposed by CMS = and > therefore needs some justification text. I am not sure that justification needs to be added to the document, but = I'll share what I was thinking. This content could be processed inside = a security boundary. Using DER allows more straightforward processing, = including the use of templates. > 10. I find the field names errorOf and errorBy to be obtuse - but = that is > not a strong reason to change them if they have a meaning that is not > documented. The field names make sense to me. Do you find the explanation wanting? > 11. does badContentInfo apply to embedded content types (i.e. = eContent) as > well as the ContentInfo structure? I was thinking that a failure at an embedded layer would result in a = badEncapContent error code. > 12. Why should there be a problem with having more than one entry in = the > digestAlgorithms field? I can potentially understand complaining if = there > is one that is not understood but not if there is more than one. I'm trying to keep it simple by requiring a single algorithm used by a = single signer. > 13. I must have missed the rule that says that there is a problem if = you > have a signed attribute that is unknown and not ignored. Is that part = of > the badSignedAttrs field or is this only an issue with the ASN.1 = encoding? AsI said above, I am following the normal CMS processing, unrecognized = attributes are ignored. > 14. notAuthroized - this description seems off for this content type. = Is > the issue that the TA is not authorized or the TA does not root the > authorization. It would not be the signer itself in this case one = presumes. TAMP (RFC 5934) can be used to associate a list of authorized content = types with a TA. > 15. put in a reference for the content-decryption-key-identifier = attribute. Good idea: * noDecryptKey indicates that the receiver does not have the key named in the content-decryption-key-identifier attribute (see=20= [RFC6032]). > 16. Is there a reason for the badKeyTransportRecipientInfo item being > absent? Added ... * badKeyTransRecipientInfo indicates that the KeyTransRecipientInfo syntax is invalid or the version is unknown or unsupported. > 17. Do you want to distinguish between a decryptFailre and a failure > processing a key management item? This is the basis of some online = attacks > to get a key when dealing with RSA v1.5 and RSA OEAP. This merits a > security consideration notice all by itself. Please see my response to comment 29 below. > 18. Are there any security attacks that occur by differentiating = between > decryptFailure and invalidMAC for AuthEnvelopedData? I do not think so. AES-CCM and AES-GCM do not return any plaintext if = there is a integrity failure. > 19. For mismatchedDigestAlg - are you comparing with the signature > algorithm or with the content digest algorithm? I think this one is clear. It indicates that the digest algorithm in = digestAlgorithms field within SignedData does not match the digest = algorithm used by the content signer. > 20. You need some text to distinguish missingCertificate and = noTrustAnchor > if keep the "using a trust anchor" text. TAMP (RFC 5934) tells how a TA can sign the content directly. That = applies here too. > 21. tooManySigners - where is this restriction imposed? I think this makes sense in most key distribution scenarios. How about = this text? * tooManySigners indicates that a SignedData content contained more than one SignerInfo for a content type that requires only one signer. > 22. can the missingSignedAttributes be used if there are attributes = that > are required to be present but are absent - even if there are some = attibutes > present? Yes. > 23. I don't understand the reason for the missingContentHints. This > attribute would be an encrypted structure not a signed structure. Why = would > a content hint make any difference in terms of the processing? This is related to CMS Content Constraints (CCC) defined in RFC 6010. > 24. Are there any security attacks that are uncovered by the use of = the > badMessageDigest error code rather than just saying that the signature > failed to validate? Please see my response to comment 29 below. > 25. badAttributes should be modified to say that this is an error = only if > the attribute is defined to say that it is not legal for that = attribute. > For some attributes having multiple attributes or multiple values is = legal. How about this? * badAttributes indicates that an attribute collection contained either multiple instances of the same attribute type that allows only one instance or contained an attribute instance with multiple values in an attribute that allows only one value. > 26. The description of unsupportedAsymmetricKeyPackage does not make = sense > - There is a difference between not prepared and unsupported How about this? * unsupportedSymmetricKeyPackage indicates that the implementation does not support symmetric key packages [RFC6031]. * unsupportedAsymmetricKeyPackage indicates that the implementation does not support asymmetric key packages [RFC5958]. > 27. Should I be able to return more than one errorCode if I find more = than > one error during processing? No. I'd like to keep it simple. > 28. Given the number of times that AuthenticatedData was mentioned in = the > text, is there a reason it is omitted from section 6? Added ... o AuthenticatedData can be used to integrity protect the content type with message authentication algorithms that support authenticated encryption, where key management information is handled in a manner similar to EnvelopedData. > 29. Security consideration on the cost benefits of using a generic vs = a > specific error code. Some specific codes might leak security = information. Does the following text capture your point? In some situations, returning very detailed error information can provide an attacker with insight into the security processing. Where this is a concern, the implementation should return the most generic error code that is appropriate. However, detailed error codes are very helpful during development, debugging, and interoperability testing. For this reason, implementations may want to have a way to configure the use of a generic error code or a detailed one. > 30. Do you really want to make the KeyPkgVersion revised or is it a = totally > independent thing? As currently setup it will be a different thing = since it > is in a different module. If you want it to be a change on what is in = the > original module then you need to re-publish that module as well. I do not see this as a problem. The v2 value is not defined in RFC = 6031, otherwise an IMPORT might be appropriate. Again, thanks very much for the review. Russ From housley@vigilsec.com Thu May 2 07:13:00 2013 Return-Path: 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 5136A21F8BCC for ; Thu, 2 May 2013 07:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 cfQ3s9wB3-75 for ; Thu, 2 May 2013 07:12:55 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 372C021F8B98 for ; Thu, 2 May 2013 07:12:55 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id D64389A412B for ; Thu, 2 May 2013 10:12:55 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id K-KOVWHLpA2P for ; Thu, 2 May 2013 10:12:50 -0400 (EDT) Received: from [192.168.2.102] (pool-96-241-221-210.washdc.fios.verizon.net [96.241.221.210]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id AE1FA9A4129 for ; Thu, 2 May 2013 10:12:54 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 2 May 2013 10:12:52 -0400 References: <20130502141128.13257.9277.idtracker@ietfa.amsl.com> To: IETF SMIME Message-Id: Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Subject: [smime] draft-housley-ct-keypackage-receipt-n-error-01.txt X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 14:13:00 -0000 The -01 version addresses most, but not all, of the comments submitted = by Jim Schaad. Russ > From: internet-drafts@ietf.org > Date: May 2, 2013 10:11:28 AM EDT > To: Russ Housley > Subject: New Version Notification for = draft-housley-ct-keypackage-receipt-n-error-01.txt >=20 >=20 > A new version of I-D, = draft-housley-ct-keypackage-receipt-n-error-01.txt > has been successfully submitted by Russ Housley and posted to the > IETF repository. >=20 > Filename: draft-housley-ct-keypackage-receipt-n-error > Revision: 01 > Title: Cryptographic Message Syntax (CMS) Key Package = Receipt and Error Content Types > Creation date: 2013-05-02 > Group: Individual Submission > Number of pages: 25 > URL: = http://www.ietf.org/internet-drafts/draft-housley-ct-keypackage-receipt-n-= error-01.txt > Status: = http://datatracker.ietf.org/doc/draft-housley-ct-keypackage-receipt-n-erro= r > Htmlized: = http://tools.ietf.org/html/draft-housley-ct-keypackage-receipt-n-error-01 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-housley-ct-keypackage-receipt-n-e= rror-01 >=20 > Abstract: > This document defines the syntax for two Cryptographic Message = Syntax > (CMS) content types, one for key package receipts, and another for > key package errors. The key package receipt content type is used to > confirm receipt of an identified key package or collection of key > packages. The key package error content type is used to indicate an > error occurred during the processing of a key package. CMS can be > used to digitally sign, digest, authenticate, or encrypt these > content types. From ietf@augustcellars.com Thu May 2 13:05:34 2013 Return-Path: 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 A7BFF21F8D2B for ; Thu, 2 May 2013 13:05:34 -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 ISvKd-dRNGdu for ; Thu, 2 May 2013 13:05:28 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id BE73F21F8539 for ; Thu, 2 May 2013 13:05:28 -0700 (PDT) Received: from Philemon (unknown [67.137.20.166]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 41CFF2CA1C; Thu, 2 May 2013 13:05:28 -0700 (PDT) From: "Jim Schaad" To: "'Russ Housley'" 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> In-Reply-To: <708EAE82-3FC4-4979-A72C-30EA52DE26C0@vigilsec.com> Date: Thu, 2 May 2013 13:04:41 -0700 Message-ID: <022901ce4770$48a51250$d9ef36f0$@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: AQJXqOTs93H7Sx2qVjApye56zgIYjwLwaxZ6ArtIz18BXIWQUZenEnow Content-Language: en-us Cc: 'IETF SMIME' 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 20:05:34 -0000 > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com] > Sent: Thursday, May 02, 2013 7:08 AM > To: Jim Schaad > Cc: 'IETF SMIME' > Subject: Re: [smime] draft-housley-ct-keypackage-receipt-n-error-00 > > Jim: > > Thank you for the review. > > > 1. What is SIR - not defined > > Source Intermediary Recipient (SIR) entity name Good > > > 2. Is it your expectation that name types which do not have ASN.1 > > values are going to be created? If not then why is there an OCTET > > STRING wrapper for nameValue. This choice should be justified in the > document. > > The nameValue is an OCTET STRING, which allows the canonical form of any > name to be carried. Two names of the same type are considered equal if the > octet strings are the same length and contain the same string of octets. Good > > > 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. > > > 4. You should probably give a reference to where signed, > > authenticated and content attributes are found. I am familiar with > > the first two since I do a lot of CMS work, however the last one > > really needs to be tied to an RFC and a specific content type. > > This attribute can appear as a signed, authenticated, and content attribute. > Signed attributes are carried in the CMS Signed-data content type described > in Section 5 of [RFC5652]. Authenticated attributes are carried in the CMS > Authenticated-data content type described in Section 9 of [RFC5652] or in the > CMS Authenticated-enveloped-data content type described in Section 2 of > [RFC5083]. Content attributes are carried in the Content-with-attributes > content type described in Section 3 of [RFC4073]. > Good > > 5. Can the key package identifier and receipt request attribute have > > multiple values or is a single value attribute? > > Even though the ATTRIBUTE syntax is defined as a SET OF AttributeValue, a > key-package-identifier-and-receipt-request attribute MUST have a single > attribute value; zero or multiple instances of AttributeValue are not > permitted. > Good > > 6. We can rehash this discussion. First I don't see any reason for > > incrementing the version number unless you are going to re-assign the > > same OID for the new structure as you did for the old one. If a new > > OID is used there is more than enough information to distinguish > > between the two different structures. Second, I am not a fan of > > assigning version numbers to these structures because they do not help any > encoding/decoding systems. > > The structure will be encoded or decoded based on the ASN and not on > > the version number. > > I'd rather not rehash this discussion, Instead, I'd like to follow the convention > used in CMS. I don't need to rehash the discussion either. I will just always raise it. > > > 7. What is the purpose of the (1..MAX) on the definition of KeyPkgVersion. > > Are you just trying to say that it cannot be a negative value? It > > would be more helpful if you used a smaller version such as 2^32-1 so > > that a compiler would know that it fit into an int32 value. I would > > also note that this is a change from the old definition of the field > > in RFC 6031 > > Yes, the reader is warned that this definition is different. This is also a reason > not to import the definition: > > -- Revised definition of KeyPkgVersion from [RFC6031] KeyPkgVersion ::= > INTEGER { v1(1), v2(2) } (1 .. MAX) > > I think a maximum of 65535 is very safe. I agree that is probably more than sufficient. > > > 8. Is there a requirement that systems should accept > > KeyPkgIdentifier.attribute values that they do not understand as it > > can be reflected in the receipt without having to decode it? > > As with all CMS processing, unrecognized attributes are ignored. I'm not sure > this needs to be repeated further. It comes up here: > > * badUnsignedAttrs is used to indicate that the unsignedAttrs > within SignerInfo contains one or more attributes. Since > unrecognized attributes are ignored, this error code is used > when the object identifier for the attribute is recognized, but > the value is malformed or internally inconsistent. I don't think that this is an acceptable solution ore response at this point. If I send you Key package id and receipt request ::= { pkgID = { random OID you never heard of, binary value } receiptReq = { encryptReceipt FALSE, receiptsFrom - absent receiptsTo = {Me} }} You have three options: 1 - say that the signed attribute is bad because you do not understand a piece if it and neither process nor receipt the package 2 - say that you don't care that the signed attribute is bad and process it and return a receipt because you do not need to understand the key package identifier 3 - say that you ignore things you do not understand and process the package but do not return a receipt. > > > 9. Why is there a requirement that the content types have to be > > encoded using the DER rules? This is not a general requirement > > imposed by CMS and therefore needs some justification text. > > I am not sure that justification needs to be added to the document, but I'll > share what I was thinking. This content could be processed inside a security > boundary. Using DER allows more straightforward processing, including the > use of templates. That's fine - I thought it might be something like that. > > > 10. I find the field names errorOf and errorBy to be obtuse - but > > that is not a strong reason to change them if they have a meaning that > > is not documented. > > The field names make sense to me. Do you find the explanation wanting? The explanations are just fine. I merely find the names odd. I would have expected something more along the lines of errorOnPackage - name of package errorReportedBy - That is longer more descriptive names. But as I said - I don't really care that much. > > > 11. does badContentInfo apply to embedded content types (i.e. > > eContent) as well as the ContentInfo structure? > > I was thinking that a failure at an embedded layer would result in a > badEncapContent error code. Ok - that is what is reflected. > > > 12. Why should there be a problem with having more than one entry in > > the digestAlgorithms field? I can potentially understand complaining > > if there is one that is not understood but not if there is more than one. > > I'm trying to keep it simple by requiring a single algorithm used by a single > signer. Ok - I can see this as being reasonable. > > > 13. I must have missed the rule that says that there is a problem if > > you have a signed attribute that is unknown and not ignored. Is that > > part of the badSignedAttrs field or is this only an issue with the ASN.1 > encoding? > > AsI said above, I am following the normal CMS processing, unrecognized > attributes are ignored. Ok - may not be correct behavior in all cases, but that can be application specific and that is the rule you are using in this application. > > > 14. notAuthroized - this description seems off for this content type. > > Is the issue that the TA is not authorized or the TA does not root the > > authorization. It would not be the signer itself in this case one presumes. > > TAMP (RFC 5934) can be used to associate a list of authorized content types > with a TA. It also allows for a list of authorized contents to be associated with a signer certificate as well I thought. If so then this description would seem to not allow for that case. That is the current signing certificate can be more restrictive than the TA is. > > > 15. put in a reference for the content-decryption-key-identifier attribute. > > Good idea: > > * noDecryptKey indicates that the receiver does not have the key > named in the content-decryption-key-identifier attribute (see > [RFC6032]). > Good > > 16. Is there a reason for the badKeyTransportRecipientInfo item being > > absent? > > Added ... > > * badKeyTransRecipientInfo indicates that the > KeyTransRecipientInfo syntax is invalid or the version is > unknown or unsupported. Good > > > 17. Do you want to distinguish between a decryptFailre and a failure > > processing a key management item? This is the basis of some online > > attacks to get a key when dealing with RSA v1.5 and RSA OEAP. This > > merits a security consideration notice all by itself. > > Please see my response to comment 29 below. > Yes that deals with the issue. > > 18. Are there any security attacks that occur by differentiating > > between decryptFailure and invalidMAC for AuthEnvelopedData? > > I do not think so. AES-CCM and AES-GCM do not return any plaintext if there > is a integrity failure. I was thinking in terms of something similar to the attacks that exist for the RSA v1.5/OAEP differences. There may be something that may leak information to an attacker that could be useful. However I think that the comment on 29 probably addresses this issue as well. > > > 19. For mismatchedDigestAlg - are you comparing with the signature > > algorithm or with the content digest algorithm? > > I think this one is clear. It indicates that the digest algorithm in > digestAlgorithms field within SignedData does not match the digest algorithm > used by the content signer. I might prefer s/used by the content signer/used in the signature algorithm/ However this was a double check so the current text is probably sufficient. > > > 20. You need some text to distinguish missingCertificate and > > noTrustAnchor if keep the "using a trust anchor" text. > > TAMP (RFC 5934) tells how a TA can sign the content directly. That applies > here too. Ok - I can see this > > > 21. tooManySigners - where is this restriction imposed? > > I think this makes sense in most key distribution scenarios. How about this > text? > > * tooManySigners indicates that a SignedData content contained > more than one SignerInfo for a content type that requires only > one signer. > Good > > 22. can the missingSignedAttributes be used if there are attributes > > that are required to be present but are absent - even if there are > > some attibutes present? > > Yes. Ok > > > 23. I don't understand the reason for the missingContentHints. This > > attribute would be an encrypted structure not a signed structure. Why > > would a content hint make any difference in terms of the processing? > > This is related to CMS Content Constraints (CCC) defined in RFC 6010. > Yes - I had forgotten that type. > > 24. Are there any security attacks that are uncovered by the use of > > the badMessageDigest error code rather than just saying that the > > signature failed to validate? > > Please see my response to comment 29 below. Again - that covers the issue > > > 25. badAttributes should be modified to say that this is an error > > only if the attribute is defined to say that it is not legal for that attribute. > > For some attributes having multiple attributes or multiple values is legal. > > How about this? > > * badAttributes indicates that an attribute collection contained > either multiple instances of the same attribute type that > allows only one instance or contained an attribute instance > with multiple values in an attribute that allows only one > value. > Yes that works > > 26. The description of unsupportedAsymmetricKeyPackage does not make > > sense > > - There is a difference between not prepared and unsupported > > How about this? > > * unsupportedSymmetricKeyPackage indicates that the > implementation does not support symmetric key packages > [RFC6031]. > > * unsupportedAsymmetricKeyPackage indicates that the > implementation does not support asymmetric key packages > [RFC5958]. > Yes that deals with the issue > > 27. Should I be able to return more than one errorCode if I find more > > than one error during processing? > > No. I'd like to keep it simple. That is fine with me, I was just making sure that you had considered the issue. > > > 28. Given the number of times that AuthenticatedData was mentioned in > > the text, is there a reason it is omitted from section 6? > > Added ... > > o AuthenticatedData can be used to integrity protect the content > type with message authentication algorithms that support > authenticated encryption, where key management information is > handled in a manner similar to EnvelopedData. > Looks good > > 29. Security consideration on the cost benefits of using a generic vs > > a specific error code. Some specific codes might leak security information. > > Does the following text capture your point? > > In some situations, returning very detailed error information can > provide an attacker with insight into the security processing. Where > this is a concern, the implementation should return the most generic > error code that is appropriate. However, detailed error codes are > very helpful during development, debugging, and interoperability > testing. For this reason, implementations may want to have a way to > configure the use of a generic error code or a detailed one. Yes that addresses the issues that I was looking at > > > 30. Do you really want to make the KeyPkgVersion revised or is it a > > totally independent thing? As currently setup it will be a different > > thing since it is in a different module. If you want it to be a > > change on what is in the original module then you need to re-publish that > module as well. > > I do not see this as a problem. The v2 value is not defined in RFC 6031, > otherwise an IMPORT might be appropriate. > Ok - no big deal. > Again, thanks very much for the review. Welcome - jim > > Russ From turners@ieca.com Thu May 2 18:46:45 2013 Return-Path: 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 6FA7B21F8EBB for ; Thu, 2 May 2013 18:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.116 X-Spam-Level: X-Spam-Status: No, score=-102.116 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] 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 QMq1Jrt0xtcL for ; Thu, 2 May 2013 18:46:40 -0700 (PDT) Received: from gateway06.websitewelcome.com (gateway06.websitewelcome.com [67.18.144.9]) by ietfa.amsl.com (Postfix) with ESMTP id B3A4621F89D5 for ; Thu, 2 May 2013 18:46:39 -0700 (PDT) Received: by gateway06.websitewelcome.com (Postfix, from userid 5007) id 3979F220E2D1D; Thu, 2 May 2013 20:46:39 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway06.websitewelcome.com (Postfix) with ESMTP id 2A817220E2CE6 for ; Thu, 2 May 2013 20:46:39 -0500 (CDT) Received: from [96.231.222.90] (port=51665 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UY554-0006ed-V3 for smime@ietf.org; Thu, 02 May 2013 20:46:39 -0500 Message-ID: <518316FD.1020107@ieca.com> Date: Thu, 02 May 2013 21:46:37 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: smime@ietf.org References: <20130418172439.25554.71786.idtracker@ietfa.amsl.com> In-Reply-To: <20130418172439.25554.71786.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130418172439.25554.71786.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [96.231.222.90]:51665 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 11 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [smime] Fwd: I-D Action: draft-turner-ct-keypackage-receipt-n-error-algs-00.txt X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 01:46:45 -0000 For draft-housley-ct-keypackage-receipt-n-error-00 there's a companion algorithm draft. spt -------- Original Message -------- Subject: I-D Action: draft-turner-ct-keypackage-receipt-n-error-algs-00.txt Date: Thu, 18 Apr 2013 10:24:39 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Algorithms for Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types Author(s) : Sean Turner Filename : draft-turner-ct-keypackage-receipt-n-error-algs-00.txt Pages : 6 Date : 2013-04-18 Abstract: This document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS) key package receipt and error content types. Specifically, it includes conventions necessary to implement SignedData, EnvelopedData, EncryptedData, and AuthEnvelopedData. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-turner-ct-keypackage-receipt-n-error-algs There's also a htmlized version available at: http://tools.ietf.org/html/draft-turner-ct-keypackage-receipt-n-error-algs-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From turners@ieca.com Thu May 9 02:58:28 2013 Return-Path: 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 C0BEB21F8765 for ; Thu, 9 May 2013 02:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.615 X-Spam-Level: X-Spam-Status: No, score=-101.615 tagged_above=-999 required=5 tests=[AWL=0.651, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] 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 Uc0oDhfpZ6r8 for ; Thu, 9 May 2013 02:58:22 -0700 (PDT) Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com [67.18.68.2]) by ietfa.amsl.com (Postfix) with ESMTP id B1C0F21F8D27 for ; Thu, 9 May 2013 02:58:22 -0700 (PDT) Received: by gateway14.websitewelcome.com (Postfix, from userid 5007) id 6A6C5FF6D1728; Thu, 9 May 2013 04:58:18 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway14.websitewelcome.com (Postfix) with ESMTP id 5B216FF6D1701 for ; Thu, 9 May 2013 04:58:18 -0500 (CDT) Received: from [31.216.236.149] (port=43692 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UaNcE-0004bq-8a for smime@ietf.org; Thu, 09 May 2013 04:58:22 -0500 Message-ID: <518B733E.3090309@ieca.com> Date: Thu, 09 May 2013 10:58:22 +0100 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: smime@ietf.org References: <20130509095643.11432.81386.idtracker@ietfa.amsl.com> In-Reply-To: <20130509095643.11432.81386.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130509095643.11432.81386.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [31.216.236.149]:43692 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [smime] Fwd: I-D Action: draft-turner-ct-keypackage-receipt-n-error-algs-01.txt X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 09:58:28 -0000 I received some off-list comments that I incorporated. spt -------- Original Message -------- Subject: I-D Action: draft-turner-ct-keypackage-receipt-n-error-algs-01.txt Date: Thu, 09 May 2013 02:56:43 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Algorithms for Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types Author(s) : Sean Turner Filename : draft-turner-ct-keypackage-receipt-n-error-algs-01.txt Pages : 6 Date : 2013-05-09 Abstract: This document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS) key package receipt and error content types. Specifically, it includes conventions necessary to implement SignedData, EnvelopedData, EncryptedData, and AuthEnvelopedData. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-turner-ct-keypackage-receipt-n-error-algs There's also a htmlized version available at: http://tools.ietf.org/html/draft-turner-ct-keypackage-receipt-n-error-algs-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-turner-ct-keypackage-receipt-n-error-algs-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From housley@vigilsec.com Fri May 17 06:34:41 2013 Return-Path: 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 5B0DE21F93E1 for ; Fri, 17 May 2013 06:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 WxUkx-2vMCEN for ; Fri, 17 May 2013 06:34:35 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id CDAC221F93E8 for ; Fri, 17 May 2013 06:34:29 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id AC612F24076; Fri, 17 May 2013 09:34:35 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id HSkoS+4VKAFE; Fri, 17 May 2013 09:34:25 -0400 (EDT) Received: from [192.168.2.109] (pool-96-241-156-29.washdc.fios.verizon.net [96.241.156.29]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 1DD7DF2406E; Fri, 17 May 2013 09:34:35 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <022901ce4770$48a51250$d9ef36f0$@augustcellars.com> Date: Fri, 17 May 2013 09:34:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <171566A4-63B6-4547-B462-2A75B9DD4D36@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> To: Jim Schaad X-Mailer: Apple Mail (2.1085) Cc: 'IETF SMIME' 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 13:34:41 -0000 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. >>=20 >> I am not totally sure what you are suggesting. Let me know if I got = it > right. >>=20 >> SIR-ENTITY-NAME ::=3D CLASS { >> &SIRNameType OBJECT IDENTIFIER UNIQUE, >> &SIRNameValue >> } WITH SYNTAX { >> SYNTAX &SIRNameValue IDENTIFIED BY &SIRNameType >> } >>=20 >> SIRNames{SIR-ENTITY-NAME:SIRNameSet} ::=3D >> SEQUENCE SIZE (1..MAX) OF SIRName{{SIRNameSet}} >>=20 >> SIRName{SIR-ENTITY-NAME:SIRNameSet} ::=3D SEQUENCE { >> sirNameType SIR-ENTITY-NAME.&SIRNameType({SIRNameSet}), >> sirNameValue OCTET STRING (CONTAINING >>=20 > SIR-ENTITY-NAME.&SIRNameValue({SIRNameSet}{@sirNameType})) >=20 > 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 From housley@vigilsec.com Fri May 17 06:37:03 2013 Return-Path: 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 D5D3921F93EB for ; Fri, 17 May 2013 06:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 PbOVmLVOnU9p for ; Fri, 17 May 2013 06:36:57 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 402A321F93E8 for ; Fri, 17 May 2013 06:36:57 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 7914BF24076; Fri, 17 May 2013 09:37:04 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id WYXbYQpGfwYg; Fri, 17 May 2013 09:36:52 -0400 (EDT) Received: from [192.168.2.109] (pool-96-241-156-29.washdc.fios.verizon.net [96.241.156.29]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id BFCE5F2406E; Fri, 17 May 2013 09:37:03 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <022901ce4770$48a51250$d9ef36f0$@augustcellars.com> Date: Fri, 17 May 2013 09:36:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <968BB011-0FA5-4E48-8043-BACA74D915FF@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> To: Jim Schaad X-Mailer: Apple Mail (2.1085) Cc: 'IETF SMIME' 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 13:37:03 -0000 Jim: >>> 8. Is there a requirement that systems should accept >>> KeyPkgIdentifier.attribute values that they do not understand as it >>> can be reflected in the receipt without having to decode it? >>=20 >> As with all CMS processing, unrecognized attributes are ignored. I'm = not > sure >> this needs to be repeated further. It comes up here: >>=20 >> * badUnsignedAttrs is used to indicate that the unsignedAttrs >> within SignerInfo contains one or more attributes. Since >> unrecognized attributes are ignored, this error code is used >> when the object identifier for the attribute is recognized, = but >> the value is malformed or internally inconsistent. >=20 >=20 > I don't think that this is an acceptable solution ore response at this > point. >=20 > If I send you=20 >=20 > Key package id and receipt request ::=3D { > pkgID =3D { random OID you never heard of, binary value } > receiptReq =3D { > encryptReceipt FALSE, > receipts=46rom - absent > receiptsTo =3D {Me} > }} >=20 > You have three options: >=20 > 1 - say that the signed attribute is bad because you do not understand = a > piece if it and neither process nor receipt the package > 2 - say that you don't care that the signed attribute is bad and = process it > and return a receipt because you do not need to understand the key = package > identifier > 3 - say that you ignore things you do not understand and process the = package > but do not return a receipt. Does this text resolve you concern? * badUnsignedAttrs is used to indicate that the unsignedAttrs within SignerInfo contains one or more attributes. Since unrecognized attributes are ignored, this error code is used when the object identifier for the attribute is recognized, but the value is malformed or internally inconsistent. In addition, this error code can be used when policy prohibits an implementation from supporting unsigned attributes. Russ= From ietf@augustcellars.com Fri May 17 10:46:55 2013 Return-Path: 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 ; 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 ; 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 ; 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" To: "'Russ Housley'" 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' 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From ietf@augustcellars.com Fri May 17 10:49:30 2013 Return-Path: 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 370CB21F8AD5 for ; Fri, 17 May 2013 10:49:30 -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 3kWOSyOiYq6x for ; Fri, 17 May 2013 10:49:24 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 681F521F8A54 for ; Fri, 17 May 2013 10:49:24 -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 smtp1.pacifier.net (Postfix) with ESMTPSA id 902CB2CA48; Fri, 17 May 2013 10:49:23 -0700 (PDT) From: "Jim Schaad" To: "'Russ Housley'" 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> <968BB011-0FA5-4E48-8043-BACA74D915FF@vigilsec.com> In-Reply-To: <968BB011-0FA5-4E48-8043-BACA74D915FF@vigilsec.com> Date: Fri, 17 May 2013 18:48:33 +0100 Message-ID: <069301ce5326$c20ae680$4620b380$@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: AQJXqOTs93H7Sx2qVjApye56zgIYjwLwaxZ6ArtIz18BXIWQUQJOCNs6AiyrZV2XmuQCcA== Content-Language: en-us Cc: 'IETF SMIME' 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 17:49:30 -0000 > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com] > Sent: Friday, May 17, 2013 2:37 PM > To: Jim Schaad > Cc: 'IETF SMIME' > Subject: Re: [smime] draft-housley-ct-keypackage-receipt-n-error-00 > > Jim: > > >>> 8. Is there a requirement that systems should accept > >>> KeyPkgIdentifier.attribute values that they do not understand as it > >>> can be reflected in the receipt without having to decode it? > >> > >> As with all CMS processing, unrecognized attributes are ignored. I'm > >> not > > sure > >> this needs to be repeated further. It comes up here: > >> > >> * badUnsignedAttrs is used to indicate that the unsignedAttrs > >> within SignerInfo contains one or more attributes. Since > >> unrecognized attributes are ignored, this error code is used > >> when the object identifier for the attribute is recognized, but > >> the value is malformed or internally inconsistent. > > > > > > I don't think that this is an acceptable solution ore response at this > > point. > > > > If I send you > > > > Key package id and receipt request ::= { > > pkgID = { random OID you never heard of, binary value } receiptReq > > = { > > encryptReceipt FALSE, > > receiptsFrom - absent > > receiptsTo = {Me} > > }} > > > > You have three options: > > > > 1 - say that the signed attribute is bad because you do not understand > > a piece if it and neither process nor receipt the package > > 2 - say that you don't care that the signed attribute is bad and > > process it and return a receipt because you do not need to understand > > the key package identifier > > 3 - say that you ignore things you do not understand and process the > > package but do not return a receipt. > > Does this text resolve you concern? > > * badUnsignedAttrs is used to indicate that the unsignedAttrs > within SignerInfo contains one or more attributes. Since > unrecognized attributes are ignored, this error code is used > when the object identifier for the attribute is recognized, but > the value is malformed or internally inconsistent. In > addition, this error code can be used when policy prohibits an > implementation from supporting unsigned attributes. > No. I think this is going to need a F2F conversation to resolve. > Russ=