Subject: RE: Comments on draft-ietf-smime-domsec-05.txt

From: "William Ottaway" <[email-masked]>
Date: Tue, 4 Jul 2000 15:54:22 +0100

Hi Jim,

Thanks for your comments.

I have responded to each of your comments below. I have also attached a
working version of the latest version of DOMSEC that reflects some of the
points you have made.

Cheers,
Bill.

> -----Original Message-----
> From: Jim Schaad [mailto:[email-masked]]
> Sent: 03 July 2000 07:40
> To: [email-masked]; [email-masked]
> Cc: Ietf-Smime
> Subject: Comments on draft-ietf-smime-domsec-05.txt
>
>
> 1.  Should the X.400 on hetrogenous messaging be expanded to X.400/P1
> similar to SMTP/MIME

Its not just P1. Have changed the text to read X.400 series. Is that better?

>
> 2. Section 1.0 bullet 4:  Should be Heterogeneous Message Formats not
> transports.  The problem is if you cannot carry the S/MIME
> content type not
> the wrapper on the message. (Microsoft Exchange actually uses
> X.400 headers
> with a custom content type for internal replication last time I
> checked and
> this did not break signatures on these messages as the MIME structure was
> carried intact.)

Done.

>
> 3. Section 1 last paragraph: change to more standard wording on MUST.

Done.

>
> 4. Section 2.1 formatting problem: "signature(if present)using" goes to
> "signature (if present) using"

Done.

>
> 5. Section 2.2 - remove MAY from the last sentence.  This is a
> reason to do
> the signatures, but is not part of the protocol definition. --
> change MAY to
> could.

Done.

>
> 6. Section 2.3 - ditto above comment for first sentence.  You can do this,
> but it is not part of the protocol defintion.  change MAY to can.

Done.

>
> 7. Section 3.0 bullet 1: change "will be id-data" to "MUST be id-data"

Done.

>
> 8. Section 3.0 bullet 1: This concept bothers me.  I think that
> there may be
> some programs out there that assume atleast one signature in a signed data
> object except for cases such as degenerate certs only messages.

This may be true. However, CMS (section 5.1) states that there may be zero
signerInfos. Therefore, the problem is with those programs that expect at
least one signature.

>
> 9. Section 3.0 bullet 1: A better term for this might be a null (or empty)
> signature layer.  This will difference the concept from the discussions
> about signing with the NULL signature algorithm.

I did have concerns over this. Have changed it to empty signature layer.

>
> 10. Section 3.0 bullet 2: This not clear about the presence (or
> absense) of
> a MIME layer.  If MIME layer exists, then I fail to see the need
> for bullet
> 1 at all.

You are going to have to humour me on this point. Can you explain your
thoughts
in more detail? Points 1 and 2 are there to describe encapsulating an
unsigned and a signed message with a domain signature. Are you suggesting
that
if a MIME layer exists you don't have to specify how to apply a domain
signature
to an unsigned message?

>
> 11. Section 3.0 Para 1:  Simple example of why counter-signature and
> parallel signatures do or don't work for this might be called for.

Since we do not mention parallel signatures any more, we only support
encapsulation, I believe an example of why counter-signature and parallel
signatures do or don't work would be inappropriate and confusing.

>
> 12. Section 3.1.1 Paragraph 5 - Apears to imply that cn="Jim Schaad -
> review-authority" is legal (difference between 'in' and 'as'.
> Additionally
> you might want to do capitalization here as utf8 strings do not do case
> insensitive name compararisions (i.e. Review-Authority).  Also is cn="Jim
> Schaad" cn="review-authority" legal? [By definition I think that
> this would
> only need to be done if the review was on the innermost signature
> layer.  On
> outer layers I don't believe the intent was that name checking of the
> certificate and sender should occur otherwise signing MLAs will
> create lots
> of havoc.]

Good point. Changed 'in' to 'as'.

>
> 13. Section 3.1.1 Paragraphy ? - Should "domain-signing-authority@com" be
> explicity forbidden?

We do not wish to forbid this capability.

>
> 14. Section 3.1.1 Last Paragraphy - Please soften last sentence.  The
> correct action should be to flag sender/certificate mismatch not to reject
> as invalid.

Done.

>
> 15. Section 3.1.2 Paragraph 4 - Please tell me where [CMS] provides a
> description of generating and processing siganture types.  I believe that
> you meant "All signatures are processed..."

