DOCSLIB.ORG

Treasury X.509 Certificate Policy [TREASURYCP].” It Only Addresses Where an OLT PKI’S Requirements Differ from the Requirements for Basic Assurance in [TREASURYCP]

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

UNCLASSIFIED

UNITED STATES
DEPARTMENT OF THE
TREASURY

DEPARTMENT OF THE TREASURY
PUBLIC KEY INFRASTRUCTURE (PKI) X.509 CERTIFICATE POLICY
VERSION 3.4 April 27, 2021

Digitally signed by Daniel W. Wood

Daniel W. Wood

Date: 2021.04.27 10:48:30 -04'00'

PKI Policy Management Authority (PMA) DANIEL W. WOOD
DATE

1

UNCLASSIFIED

DOCUMENT VERSION CONTROL
Version

2.0

  • Date
  • Author(s)
  • Description
  • Reason For Change

Bring the Treasury PKI Policy into compliance with FPKIPA change proposal requiring all cross certified PKI Policies to be in RFC 3647 format.
Department of the Treasury PKI Policy in
RFC

  • January 2008
  • James Schminky

3647 format.

As a result of mapping the Treasury
PKI Policy to Federal Policy, a number of minor changes and omissions where identified and corrected.
Errata changes to sections
2.2.1,
2.1

2.2
March 17, 2009 March 11, 2010
James Schminky James Schminky
4.8, 4.912, 5.5, and
7.1.3.

As a result of the PMA annual review a number of minor
Errata changes to sections
5.6, and 6.3.2. Change proposal changes to 2.4, 4.2.2, 5.1, 5.1.1 5.1.2.1, 5.4.4, 5.4.5, 6.1.6, 6.5.1, and 6.7. corrections, Federal Bridge Certification Authority (FBCA) Policy Change Proposal Number:
2009-02 and 2010-01, and Treasury
Change Proposal

Change proposal changes As a result of FBCA Policy Change
2.3

2.4
April 15, 2010 March 22, 2011
James Schminky James Schminky

  • to 8.1 and 8.4.
  • Proposal Number: 2010-02.

Changes Proposal Changes to 1.3.1.8,
3.1.1&.2, 3.1.5, 3.2.3.1, 4.7, 6.1.5, 8.1, and 9.4.3.
As a result of FBCA Policy Change Proposal Numbers; 2010-3 thru 8 and CPCA policy Change Proposal
Number: 2011-1

Made changes to align the
Treasury CP with the Common Policy Framework (CPF), removed

allreference to the acronym “DoT”

and replaced with the name

“Treasury”.

Changes Proposal
Changes to 3.2.3.2 and
4.9.7

  • 2.5
  • September 11,2012
  • Daniel Wood

Daniel Wood
Changes Proposal
Changes to
1.2, 3.2.3.2, 6.1.5,
6.2.3,
Made changes to align the Treasury CP with the CPF,
2.6 2.7 2.8
October 15, 2012 August 22, 2013 March 26, 2015
6.2.4.2, and 6.2.8.

1.3, 1.3.1, 1.3.1.1, 1.3.1.2,
1.3.1.3, 1.3.1.4, 1.3.1.5,

1.5.2, and 3.2.3.2.
Fred Asomani-
Atinkah
Made changes to align the Treasury CP with the CPF,

Clarified Treasury’s dual

  • role as Federal Legacy and
  • Provide capabilities to customers

SSP; Added PIV-I, role- and baseline update as requested by
Daniel Wood, Terry McBride based, and group

certificates
FPKIPA

2

UNCLASSIFIED

Adds PIV-I, andInternal
PKI OIDs, changed criteria for suspension, defined the PKIProgram Team, added theinternal PKI addendum, changes to Common/FederalCPs and editorial updates
Changes to Treasury PKI based on user needs

  • 2.9
  • March 25, 2017
  • Daniel Wood

