ietf-smime
[Top] [All Lists]

Comments on drafts.

1998-12-10 18:44:28
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. afarrell(_at_)maths(_dot_)tcd(_dot_)ie 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

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