ASN.1:
Introduction
Zdeněk Říha
ASN.1
 Abstract Syntax Notation 1
 notation for describing abstract types and
values
 Defined in ITU-T X.680 … X.695
 Used in many file formats, including crypto
 Public keys, private keys
 Certificate requests, certificates
 Digital signatures, padding, encrypted files
ASN.1
 Allows format/storage/transmission of data
 Compatible among many applications
 Not dependent on HW platform
 E.g. little/big endian
 Not dependent on operating system
 Simple & Structured types
 Multiple encoding rules (methods)
ASN.1 – Types
ASN.1 – simple types
 Integer
 signed integer (there’s no unsigned integer)
 Bit string
 The number of bits does not have to be a multiple of 8
 Octet string
 an arbitrary string of octets
 NULL
 No data (used in parameters)
 PringtableString, IA5String, UTF8String, …
 Strings – the sets of characters are various
 UTCTime
 Time
ASN.1 – OID type
 Object identifier (OID)
 Sequence of integer components that identify an
object
 Assigned in a hierarchical way
 Example
 sha-1WithRSAEncryption = 1.2.840.113549.1.1.5
 iso(1) member-body(2)
us(840) rsadsi(113549)
pkcs(1) pkcs-1(1) 5
ASN.1 – structured types
 SEQUENCE
 an ordered collection of one or more types
 SEQUENCE OF
 an ordered collection of zero or more occurrences of a
given type
 SET
 an unordered collection of one or more types
 SET OF
 an unordered collection of zero or more occurrences of a
given type
ASN.1 Encoding Rules
 XML – oriented formats
 XER (XML Encoding Rules)
 Byte-oriented formats
 BER (Basic Encoding Rules)
 CER (Canonical Encoding Rules) – subset of BER
 DER (Distinguished Encoding Rules) – subset of BER
 Used for crypto files
 Bit-oriented formats
 PER (Packed Encoding Rules)
 Verbose, human readable formats
 GSER (Generic String Encoding Rules)
BER encoding
 TLV – Tag Length Value
 All the data is encoded using a simple TLV format
 Tag – what kind of data it is
 Length – the length of the data
 Value – the data itself
 Example
 02 01 05 [hexadecimal values]
 Tag – Integer
 Length of data – 1 byte
 Data: (positive integer) 5
Nested data
 SEQUENCE is similar to struct/record
 30 09 02 01 05 04 02 FF FF 05 00
 30 09 – sequence of length 9 bytes
 02 01 05 – integer 5
 04 02 FF FF – octet string FF FF
 05 00 – NULL (no data)
BER tags
 Tag encoding
 Class
 Tag number
 Bits 1-5
 If all bits are 1 then the tag continues in the following byte(s)
class class
Constr
ucted?
Tag
#
BER length
 length >=0 && length <= 127
 The length is coded directly
 E.g. ’05’
 Otherwise the bit 8 is set, bits 1-7 code the
number of bytes that specify the length
 E.g. 255 -> ‘81’ ‘FF’
 E.g. 256 -> ’82’ ‘01’ ‘00’ or also ’83’ ‘00’ ‘01’ ‘00’
 BER x DER
 ‘80’ is “indefinite” length
 Not allowed in DER
BER value
 The data itself
 Dependent on data type
 Integer: signed – e.g. 128 -> ’00 80’
 Octet string: directly the data
 Bit string: number of unused bits + padded bit
string to a multiple of 8 bits (padding is at the end)
 UTCTime: string of one of the forms
First look at the binary DER file
 CSCA_CZE.crt
DER vs. PEM
 PEM
 Privacy Enhanced Mail
 PEM as such not used, but formats still used
 Textual formats
 Practical for transport channels where full 8bit data can
be damaged
 PEM is base64 coded DER enveloped with
 -----BEGIN SOMETHING-----
 -----END SOMETHING-----
 Where SOMETHING is CERTIFICATE/PKCS7/KEY…
Sample PEM file
 CSCA_CZE.pem
ASN.1 viewers
 Unber (part of asn1c)
 Openssl asn1parse
 ASN.1 Editor
 …
OpenSSL asn1parse
 CSCA_CZE.crt
unber  CSCA_CZE.crt
Manual viewing/processing
 30 82 04 f2
 SEQUENCE
 length 1266B
 30 82 03 26
 SEQUENCE
 length 806B
 A0 03
 CONTEXT
SPECIFIC 0
 Length 3B
 02 01 02
 INTEGER: 2
 CSCA_CZE.crt
