J. Pääjärvi <juha.paajarvi@firsthop.com>
J. Koponen <juha.koponen@firsthop.com>
First Hop Ltd., Finland
-Motivation
-Certificates
-SPKI
-XML Format for certificates
-XML-Signature and XML encoded SPKI certificates
In Brief
-XML Encoded SPKI Certificates
-SPKI Certificates
o SPKI is the Simple Public Key Infrastructure defined by IETF’s SPKI WG
-Encoded in XML
-XML-Signature for certificate signature
-Problem: Certificate encoding
o Standards use complex encoding formats (especially DER encoding of ASN.1 for X.509)
o Unnecessary burden on developers
-Question: Is there a cost efficient and widely used alternative?
-Solution: XML
-Certificates are standard form, signed documents that state something in a secure way
-Certificates are signed by someone trusted
-Two main types of certificates
o Name certificate: Juha Pääjärvi has the public-key XYZ
o Authorization certificate: The owner of the public-key XYZ has the following permissions to access the system X
-X.509 certificates are most widely used
-SPKI is an alternative to X.509 with many advantages
-Native support for authorization certificates
-Simple!
-Trust model
o Resource owner authorizes the use of resources in his control
o No need for certificate authorities (CAs)
-Well suited for distributed systems
o IP based mobile and wireless communications
Issuer - the public-key of the one that granted the certificate
Subject - the public-key of the one for whom the certificate is granted (the owner)
Tag - the permissions granted for the owner (subject) of the certificate
Delegation - a flag indicating, if the owner can pass the permissions over to a third party
Validity - constraints for the validity of the certificate:
expiration date, online tests
-Based on SPKI theory (RFC 2693)
-Structure based on the s-expression format of SPKI certificates
(draft-ietf-spki-cert-structure-06.txt, expired)
-Draft defines a DTD for
o Authorization certificates
o Name certificates
o CRLs (Certificate Revocation Lists)
-XML structure for authorization certificate:
-Special characteristics of a certificate from signature point
of view
o Simple XML document to sign
o No referred documents must be signed
o Certificates are mostly signed by the issuer, thus KeyInfo
usually not needed
-Signature form: Certificate enveloped inside an XML signature
(inside an Object element)
-Lightweight, but more powerful canonicalization method than minimal canonicalization, would be welcome
-Desired characteristics
o DTD or schema not required
o Can canonicalize even single elements (not only complete documents)
-XML is standard and widely used encoding format also suitable for certificates
-XML-Signature enables the use of XML for certificates
-XML encoded certificates are fast to implement: just combine
o Crypto library
o XML processor
o XML-Signature processor