Re: [Help-gnutls] Re: Is gnutls using the shell model or the chain model for a certificate validation

[Daniel Kahn Gillmor]

On Mon 2008-11-10 06:30:24 -0500, Simon Josefsson wrote:

> Scott Schaeffner <address@hidden> writes:
>
>> The power point presentation
>> http://www.bundesnetzagentur.de/media/archive/1894.pps#259 shows
>> the differences concerning the two different validation models.
>
> I'm not sure I understand the difference between the shell vs chain
> models based on that powerpoint, but I can say that there is only
> one algorithm implemented in gnutls for x.509 validation, and it
> validates X.509 paths in a chaining way.  Whether that matches what
> you are looking for is not clear to me.  You can read the code in
> lib/x509/verify.c.

I'm not sure that the powerpoint in question is even relevant to TLS
connections.  The powerpoint appears to be specifically about document
signatures, not X.509 certificates.  Amid all the fancy graphics and
swooping timelines, the only distinction i could suss out was:

 * the chain model implies that as long as the digital signature was
   made during the lifetime of the signer's key, it is considered
   indefinitely valid.

 * the shell model implies that the digital signature on a document is
   only valid during the lifetime of the signer's key.

How might this be relevant to TLS connections?

If you view an X.509 certificate as a document consisting of a public
key bound to a chunk of metadata, all digitally signed by a
certificate authority, then you should take into account that the
X.509 signature itself has an expiration date (validity period)

In that case, the distinction between "shell" and "chain" models would be:

 * the chain model implies that the period of validity for an X.509
   certificate is simply the validity period contained in the
   certificate.

 * the shell model implies that the period of validity for an X.509
   certificate is the intersection of the validity period in the
   certificate and the validity period of the CA's certificate.

The former is simpler to implement, but the latter seems more solidly
secure.

Why would a CA need to grant a certificate whose duration was longer
than the CA's own expiration date, unless the CA was extending its own
certificate?  And if it wants to extend itself: do we (as users) want
"trusted" root CAs to be able to unilaterally extend their own
expiration date?

I'd be interested in seeing any other references to these models that
might shed more light, as i'm still not sure i understand the
distinctions.

      --dkg

pgpxGbO4K_Kid.pgp
Description: PGP signature