Subject: RE: DPD & DPV requirements

From: "Covey, Carlin" <[email-masked]>
Date: Thu, 11 Jan 2001 09:55:32 -0800

Skip,

Skip, thanks for posting this.  This is clearly a valuable use case.

I agree that "relay" is a better term for this case than the term
"recursion," which I just meant to apply to one form of the data
structure in which the relayed data might be returned.

Regards,

Carlin

------------------------
-  Carlin Covey
   Cylink Corp.

-----Original Message-----
From: Slone, Skip [mailto:[email-masked]]
Sent: Thursday, January 11, 2001 10:39 AM
To: 'Stephen Kent'
Cc: PKIX-List
Subject: RE: DPD & DPV requirements

Steve,

The scenario I'm envisioning would be easiest to describe with the aid of a
whiteboard, cocktail napkin, or similar medium.  But, alas, I'm restricted
to email at the moment, so I'll do the best I can to draw a good mental
picture...

What I'm envisioning is a typical scenario that companies will face in the
B2B space over the coming years.  Imagine a diagram with an Intranet cloud
on one each side, with those two clouds each connected, via a firewall, to
the Internet, which is drawn in the middle.  In that environment, any
traffic that goes from Intranet A to Intranet B must traverse two firewalls
to get to its destination.

Now, fast forward a few years and you'll see that what we now call firewalls
have morphed into full-fledged boundary service environments, complete with
inward and outward facing portals and a whole bunch of servers of various
sorts, servicing the needs of each enterprise at its respective boundary.
Glossing over a lot of details, I think it's reasonable to think that
DPV/DPD servers (mostly DPV) can play a huge role in this boundary service
environment.  

Looking at the in-bound side, it's reasonable to assume that in the presence
of this capability, some companies will choose to provide DPV servers at
their boundaries and to prohibit direct in-bound traversal of their
boundaries for path discovery/validation purposes. Further, it is reasonable
to assume that companies that err of the side of paranoia will only service
DPV requests coming from known (i.e., preconfigured) sources, such as DPV
servers on the boundaries of known trading partners.

On the out-bound side, many companies currently restrict direct out-bound
access to nearly anything, requiring proxies and similar relay services
instead. As we move forward, I see this kind of restriction likely to
increase.  Thus, relying parties inside a network who need to validate
external certificates may find very few paths available for the various
steps involved in path discovery and validation (most likely a combination
of not-so-basic-DNS, LDAP, HTTP, and FTP interactions). By making path
validation available on the boundary, companies will find an attractive
alternative.  Internal RPs will be able to simply delegate the task to a
boundary-resident DPV server.

Putting the two sides of this equation together and looking at a typical B2B
scenario, we find the following case in which a relying party in Company A
needs to validate a Company B path: the RP delegates its request to the DPV
server residing on Company A's boundary.  Company A's DPV server (since it
doesn't have direct access to Company B's network) will delegate to the DPV
server residing on Company B's boundary.  Company B's DPV server will then
access the internal resources in Company B's network, perform all the
necessary discovery and validation work and return the result back upstream.

As for the need to constrain the number of relays (on further reflection,
"relay" seems like a better fit than "recursion"), consider the following.
In the scenario above, there is a need to relay the delegation exactly one
time. Thus, the RP inside A needs to allow a one-hop relay, but it may wish
to preclude paths longer than that, in order to prevent getting to Company B
by first going through Companies X, Y, and Z.  On the other hand, it may be
appropriate for a third party to be involved in the relay (industry
consortium, bridge, TTP, etc.), which would make it appropriate to be able
to specify two hops (or some other number as the situation warrants).

That's it for now... thanks for listening.

 -- Skip

---

From: Frank Balluffi <[email-masked]>
Date: Thu, 11 Jan 2001 13:03:22 -0800

Earlier, I said:

> For XML applications, each valid path should be returned by 
> reference (e.g.,
> as an ordered collection of issuer + serial number + ...) and 
> optionally as
> an opaque element (e.g., base-64 encoded SEQUENCE OF 
> Certificate).

In this case, each element in the path might include its subject and public
key (e.g., issuer + serial number + subject + public key).

Frank

---

From: Frank Balluffi <[email-masked]>
Date: Mon, 15 Jan 2001 07:02:35 -0800

Frank Balluffi said:

>Would it be valuable for a client to be able to supply the end-entity
>certificate and the trusted certificate in the path?

Steve Kent said:

> What if we say that the chain could be partial?
> 
> A trust point (anchor) is a root and the client can specify one or 
> more of these as part of the path validation parameter set, 
> explicitly or via reference.

Steve Hanna said:

> One good reason to allow the client to supply to a DPD server an
> arbitrary collection of certificates is that this is exactly what's
> delivered in a signed S/MIME message: a bunch of certificates that may
> be useful in building a path from a trust anchor to the 
> sender. Multiple
> intermediate certificates are explicitly allowed.

Steve Kent said:

> OK, that's a good argument! The argument to the server then would be 
> a lump (a new ASN.1 construct) of certs, with no implied ordering, 
> and the server if left to sort it out.   If a partial or complete 
> chain is sent, it is a valid example of the lump of certs model, 
> which happens to be ordered already. I could live with that.

A lump of certs makes sense to me.

Frank

---

From: Russ Housley <[email-masked]>
Date: Mon, 15 Jan 2001 12:20:39 -0500

Steve:

S/MIME has such a construct.  From RFC 2630:

