AS3 Discusion - Section 9 - Security Considerations

["Terry Harding" <tharding@xxxxxxxxxxxxxxxxxxx>]

Open for discussion

9.  Security Considerations

     This entire document is concerned with secure transport of business

     to business data, and considers both privacy and authentication 
     issues.

     Extracted from S/MIME Version 2 Message Specification:  40-bit  
     encryption is considered weak by most cryptographers. Using weak 
     cryptography offers little actual security over sending plaintext. 

     However, other features of S/MIME, such as the specification of 
     tripleDES or AES and the ability to announce stronger cryptographic

     capabilities to parties with whom you communicate, allow senders to

     create messages that use strong encryption. Using weak cryptography

     is never recommended unless the only alternative is no
cryptography. 
     When feasible, sending and receiving agents should inform senders 
     and recipients the relative cryptographic strength of messages.

     Extracted from S/MIME Version 3 Certificate Handling (ref [11]):  

     When processing certificates, there are many situations where the 
     processing might fail. Because the processing may be done by a user

     agent, a security gateway, or other program, there is no single way

     to handle such failures. Just because the methods to handle the 
     failures have not been listed, however, the reader should not
assume 
     that they are not important.  The opposite is true: if a
certificate

Harding, Scott                                                 [Page 25]


INTERNET DRAFT       FTP Transport Data for EDIINT           April 2005

     is not provably valid and associated with the message, the
processing
     software should take immediate and noticeable steps to inform the
end
     user about it. 

     Some of the many places where signature and certificate checking 
     might fail include:
          
          - no certificate chain leads to a trusted CA
          - no ability to check the CRL for a certificate
          - an invalid CRL was received
          - the CRL being checked is expired
          - the certificate is expired
          - the certificate has been revoked
       
     There are certainly other instances where a certificate may be 
     invalid, and it is the responsibility of the processing software to

     check them all thoroughly, and to decide what to do if the check 
     fails.

     The following certificate types MUST be supported.
            With URL
            Without URL
            Self Certified
            Certification Authority Certified

     The complete certification chain MUST be included in all 
     certificates.  All certificate verifications MUST "chain to root". 
     Additionally, the certificate hash should match the hash recomputed

     by the receiver.
 *****************************************************

Terry Harding
Cyclone Commerce Inc.