[Top] [All Lists]

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

2000-07-04 07:52:51
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.


-----Original Message-----
From: Jim Schaad [mailto:jimsch(_at_)nwlink(_dot_)com]
Sent: 03 July 2000 07:40
To: t(_dot_)dean(_at_)eris(_dot_)dera(_dot_)gov(_dot_)uk; 
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.)


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


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


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


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.


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


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
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
if a MIME layer exists you don't have to specify how to apply a domain
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'.
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(_at_)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.


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


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
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
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).


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
on the list. Let a sleeping dog lie :-)

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


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
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).
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
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 
then the public key belonging to 
domain-confidentiality-authority(_at_)eris(_dot_)dera(_dot_) 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.)


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

Attachment: draft-ietf-smime-domsec-06.txt
Description: Text document

<Prev in Thread] Current Thread [Next in Thread>