10.2.2  CertificateChoices

    The CertificateChoices type gives either a PKCS #6 extended
    certificate [PKCS#6], an X.509 certificate, or an X.509 attribute
    certificate [X.509-97].  The PKCS #6 extended certificate is
    obsolete.  PKCS #6 certificates are included for backward
    compatibility, and their use should be avoided.  The Internet profile
    of X.509 certificates is specified in the "Internet X.509 Public Key
    Infrastructure: Certificate and CRL Profile" [PROFILE].

    The definitions of Certificate and AttributeCertificate are imported
    from X.509.

       CertificateChoices ::= CHOICE {
          certificate Certificate,                 -- See X.509
          extendedCertificate [0] IMPLICIT ExtendedCertificate,
                                                   -- Obsolete
          attrCert [1] IMPLICIT AttributeCertificate }
                                                   -- See X.509 and X9.57

10.2.3  CertificateSet

    The CertificateSet type provides a set of certificates.  It is
    intended that the set be sufficient to contain chains from a
    recognized "root" or "top-level certification authority" to all of
    the sender certificates with which the set is associated.  However,
    there may be more certificates than necessary, or there may be fewer
    than necessary.

    The precise meaning of a "chain" is outside the scope of this
    document.  Some applications may impose upper limits on the length of
    a chain; others may enforce certain relationships between the
    subjects and issuers of certificates within a chain.

       CertificateSet ::= SET OF CertificateChoices

Russ

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 17 Jan 2001 14:15:06 +0100 (MET)

Frank wrote:

> I'm confused. Are people saying that the certificate whose path the client
> would like to discover or validate is in the unordered lump of certificates
> or that a separate lump of certificates may be sent to assist the server? I
> thought the latter.

This is not quite clear to me either. 

Before going to specify a syntax we should state it differently,
here some ideas:

- A client may indicate one or more certificates to be validated.

- 1 - Each certificate may be accompagnied by a 'lump' of certificates
      that may assist the server to find a valid path for that
      particular certificate.  

  2 - There may be an additional bunch of certificates that may be
      used by the server to determine valid paths.  

I tended to have 1, because for different certs the paths may be
different, but I may be wrong since even if one throws all the
different hints in 1 into one bag, the server could probably
find out the good stuff anyway. 

Peter

---

From: "Slone, Skip" <[email-masked]>
Date: Wed, 17 Jan 2001 08:59:42 -0500

Thanks, Steve. I'm not wedded to a particular solution either -- I'll just
keep an eye on things from the perspective of my particular requirements.

 -- Skip

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Tuesday, January 16, 2001 9:04 PM
To: Slone, Skip
Cc: PKIX-List
Subject: RE: DPD & DPV requirements

Skip,

>Steve,
>
>Judging from your response, I think I did both of us a disservice by
>providing too many details from my stream of consciousness.  Here's the
>distilled essence of what I intended to say:
>
>In your requirements document you wrote, "Finally, this analysis suggests
>that there are relatively few differences between a DPD and a DPV server
...
>[T]he WG must decide if two distinct protocol formats, with different
syntax
>are warranted, or if a single [one] is appropriate."  You then went on to
>conclude that they were sufficiently similar to justify a single set of
>requirements.
>
>Based on the way the discussions have gone, I'm questioning this
conclusion.
>By separating the two, DPV could focus on simplicity and efficiency (to
>better serve highly constrained clients), while DPD focuses on completeness
>(to serve the needs of highly capable, but perhaps contextually constrained
>clients). DPV could consume DPD services, creating a complete solution to a
>wide range of problems.
>
>It is this last paragraph that I'd like comment on. Without some sense of
>agreement at this conceptual level, it's fruitless to dig into details.
>

I think we are seeing some divergence in arguments for the two types 
of servers, wrt queries and responses. They may be small enough to 
use a unified format with options, or we may have two distinct 
formats with a lot of overlap.  I'm not wedded to either approach. 
But, the need for both severs to perform path validation still seems 
to be true.

Steve

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 19 Jan 2001 11:06:44 +0100 (MET)

> >
> >Not necessarily: If the DPV server just has to say Yes/No, then
> >it may not be PKI aware.
> 
> Huh? The DPV server says yes or no based on evaluation of the path 
> relative to specified parameters, and based on available revocation 
> status data.  How does it do this if is is not PKI aware?
You are right. 

> I too remain curious since it has been my assertion all along, as expressed
> in the DPV draft, that a DPV server is in fact a concentrator of PKI
> "awareness".\
>
You are right, too.  

Im my view the 'DPV' server says yes or now about concerning the
validity and trustworthiness of a certificate. The client does not
necessarily care how he server came to that conclusion.

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 23 Jan 2001 19:59:10 +0100 (MET)

> 
> I do not think that we want client applications to issue cross-certificates 
> as a means of building their certificate trust list.  I guess that an 
> implementor could do it that way, but it certainly should not be required.

It is not the DPV client, the relying party is delegated to the
DPV server.  

> 
> And, how would the subscriber get a certificate with the basic constraints 
> of CA=TRUE?

I just make one, I am *THE* root:

What subscriber? The DPV server can just be its 'own' CA, i.e., there the
configuration management for a DPV server can consist of not giving a
list of trusted roots, but install one fixed DPV-TRUST-CA cert, and the
operator of that CA issues cross certs. 

The path validation algorithm in X.509 starts with an empty naming constraint list.
Why should one add more?

Regards
Peter