Subject: A non-critical self-signed certificate extension for trust anchr renewal ...

From: Thierry Moreau <[email-masked]>
Date: Thu, 14 Jul 2005 19:32:24 -0400

To the pkix list:

Here is a new trust anchor renewal scheme explained in an Internet draft 
document draft-moreau-pkix-takrem-00.txt (submitted today, also 
available at http://www.connotech.com/draft-moreau-pkix-takrem-00.txt).

See also http://www.connotech.com/takrem.pdf for a more tutorial 
explanation.

Regards,

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: [email-masked]

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Tue, 19 Jul 2005 12:13:16 +0200

Thierry Moreau wrote:

> Here is a new trust anchor renewal scheme explained in an Internet 
> draft document draft-moreau-pkix-takrem-00.txt (submitted today, also 

Sorry about the empty message yesterday.

My comment was about what justifies defining a new trust anchor key
distribution in addition to the one already defined in RFC 2510 §2.4
(also B5 and §3.3.13).

I see two gains in your proposition :
- a smaller message (but probably not very relevant)
- the ability to still be able to update a key after it is compromised

The second point may look very useful, but in real life good procedures
should enable to keep the trust anchor private key at about the same
level of security as the future trust anchor key in your mechanism.

---

From: Thierry Moreau <[email-masked]>
Date: Tue, 19 Jul 2005 10:32:30 -0400

Jean-Marc Desperrier wrote:
>  [...]

For the period of use of the current trust anchor key, future trust 
anchor keys need not even be stored in any computing device. Perhaps a 
not-used key is a little easier to protect than a production key! It 
unlikely that "real life good procedures" offer the same level of 
protection for both. Obviously, there is a value judgment about 
"adequate" level of protection. We offer a mechanism to raise the 
achievable level of protection for future trust anchor keys.

Also, by providing an opportunity to automate the trust anchor key 
renewal operation, we facilitate shorter cryptoperiods for trust anchor 
keys (e.g. NIST SP800-57, "Recommendation for Key Management", part 1, 
section 8.1.5.1.1.1 "Distribution of a Trust Anchor's Public Key in a PKI").

Regards.

-- 

- Thierry Moreau

Tel.: (514)385-5691
Fax:  (514)385-5900

---

From: Stephen Kent <[email-masked]>
Date: Fri, 22 Jul 2005 16:14:02 -0400

Thierry,

A few of comments on your I-D:

	- the notion of including the hash of the next public key to 
be used by a CA (TA) as an extension in a cert is an old one, 
developed by the SET folks. I believe they have a patent on the 
technique. While they used a simple one-way hash for this purpose, 
use of a MASH and the salt may not be enough of a difference to not 
be covered by the patent.

	- you allow for the hash to be of the next cert, not just the 
next public key. Although the text does not seem to say so 
explicitly, I assume this feature makes sense only for scheduled 
rollover, where the complete cert contents, including the validity 
interval, can be computed in advance.

	- some discussion of when it is appropriate to include a 
sequence of future key/cert hash values in an initial cert is needed. 
it would seem sufficient to do this one key/cert at a time in 
general, allowing later keys to be generated in the future, adn thus 
not ave to be stored security for long periods.

	- the lack of a syntax for the renewal message is a worrisome 
omission. it's OK to defer to another document the means of 
transporting the message, but the syntax for the message should 
probably be defined here.

	- section 4.1 is a bit confusing and needs to be reworded, 
and 4.2 has some exposition problems as well. if one MAY rely on the 
digest values in the extension beyond the expiration date of the 
cert, then you need to explain why this is a reasonable behavior and 
under what circumstances it is likely to be necessary.

	- there are numerous odd textual conventions in the document, 
e.g., double square brackets (i.e., "[[") when the phrase "issuer of 
an initial self-signed certificate" appears.

	- the security considerations  section is a mix of 
appropriate guidance relevant to this extension, and extraneous 
guidance not specvific to this context.

Steve

---

From: Thierry Moreau <[email-masked]>
Date: Mon, 25 Jul 2005 10:09:46 -0400

Dear Stephen:

Thanks for your comments on draft-moreau-pkix-takrem-00.txt. Your points 
are well-taken. See in-line below.

I expect to work on a -01 draft after the Paris meeting, once the -00 is 
accepted as an Internet draft (there is a ban period for -00 draft 
acceptance before and during a meeting).

Stephen Kent wrote:

>     - the notion of including the hash of the next public key to be used 
> by a CA (TA) as an extension in a cert is an old one, developed by the 
> SET folks. I believe they have a patent on the technique. While they 
> used a simple one-way hash for this purpose, use of a MASH and the salt 
> may not be enough of a difference to not be covered by the patent.
> 
Thanks for this indication of a possible significant prior art document. 
Do you have any further pointers that can assist my search for an exact 
reference.

>     - you allow for the hash to be of the next cert, not just the next 
> public key. Although the text does not seem to say so explicitly, I 
> assume this feature makes sense only for scheduled rollover, where the 
> complete cert contents, including the validity interval, can be computed 
> in advance.
> 
Yes, with qualification. Yes, it makes sense for "scheduled rollover, 
where the complete cert contents, including the validity interval, can 
be computed in advance" -- this should be more clearly stated in the 
draft. The qualification is the following ones 1) the initial 
certificates are optional, and 2) the can optionally be superseded in 
the renewal message.

>     - some discussion of when it is appropriate to include a sequence of 
> future key/cert hash values in an initial cert is needed. it would seem 
> sufficient to do this one key/cert at a time in general, allowing later 
> keys to be generated in the future, adn thus not ave to be stored 
> security for long periods.
> 
Security-wise, the chaining that you suggest implies long-term security 
(i.e. the chain is no stronger than its weakest link). For sake of 
simplicity, I thought the extension usage limited to root keys (i.e. not 
for public keys that are routinely certified) and to root key 
distribution thay relies on out-of-band integrity assurance (i.e. 
initial distribution). This is subject to discussion.

> omission. it's OK to defer to another document the means of transporting 
> the message, but the syntax for the message should probably be defined 
> here.
> 
Point well taken. I intended to include a sample syntax in the -00 
revision, but at last I was not sure the details were polished enough 
for submission.

>     - section 4.1 is a bit confusing and needs to be reworded, and 4.2 
> has some exposition problems as well. if one MAY rely on the digest 
> values in the extension beyond the expiration date of the cert, then you 
> need to explain why this is a reasonable behavior and under what 
> circumstances it is likely to be necessary.
> 
I'm referring to the expiration of the initial security certificate. The 
digests of future keys are intended to be used after expiry of this 
first certificate. It is reasonable because the digest cryptography 
(i.e. an unknown hash function instance and this hash function itself) 
is stronger than the initial public key cryptography. Also, the relying 
system configuration continued integrity is somehow independent on the 
reasonableness of the behavior. The behavior is necessary for renewal of 
  trust anchor keys.

>     - there are numerous odd textual conventions in the document, e.g., 
> double square brackets (i.e., "[[") when the phrase "issuer of an 
> initial self-signed certificate" appears.
> 
Indeed.

>     - the security considerations  section is a mix of appropriate 
> guidance relevant to this extension, and extraneous guidance not 
> specvific to this context.
> 
I should try to remove the extraneous guidance.

Regards,

-- 

- Thierry Moreau

Tel.: (514)385-5691
Fax:  (514)385-5900