Request for Comment: adding chain info to keytool -list

[Xuelei Fan]

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

What the criterion to make the private key entries hierarchical? I don't
think there is hierarchical relations between private key entry. Do you
mean the hierarchical relation of the certificate chain of the target
private key entries? I'm confused here.

> [ca], TrustedCertificateEntry
>   + "CN=j"
>     + k, PrivateKeyEntry
> "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.

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

> 3. "CN=j" is neither in this keystore or cacerts
> 
If it is not in this keystore, where does it come from?

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

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