I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft updates (at least) RFC 3183. It changes the naming convention and corrects an erratum. The shepherd writeup seems to be based on an earlier version that did not include all the signature types in RFC3183. The writeup raises the possibility that the types not included could be deprecated or possibly move them to this draft and obsolete RFC3183. The current version now includes all the signature types from RFC3183 but it does not say that it intends to obsolete RFC3183. Also, the current draft was submitted at the end of the IETF Last Call and adds a new signature type "delegated originator signature." So, at least, this draft updates RFC3183. Many of the following comments come from text from RFC3183 that has not changed. I'm not sure it that makes them grandfathered in or not. The security considerations section notes some of the doing decryption at a DCA. It notes the possibility of exposure or corruption of a message either by a compromised DCA or somewhere between the DCA and the end user. This is true in any use of DOMSEC based services. In general, the recipient is trusting its own DCA to correctly report validation, or to uphold any of the security services (i.e., not to corrupt, expose or spoof the message). The same is true at the originating end user - the originator is trusting its own DCA to correctly validate the originator, to maintain the security services (not to corrupt, expose, or spoof the message), etc. And messages not protected between the originator/recipient and the sending/receiving agent are subject to damage. The delegated originator signatures seem to be a hybrid case - like originator signatures, they need not encapsulate other signatures (sec 3.2 page 10) but they also may encapsulate other signatures (sec 3.7 page 13). It is not clear when the delegated originator signatures are used in the un-encapsulated form. There are motivating descriptions of the other signature types in section 2, but not for the delegated originator signature type. Sections 5 talks about "domain signature" types, which is one of the DOMSEC-based signature types. It is not clear whether the other DOMSEC-based signature types are meant as well, particularly in the text that describes adding a new encapsulating signature. Section 3.2 page 10 notes that: A SignerInfo MUST NOT include multiple instances of SignatureType. A signed attribute representing a SignatureType MAY include multiple instances of different SignatureType values as an AttributeValue of attrValues [RFC5652], as long as the SignatureType 'additional attributes' is not present. Does this mean that one signature might be noted as a domain signature AND a review signature? A domain AND review AND delegated originator? Aside from the prohibition of the additional attributes types, are there other combinations that do not make sense? The descriptions of adding a DOMSEC-based signature type in 3.3-3.7 do not discuss when or whether an added DOMSEC-based signature might have multiple signature types. Section 2.6 describes the required relationship between a sending agent's certificate's name and the originator's certificate's name. This section is also referenced in section 4 when referring to the recipient and receiving agent. The symmetric case is pretty easy to see, but it would be nice to see it mentioned. Going sequentially through the document: Section 2, as noted above, has no description of delegated originator signature type. The need or uses or benefits were not obvious to me. It might be good for other readers to have a description. Section 2.5, page 7: A DOMSEC defined signature MAY encapsulate a message in one of the following ways: If not in one of these ways, then is no encapsulation performed? Some other encapsulation? If not in one of these ways, with the process of section 5 succeed? This applies particularly to the delegated originator signature type, which is allowed not to encapsulate an signature. Does that mean that it does not need to add the empty signature layer noted in part 1? However, the eContent field will contain the unsigned message instead of being left empty as suggested in section 5.2 in CMS [RFC5652]. Without checking RFC5652 - how do current CMS implementations treat that suggestion? IE, if an implementation of this standard is being built on an existing CMS implementation, with this departure from suggested practice run into problems? section 2.6, p8 For the other types of signature defined in future documents, no such namin rule is defined. I'm not sure what is being said here. *the* other types? do you mean "any other types"? are you making rules for future documents or saying you are making NO rules for future documents? "This naming convention does not apply to signature types define in future documents". Implementations MAY choose to supplement this convention with other locally defined conventions. However, these MUST be agreed between sender and recipient domains prior to secure exchange of messages. How is this agreed? Or expressed? Out of scope for this document? Note that a X.509 certificate of a signing Domain-based sending agent can be distinguished from a certificate of encrypting domain-based sending agent by checking for keyUsage as specified in [RFC5280] Section 4.2.1.3. RFC5280 section 4.2.1.3 says that the keyUsage field is used when there's an intended limitation of use - when the keys are to be used ONLY for a particular usage. Is there an implication in this statement that the sending/receiving agent keys MUST be so limited, so that the distinction can be made? section 3.3, page 11: If the originator's authenticity is successfully verified by one of the above methods and all other signatures present are valid, including those that have been encrypted, a 'domain signature' can be added to a message. Does that mean that a DOMSEC sending agent must be able to decrypt any encrypted layers of a message in order to add the domain signature? The text says: If the originator's authenticity is successfully verified by one of the above methods and all other signatures present are valid, including those that have been encrypted, a 'domain signature' can be added to a message. ... A recipient can assume that successful verification of the domain signature also authenticates the message originator. ... If there is no originator signature present, the only assumption that can be made is the domain the message originated from. Is that last statement consistent with the two prior? page 12 There MAY be one or more 'domain signature' signatures in an S/MIME encoding. (similar phrase appear in 3.4, 3.5) Since a signerInfo MUST NOT contain multiple SignatureTypes, this is talking about multiple encapsulation layers, right? Section 3.4 p 12: The following attributes have a special meaning, when present in an 'additional attributes' signature: I suspect you mean something like "when present in a SignerInfo containing an 'addiitonal attributes' signature. 3.5, p 13 An entity generating a review signature MUST do so using a certificate that follows the naming convention specified in Section 2.6. ((You might run afoul of those who dislike text that says a signature is generated "using" a certificate. Of course, alternates that are not clumsy are hard to compose.)) 3.6, p 13 The 'originator signature' is used to indicate that the signer is the originator of the message and its contents. It is included in this document for completeness only. An originator signature is indicated either by the absence of the signature type attribute, or by the presence of the value id-sti-originatorSig in a 'signature type' signed attribute. So this is all going to be standard CMS, except for the additional signed attribute? 3.7, p 13 The 'delegated originator signature' is similar to the 'domain signature' (Section 3.3), but it also indicates that MSA signed message with a unique originator-specific key. It also need not encapsulate other signatures, so there's no need for the empty signature layer mentioned in 2.5, p7? If the originator's authenticity is successfully verified as specified in Section 3.3 and all other signatures present are valid, including those that have been encrypted, a 'delegated originator signature' can be added to a message. So sometimes a delegated originator signature DOES encapsulate other signatures? The discussion of delegated originator signatures follows the text of 3.3 fairly closely, but leaves off discussion of actions upon reception. Are they not to be performed for delegated originator signatures? It also leaves off the statement that in included in 3.3, 3.4 and 3.5 that there can be multiples of these signatures - is that not possible for delegated signature types? section 4.1, p 15 At the sender's domain, DCA encryption is achieved using the recipient DCA's certificate or the end recipient's certificate. For this, the encrypting process must be able to correctly locate the certificate for the corresponding DCA in the recipient's domain or the one corresponding to the end recipient. Having located the correct certificate, the encryption process is then performed and additional information required for decryption is conveyed to the recipient in the recipientInfo field as specified in CMS [RFC5652]. A DCA encryption agent MUST be named according to the naming convention specified in Section 2.6. This is so that the corresponding certificate can be found. Does "A DCA encryption agent" mean the recipient DCA? The terminology is a bit confusing. Also, Section 2.6 defines a relationship between sending agent name and originator name. How would that naming convention help to find the corresponding certificate? In RFC3183, the naming convention prescribed specific names, not just a relationship. This text might have worked in that case, but I'm not sure the text is applicable now. section 4.1, p16 2. The encrypting agent maps the recipient's name to the DCA name in the manner specified in Section 2.6. The user certificate attribute associated with the DCA's directory entry is then obtained. Again, section 2.6 in the current draft defines a relationship between the sending agent name and the originator name. It does not provide an explicit mapping rule. Section 5, p16 This section talks about 'domain signature' but is referenced by 3.7 for delegated originator signatures as well. (Section 5 is not mentioned in section 3.4-3.6 - the implication is that MLA stripping of review and additional attributes signatures is impossible or of no concern.) Should the text in section 5 be amended to make the application to delegated originator signatures clear? Section 5, p17 + Strip off all the signedData layers down to the envelopedData layer. The stripped outer layer signature's signedAttributes are remembered, but not those of subsequent stripped signedData layers. The omission seems deliberate, but it would be nice to have an explanation. (I did not see the reason.) There is a possibility that the message will contain an envelopedData layer. This will be the case when the message has been encrypted within the domain for the domain's "Domain Confidentiality Authority" (see Section 4), and, possibly, the final recipient. ... 3. A. If an envelopedData layer has been found, then: ... + Locate the RecipientInfo for the local DCA and use the information it contains to obtain the message key. + Decrypt the encryptedContent using the message key. What about the case when the message has been encrypted for the final recipient? (Similar case on p18). p18: If no signedData layer containing a mlExpansionHistory attribute has been found and no envelopedData has been found, then: - 1. Strip off all the signedData layers down to the envelopedData "no envelopedData has been found" .... "down to the envelopedData" This sure looks like a typo, but I don't know what it should say. section 6.1, p21 The submit: URI scheme is used to designate SMTP Submission servers (e.g. listener endpoints, S/MIME agents performing Domain signing), SMTP accounts. ^ and? or? p22 SMTP user names are UTF-8 strings and MUST be percent-encoded as required by the URI specification [RFC3986], Section 2.1. Where do SMTP user names appear in this URI scheme? I'm probably just clueless about the usual nomenclature here. Security considerations: Clients resolving smtp: URIs that wish to achieve data confidentiality "resolving smtp: URIs" - what does it mean to resolve a URI? (Could this maybe have meant to say "using smtp: URIs"? (same comments in section 6.2) --Sandy ========================================= Nits: Please define MUA. p4 2. PKI deployment issues: There may not be any certificate paths between two organizations. Or an organization may be sensitive about aspects of its PKI and unwilling to expose them to outside access. The part that starts "Or an..." is a sentence fragment. In Section 1, 1-4 (from RFC3183) are phrased as :problem description but 5 is :solution. Section 2 - a domain is defined as having a common business function and a physical boundary. Could this technology also be used for a set of end users who meet the mutual trust criteria only? a virtual domain? Lots and lots of cases where an introductory subordinate clause or phrase is not separated from the main clause by a comma. The RFC Editor may have preferences there, I'll leave it to them. p8 - "namin rule" -> "naming rule" Note that a X.509 certificate of a signing Domain-based sending agent can be distinguished from a certificate of encrypting domain-based ^an The subject name of the Domain-based sending agent's X.509 ... Any message received where the domain part of the domain signing agent's name signing agent or sending agent? inconsistent use of quotes: 'domain signature' vs domain signature, 'originator signature' vs originator signature, vs 'additional attributes' signature, etc. p 9 "signers name" -> "signer's name" p17 How the 'domain signature' is applied will depend on what is already present within the message. Before the 'domain signature' can be applied the message MUST be searched for the "outer" signedData layer, this search is complete when one of the following is found: layer. This search p23 "end users DCA" -> "end user's DCA"