Request for Comment: adding chain info to keytool -list

[Weijun Wang]

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
>>>>>>
>>>>>>
>>>>>
>>>
>