Multiple Signatures in CMS Russ Housley IETF 66, Montreal, Canada.

Slides:



Advertisements
Similar presentations
Biometric Information Management For Security Phillip H. Griffin Griffin Consulting 1625 Glenwood Avenue Hayes Barton at Five Points Raleigh, North Carolina.
Advertisements

Kommunikationssysteme (KSy) - Block 8
Rfc4474bis-01 IETF 89 (London) STIR WG Jon & Cullen.
Advantages of modular PKI
SIP issues with S/MIME and CMS Rohan Mahy SIP, SIPPING co-chair.
SSL CS772 Fall Secure Socket layer Design Goals: SSLv2) SSL should work well with the main web protocols such as HTTP. Confidentiality is the top.
Some New RSA Mechanisms for PKCS #11 Burt Kaliski, RSA Laboratories PKCS Workshop April 14, 2003.
Overview of draft-ietf-sidr-roa-format-01.txt Matt Lepinski BBN Technologies.
Resource Certificate Profile SIDR WG Meeting IETF 66, July 2006 draft-ietf-sidr-res-certs-01 Geoff Huston Rob Loomans George Michaelson.
Cryptography1 CPSC 3730 Cryptography Chapter 13 Digital Signature Standard (DSS)
Copyright, 1996 © Dale Carnegie & Associates, Inc. Digital Certificates Presented by Sunit Chauhan.
S/MIME v3.2 draft-ietf-smime-3850bis-00.txt draft-ietf-smime-3851bis-00.txt Sean Turner Blake Ramsdell.
Trusted Archive Protocol (TAP) Carl Wallace
CSE 597E Fall 2001 PennState University1 Digital Signature Schemes Presented By: Munaiza Matin.
Diameter End-to-End Security: Keyed Message Digests, Digital Signatures, and Encryption draft-korhonen-dime-e2e-security-00 Jouni Korhonen, Hannes Tschofenig.
Secure Systems Research Group - FAU Patterns for Digital Signature using hashing Presented by Keiko Hashizume.
ITA, , 7-Secure .pptx 1 Internet Security 1 (IntSi1) Prof. Dr. Andreas Steffen Institute for Internet Technologies and Applications (ITA)
Russ Housley IETF Chair Founder, Vigil Security, LLC 8 June 2009 NIST Key Management Workshop Key Management in Internet Security Protocols.
S Security and DICOM Lawrence Tarbox, Ph.D Chair, DICOM WG 14 (Security) Siemens Corporate Research.
Security and DICOM Lawrence Tarbox, Ph.D. Chair, DICOM Working Group 14 Siemens Corporate Research.
Chapter 5 Digital Signatures MSc. NGUYEN CAO DAT Dr. TRAN VAN HOAI 1.
Bob can sign a message using a digital signature generation algorithm
DSA (Digital Signature Algorithm) Tahani Aljehani.
Chapter 10: Authentication Guide to Computer Network Security.
1 Workshop on algorithms and parameters for Electronic Signatures November 25, Brussels.
S/MIME and CMS Presentation for CSE712 By Yi Wen Instructor: Dr. Aidong Zhang.
Trust Anchor Management Problem Statement 69 th IETF Trust Anchor Management BOF Carl Wallace.
XML Signature Prabath Siriwardena Director, Security Architecture.
Security.  is one of the most widely used and regarded network services  currently message contents are not secure may be inspected either.
Certificates and FIPS 201 Tim Polk March 3, 2006.
Chapter 6 Electronic Mail Security MSc. NGUYEN CAO DAT Dr. TRAN VAN HOAI 1.
Exercises Information Security Course Eric Laermans – Tom Dhaene.
X.509 Certificate Support In The .NET Framework
Cryptography and Network Security (CS435) Part Twelve (Electronic Mail Security)
XML Encryption, XML Signature, and Derived Keys: Suggestion For a Minor Addition Magnus Nyström RSA.
Michael Myers VeriSign, Inc.
 A Web service is a method of communication between two electronic devices over World Wide Web.
