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