Update based on TOCA Compliance Audit and introduction of the Fed Key Recovery Policyand other Common and Federal Bridge policy changes
Correct minorerrors and maintain compliance withFed PKI (through

  • 2.91
  • November 20, 2018
  • Daniel Wood

2018-

06)

Updated based on Comments from BFS
Maintain conformance with FBCA
CP

3

February 28, 2019 October 30, 1,2019
Daniel Wood Daniel Wood
Updated Section 5.8with new language to cover CA terminations
Maintain conformance with

Federal/Common CPs

3.1
Updates in sections:
1, 1.1.1, 1.2, 1.4.1, 2.2.1,
4.4.2, 5.2.1, 5.2.1.1,
5.2.1.2, 5.3.1, 5.3.2, 5.3.7, roles from clearance requirements
5.4.2, 5.5.1, and 6.1.5
Responses to audit findings, annual review findings, change proposals,

  • and for separation of Key Recovery
  • 3.2

3.3

  • December 15, 2020
  • Daniel Wood

Daniel Wood on CA roles

Removed the “offline”

requirement on OLT Root CAs in section 1.3.1.2 of
Addendum 1.
Added Addendum 2 – Implementation of PKI Certificates on Treasury
Systems
To allow for remote administration on an OLT Root CA, and to define implementation policies on
March 29, 2021
SSL/TLS certificates for HTTPS

3

UNCLASSIFIED

Table of Contents

1. INTRODUCTION...........................................................................................................................................................11

1.1

OVERVIEW................................................................................................................................................................................12

1.1.1 Certificate Policy...............................................................................................................................................................................12 1.1.2 Relationships between Treasury PKI CP & Treasury PKI CA CPSs.....................................................................................................12 1.1.3 Scope ................................................................................................................................................................................................12 1.1.4 Relationships between Treasury PKI CP, the FBCA and Other Entity CPs ........................................................................................13 1.1.5 Interaction with PKIs External to the Federal Government .............................................................................................................14

1.2 DOCUMENT IDENTIFICATION ..........................................................................................................................................................14 1.3 PKI ENTITIES....................................................................................................................................................................................15

1.3.1 Treasury PKI Program Team .............................................................................................................................................................15 1.3.2 Registration Authority ......................................................................................................................................................................18

1.3.3 Subscribers.......................................................................................................................................................................................19

1.3.4 Relying Parties ..................................................................................................................................................................................19 1.3.5 Other Participants ............................................................................................................................................................................20

1.4 CERTIFICATE USAGE ........................................................................................................................................................................20

1.4.1 Appropriate Certificate Uses ............................................................................................................................................................20 1.4.2 Prohibited Certificate Uses...............................................................................................................................................................22

1.5 POLICY ADMINISTRATION ...............................................................................................................................................................22

1.5.1 Organization administering the document ......................................................................................................................................22 1.5.2 Contact Person .................................................................................................................................................................................22 1.5.3 Person Determining CPS Suitability for the Policy............................................................................................................................23 1.5.4 CPS Approval Procedures .................................................................................................................................................................23

1.6 DEFINITIONS AND ACRONYMS........................................................................................................................................................23

2. PUBLICATION & REPOSITORY RESPONSIBILITIES .........................................................................................24

2.1 REPOSITORIES .................................................................................................................................................................................24 2.2 PUBLICATION OF CERTIFICATION INFORMATION ............................................................................................................................24

2.2.1 Publication of certificates and Certificate Status .............................................................................................................................24 2.2.2 Publication of CA Information ..........................................................................................................................................................25 2.2.3 Interoperability.................................................................................................................................................................................25

2.3 FREQUENCY OF PUBLICATION .........................................................................................................................................................25 2.4 ACCESS CONTROLS ON REPOSITORIES.............................................................................................................................................25

3. IDENTIFICATION & AUTHENTICATION...............................................................................................................26

3.1 NAMING..........................................................................................................................................................................................26

