headers
Peter Sylvester | 1 Mar 2002 13:48
Picon
Picon
Favicon

Re: Comments on the DPV-DPD req doc


Denis, chairmen, group,

Ambarish asked:
> 
> 7. Section 7.1 7th para onwards
> 
> I thought the group had recommended against the "cautionary
> period". Are you planning to get rid of these paragraphs?
>  
Denis answered:
> [Answer 16]
> 
> This section is related to your first comment. This is what makes the
> difference between the time T1, where the key was used and the time T2 where
> the revocation information is available. I would guess that the next IETF
> meeting will be the right place to discuss this issue, ... in corridors
> first. 

I think the list is an appropriate place to discuss the issue.

I have the feeling that it has already been settled by the group, 
as far as I remember the working group has already decided that 
cautionary periods are not a subject of this document. 

I will not hang around in the mentioned corridors, even if ...

Anyway, I propose that the chairmen ask for a straw poll concerning actions

1)  "to remove the text in paragraph 7.1 beginning on page 8, starting with
(Continue reading)

Permalink | Reply | 1 comment |
headers
Housley, Russ | 1 Mar 2002 14:26

RE: Validation policy in DPV/DPD rqmts


Mike:

Please post your suggested text.  Based on your message, it should not need 
to be more than a paragraph.  Did I miss something?

Russ

At 10:22 AM 2/28/2002 -0800, Michael Myers wrote:
>Russ, Denis:
>
>After further thought, I see that what I was actually hunting
>for was that set of requirements leading to, among other things,
>assurance of the existence of path validation logic conformant
>to RFC 2459 among *any* technical specification claiming
>conformance to this requirements specification.
>
>I would count among those, for example, an XML-based approach
>towards satisfying these requirements.  While that technology
>platform is at present out of PKIX' scope, the existence of this
>document enables such claims from a PICS-like perspective.
>
>But if "valid" means whatever the policy OID says it means, we
>could see NULL policies, or something along the lines of "that
>individual is no longer in our customer directory, thus the
>certificate is invalid" without any path checking
>whatsoever--basically treating a certificate hash as nothing
>more than a database index. Or scenarios where a certificate may
>have a NULL subject DN, a non-conformant practice according to
>RFC 2459, but is nonetheless "valid".
(Continue reading)

Permalink | Reply | 1 comment |
headers
Yuriy Dzambasow | 1 Mar 2002 16:28

RE: Validation policy in DPV/DPD rqmts


Hi Mike,

Although section 7.1 has defined a bunch of MAYs, it does say this:

"In order to succeed, one valid certification path (i.e., none of the
certificates in the path are expired or revoked) MUST be found between an
end-entity certificate and a trust anchor and all constraints that apply to
the certification path MUST be verified."

I think if you say anything more than this you end up getting into
implementation specific details.

Yuriy

-----Original Message-----
From: owner-ietf-pkix <at> mail.imc.org [mailto:owner-ietf-pkix <at> mail.imc.org]On
Behalf Of Michael Myers
Sent: Thursday, February 28, 2002 5:14 PM
To: Housley, Russ
Cc: ietf-pkix <at> imc.org
Subject: RE: Validation policy in DPV/DPD rqmts

Russ,

Section 7.1 addresses the issues but not in my opinion to useful
degree of clarity.  Additional work in this area might improve
the document.

Mike
(Continue reading)

Permalink | Reply | 1 comment |
headers
Yuriy Dzambasow | 1 Mar 2002 16:51

RE: Comments on the DPV-DPD req doc


I was going to make the same recommendation that Peter has made below, but
instead I will vote FOR the removal of those 2 items.

Yuriy

-----Original Message-----
From: owner-ietf-pkix <at> mail.imc.org
[mailto:owner-ietf-pkix <at> mail.imc.org]On Behalf Of Peter Sylvester
Sent: Friday, March 01, 2002 7:48 AM
To: ietf-pkix <at> imc.org
Subject: Re: Comments on the DPV-DPD req doc

Denis, chairmen, group,

Ambarish asked:
>
> 7. Section 7.1 7th para onwards
>
> I thought the group had recommended against the "cautionary
> period". Are you planning to get rid of these paragraphs?
>
Denis answered:
> [Answer 16]
>
> This section is related to your first comment. This is what makes the
> difference between the time T1, where the key was used and the time T2
where
> the revocation information is available. I would guess that the next IETF
> meeting will be the right place to discuss this issue, ... in corridors
(Continue reading)

Permalink | Reply | 0 comments |
headers
Yuriy Dzambasow | 1 Mar 2002 17:28

More Comments on DPD/DPV Requirements


Some additional comments.  I have separated them into the following
categories: editorial and technical.

Editorial (at least I am assuming these are editorial):

1) Recommend deleting the 2nd paragraph on page 5 (Section 5) for the
following reasons:
	- the first sentence attempts to qualify the preceding paragraph, and in my
opinion, adds no additional value
	- the second sentence contains redundant information already defined two
paragraphs above

2) In section 5, 3rd paragraph it says, "...In that case it is acceptable to
pass the parameters from the path discovery policy with each individual
request, i.e. a set of trust anchors..."  Please change the "i.e." to "e.g."

3) Section 8, first paragraph: The text states that a client can use a
request/response pair to define to a server a "..validation policy and/or a
path discovery policy..."  Please change "and/or" to "or".

