Subject Directory Attributes Extended Key Usage (1) Extended Key

Subject Directory Attributes
Extended Key Usage (1)
Indicates one or more purposes for which the certified public key
may be used, in addition to or in place of the basic purposes
indicated in the key usage extension
It is used to convey identification attributes (e.g.,
nationality) of the subject.
subject The extension is defined as a
sequence of one or more attributes.
For example:
Code signing
OCSP signing
Timestamping
MUST be non-critical
SubjectDirectoryAttributes
j
y
::= SEQUENCE SIZE ((1..MAX)) OF Attribute
ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
KeyPurposeId ::= OBJECT IDENTIFIER
../Certificates/text/BNetz_TSS_EKU.cxt ((text))
../Certificates/BNeztA_TSSSigner.cer
/Certificates/BNeztA TSSSigner cer (bin)
36
37
Extended Key Usage (2)
Extended Key Usage (2)
If a certificate contains both a key
y usage
g extension
and an extended key usage extension, then both
processed independently
p
y and the
extensions MUST be p
certificate MUST only be used for a purpose
consistent with both extensions. If there is no
purpose consistent with both extensions, then the
certificate MUST NOT be used for any
yp
purpose.
p
If a certificate contains both a key
y usage
g extension
and an extended key usage extension, then both
processed independently
p
y and the
extensions MUST be p
certificate MUST only be used for a purpose
consistent with both extensions. If there is no
purpose consistent with both extensions, then the
certificate MUST NOT be used for any
yp
purpose.
p
38
39
List of other extensions
PGP
Pretty Good Privacy (PGP) is a computer
program
p
g
that p
provides cryptographic
yp g p
privacy
p
y
and authentication. PGP is often used for
signing,
g g encrypting
yp g and decrypting
yp g e-mails to
increase the security of e-mail communications. It was created by
y Philip
p Zimmermann
in 1991.
Certificate Policies
Policy Mappings
Policy Constraints
Basic Constraints
Name Constraints
CRLDistributionPoints
Inhibit Any-Policy
Any Policy
Freshest CRL
Authority
h i Information
I f
i Access
Subject Information Access
PGP and similar products follow the OpenPGP
standard (RFC 4880) for encrypting and
decrypting data.
Source: http://en.wikipedia.org/wiki/Pretty_Good_Privacy
40
41
PGP
GPG
Pretty Good Privacy (PGP) is a computer
program
p
g
that p
provides cryptographic
yp g p
privacy
p
y
and authentication. PGP is often used for
signing,
g g encrypting
yp g and decrypting
yp g e-mails to
increase the security of e-mail communications. It was created by
y Philip
p Zimmermann
in 1991.
GNU Privacy Guard (GnuPG or GPG) is a free
software alternative to the PGP suite of
crypto-graphic software. GnuPG is compliant
with RFC 4880.
GPG is a part of the Free Software
Foundation's GNU software project, and has
received major funding from the German
government. It is released under the terms
of version 3 of the GNU General Public
License.
PGP and similar products follow the OpenPGP
standard (RFC 4880) for encrypting and
decrypting data.
Source: http://en.wikipedia.org/wiki/Pretty_Good_Privacy
Source: http://en.wikipedia.org/wiki/GNU_Privacy_Guard
42
43
GPG
PGP Certificates
GNU Privacy Guard (GnuPG or GPG) is a free
software alternative to the PGP suite of
crypto-graphic software. GnuPG is compliant
with RFC 4880.
GPG is a part of the Free Software
Foundation's GNU software project, and has
received major funding from the German
government. It is released under the terms
of version 3 of the GNU General Public
License.
Source: http://en.wikipedia.org/wiki/GNU_Privacy_Guard
44
Source: http://www.ece.cmu.edu/~adrian/630-f04/PGP-intro.html
PGP Keys
45
Example
One UserID with one signature
Legend
Public Key Packet
User ID Packet
Signature Packet
46
47
Example (2)
Example (3)
One UserID with one signature and
One UserID with four signatures
a second UserID without signature
Legend
Legend
Public Key Packet
Public Key Packet
User ID Packet
User ID Packet
Signature Packet
Signature Packet
48
49
Example (4)
Public Key Packet
One UserID with one signature and
a second UserID with one signature and
a second key (subkey) with one signature
Version
Creation Time
Public Key
(RSA case)
Public Key Algorithm
Legend
Public Key Packet
User ID Packet
Signature Packet
50
51
User ID Packet
User ID Packet
A User ID packet consists of UTF-8 text
that is intended to represent
p
the name and
email address of the key holder. By
convention, it includes an RFC 2822 mail
name-addr, but there are no restrictions on
its content. The p
packet length
g in the header
specifies the length of the User ID.
A User ID packet consists of UTF-8 text
that is intended to represent
p
the name and
email address of the key holder. By
convention, it includes an RFC 2822 mail
name-addr, but there are no restrictions on
its content. The p
packet length
g in the header
specifies the length of the User ID.
From RFC 4880
From RFC 4880
Example:
Alex Wiesmaier <wiesmaier@cased.....>
<wiesmaier@cased >
Example:
Alex Wiesmaier <[email protected]>
<wiesmaier@cased de>
52
Signature Packet
Subpacket content
…
…
Version
Si
Signature
T
Type
Public Key Algorithm
Hash Algorithm
Counter
53
Hashed Subpackets
Unhashed Subpackets
16 bits of signed hash value
signature creation time
signature
g
expiration
p
time
exportable certification
trust signature
regular
l expression
i
revocable
key expiration time
placeholder for backward
compatibility
preferred symmetric
algorithms
revocation key
issuer key ID
notation data
preferred hash algorithms
preferred compression
algorithms
key server preferences
preferred key server
primary user id
policy URL
key flags
signer's user id
reason for revocation
Si
Signature
(RSA C
Case))
54
55
WAP certificates
WAP certificates – ASN.1
Wireless Application Protocol (WAP)
Wireless Markup Language (WML)
Lik X.509
Like
X 509 certificates
c tific t s but sm
smaller
ll
For usage in mobile Internet
Serial Number: usually not longer than 8 bytes
Algorithms: SHA1withRSA,
SHA1withRSA SHA1withECDSA
Extensions: not all are included
56
WAPCertificateInfo ::= SEQUENCE {
version
[0]
EXPLICIT Version DEFAULT v1,
serialNumber
CertificateSerialNumber,
signature
AlgorithmIdentifier
{{SupportedSignatureAlgorithms}},
{{SupportedSignatureAlgorithms}}
issuer
Name
{{SupportedNamingAttributes}},
{{SupportedNamingAttributes}}
validity
Validity,
subject
Name
{{SupportedNamingAttributes}},
j
y
SubjectPublicKeyInfo
j
y
subjectPublicKeyInfo
{{SupportedPublicKeyAlgorithms}},
extensions [3]
EXPLICIT Extensions
{{S
{{SupportedExtensions}}
t dE t
i
}} OPTIONAL
}
CV Certificates
57
Attribute certificate
Card Verifiable Certificate (CVC)
An attribute certificate (AC) is a
structure similar to a PKC; the main
difference being that the AC contains no
public key. An AC may contain attributes
that specify group membership, role,
security clearance, or other authorization
information associated with the AC holder.
Even compacter than WAP Certificates
For usage on smart cards (authentication)
Signature with message recovery
Contains barely more than Issuer, Subject,
Public Key,
Key Validity
From RFC 5755
58
59
Attribute certificate
Attribute certificate
Authorization information may be placed in a PKC
extension or placed in a separate attribute
certificate (AC). The placement of authorization
information in PKCs is usually undesirable for two
reasons First,
reasons.
First authorization information often
does not have the same lifetime as the binding of
the identity and the public key. When
authorization information is placed in a PKC
extension, the general result is the shortening of
the PKC useful lifetime. Second, the PKC issuer is
not usually authoritative for the authorization
information. This results in additional steps for
the PKC issuer to obtain authorization information
from the authoritative source.
source
Authorization information may be placed in a PKC
extension or placed in a separate attribute
certificate (AC). The placement of authorization
information in PKCs is usually undesirable for two
reasons First,
reasons.
First authorization information often
does not have the same lifetime as the binding of
the identity and the public key. When
authorization information is placed in a PKC
extension, the general result is the shortening of
the PKC useful lifetime. Second, the PKC issuer is
not usually authoritative for the authorization
information. This results in additional steps for
the PKC issuer to obtain authorization information
from the authoritative source.
source
From RFC 5755
From RFC 5755
60
Attribute certificate
61
Attribute Certificate
AttributeCertificate ::= SEQUENCE {
acinfo
AttributeCertificateInfo,
signatureAlgorithm
AlgorithmIdentifier,
signatureValue
BIT STRING }
Authorization information may be placed in a PKC
extension or placed in a separate attribute
certificate (AC). The placement of authorization
information in PKCs is usually undesirable for two
reasons First,
reasons.
First authorization information often
does not have the same lifetime as the binding of
the identity and the public key. When
authorization information is placed in a PKC
extension, the general result is the shortening of
the PKC useful lifetime. Second, the PKC issuer is
not usually authoritative for the authorization
information. This results in additional steps for
the PKC issuer to obtain authorization information
from the authoritative source.
source
Attribute Certificate Information (acinfo)
This part holds all information; this will be signed.
Signature Algorithm
The algorithm that is used for signing the acinfo part.
Signature Value
Th calculated
The
l l t d signature.
si
t
From RFC 5755
62
63