First, commenting on your proposal:
It's a bunch of independent chains, not a tree. It's more similar to my
original proposal, which was:
user, Sep 6, 2007, PrivateKeyEntry, user - signer - rootca(self)
In your format, it becomes:
user, Sep 6, 2007, PrivateKeyEntry
CN=Root CA
CN=Signer
CN=User
Certainly it looks better (dnames are usually quite long), but not what
I think of a tree.
What I think of a tree, is that if two certs are signed by the same
issuer, then the two certs (or entity) should be the branches of this
single signer. Thus the tree shows the relationship of signing.
In this tree, each node represents an entity (which normally has a
certificate and a dname), whether it's a root CA, an intermediate CA or
an end-entity, and each entity appears only once. The tree is
constructed so that a node signs its direct children. If it happens to
be an entry in this keystore (which means it equals to the
getCertificate() for that entry), the alias and entry type is printed.
If it can be found in cacerts, [alias] is shown. Otherwise, the
"distinguished name" is shown.
Because not all entities can be connected by signing, so he tree has a
special root node that has all self-signed certs as its children. This
root has another special child whose children are certs that are not
self-signed but their signers are not available, aka, incomplete chains.
I understand that sometimes certs sign each other to form a loop. I
haven't yet figured out how to best show this in a tree.
More description below inline.
On 01/19/2011 10:50 PM, Xuelei Fan wrote:
I'm not sure I understand the proposal completely. Please read in-lines
comments.
On 1/19/2011 5:34 PM, Weijun Wang wrote:
Oh, I have a design now. keytool -list -tree will show:
******************************************
* Chained entries
******************************************
b, PrivateKeyEntry
+ h, PrivateKeyEntry
+ f, PrivateKeyEntry
+ i, PrivateKeyEntry
These are all PrivateKeyEntries, and b signs h, h signs f, and f signs i.
What the criterion to make the private key entries hierarchical? I don't
think there is hierarchical relations between private key entry. Do you
Yes, there are. The entries are created with:
kt -genkeypair -alias b
kt -genkeypair -alias h
kt -genkeypair -alias f
kt -certreq -alias h | kt -gencert -alias b | kt -import -alias h
kt -certreq -alias f | kt -gencert -alias h | kt -import -alias f
mean the hierarchical relation of the certificate chain of the target
private key entries? I'm confused here.
[ca], TrustedCertificateEntry
+ "CN=j"
+ k, PrivateKeyEntry
This is the most typical case in a keystore for a privateKeyEntry. The
user k gets the chain from a CA. The chain ends with a root CA [ca] in
cacerts, the intermediate CA is "CN=j" but it's neither listed in this
keystore or cacerts.
"CN=a"
+ e, PrivateKeyEntry
+ d, PrivateKeyEntry
+ g, TrustedCertificateEntry
I don't think I understand the above two trees. Is there any connection
between privaeKeyEntry and TrustedCertificateEntry? It is not intuitive
to me.
It's just that the entry with alias g is a TrustedCertificateEntry.
Non self signed:
+ "CN=l"
+ m, PrivateKeyEntry
******************************************
* Other entries:
******************************************
x, SecretKeyEntry
which means:
1. b signs h, h signs f and i. b, h, i, and f are aliases in this keystore.
2. [ca] is not in this keystore, but in cacerts.
Do you mean that the keyTool will try to parse the cacerts keystore?
Yes, but it only shows those related to this keystore.
3. "CN=j" is neither in this keystore or cacerts
If it is not in this keystore, where does it come from?
It's in the cert chain for privateKeyEntry k. As I said, the tree shows
all entities, whether it's an alias in this keystore, in cacerts, or
neither.
4. b, [ca] and "CN=a" are all self-signed certs, which are listed at top
level of the tree. "CN=l" is not a self-signed cert, so it's listed
under "Not self signed". But we still know "CN=l" signs m.
I guess I can understand your purpose. Do you want to category the
entries into private key entries, intermediate certificates, authorities
and others?
No, still only PrivateKeyEntry and TrustedCerticateEntry (and others).
Thanks
Max
5. x is a SecretKeyEntry so not put inside chained entries.
Any suggestions?
From my understand,a key store contains three types of entries:
1. secret key entry
2. trusted certificate
3. private key entry and the related certificate chain.
Of course, the chain concept does not apply to secret key entry.
Normally, the trusted certificates do not store in chains. Most
of the time, they are only individual certificate. That's to say, if we
want to show them in trees, the tree normally only has multiple root,
but no branches. It may looks like:
+ trusted cert 1
+ trusted cert 2
+ trusted cert 3
So if only for trusted certificates, I don't think it is necessary to
display the key store in tree style, or mark the signing sequence in any
other method.
BTW, I think we may not want to introduce the concept of self-signed
certificate. It adds confusion. The trusted certificate is the root
certificate. As I don't care, I may be lazy to tell whether it is a
self-signed, self-issued, non-self signed, non-self issued certificate.
Considering the private key entry, it is accompanied by a certificate
chain for the corresponding public key. To display the chain in order, I
think that's the purpose to display the key store in tree, or adding
chain info to keytool list command.
From my understanding of KeyStore, I think the tree may looks like (if
we still want to category the entities into three)
+ private key entries
+ PrivateKeyEntry instance 1 [alias]
+ the top issuer's certificate [subject, KID]
+ ... the intermediate issuer's certificates ...
+ the certificate of the private key entry
+ PrivateKeyEntry instance 2 [alias]
+ the top issuer's certificate [subject, KID]
+ ... the intermediate issuer's certificates ...
+ the certificate of the private key entry
...
+ PrivateKeyEntry instance n [alias]
+ the top issuer's certificate [subject, KID]
+ ... the intermediate issuer's certificates ...
+ the certificate of the private key entry
+ trusted certificates
+ trusted cert 1 [alias]
+ trusted cert 2 [alias]
...
+ trusted cert n [alias]
+ secret entries
+ secret entry 1 [alias]
+ secret entry 2 [alias]
...
+ secret entry n [alias]
Xuelei
Thanks
Max
On 01/18/2011 09:45 AM, Xuelei Fan wrote:
On 1/18/2011 9:40 AM, Weijun Wang wrote:
You mean a tree of the whole keystore, but not chain for each entry.
Right?
Right.
Andrew
Max
On 01/18/2011 09:26 AM, Xuelei Fan wrote:
I would like to see a option to display the intuitive tree. For
example:
$ keytool -list -tree -keystore ...
+ root CA alias
+ intermediate CA alias
+ entity cert 1 alias
+ entity cert 2 alias
Andrew
On 1/17/2011 4:59 PM, Weijun Wang wrote:
Hi All
I have a keystore with a bunch of testing root CA, intermediate CA and
entity certs, some PrivateKeyEntry and some TrustedCertEntry, and it's
quite difficult to know who signs who. Therefore I suggest some
enhancement for the simple "keytool -list". (by simple, I mean no
"-v").
The entry will look like:
user, Sep 6, 2007, PrivateKeyEntry, user - signer - rootca(self)
Here, "user - signer - bigca(self)" means the entry's cert chain has 3
certs, which matches aliases user, signer, and rootca in the same
keystore, and rootca is a self-signed cert.
When a cert is not inside this keystore, its distinguished name can be
printed, like this:
user, Sep 6, 2007, PrivateKeyEntry, user - signer - "CN=Root
CA"(self)
Also, if the last cert is not self-signed, its signed can also be
added
after "--", like this:
user, Sep 6, 2007, PrivateKeyEntry,
user - signer -- "CN=Another CA"(self)
Do you find this useful?
Thanks
Max