Your right. Have changed.

>
> 16. Section 3.1.2 Paragraph ~5 - Please put text in to OID
> definition using
> the -- comment syntax of ASN.  i.e.
> 	id-aa-sigtype-domain-signature :: OBJECT ID {....}
> 		-- Domain Signature

Done.

>
> 17. Section 3.1.2 Paragraphy last - 3 - Please remove or refine text about
> originator signature not ecapuslating other signatures -- you are
> eleminating triple wrapped signature from existance (i.e.
> S2(E(S1(M))) where
> S1 and S2 are by the originator.

Good point. Have changed text to allow this.

>
> 18. Section 3.1.2 Paragraph last-2 - Can different SignerInfos at the same
> level have different content in the SigantureType attribute or not?

No they can't have different content. Text has now been added to state this.

>
> 19. Section 3.2 Paragraph 4 - If this siganture is to be kept around, you
> must remove the mlaExpansion or the first MLA outside will strip
> the domain
> signature from the message.

Removing the mlaExpansion will not stop this in all cases. If there is an
envelopedData within the message the MLA will strip off all signatures
outside
of the envelopedData.

Any suggestions as to how to keep the domain signature?

>
> 20. Section 3.2 Paragarph 11 - Why is this only a MAY.  It would
> appear that
> the correct statement is MUST as otherwise the whole process is wasted.
>

Where are you referring to? 3.2 para 11 does not contain a MAY.

> 21. Section 3.2 Paragaph  ? - Where and how did you get the FROM
> address in
> the message.  Unless you make a statement about including the SMTP headers
> at the time of wrapping all you get is the MIME headers which do
> not include
> this information.  (i.e. this is never going to happen unless you call for
> it to happen.)

After reviewing this issue we have decided to remove this text, since even
if
this field is within the message you can not assume that it contains the
identity of the originator.

>
> 22. Section 3.2 Last Paragraph - Change to make a statement about a single
> layer as well (or instead of).

Done.

>
> 23. Section 3.3 Paragraph 4 - did you mean to reference ESS not CMS?

Good catch. Done.

>
> 24. Section 3.3 Bullet 1 - If I have S1(S2(S3(M))).  S1 has an equivalent
> label, S2 and S3 both have labels, and the labels are different.  Is the
> equivalent label the same as both labels or only one?

This is outside the scope of DOMSEC. I recall this subject being discussed
before
on the list. Let a sleeping dog lie :-)

>
> 25. Section 3.3 Paragraphy Last-2 - This MAY should be a MUST

Done.

>
> 26. Section 3.3 Paragarph Last - ditto froms ection 3.3

If you are referring to the 'MAY' as in "There MAY be one or more 'domain
signature'
signatures in an S/MIME encoding" then this should be a MAY and not a MUST.

>
> 27. Section 3.5 - By default you can have multiple originator signatures
> (potentially with different algorithms) in a message.  So the
> restriction in
> this section makes no sense.

You are correct. Have removed the restriction.

>
> 28. Section 4 - Where on this table would you put the case of Originator
> Encrypts to Recipient Domain which encrypts to Receipient?  It
> would appear
> to be an instance of (a), (b) and (c).

If the originator encrypts to the recipients domain then this is case (b).
Then
when the recipients domain encrypts to the recipient this is case (c).

>
> 29. Section 4 Paragraphy Last-2 - How can I possibly enforce
> this?  For Key
> Transport the sender is anonymous, for Key Agreement the senders
> certificate
> is often not examined.  Additionally the domain component could change so
> that does match -- or it might be my domain component that did the
> re-enecryption and would therefore match my domain name and not
> the senders
> domain name.

The only extra specification to those specified in CMS is that the naming
convention and name mapping convention defined in DOMSEC is used. This is
specified to locate public keys. For example, if a domain needs to locate
the public key for the domain of the recipient [email-masked]
then the public key belonging to [email-masked].
gov.uk needs to be located, or if not present the public key of an ascendant
of the domain name needs to be located.

>
> 30. General - Please include ASN.1 module at the end with a list of all
> defined OIDs and structures.  Get module oid from Russ.  (This request is
> just pure lazyness on my part but makes some things easier.)

Done.

>
> 31. General - Do we need to specify the big brother syndrome at this time
> (encrypt for end-entity and for DCA)?

Can you foresee any problems if we do?

> jim schaad