Subject: Re: Unsigned DPD responses for SCVP15

From: Russ Housley <[email-masked]>
Date: Tue, 13 Jul 2004 12:38:56 -0400

My personal preference Option #2; however, I think that absence of this 
flag should indicate that the response should be signed.  One needs to make 
a guess about deployment to select the best semantic for this situation, 
and my guess is that server authentication will be important.

Russ

Trevor Freeman wrote:
>I have been asked to add unsigned responses for DPD clients to SCVP15. 
>There are two models proposed on how we accomplish that both of which meet 
>the requirements for 3379. I would therefore like some feedback on how the 
>group views the two mechanisms
>
>Global Server Policy that it is DPD only
>The first proposal is to make the option controlled by the server as a 
>global policy. Therefore the server would publish via policy that is only 
>supports DPD as such never signs a response. DPV client and DPD clients 
>wanting a signed response then know to use another server.
>
>SCVP Request option to not sign response
>The second option is to leave it to the client to signal to the server it 
>does not need a signature on the response by a new flag in the request (or 
>its twin the flag indicates it does want a signature on the response). 
>This allows clients to be benevolent towards the server by asking it to 
>skip the signature. Server can still at their discretion still sign.
>
>Needless to say it is possible to hybridize the two but I am hopeful we 
>can try and keep this as simple as possible be picking on of the two.
>Trevor

---

From: "Michael Myers" <[email-masked]>
Date: Tue, 13 Jul 2004 10:38:27 -0700

Russ,

As you know, I disagree on the default.  My point is that DPD as
originally conceived and further defined by the requirements
RFC is to a first degree simply a proxy for the various
protocols and schemas devised over the years to acquire these
data.

I can live with the default as defined but I think it is useful
and necessary to establish why super-signing of previously
signed data is a good thing.  Hypothetical replay attacks have
been proposed.  OK, fine.  So we have a flag that enables an
environment to assert source authenticity so those become
reality.

But these data, i.e. {path, rev-info}, are not only signed but
dated with respect to their reliability.  That was the basis of
the original theory behind the notion that these data can be
made public without any concern for their source.  I have yet to
hear a refutation of those prior assumptions.

If source authenticity in important in this instance, does that
then mean all extant protocols and schemas are at risk?  If so,
why?

Mike

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Russ Housley
Sent: Tuesday, July 13, 2004 9:39 AM
To: [email-masked]
Subject: Re: Unsigned DPD responses for SCVP15

My personal preference Option #2; however, I think that absence
of this
flag should indicate that the response should be signed.  One
needs to make
a guess about deployment to select the best semantic for this
situation,
and my guess is that server authentication will be important.

Russ

---

From: Russ Housley <[email-masked]>
Date: Tue, 13 Jul 2004 16:53:30 -0400

In DPD, the server is doing more than just returning signed objects.  The 
server is constructing a certification path too.  In a world with 
cross-certification and bridge CAs, there can be more than one choice for 
valid paths.  This is a topic that has received plenty of discussion 
elsewhere, and I hope we do not need to revisit all of the nooks and 
crannies of that topic here.  So, a different collection of signed object 
can be returned, each of which is valid, and each of which represents a 
different amount of effort on the part of the client to validate.  Given 
this situation, I believe that the client will want to be able to confirm 
the source of the path.

Russ

---

From: "Michael Myers" <[email-masked]>
Date: Tue, 13 Jul 2004 14:47:37 -0700

Russ,

So what if no optional parameters are present in the request to
facilitate path navigation?  What if all the defined ASN.1 defaults are
taken?  What if its a simple enterprise-level issue?  Does it not make
sense to default to the larger case, and to reserve an upscope in
security diligence to those environments subject to cross-domain source
authenticity concerns? Or is the latter the larger case? I argue that,
in the absence of the flag, should it come to pass in -15, SCVP
responses containing ONLY {path, rev-info} MAY be signed.

