[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: draft-ietf-smime-3850bis-02 (fwd)
Thanks for the review. Responses inline.
>(1) Conventions used ...
>a) I have not followed the progress of
> 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/
>(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:
>| A receiving agent MUST be capable of verifying RSA and DSA
> 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
>"[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]"
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.