06.01.2013 Views

Unmanned Aircraft Systems Roadmap 2005-2030 - Federation of ...

Unmanned Aircraft Systems Roadmap 2005-2030 - Federation of ...

Unmanned Aircraft Systems Roadmap 2005-2030 - Federation of ...

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

UAS ROADMAP <strong>2005</strong><br />

� SDN.706, X.509 Certificate and Certificate Revocation List Pr<strong>of</strong>iles and Certification Path<br />

+Processing Rules, Revision D, 12 May 1999. [SUNSET] This standard will be deleted when GES<br />

can provide secure messaging confirmation, to include authentication, delivery and encryption.<br />

� SDN.801, Access Control Concept and Mechanisms, Revision C, 12 May 1999. [SUNSET] This<br />

standard will be deleted when GES can provide secure messaging confirmation, to include<br />

authentication, delivery and encryption.<br />

The secure/multipurpose internet mail extensions (S/MIME) v3 protocol suite provides application layer<br />

privacy, integrity, and non-repudiation (pro<strong>of</strong> <strong>of</strong> origin) security services for messaging (e-mail). Three<br />

internet engineering task force (IETF) RFCs—RFC 2630, RFC 2632, and RFC 2633—provide the core<br />

security services listed above. For individual messages that use certificates issued by the DoD public-key<br />

infrastructure (PKI) to protect unclassified, sensitive information or sensitive information on system high<br />

networks the following standards are mandated:<br />

� IETF RFC 2630, Cryptographic Message Syntax, June 1999. [SUNSET] This standard will be deleted<br />

when new standards are selected as part <strong>of</strong> the development <strong>of</strong> the IA component <strong>of</strong> the GIG<br />

architecture.<br />

� IETF RFC 2632, S/MIME Version 3 Certificate Handling, June 1999.<br />

� IETF RFC 2633, S/MIME Version 3 Message Specification, June 1999.<br />

IETF RFC 2634 provides optional enhanced security services, which are signed receipts (nonrepudiation—pro<strong>of</strong><br />

<strong>of</strong> receipt), security labels, secure mailing lists, and signing certificates. For enhanced<br />

security services, the following standard is mandated:<br />

� IETF RFC 2634, Enhanced Security Services for S/MIME, June 1999.<br />

Cryptographic Security Services<br />

To support interoperability using encrypted messages, products must share a common communications<br />

protocol. This protocol must include common cryptographic message syntax, common cryptographic<br />

algorithms, and common modes <strong>of</strong> operation (e.g., cipher-block chaining). The mechanisms to provide<br />

the required security services are as follows.<br />

Encryption Algorithms<br />

Encryption algorithms are a set <strong>of</strong> mathematical rules for rendering information unintelligible by affecting<br />

a series <strong>of</strong> transformations to the normal representation <strong>of</strong> the information through the use <strong>of</strong> variable<br />

elements controlled by a key.<br />

The following standard is mandated when the security policy or the program security pr<strong>of</strong>ile requires this<br />

level <strong>of</strong> protection, and Fortezza applications are in use:<br />

� SKIPJACK and KEA Algorithm Specification, Version 2.0, NIST, 29 May 1998. [SUNSET] This<br />

standard will be deleted when AES becomes the mandated standard.<br />

For those systems required or desiring to use a cryptographic device to protect privacy-act information<br />

and other unclassified information not covered by the Warner Amendment to Public Law 100-235, the<br />

following standard is mandated:<br />

� FIPS PUB 46-3, Data Encryption Standard, 25 October 1999. [SUNSET] This standard will be<br />

deleted when AES becomes the mandated standard.<br />

Signature Algorithms<br />

A signature algorithm is an algorithm developed to assure message-source authenticity and integrity. The<br />

intent <strong>of</strong> the signature is to provide a measure <strong>of</strong> assurance that the person signing the message actually<br />

sent the message that is signed, and that the content <strong>of</strong> the message has not been changed. The following<br />

standard is mandated when the security policy or program-security pr<strong>of</strong>ile requires this level <strong>of</strong><br />

protection:<br />

APPENDIX E – INTEROPERABILITY STANDARDS<br />

Page E-13

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!