Mike

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Tuesday, July 13, 2004 1:54 PM
To: Michael Myers; [email-masked]
Subject: RE: Unsigned DPD responses for SCVP15

In DPD, the server is doing more than just returning signed objects.
The
server is constructing a certification path too.  In a world with
cross-certification and bridge CAs, there can be more than one choice
for
valid paths.  This is a topic that has received plenty of discussion
elsewhere, and I hope we do not need to revisit all of the nooks and
crannies of that topic here.  So, a different collection of signed
object
can be returned, each of which is valid, and each of which represents a
different amount of effort on the part of the client to validate.  Given
this situation, I believe that the client will want to be able to
confirm
the source of the path.

Russ

---

From: Tim Polk <[email-masked]>
Date: Wed, 14 Jul 2004 09:50:28 -0400

I also prefer the client-side flag option.  However, I *strongly* believe 
that the default behavior (i.e., in the absence of the flag) should be 
"signature is REQUIRED" on the SCVP response.

In this way, the default behavior for SCVP always satisfies the 
requirements specified in RFC 3379.   Where the client has explicitly 
determined that source authentication is not required, the client may 
explicitly state this.

I believe this option boils down to four fairly simple statements.

(1) Where an SCVP request omits the "not going to authenticate" flag, the 
server is required to sign the response or return an error.

