Stefan:
A nice short document, hopefully the following will be helpful!:
1. Clause 1, Introduction:
It is understood that the prime driver for this draft is to provide a mechanism
to signal the receiver's available and default encryption algorithms, but it
might be appropriate to mention in the introduction that the mechanism will also
allow other receiver capabilities to be obtained. In the first paragraph you
may wish to add a sentence indicating that capabilities in addition to the
encryption algorithms may also be provided.
In the third paragraph, you may not wish to restrict the mechanism's
applicability to only encrypted first messages, since it is useful for initial
signed messages as well (e.g. initial signed message may be compressed).
Possibly change "encrypted message" to "S/MIME message" to make it more general.
2. Clause 3
In the second paragraph, it is declared out of scope to discuss what should be
considered as a more reliable source of this information. However, I would have
preferred a note at least introducing the options for establishing the
precedence of capability information from multiple sources. For example:
The Capabilities in the PKC are inherently signed by the certificate issuer, who
is normally considered more trusted than the end-user who signed the
Capabilities in a signed message. (So one approach is to take PKC information
in precedence to Capabilities received in a signed message.)
Another approach is to presume that the "latest" list should be used. I believe
this was discussed earlier on the list.
Another approach when receiving the capabilities from more than one source is to
use the most restrictive set.
3 Other Issues.
3.1 There is no explicit statement that the S/MIME Capabilities are only (?) to
be included in the encryption PKC in multiple keypair implementations. I assume
this is intended since it does not make sense to include most currently defined
S/MIME capability attributes in signing PKC's. But I worry about the
compression attribute (for signed-only exchanges where there need be no
encryption certificate), and S/MIME Capability attributes are extensible so we
cannot know the future. Some explicit guidance may be appropriate ("... put the
attributes in the relevant PKC ..."), and noting that if attributes are
duplicated across PKC's they should not conflict. Right now I think what is put
in which PKC(s) is open to interpretation (some implementers may put the info in
all the PKC's).
3.2 I believe there should be more discussion about the impact of this approach
on certificate revocation, both in terms of the overhead of re-issuing
certificates and the impact on the size of the CRL. In large organizations with
many certificates this may represent a barrier to the use of this mechanism.
Finally, in Clause 4, "week" should be "weak".
Regards,
Tony