Subject: Comments on drafts.

From: "Andrew Farrell" <[email-masked]>
Date: Thu, 10 Dec 1998 17:10:30 -0700

AFAIK, none of these have been brought up before. Apologies if any of them have (particularly the really small stuff). Also, the stuff I brought up about certdist won't be repeated here: It may be in the minutes, and I'm sure it'll be in the next draft.

cert-05.txt:

3.1: The last paragraph has nothing to do with email addresses in certificates, and looks more like it belongs is section 3.2. Now that (Paul said) 3.2 has disappeared, this should perhaps become section 3.2.
OR, specify that the SubjectAlternateName in this paragraph be resticted to rfc822address, if that's what we mean.

certdist-02.txt:

4: Third paragraph should read :

The ASN.1 definition of a SMimeCertificatePublish object is the same as that of a CMS signed object.

Also, throughout the document, shouldn't ASN be ASN.1?

cms-09.txt:

1: Reference to MUSTSHOULD?

1: The first sentence is the same as the first sentence from the Abstract, but missing authentication or digesting.

5.1: Last two paragraphs belong in 5.2

11: The attributes defined can also presumably be used in enveloped-data. I can't actually see how or why, but there's a pointer from 6.1 to here.

ess-09.txt:

1: reference to MUSTSHOULD?

2.3, second paragraph: I'm unhappy with the two consecutive sentences which say that if two verified signatures conflict, a signature must not be generated, but a signature should be generated if any signature verifies (or 'validates') and another doesn't because you don't recognize the algorithm. I suggest moving the second half of the second sentence up near the start of the paragraph, as the third sentence:

Note that it is possible that the receiving agent cannot verify a receiptRequest because the containing signerInfo is signed using an algorithm not supported by the receiving agent.

And replacing the last sentence in the paragraph with:

Failing this, the reciving agent SHOULD return a signed receipt.

2.3, flowchart item 3.1: 'should' should be capitalised.

4.2.3.2: I'm not sure this flowchart-like process will work. Unless I'm mistaken, it gives different results on, for example, 4.2.1 example 5, where I see it returning S4(S2(E1(S1(Original Content)))). Or example 2, where I see it returning S4(S2(S1(Original Content))). If the text between 4.2 and 4.2.1 is what the group wants, I'm not convinced that the stuff between the end of 4.2.1 and 4.3 does any good, apart from mentioning replacing originatorInfo.

msg-09.txt:

2.2: "The algorithm parameters for DSA MUST be absent."

x942-04.txt:

2.1.1: j and q are more or less out of nowhere. I'd suggest (for clarity) 

p is a large prime such that
j is a large integer, q is a large prime and p=qj + 1

or swapping the order of q and j so that j existence is a property of q, rather than vice versa:

q is a large prime such that
j a large integer and p=qj + 1.

That's all, folks.

Andrew (great to meet you all)
---
Insecure travelling address. [email-masked] is no less secure, but more likely to be read.

Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sun, 13 Dec 1998 05:11:46 -0500

Andrew makes many good points that should be considered by other S/MIME

>1: reference to MUSTSHOULD?

Er, yes. Added.

>2.3, second paragraph: I'm unhappy with the two consecutive sentences which 
>say that if two verified signatures conflict, a signature must not be 
>generated, but a signature should be generated if any signature verifies (or 
>'validates') and another doesn't because you don't recognize the algorithm. 

That's not what they say, I believe. They say if two *receiptRequest*
attributes in a SignedData conflict, don't send back a receipt. If you
can't validate a signature due to not knowing a particular algorithm, keep
going.

>2.3, flowchart item 3.1: 'should' should be capitalised.

Yup.

>4.2.3.2: I'm not sure this flowchart-like process will work. Unless I'm 
>mistaken, it gives different results on, for example, 4.2.1 example 5, where 
>I see it returning S4(S2(E1(S1(Original Content)))).

I don't see this. I think that step 3.2.1 strips off S2, yes?

> Or example 2, where I 
>see it returning S4(S2(S1(Original Content))).

Yes, I agree; good catch! I have changed step 2 of 4.2.3.2 to:

2. If the outermost SignedData layer includes an signed mlExpansionHistory
attribute, the MLA checks for an expansion loop as described in the
"Detecting Mail List Expansion Loops" section, then go to step 3. If the
outermost SignedData layer does not include an signed mlExpansionHistory
attribute, go directly to step 4.
 
...and changed the flowchart to:

2. Does outermost SignedData layer contain mlExpansionHistory?
       YES -> Check it, then -> 3.
       NO  -> 4.

> If the text between 4.2 and 
>4.2.1 is what the group wants, I'm not convinced that the stuff between the 
>end of 4.2.1 and 4.3 does any good, apart from mentioning replacing 
>originatorInfo.

I think that it gives additional valuable examples of how to do processing.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Andrew Farrell <[email-masked]>
Date: Mon, 14 Dec 1998 14:47:32 +0000

>can't validate a signature due to not knowing a particular algorithm, keep

First, the paragraph (in ess-09):

Before processing a receiptRequest signedAttribute, the receiving agent
MUST verify the signature of the SignerInfo which covers the
receiptRequest attribute. A recipient MUST NOT process a receiptRequest
attribute that has not been verified. Because all receiptRequest
attributes in a SignedData object must be identical, the receiving
application fully processes (as described in the following paragraphs)
the first receiptRequest attribute that it encounters in a SignerInfo
that it verifies, and it then ensures that all other receiptRequest
attributes in signerInfos that it verifies are identical to the first
one encountered. If there are verified ReceiptRequest attributes which
conflict, then the processing software MUST NOT return any signed
receipt. A signed receipt SHOULD be returned if any signerInfo
containing a receiptRequest attribute can be validated, even if other
signerInfos containing the same receiptRequest attribute cannot be
validated because they are signed using an algorithm not supported by
the receiving agent.

First, I'd like to propose 'recipient' for the list of terms whose use
should be regulated:) The problem is that what the final sentence means,
is that a signed receipt should be returned if any receiptRequest
verifies, under the restriction of the preceding sentence. In other
words, the final sentence doesn't stand on its own. And it doesn't say
anything different than the second sentence of the paragraph, it just
gives a reason why not processing a receiptRequest may not be an
'"error" error'.

>>4.2.3.2: I'm not sure this flowchart-like process will work. 

To shorten the path, what I mean by this is that the words in 4.2 say
that we determine the outer signed data by recursing through the nested
signatures until we find something we like, and that if we don't find
one, we treat the _original_ message as the outer signed data. This
isn't the sort of algorithm that I think can be represented in
flowcharts, without some sort of explicit variable storage, if you see
what I mean.

Andrew.

---

From: Russ Housley <[email-masked]>
Date: Mon, 21 Dec 1998 17:01:23 -0500

>1: Reference to MUSTSHOULD?

Why?  The document does not capitalize those words.

>11: The attributes defined can also presumably be used in enveloped-data. I 
>can't actually see how or why, but there's a pointer from 6.1 to here.

None of these are a big deal.  I will add them if a version 11 is needed.

Russ

---

From: Andrew Farrell <[email-masked]>
Date: Tue, 22 Dec 1998 11:24:22 +0000

>Why?  The document does not capitalize those words.

Hurm. I went back and checked this when I was composing the mail, and
meant to leave it out. Apologies.

Andrew.