(2) Where an SCVP request includes the flag, the server may include or omit 
the signature on the response.  (So, a server that *always* signs responses 
doesn't need to process this flag...)

(3) An SCVP client MUST NOT assert the "not going to authenticate" flag and 
request a statement about validity.

(4) Where the request did not assert the new flag, the SCVP client MUST 
process the digital signature on a response.

I believe these changes would result in a protocol whose default behavior 
satisfies all the requirements in 3379, permits the employment of unsigned 
messages for DPD, and precludes any ambiguity in the implementation of 
mixed mode servers.

Tim Polk

At 12:38 PM 7/13/2004 -0400, Russ Housley wrote:

>flag should indicate that the response should be signed.  One needs to 
>make a guess about deployment to select the best semantic for this 
>situation, and my guess is that server authentication will be important.
>
>Russ
>
>
>Trevor Freeman wrote:
>>There are two models proposed on how we accomplish that both of which 
>>meet the requirements for 3379. I would therefore like some feedback on 
>>how the group views the two mechanisms
>>
>>does not need a signature on the response by a new flag in the request 
>>(or its twin the flag indicates it does want a signature on the 
>>response). This allows clients to be benevolent towards the server by 
>>asking it to skip the signature. Server can still at their discretion 
>>still sign.
>>

---

From: Russ Housley <[email-masked]>
Date: Wed, 14 Jul 2004 10:02:01 -0400

Mike:

Different servers will have different default path discovery policies.

RFC 3379 says:

    For the client to be confident that all of the elements from the
    response originate from the expected DPD server, an authenticated
    response MAY be required.  For example, the server might sign the
    response or data authentication might also be achieved using a
    lower-layer security protocol.

So, all we are discussing is whether the protocol requirement in this MAY 
statement is the default or not.

Russ

---

From: "Michael Myers" <[email-masked]>
Date: Wed, 14 Jul 2004 08:35:54 -0700

Yes.  I'm all for the flag.  And I said, I can live with the default as
defined.  So I'll just leave it at that.

Mike

-----Original Message-----
Sent: Wednesday, July 14, 2004 7:02 AM

Mike:

RFC 3379 says:

So, all we are discussing is whether the protocol requirement in this
MAY
statement is the default or not.

Russ

---

From: "Michael Myers" <[email-masked]>
Date: Wed, 14 Jul 2004 09:16:55 -0700

I would add one other requirement.  Clients MUST be capable of asserting
the flag.

Mike

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Tim Polk
Sent: Wednesday, July 14, 2004 6:50 AM
To: Russ Housley; [email-masked]
Subject: Re: Unsigned DPD responses for SCVP15

I also prefer the client-side flag option.  However, I *strongly*
believe
that the default behavior (i.e., in the absence of the flag) should be
"signature is REQUIRED" on the SCVP response.

(1) Where an SCVP request omits the "not going to authenticate" flag,
the
server is required to sign the response or return an error.

(2) Where an SCVP request includes the flag, the server may include or
omit
the signature on the response.  (So, a server that *always* signs
responses
doesn't need to process this flag...)

(3) An SCVP client MUST NOT assert the "not going to authenticate" flag
and
request a statement about validity.

I believe these changes would result in a protocol whose default
behavior
satisfies all the requirements in 3379, permits the employment of
unsigned
messages for DPD, and precludes any ambiguity in the implementation of
mixed mode servers.

Tim Polk

---

From: Tim Polk <[email-masked]>
Date: Wed, 14 Jul 2004 14:17:44 -0400

Mike,

Geez... read your last message and thought we were done!

I don't believe this requirement is necessary.  An SCVP client that doesn't 
perform local path validation (i.e., a DPV client *only*) doesn't need to 
be able to assert this flag.  An SCVP client that is designed to always 
perform local path validation (i.e., DPD *only*) might be designed so this 
was configurable, or could be designed to always assert this flag.

Let's drop this one and claim victory/bipartisan agreement/etc...

Thanks,

Tim

---

From: "Michael Myers" <[email-masked]>
Date: Wed, 14 Jul 2004 11:57:23 -0700

I thought we were done too until I read more carefully your proposed
text.  I do believe the requirement is necessary or I wouldn't have
brought it up.  The need to assert the flag cannot be 100% predicted
ahead of time.  Given the presumptive definition of the flag, I believe
interoperability would benefit.  It doesn't say the flag must be used,
but only that the capability we all worked so hard on to define is an
assumption rather than a stovepipe.

Mike

-----Original Message-----
From: Tim Polk [mailto:[email-masked]]
Sent: Wednesday, July 14, 2004 11:18 AM
To: Michael Myers; Russ Housley; [email-masked]
Subject: RE: Unsigned DPD responses for SCVP15

Mike,

I don't believe this requirement is necessary.  An SCVP client that
doesn't
perform local path validation (i.e., a DPV client *only*) doesn't need
to
be able to assert this flag.  An SCVP client that is designed to always
perform local path validation (i.e., DPD *only*) might be designed so
this
was configurable, or could be designed to always assert this flag.

Thanks,

Tim

At 09:16 AM 7/14/2004 -0700, Michael Myers wrote:
> >>The second option is to leave it to the client to signal to the
server
>it

---

From: "Terry Hayes" <[email-masked]>
Date: Wed, 14 Jul 2004 12:14:32 -0700

Mike,

The client should not be required to have this capability.  If a client applicatio will never assert the flag because of its operating environment and policy, why should it be required to implement code that can set it?  The need to assert the flag (or not) can be predicted ahead of time in some environments.

Terry

---

From: Russ Housley <[email-masked]>
Date: Wed, 14 Jul 2004 15:13:51 -0400

There is no need for DPV clients to assert the flag!

Russ

---

From: "Michael Myers" <[email-masked]>
Date: Wed, 14 Jul 2004 12:31:54 -0700

True, SCVP clients that assert the OID that drives a server to produce a
validity assertion MUST accept and process a signature.  But assuming
that same client is also implemented to assert simply a return of {path,
rev-info}, then it seems reasonable to assume it should also be capable
of asserting the flag.

Mike

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Wednesday, July 14, 2004 12:14 PM
To: Michael Myers; Tim Polk; [email-masked]
Subject: RE: Unsigned DPD responses for SCVP15

Russ

server

---

From: Russ Housley <[email-masked]>
Date: Wed, 14 Jul 2004 15:37:27 -0400

I do not accept your assumption.  I expect many clients to be DPV-only.

Russ

---

From: "Michael Myers" <[email-masked]>
Date: Wed, 14 Jul 2004 13:03:33 -0700

I'm not sure that can be predicted to such a degree.

When Carlisle Adams, Stephen Farrell and I first addressed introduced
DPV and DPD to the WG, it was Stephen who was forceful in convincing
Carlisle and I that one of the most difficult issues wrt PKI was simply
acquiring the data necessary to path validation.  This was due in no
small part to the various protocols and schemas associated with that
process, as now amply documented in 3379.  Further, a "client" is not
just, for example, a web browser.  It could be amalgamation of back
office mechanisms, AAA, Radius and what have you.  I suspect there might
come to exist a non-trivial number of such instances.

Also, are you saying that in your view an SCVP client is compliant if it
fails to allow use of id-stc-build-pkc-path in CertChecks syntax and
id-swb-pkc-cert-path and id-swb-pkc-revocation-info in the WantBack
syntax?

Mike

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Wednesday, July 14, 2004 12:37 PM
To: Michael Myers; Tim Polk; [email-masked]
Subject: RE: Unsigned DPD responses for SCVP15

Russ

---

From: Russ Housley <[email-masked]>
Date: Wed, 14 Jul 2004 17:10:28 -0400

Mike:

Recently, I have done a fair amount of work in the wireless space, and I am 
convinced that clients on these devices with limited processing 
capabilities will make use of DPV.  So, maybe what we need is a profile at 
the end of the document that lists the features that must be implemented to 
be considered a DPV client, a DPV server, a DPD client, and a DPD 
server.  This should be pretty easy to put together, although I doubt that 
it can be done before the draft deadline for the San Diego meeting.

Russ

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 15 Jul 2004 15:14:03 -0700

Russ,

Seems a matter for San Diego at this point.

Mike

-----Original Message-----
Sent: Wednesday, July 14, 2004 2:10 PM

Mike:

Recently, I have done a fair amount of work in the wireless space, and I
am
convinced that clients on these devices with limited processing
capabilities will make use of DPV.  So, maybe what we need is a profile
at
the end of the document that lists the features that must be implemented
to
be considered a DPV client, a DPV server, a DPD client, and a DPD
server.  This should be pretty easy to put together, although I doubt
that
it can be done before the draft deadline for the San Diego meeting.

Russ

At 04:03 PM 7/14/2004, Michael Myers wrote:
> >True, SCVP clients that assert the OID that drives a server to
produce
>a

---

From: Tim Polk <[email-masked]>
Date: Fri, 16 Jul 2004 10:29:20 -0400

Mike,

If the client is implemented to permit asserting simply a return of {path,
rev-info}, then it is required to be capable of asserting the flag.

That is different from requiring this for all clients.

Tim

---

From: Tim Polk <[email-masked]>
Date: Fri, 16 Jul 2004 10:38:54 -0400

Mike,

Why delay to San Diego?

Really, it makes no sense to require a DPV client to be capable of 
asserting a flag that will incur a response it cannot hope to 
process!!!  That is the result if a client that does not implement path 
validation asserts that flag!

I strongly believe that:

(1) some clients will be DPV-only since they will not include an X.509 path 
validation module, and need not implement the flag at all;

(2) some clients will be designed for unsigned DPD only, and will be 
hard-wired to assert the flag; and

(3) some clients will support unsigned DPD as well asat least one of (a) 
signed DPD and (b) DPV, and will need to implement flag and provide 
configuration

Let's forward a spec that reflects this reality.

Tim

---

From: "Michael Myers" <[email-masked]>
Date: Fri, 16 Jul 2004 16:11:28 -0700

Tim,

I think a face-to-face is useful in this instance.

Mike

-----Original Message-----
Sent: Friday, July 16, 2004 7:39 AM

Mike,

Why delay to San Diego?

I strongly believe that:

(1) some clients will be DPV-only since they will not include an X.509
path
validation module, and need not implement the flag at all;

Tim