Lecture 8 Overview. Secure Hash Algorithm (SHA) SHA SHA SHA – SHA-224, SHA-256, SHA-384, SHA-512 SHA-1 A message composed of b bits.
BGPSEC Router Key Roll-over draft-rogaglia-sidr-bgpsec-rollover-00 Roque Gagliano Keyur Patel Brian Weis.
Certificate Requests to HIP Jani Pellikka 80 th IETF Mar 27 th – Apr 1 st 2011 Prague, Czech Republic.
FMS/TR-069 File Download Security Source: QUALCOMM Incorporated Contact(s): Anand Palanigounder Yinian Mao
TNC Proposals for NEA Protocols Presentation by Steve Hanna to NEA WG meeting at IETF 71 March 11, 2008.
Electronic signature Validity Model 1. Shell model Certificate 1 Certificate 2 Certificate 3 Signed document Generate valid signature validCheck invalidCheck.
PKI Future Directions 29 November 2001 Russ Housley RSA Laboratories CS – Class of 1981.
Manifests (and Destiny?) Stephen Kent BBN Technologies.
S/MIME (Secure/Multipurpose Internet Mail Extensions) security enhancement to MIME – original Internet RFC822 was text only – MIME provided.
LTANS WG: ERS November 7, 2005 Tobias Gondrom. LTANS WG (ltans): ERS Draft straightened up Corrected ERS (feedback from Peter and Carl) Prepared for WG.
Overview of draft-ietf-sidr-roa-00.txt Steve Kent BBN Technologies.
Electronic Mail Security Prepared by Dr. Lamiaa Elshenawy
CCSDS Security/DTN Status 11/6/2015 DENNIS IANNICCA CCSDS GRC CHARLES SHEEHE CCSDS GRC POC 1.
Digital Signature Standard (DSS) US Govt approved signature scheme designed by NIST & NSA in early 90's published as FIPS-186 in 1991 revised in 1993,
Lecture 11 Overview. Digital Signature Properties CS 450/650 Lecture 11: Digital Signatures 2 Unforgeable: Only the signer can produce his/her signature.
Network Security Celia Li Computer Science and Engineering York University.
Security SMIME IT352 | Network Security |Najwa AlGhamdi 1.
ECC Design Team: Initial Report Brian Minard, Tolga Acar, Tim Polk November 8, 2006.
Domain Security Services Using S/MIME draft-ietf-smime-domsec-04.txt William Ottaway DERA Malvern,UK IETF 47 Adelaide, Australia.
RSA Data Security, Inc. PKCS #13: Elliptic Curve Cryptography Standard Burt Kaliski RSA Laboratories PKCS Workshop October 7, 1998.
S/MIME Capabilities Certificate Extension Stefan Santesson Microsoft.
IGTF Risk Assessment Team 5/11/091.
Lecture 8 (Chapter 18) Electronic Mail Security Prepared by Dr. Lamiaa M. Elshenawy 1.
Lab#7 Digital signature Cpit 425
Trust Anchor Management Problem Statement
S/MIME T ANANDHAN.
LTANS WG: ERS Status July 10, 2006 Tobias Gondrom.
(free certificate not available)
ELECTRONIC MAIL SECURITY
ELECTRONIC MAIL SECURITY
Digital Signatures…!.
Lecture 6: Digital Signature
Resource Certificate Profile SIDR WG Meeting IETF 66, July 2006
Presentation transcript:

Multiple Signatures in CMS Russ Housley IETF 66, Montreal, Canada

Goal Change the processing in CMS to ensure that it accommodates transition from one signature algorithm to another one S/MIME Mechanism: the originator generates two signatures (one with the old algorithm and one with the new algorithm), and the recipient considers the message valid if either one of the signatures validates

ASN.1 Syntax Reminder (1 of 2) SignedData ::= SEQUENCE { version CMSVersion, digestAlgorithms DigestAlgorithmIdentifiers, encapContentInfo EncapsulatedContentInfo, certificates [0] IMPLICIT CertificateSet OPTIONAL, crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, signerInfos SignerInfos } SignerInfos ::= SET OF SignerInfo

ASN.1 Syntax Reminder (2 of 2) SignerInfo ::= SEQUENCE { version CMSVersion, sid SignerIdentifier, digestAlgorithm DigestAlgorithmIdentifier, signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, signatureAlgorithm SignatureAlgorithmIdentifier, signature SignatureValue, unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } SignerIdentifier ::= CHOICE { issuerAndSerialNumber IssuerAndSerialNumber, subjectKeyIdentifier [0] SubjectKeyIdentifier }

One Signature Fred: RSA with SHA-1

Two Signatures Fred: RSA with SHA-256 Fred: RSA with SHA-1

Four Signatures Gary: RSA with SHA-256 Gary: ECDSA with SHA-256 Fred: RSA with SHA-256 Fred: RSA with SHA-1

Five Signatures Irene: RSA with SHA-256 Harry: RSA with SHA-1 Gary: ECDSA with SHA-256 Fred: RSA with SHA-256 Earl: DSA with SHA-1

draft-ietf-smime-cms-mult-sign-00 The text in the current draft is not quite right. It says: When more than one signature is present, the successful validation of any one of these signatures ought to be treated as a successful validation of the signed-data content type. The primary reason is that signers may include separate signatures for different communities of recipients. For example, the signed-data content type might include signatures generated with the RSA signature algorithm and with the ECDSA signature algorithm. This allows recipients to verify one algorithm or the other.

Proposed Way Forward Proposed replacement text: When more than one signature is present, the successful validation of one of signature associated with each signer ought to be treated as a successful validation of the signed-data content type. However, there are some application environments where all of the included signatures must be valid. Support of different communities of recipients is the primary reason that signers choose to include more than one signature. For example, the signed-data content type might include signatures generated with the RSA signature algorithm and with the ECDSA signature algorithm. This allows recipients to verify one algorithm or the other.

Discussion! Questions?