ASN.1 Editor  CSCA_CZE.crt
ASN.1 Grammar
 To understand the structure (what is the
meaning of particular fields) we need ASN.1
grammar
ASN.1 – RSA keys
Source:
PKCS#1 RSA.key
ASN.1 – RSA padding
 PKCS#1 v1.5
 m = 0x00 || 0x01 || 0xFF … 0xFF || 0x00 || T
 Where T is defined as DER encoding of
 In practice:
Source:
PKCS#1
ASN.1 – RSA signature
 RSA signature is the number s = md mod n
 TSA.crt
ASN.1 – signature OIDs
Source:
BSI TR-03105 Part 5.1
ASN.1 – RSA PSS params
RSASSA-
PSS
SHA256
SHA256
MGF1
Source:
PKCS#1
 CSCA_CZE.crt
ASN.1 – DSA keys
DSAPrivateKey is an INTEGER, usually denoted as X
Source:
RFC 5480
Source:
OpenSSL
 DSA.key
ASN.1 – DSA signature
Source:
RFC 5480
 DSA.crt
ASN.1 – DSA - OIDs
Source: RFC 5480
ASN.1 – ECDSA keys
ECPoint
INTEGER
Source: RFC 5915
ASN.1 - ECDSA public key
 CSCA_Switzerland.crt
ASN.1 – ECDSA signatures
1.2.840.10045.4.1 - ecdsa-with-SHA1
Source:
RFC 5480
 CSCA_Switzerland.crt
ASN.1 – ECDSA signature OID
Source:
BSI TR-03105 Part 5.1
ASN.1 - certificates
Source:
RFC 5280
ASN.1 – certificates - pubkey
Source:
RFC 5280
 CSCA_CZE.crt
ASN.1 – certificates - times
 Until 2049: UTCTime
 YYMMDDHHMMSSZ
 From 2050: GeneralizedTime
 YYYYMMDDHHMMSSZ
Source:
RFC 5280
 CSCA_CZE.crt
ASN.1 – certificates - names
Source:
RFC 5280
ASN.1 – certificate - names
 CSCA_CZE.crt
ASN.1 – certificate - names
Source:
ITU-T X.520
ASN.1 – certificate - names
Source:
ITU-T X.520
Certificate profiles
 For particular areas/purposes there exist certificate
profiles which prescribe what kind of attributes will
be used in Names
 E.g. for electronic passports ICAO Doc. 9303 states:
Source:
ICAO Doc. 9303
ASN.1 – certificates – v3
 Critical x non-critical extensions
Source:
RFC 5280
ASN.1 – certs – extensions
 CSCA_CZE.crt
X509v3 cert extensions
 Authority Key Identifier
 Identification of the issuing CA
 Non critical
 Similarly “Subject Key Identifier” Source:
RFC 5280
X509v3 cert extensions
 Key Usage
 Restrictions of the use of the key
Source:
RFC 5280
X509v3 cert extensions
 Extended Key Usage
 Purposes of the certified key
Source:
RFC 5280
X509v3 cert extensions
 Certificate Policies
 Policy relevant for
the issue and use of
the certificate
 Preferably only an
OID
Source:
RFC 5280
X509v3 cert extensions
 Subject Alternative Name
 Issuer Alternative Name
 “Internet style identities”
 Email
 DNS name
 IP address
 URL
 Must be verified by CA
X509v3 cert extensions
 Basic Constraints
 Is Subject a CA?
 Max. length/depth of the certificate chain/path
 A pathLenConstraint of zero indicates that no
non-self-issued intermediate CA certificates may
follow in a valid certification path.
Source:
RFC 5280
X509v3 cert extensions
 Name Constraints
 Only for CA certificates
 “indicates a name space within which all
subject names in subsequent certificates in a
certification path MUST be located”
Source:
RFC 5280
X509v3 cert extensions
 Policy Constraints
 Must be critical
 For CA certificates
 Constraints path validation
 Prohibit policy mapping (or)
 Require acceptable policy OID in each certificate
Source:
RFC 5280
X509v3 cert extensions
 CRL Distribution Points
 How to obtain CRL
Source:
RFC 5280
ASN.1 – certificate request
Source:
RFC 5280
ASN.1 - CRL
Source:
RFC 5280
ASN.1 – PKCS#7 / CMS
Source:
RFC 5652
ASN.1 - PKCS#7 / CMS
Source:
RFC 5652
PKCS#7 Sample  France.p7s
ASN.1 – PKCS#8
Source:
PKCS#8