-----Original Message-----
From: Jim Schaad (Exchange)
[mailto:jimsch(_at_)EXCHANGE(_dot_)MICROSOFT(_dot_)com]
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