Re: support for v1 certificates?

"Housley, Russ" <rhousley@rsasecurity.com> Fri, 15 November 2002 18:30 UTC

Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gAFIUug00882; Fri, 15 Nov 2002 10:30:56 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA26592 Fri, 15 Nov 2002 13:07:43 -0500 (EST)
From: "Housley, Russ" <rhousley@rsasecurity.com>
To: Brian Korver <briank@xythos.com>
Cc: ipsec@lists.tislabs.com
Message-Id: <5.1.0.14.2.20021115115605.02114618@exna07.securitydynamics.com>
X-Sender: rhousley@exna07.securitydynamics.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 15 Nov 2002 12:00:38 -0500
Subject: Re: support for v1 certificates?
In-Reply-To: <38CDEEF6-F845-11D6-A746-000393751598@xythos.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk

>Re: draft-ietf-ipsec-pki-profile-01.txt

Brian:

>>>>In section 4.1.1, I agree that v3 certificates should be required for 
>>>>end entity and CA certificates.  However, the same code will likely be 
>>>>used for several purposes, and one of them is trust anchors.
>>>>Self-signed v1 certificates are often used to establish trust anchors.
>>>
>>>3280 mandates that BasicConstraints appear in CA certificates, but
>>>doesn't appear to state that a self-signed trust anchor can
>>>be treated differently.  3280 does state the following:
>>>
>>>    When the trust anchor is provided in the form of a self-signed
>>>    certificate, this self-signed certificate is not included as part of
>>>    the prospective certification path.
>>>
>>>However, without going back and examining the validation algorithm,
>>>it's difficult to know what this means with regards to BC.
>>>
>>>In the context of IPsec, do we see many v1 certificates used for this
>>>purpose?  I kinda thought that v1 certificates were a dying breed.
>>
>>Management of trust anchors is outside the scope of the validation 
>>algorithm in RFC 3280.  If self-signed certificates are used, the 
>>algorithm will not validate them.  They are not part of the certification path.
>>
>>I would like to see v1 certificates go away too.  I do not think it will 
>>happen soon.  For example, there are several v1 certificates built in to 
>>Internet Explorer that will not expire until 2018.  Others will not 
>>expire until 2028.  So, if the IPsec certificates chain to these trust 
>>anchors, one can expect to encounter the situation that I raised.
>
>I'm not sure it is a good thing to be chaining to the v1
>certificates in Internet Explorer, but that's perhaps a
>different issue.  :)
>
>That said, if someone supports v3, v1 basically comes
>for free.

Not really.  With v1 certificates, you cannot have the basic constraints 
extension.  That was the point that started this thread.

>Does anyone care whether support for v1 is optional
>vs. mandatory?

I do not see a need for v1 certificates in general.  That is why I 
suggested breaking the discussion into two parts.  One part should address 
trust anchors.  In this area, v1 should be permitted.  The other part 
should address the certification path, which terminates at the trust 
anchor, but does not include the trust anchor itself. In this area, v3 
should be mandated.

Russ