[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ShrinkWrap draft -- comments ?



	I haven't read through the draft yet, but on a separate list it came up 
that we might want to do a lot more production of Cert Result Certs than I 
originally thought.

	That other discussion was about the need to discover a set of certs out of 
all the certs in the world which the prover will submit to the verifier.  
One of the cases is when the prover doesn't trust the verifier and wants to 
keep it from learning anything more than that the prover has the right to 
gain access.

	One piece of information to hide from the verifier is your public key, 
since your public key is a good name for you.  E.g., if you have a fragment 
of a cert loop in the form of the chain:

	B -> C -> D

where D's subject is your public key and the verifier has ACL A and final 
condition E such that

	A -> B -> C -> D -> E

says the verifier says you have access to the final condition, if we hand 
the cert fragment BCD to the verifier, he can read your public key.

However, if we have a shrinkwrapper running at issuer(B), we can generate a 
new key pair, and a new cert, F, delegating all from subject(D) to that 
public key then hand

	B -> C -> D -> F

off to be shrink wrapped, getting back a single cert in which B empowers F.  
This not only gives you access while hiding your identity (from the verifier 
- -- not from issuer(B)), it also saves time during the search for the right 
certs -- both by shortening the path and by having a single public key with 
only one cert in your cache for that function.

 - Carl

Version: PGP for Personal Privacy 5.0
Charset: noconv


|Carl M. Ellison  cme@cybercash.com   http://www.clark.net/pub/cme |
|CyberCash, Inc.                      http://www.cybercash.com/    |
|207 Grindall Street   PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 |
|Baltimore MD 21230-4103  T:(410) 727-4288  F:(410)727-4293        |