[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. 
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 
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 
    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> 
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: 
 for "object" 
 by  "FooBar Corp." 
 sig "1234") 
or with a default target: 
 by  "FooBar Corp." 
 sig "1234") 
so with this format of signature a simple certificate might look like: 
  (name "FooBar Corp." 
   key  "123") 
   by   "TrustIsUs" 
   sig  "234231231")) 
supportted by a self signed cert: 
  (name "TrustIsUs" 
   key  "3242342") 
   by   "TrustIsUs" 
   sig  "5675675675")) 
With real keys the size of the cert would be: 
  (name "Alice"  
   key  "iQCVAwUBMX+4xFpj/0M1dMJ/AQEPZQP+KzUO7+dp2bbg7n1FLzW  
         qsanYGarprw=" )  
  (by   "."  
   sig  "01zaQ3C66pGYgDubd8lCXZCYzbzsxewFTfPb7rPplmgbBVsrjEC  
         t0FI1AphybtBmlA=" )  
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>  
The name field of the pke signature block provides a   
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).  
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:  
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  
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 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