Charles
1. Great - happy to see it coming - comments below
2.
>>Charter - The group will place particular emphasis on strong
cryptography based on open and freely available algorithms.<<
Fully concur
>>Charter - 1. interoperability using cryptographic algorithms
>>(asymmetric/symmetric including key lengths) that are consider
>>strong, open and unencumbered, and
Is there any way of ensuring (or at least attempting) interoperability
amongst mesage security applications (e.g. PGP and RSA. My
understanding is that even if the 2 applications use the same
algorithms, they are still not interoperable)
Allen Simpson wrote:
>>>1. mandatory support for strong, open and unencumbered
>>>cryptographic algorithms. Other algorithms may be optionally
>>>specified, but will >>not be required for conformance.
I disagree - There MUST NOT be any mandatory requirements for
algorithms, keys, ...
If two correspondents need to correspond securely, they must first
establish their respective mail security capabilities (ie find out
what they can receive) through the use of other relevant mail
capabilities such as Directories.
If they h ave compoatible capabilities, they will correspond, if they
do not, tough luck. This is no problem for e-commerce because I
expect commercial enterprises will implement a multitude of security
capabilities to satisfy their cusdtomers.
3.
>>Charter - 2. limited backwards compatibility with the existing pgp
message
""Limited"" is good - anything more (as Allen Simpson suggested)
will encumber (and probably regress) the specification
4.
>>Charter - 3. Government and legislative policies from any country
>>SHOULD not impact the specification
How about:
""3. Gov and legislative policies from any country SHALL NOT be
considered nor shall they be caused to impact the specifications""
I think this what you intend!
5.
>>Charter - 5. certificate and message format
Could we work towards unifying the different secure mail messsage
formats floating around and making this the unified format
Cheers
David Gaon