Subject: Re: RFC 5280 question

From: Stephen Kent <[email-masked]>
Date: Fri, 13 Jun 2008 11:45:52 -0400

Peter,

Yes, I too have been disappointed that the X.509 path validation 
algorithm says to not use constraints from the TA.  I brought this 
point up on the list a few years ago, because I felt that this was 
especially bad in the case of name constraints. I agree that such 
behavior is contrary to user expectations.

However, there is a relatively simple way around this that is 
consistent with the standards. One can extract the contents of a 
self-signed cert that has been provided as a TA, and issue a new cert 
under a TA managed locally. This could be done with minimal user 
effort for most folks, and advanced users could be provided with a 
menu that allowed more direct control over the process. Any 
extensions contained in this new cert (which is no longer a TA), will 
be used to control path validation, as specified by the X.509 and 
PKIX standards.

I have always preferred this model for dealing with TA material, as 
it also allows an RP to impose constraints (via extensions) on TA 
material provided by an outside source, even if the source did not 
put such constraints into the self-signed cert it offered.

Steve

---

From: "Reddy, Raksha P." <[email-masked]>
Date: Tue, 17 Jun 2008 17:04:27 -0400

FYI--The concepts described in draft-ietf-pkix-ta-mgmt-problem-statement-01
are being further developed into a requirements document, which is currently
being finalized.  This document is intended to list requirements that are in
this problem space of trust anchor management and acknowledges that a trust
anchor should enable certificate path validation in compliance with RFC
5280.  I encourage all parties interested in this work to review the
document, which will be submitted very soon, and provide feedback
accordingly.

Raksha Reddy
National Security Agency  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Santosh Chokhani
Sent: Friday, June 13, 2008 7:30 PM
To: Tom Gindin; Julien Stern
Cc: [email-masked]; Max Pritikin (pritikin); Bob Bell (rtbell); Tim Polk
Subject: RE: RFC 5280 Question

Tom,

I am all for moving forward with
draft-ietf-pkix-ta-mgmt-problem-statement-01.

I am all for clarifying 5280.

I even do not mind change as some would like if the implementers (relying
party client developers) do not object.

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]]
Sent: Friday, June 13, 2008 4:29 PM
To: Julien Stern; Santosh Chokhani
Cc: [email-masked]; Max Pritikin (pritikin); Bob Bell (rtbell); Tim Polk
Subject: Re: RFC 5280 Question

        Julien, Santosh:

        Actually, I think I have an idea why Max and Bob are using terms

in a way that is at odds with many of the rest of us.  The term "Trust
Anchor" has meant, in RFC's 3280 and 5280 and X.509v4 and later (it wasn't
used in 2459 or X.509v3), a certificate issuer at the beginning of a chain
of trusted certificates.  However, in
draft-ietf-pkix-ta-mgmt-problem-statement-01, a trust anchor may be such a
certificate issuer or it may instead be "a public key and associated data
used by a relying party to validate a signature on a signed object"
where
that object is not a public key certificate and cannot be validated using a
certification path.  Max and Bob are clearly using a definition consistent
with that one, rather than with RFC 3280 or 5280.
        We should do something to clear up this confused usage.  Either
"trust anchors" must be issuers and the "TA Management" draft needs to
reduce its scope or have its name changed (perhaps to "directly trusted
keys"), or else "trust anchors" can include EE certificates and the use in
3280 and 5280 should be called "anchor CA's" or something like that.

                Tom Gindin

Julien Stern <[email-masked]> Sent by:
[email-masked]
06/13/2008 04:13 AM

To
"Bob Bell (rtbell)" <[email-masked]>
cc
Santosh Chokhani <[email-masked]>, "Max Pritikin (pritikin)" 
<[email-masked]>, Tim Polk <[email-masked]>, [email-masked]
Subject
Re: RFC 5280 Question

If I may (briefly) jump into the discussion.
There seem to be a misunderstanding regarding "trusted certificates" and

"trust store".

Neither X.509 nor 5280 define the notion of trust store or trusted
certificate. This does not exist and there is no such thing as trusted EE
certificates or trusted CA certificates.

You can have a "Trust Anchor" that is a DN and a public Key (see X.509
p.6 for the definition) which can be used to verify other certificates. 
In practice, the DN and the public key, are commonly distributed as an
X.509 certificate, but that's to make things simple. 
Extensions/constraints, etc are not supposed to apply (See validation
algorithm in X.509, p.50)

Then, you have the notion of "Direct Trust", which is not clearly expressed
in X.509 or 5280, but which is natural in a PKI.
Direct Trust means that you have verified the binding between a DN and a

public key by out of band means. In other words, it means you know the owner
of the key.

It this owner happens to be a CA, you are essentially in the "Trust Anchor"
case. Otherwise, you are also supposed to know (by out of band
means) what the public key can be used for.

In your specific case, my reading of the standard is the following:

1) you insert a "certificate" in a "trust store" => This means that you
insert only the public key and the DN as trusted and as a CA (the rest of
the certificate is irrelevant).

