Subject: draft-ietf-pkix-scvp-32.txt

From: "David A. Cooper" <[email-masked]>
Date: Fri, 06 Jul 2007 17:17:16 -0400

All,

I just submitted draft 32 of SCVP for posting.  This draft contains some 
editorial changes to address comments raised as a result of IESG review, 
but there are no changes to the protocol, either syntactic or semantic.  
A diff file comparing drafts 31 and 32 is available at 
http://csrc.nist.gov/pki/documents/PKIX/wdiff_draft-ietf-pkix-scvp-31_to_32.html.

I should note that this draft does not address every issue raised during 
the IESG review.  In particular, there are still outstanding comments 
from Lisa Dusseault relating to the use of HTTP, which is mainly 
specified in Appendix B of SCVP.  Lisa's comments may be found at 
https://datatracker.ietf.org/idtracker/draft-ietf-pkix-scvp/comment/65322.  
If there is someone who has a sufficient knowledge of HTTP to address 
the issues that Lisa raises and who is willing to work with us to 
resolve these issues, that would be appreciated.

Dave

---

From: "Anders Rundgren" <[email-masked]>
Date: Sat, 7 Jul 2007 16:36:54 +0200

Although probably not NIST's intentions with SCVP, I would not be surprised if SCVP long-term will put the final nail in the Bridge CA coffin.

Off-loaded validation is a MUCH better concept since it is fully dynamic, allows arbitrary granularity down to individual EE certificates, and most of all does not rely on a centrally funded/trusted "über-CA".  In fact, a successful rollout of SCVP will probably eliminate most other uses of cross-certification as well.

Anders

----- Original Message ----- 
From: "David A. Cooper" <[email-masked]>
To: "pkix" <[email-masked]>
Sent: Friday, July 06, 2007 23:17
Subject: draft-ietf-pkix-scvp-32.txt

All,

Dave

---

From: Dave Engberg <[email-masked]>
Date: Sat, 07 Jul 2007 08:49:51 -0700

I disagree.

SCVP is a protocol that can make complex PKIs work.  The big problem 
with a federated PKI using bridged and cross-certified CAs is that it 
forces the relying party to do too much work in crawling the CA network 
and checking the revocation of every link.  This has an unacceptable 
risk of failure unless every server and service in the network is 100% 
reliable and available.  SCVP moves the path discovery and validation to 
a server which can be configured to do much more intelligent caching, 
pre-fetching, etc.  SCVP in DPD mode is perfect for this.  As new CAs 
join the bridged network, they will "automatically" be usable by the 
server and clients without having to add yet another hard-coded root CA 
into a massive trust list.

Anders Rundgren wrote:
> Although probably not NIST's intentions with SCVP, I would not be 
> surprised if SCVP long-term will put the final nail in the Bridge CA 
> coffin.
>
> Off-loaded validation is a MUCH better concept since it is fully 
> dynamic, allows arbitrary granularity down to individual EE 
> certificates, and most of all does not rely on a centrally 
> funded/trusted "über-CA".  In fact, a successful rollout of SCVP will 
> probably eliminate most other uses of cross-certification as well.
>
> Anders

---

From: "Anders Rundgren" <[email-masked]>
Date: Sat, 7 Jul 2007 19:22:54 +0200

Dave,

There are many other problems with bridge CAs:

http://csrc.nist.gov/pki/documents/B2B-article.pdf

Although private sector competitors funding a common bridge CA indeed is a cute idea it simply has nothing to do with reality.
Using SCVP (and similar), each company can administer PKI trust in a completely distributed way and being as discriminative they want as well.

The day VISA, Amex and MasterCard cross-certifies each other in order to simplify trust management for merchants, I will though back from my position that "The Bridge CA is dead, long live the Bridge CA".

Regards
Anders Rundgren

----- Original Message ----- 
From: Dave Engberg 
To: pkix 
Sent: Saturday, July 07, 2007 17:49
Subject: Re: draft-ietf-pkix-scvp-32.txt