3.1.1 Types of Names ................................................................................................................................................................................26 3.1.2 Need for Names to Be Meaningful...................................................................................................................................................30 3.1.3 Anonymity or Pseudonymity of Subscribers ....................................................................................................................................30 3.1.4 Rules for Interpreting Various Name Forms.....................................................................................................................................31

4

UNCLASSIFIED

3.1.5 Uniqueness of Names.......................................................................................................................................................................31 3.1.6 Recognition, Authentication, & Role of Trademarks........................................................................................................................31

3.2 INITIAL IDENTITY VALIDATION ........................................................................................................................................................31

3.2.1 Method to Prove Possession of Private Key.....................................................................................................................................32 3.2.2 Authentication of Organization Identity ..........................................................................................................................................32 3.2.3 Authentication of Individual Identity ...............................................................................................................................................33 3.2.4 Non-verified Subscriber Information ...............................................................................................................................................37 3.2.5 Validation of Authority.....................................................................................................................................................................38 3.2.6 Criteria for Interoperation................................................................................................................................................................38

3.3 IDENTIFICATION AND AUTHENTICATION FOR RE-KEY REQUESTS ....................................................................................................38

3.3.1 Identification and Authentication for Routine Re-key .....................................................................................................................38 3.3.2 Identification and Authentication for Re-key after Revocation .......................................................................................................40

3.4 IDENTIFICATION AND AUTHENTICATION FOR REVOCATION REQUEST ............................................................................................40

4. CERTIFICATE LIFE-CYCLE ........................................................................................................................................41

4.1 APPLICATION ..................................................................................................................................................................................41

4.1.1 Submission of Certificate Application ..............................................................................................................................................41 4.1.2 Enrollment Process and Responsibilities..........................................................................................................................................41

4.2 CERTIFICATE APPLICATION PROCESSING .........................................................................................................................................41

4.2.1 Performing Identification and Authentication Functions.................................................................................................................41 4.2.2 Approval or Rejection of Certificate Applications ............................................................................................................................42 4.2.3 Time to Process Certificate Applications..........................................................................................................................................42

4.3 ISSUANCE........................................................................................................................................................................................43

4.3.1 CA Actions during Certificate Issuance.............................................................................................................................................43 4.3.2 Notification to Subscriber of Certificate Issuance............................................................................................................................43

4.4 ACCEPTANCE...................................................................................................................................................................................43

4.4.1 Conduct constituting certificate acceptance....................................................................................................................................43 4.4.2 Publication of the Certificate by the CA ...........................................................................................................................................43 4.4.3 Notification of Certificate Issuance by the CA to other entities.......................................................................................................43

4.5 KEY PAIR AND CERTIFICATE USAGE .................................................................................................................................................44

4.5.1 Subscriber Private Key and Certificate Usage ..................................................................................................................................44 4.5.2 Relying Party Public key and Certificate Usage ................................................................................................................................44

4.6 CERTIFICATE RENEWAL....................................................................................................................................................................44

4.6.1 Circumstance for Certificate Renewal ..............................................................................................................................................44 4.6.2 Who may Request Renewal .............................................................................................................................................................45 4.6.3 Processing Certificate Renewal Requests.........................................................................................................................................45 4.6.4 Notification of new certificate issuance to Subscriber.....................................................................................................................45 4.6.5 Conduct constituting acceptance of a Renewal certificate ..............................................................................................................45 4.6.6 Publication of the Renewal certificate by the CA.............................................................................................................................45 4.6.7 Notification of Certificate Issuance by the CA to other entities.......................................................................................................45

4.7 CERTIFICATE RE-KEY ........................................................................................................................................................................45

4.7.1 Circumstance for Certificate Re-key.................................................................................................................................................46 4.7.2 Who may request certification of a new public key.........................................................................................................................46 4.7.3 Processing certificate Re-keying requests........................................................................................................................................46

5

UNCLASSIFIED

