Subject: RE: Last Call comments on the Message And Certificate Drafts

From: "Blake Ramsdell" <[email-masked]>
Date: Thu, 14 Jan 1999 10:18:20 -0800

> -----Original Message-----
> From: Jim Schaad (Exchange) [mailto:[email-masked]]
> Sent: Saturday, January 09, 1999 3:48 PM
> To: Ietf-Smime (E-mail); Blake Ramsdell
> Cc: Russ Housley (E-mail)
> Subject: Last Call comments on the Message And Certificate Drafts
> 
> 1.  I would like to see some consistancy developed in the 
> reference naming
> between the different documents produced from the S/MIME 
> working group.  I
> especially dislike the KEYM reference name for PKIX Part1 as 
> this is really
> misleading.  Part1 does not really say anything bout key management.

This makes sense.

> 2. Are we requesting obsoletion of the V2 drafts or not.  If 
> we are then why
> are we refering to them.  If we are not then we need to make 
> this clear to
> the RFC editors.  Based on the current thinking, it would be 
> my guess that
> we are not requesting the obsoletion of the S/MIME V2 drafts.

My understanding is that because an RFC is obsolete it does mean you can't
refer to it any more.  We do this for PKCS #1 v1.5 and PKCS #1 v2.0, even
though the PKCS #1 v1.5 RFC is technically obsolete.

> 1. Section 2.4.1 - Example on signature appears to eleminate
> multipart/signed as it states content MUST be stored in eContent OCTET
> STRING.  I would strongly recommend removing the MUST on this as it is
> example not statement of operation.

Hmm...  I understand the concern.  Thinking...

> 2. Section 2.5 - Why do we mention receipt requests but not 
> security labels.
> I would think they are of equal importance and should either both be
> mentioned or omitted.  This is especially true as security 
> labels can easily
> be understood by V2 clients but not receipts (well at least 
> not easily).  I
> recommend we strike the reference to receipt requests.

Agree.

> 3. Section 2.6 -- This is not stated in the format of a MUST. 
>  Change to
> "S/MIME v3 agents MUST use the isserAndSerialNumber form of 
> SignerInfo." or
> similar statement.

Can I just capitalize MUST in the current sentence?

> 5. Section 3.2.1 - The last sentence contains a "MUST not" 
> this should be
> "MUST NOT"

Agree.

> 6. Section A - Changing to an ASN module would be considered 
> niceness but
> not necessity.  I an finding that I use ASN modules more and more for
> creation of ASN encode/decode functions.  Given that we now 
> have several
> different ASN structures in this appendix, I would like to 
> see this combined
> into an ASN module.  I can create this if desired.

I personally think that this would be cool (to have the ASN).

> 7. References -- The [DH] citation should be made to 
> reference the internet
> draft/RFC 

Agree.

> 1. Section 1 - Reference to KEYM in the last sentence of 
> paragraph #1 is
> almost certianly meant to be a reference to SMIME-MSG

Hmm.  I'll buy that.  Agree.

> 2. Section 1 - PKCS#10 requirements are in the V2 Msg Draft 
> and not the V3
> message draft.  This text needs to be omitted or refer to 
> MSG-V2 instead.
> (CERT-V2?) 

I believe that this text should be omitted, since we came to agreement at
one point that we would not speak of it.

> 3. Section A - Remove reference to CRMF as we don't use it

Agree.

> 4. Section 2.3 - P#3 - Given inheritance of DSA parameters do 
> we need to
> modify the statement on not sending the root CA cert.  
> Messages are not even
> internally validatable with out the root in some cases.

Hmm.  I'd rather make it so that DSA parameters MUST NOT be scattered all
the way up and down the certificate chain, which I understand will increase
the certificate size, but will greatly simplify implementation.  Comments?

> 5. Section 4.3 - Why is there a reference to SMIME-MSG for 
> RSA but not for
> DSA?  Why is there no reference for DSA?

Not to mention that SMIME-MSG is a pretty stupid reference for RSA
signatures -- the PKCS #1 RFC would be better, wouldn't it?

Recommend that we fix the reference to point to PKCS #1 for the RSA
algorithms and to point to the DSA reference for the DSA algorithm.

> 6. Section 4.4 - P#1 - Lets replace the last sentence with 
> "The syntax and
> semantics of all the identified extensions are defined in [KEYM]."

I think this sounds OK.

> 7. Section 4.4 - P#2 - Replace sentence #1 with "... the 
> Basic Constraints,
> Key Usage, Authority Key Identifier, Subject Key Identifier 
> and Subject
> Alternative Name Certificate Extensions when they ..."

Agree.

> 8. Section 4.4.1 - We have a big conflict with PKIX.  We say
> basicConstraints should appear, they say it should not.  My 
> personal opinion
> on this one is that PKIX is wrong and we should not change 
> it, but I raise
> this as an incompatiblity between the two drafts.

I believe that in the event that PKIX says one thing and -cert says
something else, -cert wins.

> 9. Section 4.4.1 - Should we add the same criticality 
> statement as occurs in
> PKIX -- i.e. MUST be critical if it appears.  I recommend 
> that we strike the
> criticality statment in 4.4.2 as it duplicates information in 
> PKIX part1.

Agree.

Blake

---

From: [email-masked] (John Pawling)
Date: Fri, 29 Jan 1999 18:06:25 -0500

All,

I respectfully disagree with Jim and Blake regarding the attached message
exchange.  The intent of the Cert I-D is to specify cert processing
requirements in addition to those defined in PKIX I.  IMHO, the last
sentence in the first para in Section 1 should be changed to state:  "S/MIME
agents MUST meet the certificate processing requirements documented in this
I-D in addition to those stated in [KEYM]."

- John Pawling

>> Subject: Last Call comments on the Message And Certificate Drafts

<snip>

---

From: "Jim Schaad (Exchange)" <[email-masked]>
Date: Fri, 29 Jan 1999 16:02:41 -0800

After re-reading this, I think John is probably correct.

jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, January 29, 1999 3:06 PM
To: Ietf-Smime (E-mail)
Subject: RE: Last Call comments on the Message And Certificate Drafts

All,

- John Pawling

<snip>

---

From: "Blake Ramsdell" <[email-masked]>
Date: Fri, 29 Jan 1999 16:14:01 -0800

> Sent: Friday, January 29, 1999 4:03 PM
> To: [email-masked]'; Ietf-Smime (E-mail)

I'll buy it.  Please let the
"absolutely-last-call-I'm-not-kidding-don't-mess-with-me" changes list
reflect this change.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060