I disagree.

SCVP is a protocol that can make complex PKIs work.  The big problem with a federated PKI using bridged and cross-certified CAs is that it forces the relying party to do too much work in crawling the CA network and checking the revocation of every link.  This has an unacceptable risk of failure unless every server and service in the network is 100% reliable and available.  SCVP moves the path discovery and validation to a server which can be configured to do much more intelligent caching, pre-fetching, etc.  SCVP in DPD mode is perfect for this.  As new CAs join the bridged network, they will "automatically" be usable by the server and clients without having to add yet another hard-coded root CA into a massive trust list.

Anders Rundgren wrote: 

  Anders

---

From: Peter Sylvester <[email-masked]>
Date: Sun, 08 Jul 2007 15:20:57 +0200

Section 3.2.3  now has reintroduced the 'prospective' certification path.

I think that we had understood that either this term borrowed from
3280 only means an arbitrary sequence of n certificates and that is
not exactly what is desired here.

---

From: "David A. Cooper" <[email-masked]>
Date: Mon, 09 Jul 2007 09:16:00 -0400

> not exactly what is desired here.
Peter,

The paragraph that you are referring to in section 3.2.3 is discussing 
the use of the path building wantBacks (id-stc-build-pkc-path and 
id-stc-build-aa-path), which are described in section 3.2.2 as follows:

    - id-stc-build-pkc-path: Build a prospective certification path to a
       trust anchor (as defined in section 6.1 of [PKIX-1]);
  
 - id-stc-build-aa-path: Build a prospective certification path to a
       trust anchor for the AC issuer;

The description of id-stc-build-pkc-path has been unchanged since draft 
18 and the description of id-stc-build-aa-path has been unchanged since 
draft 24.

Dave

---

From: "Guida, Richard [JJCUS]" <[email-masked]>
Date: Mon, 9 Jul 2007 09:25:35 -0400

Anders - a bridge CA is most certainly not a centrally trusted "Ueber-CA" - in fact to the contrary, a bridge optimally has no self-signed cert and appears in no-ones trust list as an anchor.  That is why it is called a "bridge" - between other CAs.  Bridge CAs and SCVP seem to me to fit together harmoniously and in a complementary fashion.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Anders Rundgren
Sent: Saturday, July 07, 2007 10:37 AM
To: David A. Cooper; pkix
Subject: Re: draft-ietf-pkix-scvp-32.txt

Anders

----- Original Message ----- 
From: "David A. Cooper" <  <mailto:[email-masked]> [email-masked]>
To: "pkix" <  <mailto:[email-masked]> [email-masked]>
Sent: Friday, July 06, 2007 23:17
Subject: draft-ietf-pkix-scvp-32.txt

All,

 <http://csrc.nist.gov/pki/documents/PKIX/wdiff_draft-ietf-pkix-scvp-31_to_32.html> http://csrc.nist.gov/pki/documents/PKIX/wdiff_draft-ietf-pkix-scvp-31_to_32.html.

 <https://datatracker.ietf.org/idtracker/draft-ietf-pkix-scvp/comment/65322> https://datatracker.ietf.org/idtracker/draft-ietf-pkix-scvp/comment/65322.

Dave

---

From: Stephen Kent <[email-masked]>
Date: Mon, 9 Jul 2007 10:30:02 -0400

At 4:36 PM +0200 7/7/07, Anders Rundgren wrote:
>Although probably not NIST's intentions with 
>SCVP, I would not be surprised if SCVP long-term 
>will put the final nail in the Bridge CA coffin.
>
>Off-loaded validation is a MUCH better concept 
>since it is fully dynamic, allows arbitrary 
>granularity down to individual EE certificates, 
>and most of all does not rely on a centrally 
>funded/trusted "über-CA".  In fact, a successful 
>rollout of SCVP will probably eliminate most 
>other uses of cross-certification as well.
>
>Anders
>