2) You want to try to use standard validation mechanisms (and not direct

trust). You take your EE cert, and since it is self signed and self-issued,
it will validate up to the trust anchor that you have entered.

3) Be warned, however, that the owner of this public key will now be able to
issue as many certificates for other DNs that he wishes.

Alternative option: you use "direct trust".

1) You insert your certificate in a "direct trust store".
2) When encountering the certificate, you do not perform the X.509
validation if is it "directly trusted"
3) Be warned that you can only revoke by hand.

Now, I believe (experts, please correct me if I'm wrong), that you are 
free to modify the X.509 or the 5280 validation algorithm as long as you

are more restrictive. So, I assume you could define a "trust store with 
constraints" that would be populated with "trust anchors with 
constraints" in any way you see fit.

Hope this helps.

Regards,

--
Julien

Bob Bell (rtbell) wrote:
> Santosh -
> 
> I would recommend that the definition be broadened slightly to
indicate 
that
> regardless of whether basic constraints are present (as long as the CA

bit
> is false or non-existent), and that the keyCertSign bit is false.
This, 
at
> least as I read the definitions, defines the cert as an end-entity
cert.
> That kind of a cert in the trust store is what is causing problems for

me.
> 
> Bob
> 
>> -----Original Message-----
>> From: [email-masked] 
>> [mailto:[email-masked]] On Behalf Of Santosh Chokhani
>> Sent: Thursday, 12 June, 2008 18:21
>> To: Max Pritikin (pritikin)
>> Cc: Tim Polk; Bob Bell (rtbell); [email-masked]
>> Subject: RE: RFC 5280 Question
>>
>>
>> Max,
>>
>> So, are you saying that you wanted to explore the implication 
>> of a self-signed certificate that does not have basic 
>> constraints extension in it and does not set keyCertSign bit 
>> in the key usage?  I ask because that is the certificate Bob sent me.
>>
>> Please provide a clear, concise and complete description of 
>> your issues so that we have the same point of reference for 
>> discussions.
>>
>> -----Original Message-----
>> From: max pritikin [mailto:[email-masked]]
>> Sent: Thursday, June 12, 2008 7:07 PM
>> To: Santosh Chokhani
>> Cc: Tim Polk; Bob Bell (rtbell); [email-masked]
>> Subject: Re: RFC 5280 Question
>>
>>
>> I think Bob's question touched on an important issue. The 
>> inclusion of 
>> self-signed or EE certificates into the certificate store.
>>
>> For an example one should experiment with how the various major web 
>> browsers handle "trust this certificate" (sometimes called 
>> "trust this 
>> web page" etc). They all do it differently.
>>
>> - max
>>
>> On Jun 11, 2008, at 9:28 AM, Santosh Chokhani wrote:
>>
>>> Max,
>>>
>>> I do not understand from your posting what the specific concern or 
>>> issue
>>> you want to bring to the attention of PKIX.
>>>
>>> We have had lot of digressions on this topic.
>>>
>>> Please restate what your concerns are.
>>>
>>> -----Original Message-----
>>> From: max pritikin [mailto:[email-masked]]
>>> Sent: Tuesday, June 10, 2008 11:11 PM
>>> To: Santosh Chokhani
>>> Cc: Tim Polk; Bob Bell (rtbell); [email-masked]
>>> Subject: Re: RFC 5280 Question
>>>
>>>
>>> I'm not sure what Bob's goals are, perhaps just to ask the question.
>>> We don't work very closely together.
>>>
>>> This just struck a note with me because I've seen it raised as a
>>> problem in other cases as well.
>>>
>>> - max
>>>
>>> On Jun 10, 2008, at 9:35 PM, Santosh Chokhani wrote:
>>>
>>>> Max,
>>>>
>>>> I am just responding to inaccuracies in what you are saying.
>>>>
>>>> Can you and Bob tell me why you started this thread and 
>> what you are
>>>> seeking from the PKIX community?
>>>>
>>>> I for sure am clueless except for pointing out inaccuracies in your
>>>> assertions and/or conclusions.
>>>>
>>>> -----Original Message-----
>>>> From: max pritikin [mailto:[email-masked]]
>>>> Sent: Tuesday, June 10, 2008 6:51 PM
>>>> To: Santosh Chokhani
>>>> Cc: Tim Polk; Bob Bell (rtbell); [email-masked]
>>>> Subject: Re: RFC 5280 Question
>>>>
>>>>
>>>> Santosh, you've moved the conversation back to a discussion of item
>>>> (3) in my comments below: out-of-scope population of the trust
>>>> anchors. I think this is orthogonal to a discussion of dealing with
>>>> trust-anchors that exactly match a single certificate being 
>>>> validated.
>>>>
>>>> - max
>>>>
>>>>
>>>> On Jun 10, 2008, at 5:20 PM, Santosh Chokhani wrote:
>>>>
>>>>> Max,
>>>>>
>>>>> I do not have any problem with successfully verifying 
>> signature made
>>>>> by
>>>>> a trust anchor.
>>>>>
>>>>> As I said a day or two back in this chain, if the relying 
>> party who
>>>>> installs the certificate as a trust anchor and does not make
>>>>> additional
>>>>> checks of basic constraints, is susceptible to undetected 
>> compromise
>>>>> of
>>>>> this end entity certificate spawning an entire PKI hierarchy.
>>>>>
>>>>> -----Original Message-----
>>>>> From: max pritikin [mailto:[email-masked]]
>>>>> Sent: Tuesday, June 10, 2008 6:17 PM
>>>>> To: Santosh Chokhani
>>>>> Cc: Tim Polk; Bob Bell (rtbell); [email-masked]
>>>>> Subject: Re: RFC 5280 Question
>>>>>
>>>>>
>>>>> We're into the realm of discussing _how_ one would modify 
>>>>> Certificate
>>>>> Path Validation to support EE certificates as a trust 
>> anchor where 
>>>>> my
>>>>> intention was only to support the concept as a discussion point.
>>>>>
>>>>> Santosh, it isn't that the constraints/extensions are 
>> ever applied 
>>>>> to
>>>>> the trust anchor credential itself. It is that they are 
>> applied when
>>>>> validating the chain. Take for example Name Constraints or Policy
>>>>> Constraints or other Basic Constraints fields such as
>>>>> pathLenConstraint  which are all in the trust anchor 
>> certificate and
>>>>> then taken into account when validating a certificate 
>> chain. If the
>>>>> trust anchor certificate does not have keyCertSign set then 
>>>>> logically
>>>>> no 'chained' certificates would be valid; just like if the
>>>>> pathLenConstraint was '1' but the chain being verified has a path
>>>>> length of something greater.
>>>>>
>>>>> I think this question of EE cert vs CA cert as a trust anchor is
>>>>> about
>>>>> what should happen if the chain being validated consists 
>> of only the
>>>>> trust anchor. Independent of any questions concerning key usage,
>>>>> constraints or anything else.
>>>>>
>>>>> - max
>>>>>
>>>>> On Jun 10, 2008, at 4:36 PM, Santosh Chokhani wrote:
>>>>>
>>>>>> Max,
>>>>>>
>>>>>> The text you cite does not apply to trust anchor. 
>> Please see X.509
>>>>>> and
>>>>>> RFC 5280 path validation text.  Nothing needs to be 
>> verified from a
>>>>>> trust anchor.
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: max pritikin [mailto:[email-masked]]
>>>>>> Sent: Tuesday, June 10, 2008 4:47 PM
>>>>>> To: Santosh Chokhani
>>>>>> Cc: Tim Polk; Bob Bell (rtbell); [email-masked]
>>>>>> Subject: Re: RFC 5280 Question
>>>>>>
>>>>>>
>>>>>> Santosh,
>>>>>>
>>>>>> RFC5280 section 4.2.1.9 (Basic Constraints) says:
>>>>>>> The cA boolean indicates whether the certified public key may be
>>>>>>> used
>>>>>>> to verify certificate signatures.  If the cA boolean is not
>>>>>>> asserted,
>>>>>>> then the keyCertSign bit in the key usage extension MUST NOT be
>>>>>>> asserted.  If the basic constraints extension is not 
>> present in a
>>>>>>> version 3 certificate, or the extension is present but the cA
>>>>>>> boolean
>>>>>>> is not asserted, then the certified public key MUST NOT 
>> be used to
>>>>>>> verify certificate signatures.
>>>>>> An EE certificate being in the trust store would not cause 
>>>>>> confusion
>>>>>> about this.
>>>>>>
>>>>>> - max
>>>>>>
>>>>>> On Jun 10, 2008, at 2:07 PM, Santosh Chokhani wrote:
>>>>>>
>>>>>>> Max,
>>>>>>>
>>>>>>> I do not agree with your point on item 2.  Once a 
>> certificate is a
>>>>>>> trust
>>>>>>> anchor, neither X.509 not 5280 have any constraints on it from
>>>>>>> being a
>>>>>>> issuer.
>>>>>>>
>>>>>>> Furthermore, path length constraint if present in the 
>> self-signed
>>>>>>> certificate can be ignored by relying parties.
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: [email-masked]
>>>>>> [mailto:[email-masked]
>>>>>>> ]
>>>>>>> On Behalf Of max pritikin
>>>>>>> Sent: Tuesday, June 10, 2008 2:35 PM
>>>>>>> To: Tim Polk
>>>>>>> Cc: Bob Bell (rtbell); [email-masked]
>>>>>>> Subject: Re: RFC 5280 Question
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> A few comments on this thread:
>>>>>>>
>>>>>>> 1) Any entry in the trust anchor store would seem to be 
>> "directly
>>>>>>> trusted". If so an additional flag isn't needed so much as a
>>>>>>> statement
>>>>>>> about how path validation proceeds if, during path discovery, it
>>>>>>> turns
>>>>>>> out the certificate being validated is already directly trusted.
>>>>>>>
>>>>>>> 2)  Inclusion into the trust anchor store doesn't imply that a 
>>>>>>> cert
>>>>>>> is
>>>>>>> trusted to issue certificates -- that is directly 
>> controlled by 
>>>>>>> the
>>>>>>> values within the certificate (chain).
>>>>>>>
>>>>>>> 3) The out-of-band mechanism is out of scope for 
>> 5280/3280 but has
>>>>>>> been the subject of recent BoF work (and more?). It 
>> would nice if
>>>>>>> that
>>>>>>> work also addressed this question.
>>>>>>>
>>>>>>> Issues related to this come up on a regular basis. Look at the
>>>>>>> various
>>>>>>> ways browser deal with caching EE certificates to 
>> "trust this site
>>>>>>> always" etc. I think Bob has raised a good point.
>>>>>>>
>>>>>>> - max
>>>>>>>
>>>>>>> On Jun 10, 2008, at 12:27 PM, Tim Polk wrote:
>>>>>>>
>>>>>>>> Bob,
>>>>>>>>
>>>>>>>> [I realize I am late to the party, and that Santosh, Steve, and
>>>>>>>> Wen-
>>>>>>>> Chen Wang have already provided a lot of good feedback.  I 
>>>>>>>> decided
>>>>>>>> to respond to the original message because I would like to go 
>>>>>>>> back
>>>>>>>> to the perceived requirement.]
>>>>>>>>
>>>>>>>> It sounds like you want to construct a list of 
>> directly trusted 
>>>>>>>> EE
>>>>>>>> certificates, but are trying to satisfy this 
>> requirement using 
>>>>>>>> the
>>>>>>>> application's trust anchor store.  There is nothing inherently
>>>>>>>> wrong
>>>>>>>> with direct trust (and RFC 5280 does not preclude directly
>>>>>>>> trusting
>>>>>>>> an EE certificate), but you really need a different - and far
>>>>>>>> simpler - mechanism.  The trust anchor store is 
>> implicitly linked
>>>>>>>> to
>>>>>>>> path discovery and validation, which are not relevant here 
>>>>>>>> since a
>>>>>>>> directly trusted certificate cannot be validated.  With a 
>>>>>>>> directly
>>>>>>>> trusted certificate, there is also no mechanism to validate 
>>>>>>>> status
>>>>>>>> information.
>>>>>>>>
>>>>>>>> To further complicate matters, storing the certificate 
>> you wish 
>>>>>>>> to
>>>>>>>> directly trust in the trust anchor store implies that it is
>>>>>>>> trusted
>>>>>>>> to issue certificates as well.  The path validation inputs
>>>>>>>> specified
>>>>>>>> in 6.1.1 (d) consider only four aspects of a trust 
>> anchor (name,
>>>>>>>> public key algorithm, public key, and parameters if 
>> needed).  The
>>>>>>>> assumption is that the trust anchor's authority to issue
>>>>>>>> certificates was verified based on an out-of-band 
>> trust mechanism
>>>>>>>> (which is out of scope for 5280).  This makes sense 
>> since a trust
>>>>>>>> anchor might have distributed a v1 certificate (which does not
>>>>>>>> include extensions).
>>>>>>>>
>>>>>>>> As others have noted, direct trust also implies an out-of-band
>>>>>>>> trust
>>>>>>>> mechanism.  I received the EE certificate from a trusted source
>>>>>>>> so I
>>>>>>>> can trust the binding between the subject name and the key; 
>>>>>>>> issuer
>>>>>>>> name and the signature are irrelevant.   If the certificate 
>>>>>>>> status
>>>>>>>> matters, I am also depending on an out-of-band mechanism to 
>>>>>>>> inform
>>>>>>>> me!  The out-of-band mechanism(s) in combination with protected
>>>>>>>> local storage provide the basis for security in this system...
>>>>>>>>
>>>>>>>> Trying to combine these two mechanisms using a single 
>> certificate
>>>>>>>> store probably requires an additional flag on every entry to
>>>>>>>> differentiate between directly trusted certificates and trust
>>>>>>>> anchors.  Two separate stores might be cleaner in the long run.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Tim Polk
>>>>>>>>
>>>>>>>> On Jun 9, 2008, at 12:29 PM, Bob Bell (rtbell) wrote:
>>>>>>>>
>>>>>>>>> Folks-
>>>>>>>>>
>>>>>>>>> I am hoping someone can give me the answer to this. Does RFC 
>>>>>>>>> 5280
>>>>>>>>> adress the case where an end-entity certificate (not 
>> a CA cert)
>>>>>>>>> is
>>>>>>>>> installed in the trust anchor list by the user accepting the
>>>>>>>>> presented cert as authoritative and then the cert is 
>>>>>>>>> subsequently
>>>>>>>>> presented (in a later access to the site). There should be no
>>>>>>>>> path
>>>>>>>>> search, since the presented cert is in the trust 
>> anchor list. 
>>>>>>>>> So,
>>>>>>>>> where is it defined to accept the end-entity cert?
>>>>>>>>>
>>>>>>>>> Thanks ---- Bob
>>>>>>>>>
>>>>>>>>> Bob Bell
>>>>>>>>> Cisco Systems, Inc.
>>>>>>>>> 576 S. Brentwood Ln.
>>>>>>>>> Bountiful, UT 84010
>>>>>>>>> 801-294-3034 (v)
>>>>>>>>> 801-294-3023 (f)
>>>>>>>>> 801-971-4200 (c)
>>>>>>>>> [email-masked]
>>>>>>>>>
>>

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________