[secdir] secdir comments on draft-melnikov-smime-msa-to-mda

[Sandra Murphy <[e-mail]>]

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 <tag>:problem description
but 5 is <phrase>: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"