4.7.4 Notification of new certificate issuance to Subscriber.....................................................................................................................46 4.7.5 Conduct constituting acceptance of a Re-keyed certificate.............................................................................................................46 4.7.6 Publication of the Re-keyed certificate by the CA............................................................................................................................46 4.7.7 Notification of certificate issuance by the CA to other Entities .......................................................................................................46

4.8 MODIFICATION ...............................................................................................................................................................................47

4.8.1 Circumstance for Certificate Modification .......................................................................................................................................47 4.8.2 Who may request Certificate Modification......................................................................................................................................47 4.8.3 Processing Certificate Modification Requests..................................................................................................................................47 4.8.4 Notification of new certificate issuance to Subscriber.....................................................................................................................48 4.8.5 Conduct constituting acceptance of modified certificate ................................................................................................................48 4.8.6 Publication of the modified certificate by the CA ............................................................................................................................48 4.8.7 Notification of certificate issuance by the CA to other Entities .......................................................................................................48

Recommended publications
  • Using Frankencerts for Automated Adversarial Testing of Certificate

    Using Frankencerts for Automated Adversarial Testing of Certificate

    Using Frankencerts for Automated Adversarial Testing of Certificate Validation in SSL/TLS Implementations Chad Brubaker ∗ y Suman Janay Baishakhi Rayz Sarfraz Khurshidy Vitaly Shmatikovy ∗Google yThe University of Texas at Austin zUniversity of California, Davis Abstract—Modern network security rests on the Secure Sock- many open-source implementations of SSL/TLS are available ets Layer (SSL) and Transport Layer Security (TLS) protocols. for developers who need to incorporate SSL/TLS into their Distributed systems, mobile and desktop applications, embedded software: OpenSSL, NSS, GnuTLS, CyaSSL, PolarSSL, Ma- devices, and all of secure Web rely on SSL/TLS for protection trixSSL, cryptlib, and several others. Several Web browsers against network attacks. This protection critically depends on include their own, proprietary implementations. whether SSL/TLS clients correctly validate X.509 certificates presented by servers during the SSL/TLS handshake protocol. In this paper, we focus on server authentication, which We design, implement, and apply the first methodology for is the only protection against man-in-the-middle and other large-scale testing of certificate validation logic in SSL/TLS server impersonation attacks, and thus essential for HTTPS implementations. Our first ingredient is “frankencerts,” synthetic and virtually any other application of SSL/TLS. Server authen- certificates that are randomly mutated from parts of real cer- tication in SSL/TLS depends entirely on a single step in the tificates and thus include unusual combinations of extensions handshake protocol. As part of its “Server Hello” message, and constraints. Our second ingredient is differential testing: if the server presents an X.509 certificate with its public key.
  • Implementing PKI Services on Z/OS

    Implementing PKI Services on Z/OS

    Front cover Implementing PKI Services on z/OS Installation of PKI and all of its prerequistes on z/OS An example of the PKI Exit PKI’s use of ICSF to store Master Key Chris Rayns Theo Antoff Jack Jones Patrick Kappeler Vicente Ranieri Roland Trauner ibm.com/redbooks International Technical Support Organization Implementing PKI Services on z/OS February 2004 SG24-6968-00 Note: Before using this information and the product it supports, read the information in “Notices” on page vii. First Edition (February 2004) This edition applies to z/OS Version 1, Release 3. © Copyright International Business Machines Corporation 2004. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Notices . vii Trademarks . viii Preface . ix The team that wrote this redbook. ix Become a published author . x Comments welcome. xi Chapter 1. Security Server PKI Services. 1 1.1 Overview of digital certificate. 2 1.2 The PKIX standards . 4 1.2.1 CA hierarchy . 6 1.2.2 The X.509 certificate and Certificate Revocation List . 9 1.2.3 The x.509 v3 certificate extension fields . 14 1.2.4 Certificate and CRL appearance. 17 1.3 The z/OS PKI Services . 21 1.3.1 Security Server PKI Services in z/OS . 21 1.3.2 Prerequisite products . 22 1.3.3 Requests supported by z/OS PKI Services. 23 1.3.4 Browser and server certificates. 24 1.3.5 The z/OS PKI Services architecture . 26 1.4 Security Server PKI Services enhancement in z/OS V1R4.
  • Amazon Trust Services Certificate Policy

    Amazon Trust Services Certificate Policy

    Certificate Policy Version 1.0.9 1 1 INTRODUCTION ................................................................................................................................................... 13 1.1 Overview ...................................................................................................................................................... 13 1.1.1 Compliance ............................................................................................................................................ 13 1.1.2 Types of Certificates .............................................................................................................................. 13 1.1.2.1 CA-Certificates .............................................................................................................................. 13 1.1.2.1.1 Missing Heading ........................................................................................................................ 14 1.1.2.1.2 Missing Heading ........................................................................................................................ 14 1.1.2.1.3 Terminus CA-Certificates .......................................................................................................... 14 1.1.2.1.4 Policy CA-Certificates ................................................................................................................ 14 1.1.2.1.5 Technically Constrained CA-Certificates ..................................................................................
  • How to Build an X.509 PKI That Works

    How to Build an X.509 PKI That Works

    How to build a PKI that works Peter Gutmann University of Auckland How to build an X.509 PKI that works Peter Gutmann University of Auckland Preliminaries Whose PKI are we talking about here? •Not SSL certs –Certificate manufacturing, not PKI It’s just an expensive way of doing authenticated DNS lookups with a TTL of one year. Plenty of PK, precious little I — Peter Gutmann on the crypto list •Not PGP, SPKI, *ML, etc –Doing fairly well in their (low-I) area •Not government PKI initiatives –Government IT project reality distortion field, keep pumping in money until it cries Uncle –Even then, the reality distortion has failed in parts of Europe, Australia Preliminaries (ctd) This is PKI for the rest of us •Businesses, individuals, etc Talk covers exclusively technical issues •Policies are someone else’s problem Ted says that whenever he gets asked a religious question he doesn’t understand he always responds with “Ah, that must be an ecumenical matter” which universally produces nods of admiration at the profound wisdom of the statement. It seems that that the PKIX list equivalent is “Ah, that must be a policy matter” — Father Ted (via Anon) •Some religion may sneak in Preliminaries (ctd) Microsoft bashing: An apology in advance •Their PKI software is the most widespread, and features prominently in examples because of this •There is no indication that other software is any better, it just gets less publicity It may be a little controversial… 56th IETF agenda item, submitted as a joke when someone pointed out that PKIX didn’t have any agenda What needs to be done to make PKI work? This forum will be open to all PKIX members, and will constitute a large pool filled knee-deep with custard.
  • Security Policies for the Federal Public Key Infrastructure

    Security Policies for the Federal Public Key Infrastructure

    Security Policies for the Federal Public Key Infrastructure Noel A. Nazario Security Technology Group National Institute of Standards and Technology Abstract This document discusses provisions for the handling of security policies in the proposed Federal Public Key Infrastructure (PKI). Federal PKI policies deal with the generation, deactivation, and dissemination of public key certificates, the integrity of the infrastructure, maintenance of records, identification of certificate holders, and the establishment of trust relationships between Certification Authorities (CAs). The verification of a digital signature is not sufficient indication of the trustworthiness of an electronic message or data file. The verifier needs to factor the trustworthiness of the CAs involved in the certification of the sender. To accomplish this, the verifier needs to examine the certificate policy for those CAs. The Federal PKI Technical Security Policy establishes guidelines for the operation of Federal CAs and the identification of the parties requesting certification. It also defines Policy Approving Authorities (PAA) responsible for assessing the policies and operational practices of all Federal CAs within a domain and assigning them corresponding Federal Assurance Levels. These assurance levels may be used in lieu of a certificate policy when making an on-line determination of the trustworthiness of a certificate. Key words Certificate policy, Federal Assurance Levels, PAA, PKI, Policy Approving Authority, public key infrastructure, security policy. SECURITY POLICIES FOR THE FEDERAL PUBLIC KEY INFRASTRUCTURE Noel A. Nazario NIST North, Room 426 820 West Diamond Avenue Gaithersburg, MD 20899 [email protected] Introduction and Background This paper discusses provisions for the handling of security policies in the proposed Federal Public Key Infrastructure (PKI).
  • Certificate Policy of the Public Key Infrastructure in The

    Certificate Policy of the Public Key Infrastructure in The

    Certificate Policy of the Public Key Infrastructure in the Deutsche Forschungsnetz - Grid - DFN-Verein Grid-CP V1.4, May 2008 This document and all parts thereof are copyrighted. Distribution or reproduction of the document in unchanged form is explicitly allowed. No transfer of this document, either in whole or in part, into modifiable electronic formats is al- lowed without permission of the DFN-Verein. Contact: [email protected] © DFN-Verein 2008 DFN-Verein - 2 - Grid-CP V1.4 CONTENTS 1 INTRODUCTION.......................................................................................................5 1.1 Overview..........................................................................................................5 1.2 Document name and identification ......................................................................5 1.3 PKI participants ................................................................................................6 1.4 Certificate usage................................................................................................7 1.5 Policy administration .........................................................................................7 1.6 Definitions and acronyms....................................................................................7 2 PUBLICATION AND REPOSITORY RESPONSIBILITIES...................................................7 2.1 Repositories......................................................................................................7 2.2 Publication of certification information..................................................................7
  • The BEAST Wins Again: Why TLS Keeps Failing to Protect HTTP Antoine Delignat-Lavaud, Inria Paris Joint Work with K

    The BEAST Wins Again: Why TLS Keeps Failing to Protect HTTP Antoine Delignat-Lavaud, Inria Paris Joint Work with K

    The BEAST Wins Again: Why TLS Keeps Failing to Protect HTTP Antoine Delignat-Lavaud, Inria Paris Joint work with K. Bhargavan, C. Fournet, A. Pionti, P.-Y. Strub INTRODUCTION Introduction Cookie Cutter Virtual Host Confusion Crossing Origin Boundaries Shared Session Cache Shared Reverse Proxies SPDY Connection Pooling Triple Handshake Conclusion Why do we need TLS? 1. Authentication – Must be talking to the right guy 2. Integrity – Our messages cannot be tampered 3. Confidentiality – Messages are only legible to participants 4. Privacy? – Can’t tell who we are and what we talk about Why do we need TLS? 1. Authentication – Must be talking to the right guy Active Attacks 2. Integrity (MitM) – Our messages cannot be tampered 3. Confidentiality – Messages are only legible to participants Passive Attacks 4. Privacy? (Wiretapping) – Can’t tell who we are and what we talk about What websites expect of TLS • Web attacker – Controls malicious websites – User visits honest and malicious sites in parallel – Web/MitB attacks: CSRF, XSS, Redirection… • Network attacker – Captures (passive) and tampers (active) packets What websites expect of TLS • Web attacker – Controls malicious websites – User visits honest and malicious sites in parallel – Web/MitB attacks: CSRF, XSS, Redirection… • Network attacker Strictly stronger – Captures (passive) and tampers (active) packets What websites expect of TLS If a website W served over HTTP is secure against a Web attacker, then serving W over HTTPS makes it secure against a network attacker. What websites expect of TLS If a website W served over HTTP is secure against a Web attacker, then serving W over HTTPS makes it secure against a network attacker.
  • RSA Certificate Manager Version 6.7 Security Target

    RSA Certificate Manager Version 6.7 Security Target

    RSA Certificate Manager Version 6.7 Security Target RSA Security Inc. 174 Middlesex Turnpike Bedford, MA 01730 USA Tel: 877-RSA-4900 Fax: 781-515-5010 E-mail: [email protected] Web: http://www.rsasecurity.com Document ID: ASE Issue Number: 1.7 Date: December 7, 2006 © RSA Security, Inc., 2006 RSA Certificate Manager Version 6.7 Security Target Revisions to Document Date Ver. Author Changes Made Aug. 18 2006 1.0 MJM Update to RCM v6.7 Aug. 24, 2006 1.1 TC Updated by SAIC for CCv2.3 changes Oct. 15, 2006 1.2 MJM Error corrections and updates Oct. 22, 2006 1.4 MJM Corrections per RSA ETR ASE – Revised (SAIC): • Changed cover page, updated year of pub. to 2006 • Section 1.1 corrected TOE identification • Section 1.1 corrected conformance “Part 3 augmented” • Many changes to SFR conventions • Section 5.1 backed out “based on the auditable event…” from FAU_GEN.1.2 (not a CCv2.3 change) • Section 5.1 fixed PP operation convention in FAU_SAR.1 • Section 5.1 backed out “no other actions” change from FAU_STG.4.1 (not a CCv2.3 change) • Section 5.2 added dependency to FMT_MOF.1.1, FMT_MSA.1.1, FMT_MTD.1.1 • Section 5.4 added FIA_USB.1.2 and FIA_USB.1.3 • Section 5.6 added AES/FIPS197 to FCS_CKM.1.1 • Section 5.6 added dependency to FCS_CKM.4.1 • Section 5.8 added algorithms, keylengths and dependency to FCS_COP.1.1 • Section 6.1 backed out “based on the auditable event…” from FAU_GEN.1.2 (not a CCv2.3 change) • Section 6.1 backed out “no other actions” change from FAU_STG.4.1 (not a CCv2.3 change) • Section 6.2 added dependency to FMT_MOF.1.1 • Section 6.5 removed reference to OCSP from assignment in FIA_UAU.1.1 and FIA_UID.1.1 • Section 6.5 added FIA_USB.1.2 and FIA_USB.1.3 • Section 6.6 reversed change in FDP_ITT.1.1 • Section 6.10 added note re.
  • The Most Dangerous Code in the World: Validating SSL Certificates In

    The Most Dangerous Code in the World: Validating SSL Certificates In

    The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software Martin Georgiev Subodh Iyengar Suman Jana The University of Texas Stanford University The University of Texas at Austin at Austin Rishita Anubhai Dan Boneh Vitaly Shmatikov Stanford University Stanford University The University of Texas at Austin ABSTRACT cations. The main purpose of SSL is to provide end-to-end security SSL (Secure Sockets Layer) is the de facto standard for secure In- against an active, man-in-the-middle attacker. Even if the network ternet communications. Security of SSL connections against an is completely compromised—DNS is poisoned, access points and active network attacker depends on correctly validating public-key routers are controlled by the adversary, etc.—SSL is intended to certificates presented when the connection is established. guarantee confidentiality, authenticity, and integrity for communi- We demonstrate that SSL certificate validation is completely bro- cations between the client and the server. Authenticating the server is a critical part of SSL connection es- ken in many security-critical applications and libraries. Vulnerable 1 software includes Amazon’s EC2 Java library and all cloud clients tablishment. This authentication takes place during the SSL hand- based on it; Amazon’s and PayPal’s merchant SDKs responsible shake, when the server presents its public-key certificate. In order for transmitting payment details from e-commerce sites to payment for the SSL connection to be secure, the client must carefully verify gateways; integrated shopping carts such as osCommerce, ZenCart, that the certificate has been issued by a valid certificate authority, Ubercart, and PrestaShop; AdMob code used by mobile websites; has not expired (or been revoked), the name(s) listed in the certifi- Chase mobile banking and several other Android apps and libraries; cate match(es) the name of the domain that the client is connecting Java Web-services middleware—including Apache Axis, Axis 2, to, and perform several other checks [14, 15].
  • A Pki Architecture Using Open Source Software for E- Government Services in Romania

    A Pki Architecture Using Open Source Software for E- Government Services in Romania

    Nicusor Vatra et al./ Indian Journal of Computer Science and Engineering (IJCSE) A PKI ARCHITECTURE USING OPEN SOURCE SOFTWARE FOR E- GOVERNMENT SERVICES IN ROMANIA NICUȘOR VATRA The Doctoral School Department, The Bucharest Academy of Economic Studies, 6, Romana Square, district 1 Bucharest, 010374, Romania [email protected] http://doctorat.ase.ro Abstract This article presents an architecture based on Open Source software that promote citizen’s access to electronic services in a secure way and attempt to make an analysis between two different Open Source Public Key Infrastructure software: OpenCA PKI and EJBCA. The architecture represents a suitable solution for a large enterprise or public administration that enables security and easy management of electronic documents in e-Government Services area. Keywords: - public key infrastructure, e-Government Services, Open Source, encryption, electronic signature. 1. Introduction The recent technological developments such as extension of modern communication and particularly the Internet boom have made the electronic world to create brand new opportunities for realizing transactions on the Internet. Due to ease to use, flexibility but also lack of explicit rules and restrictions, the Internet has become the most popular platform and the most important communication channel for the electronic transactions. One of the major characteristics of any electronic transactions performed on the Internet is trust. On the Internet, where there is no direct contact between parties and millions of users exchange information daily is necessary to take security measures to validate our collaborators, customers and suppliers prior to the exchange information’s, goods and services or make payments. Public Key Infrastructure (PKI) provides the needed trust using Trusted Third Parties (TTPs) known as Certification Authorities (CAs) [1].
  • ATIS-1000080.V003, Signature-Based Handling of Asserted Information Using Tokens (SHAKEN): Governance Model and Certificate Management

    ATIS-1000080.V003, Signature-Based Handling of Asserted Information Using Tokens (SHAKEN): Governance Model and Certificate Management

    ATIS-1000080.v003 Signature-based Handling of Asserted information using toKENs (SHAKEN): Governance Model and Certificate Management JOINT STANDARD As a leading technology and solutions development organization, the Alliance for Telecommunications Industry Solutions (ATIS) brings together the top global ICT companies to advance the industry’s most pressing business priorities. ATIS’ nearly 200 member companies are currently working to address the All-IP transition, 5G, network functions virtualization, big data analytics, cloud services, device solutions, emergency services, M2M, cyber security, network evolution, quality of service, billing support, operations, and much more. These priorities follow a fast-track development lifecycle — from design and innovation through standards, specifications, requirements, business use cases, software toolkits, open source solutions, and interoperability testing. ATIS is accredited by the American National Standards Institute (ANSI). The organization is the North American Organizational Partner for the 3rd Generation Partnership Project (3GPP), a founding Partner of the oneM2M global initiative, a member of the International Telecommunication Union (ITU), as well as a member of the Inter-American Telecommunication Commission (CITEL). For more information, visit www.atis.org. The SIP Forum is a leading IP communications industry association that engages in numerous activities that promote and advance SIP-based technology, such as the development of industry recommendations; interoperability testing
  • White Paper Certificate and Trust Management Requirements for Certificates and Trust Relationships

    White Paper Certificate and Trust Management Requirements for Certificates and Trust Relationships

    White Paper Certificate and Trust Management Requirements for certificates and trust relationships Version: 1.0 Last revised: 2010-11-12 Classification: öffentlich/public E – M A I L S E C U R I T Y - CERTIFIC ATE AND TRUST MANAGEMENT Table of contents Introduction ............................................................................................................................. 4 Initial context ............................................................................................................................. 4 General principles of the document ............................................................................... 5 Roles and responsibilities in secure e-mail communication ............................................ 6 Sender’s side ............................................................................................................................ 7 Sender .................................................................................................................. 7 E-mail infrastructure manager ................................................................................. 7 Recipient’s side ......................................................................................................................... 8 E-mail infrastructure manager ................................................................................. 8 Addressee ............................................................................................................ 8 Trust management ..................................................................................................................