RE: draft-ietf-smime-3850bis-02 (fwd)

["Turner, Sean P." <turners@xxxxxxxx>]

Alfred,

Thanks for the review. Responses inline. 

spt

>-----Original Message-----
>(1)  Conventions used ...
>
>a)  I have not followed the progress of
>    draft-hoffman-additional-key-words,
>    but it looks like the evolution of that document might
>    be worth being monitored or coordinated with, in order
>    to avoid repeated re-specification of the new keywords.
>
>b)  last paragraph:
>
>     MUST- This term means the same as MUST.  However, we 
>expect at some
>      point that this algorithm will no longer be a MUST in a future
>      document.  [...]
>
>I'd give preference to the word-shuffled variant:
>
>|    MUST- This term means the same as MUST.  However, we 
>expect that at
>|     some point this algorithm will no longer be a MUST in a future
>      document.  [...]

We're following Paul's draft. I copied the text from Paul's ID so the text
is now aligned.

>(2)  Section 2.2
>
>Without explanation, the draft says:
>
>   Receiving agents MUST support v1 X.509 and v3 X.509 identity
>   certificates as profiled in [KEYM].  [...]
>
>This comes to surprise.  Why are v2 certificates excluded?
>
>The deliberations in RFC 5280 seem to make v1 much less preferable.
>
>If there ideed are reasons for this particular requirement, a 
>hint on the rationale would be useful.

v1 is required for backwards compatibility. v2 isn't used because they add
issuerUniqueIdentifier and subjectUniqueIdentifer - both of which were
SHOULD NOT in RFCs 2459/3280 and are MUST NOT in RFC5280.

>(3)  Section 3
>
>Below the ASN.1 fragment, please
>
>     s/an upper bounds/an upper bound/
>                     ^

Fixed

>(4)  Section 4.3
>
>The last paragraph says:
>
>   A receiving agent MUST be capable of verifying the signatures on
>   certificates and CRLs with key sizes from 512 bits to 2048 bits.
>
>This requirement seems to be taylored to RSA/DSA key sizes, 
>but possibly not appropriate for the developing ECDSA context.
>
>To not inappropriately exclude shorter ECDSA key sizes and 
>request support for unusually large ECDSA key sizes, the above 
>statement should perhaps be restricted in scope.  Matching the 
>algorithm support requirements in the earlier parts of 4.3, 
>but not precluding future more previce specification of ECDSA 
>use with PKIX, CMS, and S/MIME, I propose to amend the above 
>statement to say:
>
>                                                 vvvvvvvvvvvvv
>|  A receiving agent MUST be capable of verifying RSA and DSA 
>signatures
>   on certificates and CRLs with key sizes from 512 bits to 2048 bits.

Somebody else also noted this. In the next version I added a table and noted
that it's for RSA and DSA.

>(5)  Sections 6
>
>The lenghty deliberations on MD2 in this section seem to be 
>aged, or almost historical now.  Shouldn't there be some words 
>pointing out more recent developments, in particular the 
>perceived issues with / reduced confidence in MD5 (and perhaps 
>also SHA-1) as well?

We're working on updating the security considerations section in both
3850bis/3851bis. I'm hoping to get the algorithm security considerations
text agreed in 3850bis then we can also copy it to 3850bis.

>(6)  Appendix A
>
>It is very unusual to label these sections "Appendix".
>I suggest to renumber "Appendix A" to "Section 7".

This is historical and at this point I guess I'd like to leave the numbering
alone so the sections align. If the RFC-editor complains then we'll change
it.

>"[RFC-2822]" is the only ref. tag used incorporating an RFC number.
>I do not know the planned schedule, but it might happen that 
>2822-upd will be faster on the publication track, making a ref.
>update necessary.  To prepare for it, and to arrive at a more 
>homogenous ref. tag style, I suggest replacing "[RFC-2822]"
>by "[IMF]".

Changed it to IMF noted the work-in-progress.

>For clerical completeness, I note the race condition that has 
>occurred by nearly concurrent publication events, making the
>draft miss the ref. update:   [KEYM] --> RFC 5280.

Fixed