[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Random Thoughts
Over the weekend I was scratching out some spki related ideas. Attached below
ideas on requirements and simple examples of possible approaches.
Paul
PS - I just got the SDSI paper ... I think we are using a very similar syntax,
but there may be some minor philosophical differences. I hope this is still a
usefull contribution :-)
---
A few ideas on PKI requirements. Where there seems to be a choice to be made,
"a" and "b" options are listed.
SPKI Requirements and Recommendations. SPKI shall:
0 keep it simple
1 use version numbers to support future enhancements
2 use basic defaults to allow simple early implementations
o default to public key algorithm of RSA with arbitrary
key size (recommend >512)
o default hash use MD5 (or SHA?)
o to reduce number of required qualifying fields
3 use additional optional fields to support:
o additional algorithms
o key usage restrictions
o extra alternate names
o additional attributes
o bundle algorithm options (e.g. spki-RSA-SHA)
4 define an spki signature format
o detached signature for flexibility
o implicit or explicit reference to signed object
o use detached spki signature to create spki certs
5a names are required in spki certificate
or
5b names are optional in spki certificates
o certificate names have local significance based on
the context established by the signing "authority"
<It would seem reasonable to require names
simply to have a human readable handle for keys.>
6 provide flexible support for indication of signature/certificate
"meaning"
o optional attributes in certificate to indicate policy
<suggest use of PICS labels>
8 provide flexible support for hierarchies of certification
o e.g. PEM-like
o e.g. PGP-like
9 support various applications
o like .... <tbsl>
o
o
10 support international character sets for text
11 support key usage restrictions
o encrypt-only
o sign-only
o encrypt-and-sign
<not my favorite requirement, but necessary
for DSA and useful for some approaches to export>
12a support single key in a "certificate"
o req 11 by multi certs
12b support 1 or 2 public keys in a certificate
o req 11 by single cert
13 <ran out of steam ... more later>
So using a PICs-like syntax for a example named object:
Example signature:
(pke-sig-1.0
for "object"
by "FooBar Corp."
sig "1234")
or with a default target:
(pke-sig-1.0
by "FooBar Corp."
sig "1234")
so with this format of signature a simple certificate might look like:
(pke-cert-1.0
(name "FooBar Corp."
key "123")
(pke-sig-1.0
by "TrustIsUs"
sig "234231231"))
supportted by a self signed cert:
(pke-cert-1.0
(name "TrustIsUs"
key "3242342")
(pke-sig-1.0
by "TrustIsUs"
sig "5675675675"))
With real keys the size of the cert would be:
(pke-cert-1.0
(name "Alice"
key "iQCVAwUBMX+4xFpj/0M1dMJ/AQEPZQP+KzUO7+dp2bbg7n1FLzW
01zaQ3C66pGYgDubd8lCXZCYzbzsxewFTfPb7rPplmgbBVsrjEC
UzQla/RJqmS0duguuW11kK6l/q5t0FI1AphybtBmlAx9hLFfqwy
qsanYGarprw=" )
(by "."
sig "01zaQ3C66pGYgDubd8lCXZCYzbzsxewFTfPb7rPplmgbBVsrjEC
iQCVAwUBMX+4xFpj/0M1dMJ/AQEPZQP+KzUO7+dp2bbg7n1FLzW
UzQla/RJqmS0duguuW11kK6l/q5t0FI1AphybtBmlAx9hLFfqwy
t0FI1AphybtBmlA=" )
)
for
The "for" field in the pke signature block provides a pointer to the signed
object. The "for" field is optional. When the "for" field is not included
the location of the signed object is implicit in the usage of the signature.
The value of the "for" field contains a pke-RI.
<note - this could be URL or URI>
name
The name field of the pke signature block provides a
by
The "by" field in the pke signature block indicates the certificate used to
create the digital signature. The value of the "by" field contains a
universal certificate indicator (UCI).
sig-alg
The "sig-alg" field indicates the type of cryptographic processing used to
create the digital signature carried in the "sig" field. The "sig-alg" field
is optional. When the sig-alg field is not included in the signature block
the default proccesing type shall be pke-RSA-MD5-sig. The xxxxx annex
describes the processing for:
pke-RSA-MD5-sig
pke-RSA-MD5-txt-sig
pke-RSA-SHA-sig
pke-DSA-SHA-sig
sig
The "sig" field in the pke signature block contains the digital signature of
the item described by the "for" field. The cryptographic processing required
to create or validate the "sig" field is selected by the sig-alg field. When
no sig-alg field is included in the pke signature block the default signature
processing will be based on the use of the pke-RSA-MD5-sig processing. The
processing for the pke-RSA-MD5-sig uses the MD5 [r2] algorithm to hash the
target information and the RSA [r1] to encrypt the hash. The detailed
processing for pke-RSA-MD5-sig is described in section xxxxxx.
<editing note - need to support both raw hash of target and a text oriented
has that provides special processing for white space charaters. This could be
as a new sig-alg or as a new optional field that describes the hash
preprocessing.>
key
The "key" field of the pke certificate contains the public key components of a
public key pair in <xxx> format.
For a single non-RSA public key the pke certificate would contain:
key-type "RSB-pk"
key "9234d23x344s"
By default the key may be used for both signature and encryption.
To support separate encryption and signature keys the pke format allows two
key fields to be included in the certificate. For example:
key-usage encryption
key "423423423"
key-usage signature
key "231231231"
When no key-type preceeds a key the default is always RSA-pk.
key-usage encryption
key-type RSA-pk
key "12331231223"
key-usage signature
key-type DSA-pk
key "r4r4f4fw4ffwe"
Since the key-type default is RSA-pk the example above could also be
constructed as:
key-usage encryption
key "2231231233"
key-usage signature
key-type DSA-pk
key "r4r4f4fw4ffwe"
Paul
--------------------------------------------------------------
Paul Lambert Director of Security Products
Oracle Corporation Phone: (415) 506-0370
500 Oracle Parkway, Box 659410 Fax: (415) 413-2963
Redwood Shores, CA 94065 palamber@us.oracle.com
--------------------------------------------------------------