4) Change title of 8.1.1 to Certification Path Requirements, so that it is
consistent with the text in section 8.1, item 1.

Technical:

Most of my comments have been addressed (or are being addressed on previous
threads).  I have these three additional comments:

1) Why does DPD say that it is OK to pass some policy parameters within a
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stephen Kent | 1 Mar 2002 17:19
Picon

Re: Validation policy in DPV/DPD rqmts


At 2:56 PM -0800 2/28/02, todd glassey wrote:
>Steve
>
>----- Original Message -----
>From: "Stephen Kent" <kent <at> bbn.com>
>To: "todd glassey" <todd.glassey <at> worldnet.att.net>
>Cc: <ietf-pkix <at> imc.org>
>Sent: Thursday, February 28, 2002 1:37 PM
>Subject: Re: Validation policy in DPV/DPD rqmts
>
>
>>  At 1:24 PM -0800 2/28/02, todd glassey wrote:
>>  >And Steve how many years have you been the WG Chair of this WG?
>>  >
>>  >Todd
>>  >
>>
>>  I've chaired PKIX since it's inception.
>
>My point exactly
>
>>  For comparison, the duration
>>  of my role as chair is less than the amount of time that John Linn
>>  has chaired CAT.
>
>Not a good comparison - CAT is not building technologies to be used in
>commercial transaction standards and you and your WG are, so the work PKIX
>is doing has more than just communications value, it has intrinsic value as
>part of the transaction infrastructrue itself and that is why PKIX is
(Continue reading)

Permalink | Reply | 11 comments |
headers
Yuriy Dzambasow | 1 Mar 2002 16:47

RE: Comments on the DPV-DPD req doc


...snip...

[COMMENT 10]

1. Section 4 2nd paragraph

If a client is asking a server to validate a certificate at
a particular time, that means "was the certificate valid at that
time" (based on information available at that time or information
obtained later). I don't think we should allow it to mean multiple
things.

[Answer 10]

The question is what means the sentence: "Is the certificate valid
at a time T ? ".  Does it mean:

1) valid when compared to the revocation status information that is
   available at that time T (which may not be up to date) ? , or

2) valid for the time T, where the key was used ?

These two times are not always identical and thus the response is
dependant upon the meaning of that time which is left to the policy.
Yuriy> I agree w/ Ambarish.  Since the meaning of the response is dependent
upon policy, we should not try and define the types of responses here.

[COMMENT 11]
(Continue reading)

Permalink | Reply | 0 comments |
headers
Yuriy Dzambasow | 1 Mar 2002 17:39

Should PDP Be a Separate Specification??


It seems to me that it would be more beneficial to have a separate
requirements document for the Policy Definition Protocol (PDP) defined in
the DPD/DPV requirements document, than to integrate into the DPD/DPV
document (which also attempts to address DSV policy requirements).  The
benefits of having a separate PDP requirements document are:

- it focuses solely on policy definition to support protocols such as
DPD/DPV/DSV;
- the DPD/DPV/DSV specification can simply reference PDP as needed
- change control on the specifications are simplified (i.e., PDP changes
don't necessarily force changes to DPD/DPV/DSV)

I'd like to hear thoughts from others on this.

Yuriy
Permalink | Reply | 3 comments |
headers
Michael Myers | 1 Mar 2002 18:03

RE: Validation policy in DPV/DPD rqmts


> -----Original Message-----
> From: Yuriy Dzambasow [mailto:yuriy <at> trustdst.com]
>
> Hi Mike,
>
> Although section 7.1 has defined a bunch of MAYs, it
> does say this:
>
> "In order to succeed, one valid certification path
> (i.e., none of the certificates in the path are
> expired or revoked) MUST be found between an
> end-entity certificate and a trust anchor and all
> constraints that apply to the certification path
> MUST be verified."
>
> I think if you say anything more than this you end up
> getting into implementation specific details.

Yuriy,

Probably so on the policy/operational side. It turns out my real
concern has more to do with establishing a floor on the more
algorithmic aspects of path checking, revocation data
referencing and so forth.  Which, at Russ' invitation, I'm
working on at the moment and will later post to the list a
paragraph of proposed text addressing this issue.

Mike
(Continue reading)

Permalink | Reply | 0 comments |
headers
Yee, Peter | 1 Mar 2002 19:26

RE: I-D ACTION:draft-ietf-pkix-acrmf-00.txt


Stephen,

>What I was thinking was that if you did incorporate that nicely then 
>there'd be no need for LAAP anymore (and since no-one seems to want 
>to produce a new LAAP draft that'd be a happy outcome - if someone
>does, let me know and I'll send you the source).

["that" referring to a mechanism to request an AC be issued under a
pre-agreed policy].

I'm adding a new control attribute which allows the requester to specify
how the requested attribute set may be modified by the AA (or LARA).  One
option will be that the attributes are to be issued according to policy.
I'm putting in a policy OID carrier, but if that (optional) OID is not
present, then I'm specifying that the default procedure is to fallback
to a pre-agreed policy.  A bit hidden in the overall machinations, but
I believe that would cover the LAAP-usage case.  Would that suffice for
your needs?

							-Peter
Permalink | Reply | 1 comment |

Gmane