David asked a question about HTTP use in SCVP, for which this is NOT an answer.

Try to keep on topic.

Steve

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 10 Jul 2007 15:00:18 +0200

David,

If something hasn't changed since years, this doesn't mean that is correct.
You wrote the following in May 2006 where you indicate that your
understanding of 'prospective path' was not correct.
 
At the end you say 'certification path', but is is a totally arbitary 
sequence
of  certficates. What the protocol allows is that a MIM can create a DOS 
attack
by throwing all kinds of certificates and tell that it has more info in 
case
the client doesn't like.
what defense ha the client, how and when can it detect that something is 
wrong?
It can apply some heuristics, assuming that a server would at least return
certs where the names are chaining, and maybe the signature verify for 
example.
But that is not currently in the protocol.

If you take a directory implementation and a client that searches
in that to build a path, the directory does not return arbitrary certs,
or at least, if it does, the client stops immediately and detects a faulty
behaviour.

Your suggestion is useful but it has not found its way into the text
in any way. Furthermore, because you have misread 3820, I think that
the your citation of the definition of
     id-stc-build-aa-path
also means you had the same error in mind.

I think just encouraging is a little bit weak.
A server MUST return a "propective path" that least verifies some 
conditions.
(which doesn't mean that the client does not verify them).  Otherwise
the client has no means to decide whether to stop talking to the server.

David A. Cooper wrote:
> Peter,
>
> Your initial response to my message was correct.  I simply read RFC 
> 3280 too
> quickly when responding to Thomas's message and quoted the wrong text 
> for the
> definition of prospective certification path.  RFC 3280 does define a
> prospective certification path as a sequence of n certificates and 
> indicates
> that path validation involves (among other things) verifying the items 
> listed in
> a) - d).
>
> I agree that the description of id-stc-build-aa-path should be change 
> to be
> consistent with the description for id-stc-build-pkc-path.  By design, 
> it should
> be possible to operate a DPD server as an untrusted system, which 
> means that the
> client cannot necessarily rely on any of the information returned by 
> the server.
>  The client must perform all of the steps of path validation and 
> cannot assume
> that the path returned by the server satisfies certain conditions.  Of 
> course,
> it would be preferable from the client's point of view for the server 
> not to
> send it invalid certification paths, so I would encourage DPD servers 
> to perform
> at least some checks on the certification paths that they return to 
> clients,
> even if this is not a requirement of the protocol.
>
> Dave
>   

David A. Cooper wrote:
> The description of id-stc-build-pkc-path has been unchanged since 
> draft 18 and the description of id-stc-build-aa-path has been 
> unchanged since draft 24.
>
> Dave
>
>

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 10 Jul 2007 17:01:23 -0400

Peter,

You said "Section 3.2.3  now has *reintroduced* the 'prospective' 
certification path."  I was simply pointing out that this was not a 
change.  Nothing was "reintroduced".

Dave
>> The paragraph that you are referring to in section 3.2.3 is 
>> discussing the use of the path building wantBacks 
>> (id-stc-build-pkc-path and id-stc-build-aa-path), which are described 
>> in section 3.2.2 as follows:
>>

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 11 Jul 2007 12:13:45 +0200

> change.  Nothing was "reintroduced".
indeed, I was incorrect:

The text introduces the word 'prospective' in 3.2.3
in order to make it formally compatible withe 3.2.2.
As a resolution of what we discussed a year ago,
I would have expected something different, i.e. clarifying that

    id-stc-build-aa-path: Build a prospective certification path to a
      trust anchor for the AC issuer

is problematic if one takes the definition of 3280.  3.2.3
said before that the server returns a certificate path (and not just
a set of certs).

>>> (id-stc-build-pkc-path and id-stc-build-aa-path), which are 
>>> described in section 3.2.2 as follows:
>>>