Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-01.txt

From: "Housley, Russ" <[email-masked]>
Date: Wed, 16 Jan 2002 09:39:48 -0500

Petra and Denis:

The structure of SCVP makes it very easy to add support of attribute 
certificates (or PGP certificates for that matter) at a later date.  We 
need to make sure that there is a constituency for the protocols we develop 
for the standards track.

Russ

At 12:36 PM 1/16/2002 +0100, Denis Pinkas wrote:

>Petra,
>
> > Yes, thanks for the pointer. I found the ASN.1 definitions there.
> >
> > One more question turned up:
> > Is DPV restricted to X.509 public key certificates or is it possible
> > to use it for X.509 attribute certificates as well?
>
>Clearly, both the DPV-DPD protocol draft and the DPV-DPD requirement draft
>have been specifically written to support PKIX public key certificates.
>
>At the last IETF meeting a question has been raised to the audience:
>Who, in the room, has implemented Attribute Certificates ?
>No hand showed up.
>
>So it seems that there is no urgence to support PKIX attribute
certificates.
>
>However, maybe by making some changes, PKIX attribute certificates could be
>supported, but this is an exercise that I have not undertaken.
>
>The basic question is thus whether to include the support of attribute
>certificates in the current DPV-DPD requirement draft.
>
>Unless you, or someone else, can rapidly provide arguments and demonstrate
>that it will not delay the support of PKIX public key certificates, I would
>rather think that it should not be included at this time.
>
>Regards,
>
>Denis
>
>
> > - Petra
> >
> > Denis Pinkas schrieb:
> >
> > > Petra,
> > >
> > > Please take a look at RFC 3126, where many of the ASN.1 structures
were
> > > imported from and are thus defined there. This should answer all your
> > > questions.
> > >
> > > Regards,
> > >
> > > Denis
> > >
> > > > Denis,
> > > >
> > > > may I still ask some questions concerning the document "Delegated
> > > > Path Validation and Delegated Path Discovery Protocols" ?
> > > >
> > > > > PathValues :: = SEQUENCE {
> > > > >        certificateValues      CertificateValues,
> > > > >        revocationValues       RevocationValues }
> > > > >
> > > > I'm missing some ASN.1 definitions. You refer to "CertificateValues"
> > > > and "RevocationValues" but I couldn't find these definitions.
> > > >
> > > > By the way, you should move this definition of "PathValues" from
> > > > the chapter "5.2.1. Request" to the chapter "5.2.2.  Response
Syntax"
> > > > where it is used.
> > > >
> > > > Another ASN.1 question:
> > > >
> > > > > UsefulRevoc ::= CHOICE {
> > > > >        certificateRevocationLists     CertificateRevocationLists,
> > > > >        completeRevocationRefs         CompleteRevocationRefs }
> > > > >
> > > > A DPV request may contain useful revocation information provided
> > > > by the client. Maybe it's because I don't know the element
> > > > "CompleteRevocationRefs" but where do I store OCSP answers?
> > > >
> > > > Could you please send the definition of "CompleteRevocationRefs"
> > > > and "completeCertificateRefs"? I guess they are imported from
[ES-F],
> > > > "Electronic Signature Formats for long term electronic signatures", 
> aren't
> > > > they?
> > > >
> > > > >    CertOrCertRef ::=  CHOICE {
> > > > >        certificate          [1]  Certificate,
> > > > >        certRef              [2]  OtherCertID }
> > > > >
> > > > I'm also missing the definition of OtherCertID used in a DPV and DPD
> > > > request.
> > > >
> > > > Thanks, Petra
> > > >
> > > > Denis Pinkas schrieb:
> > > >
> > > > > Petra,
> > > > >
> > > > > > Denis,
> > > > >
> > > > > > is there also a new version of the document "Delegated Path
> > > > > > Validation and Delegated Path Discovery Protocols"
> > > > >
> > > > > Not at this time. Currently we need first to agree on the DPV /
DPD
> > > > > requirements, then we will discuss the solutions to these 
> requirements.
> > > > >
> > > > > The so-called "Delegated Path Validation and Delegated Path
Discovery
> > > > > Protocols" document could be a candidate to fulfill these 
> requirements.
> > > > > It is too early to say and this will only be discussed once the
> > > > > requirements
> > > > > document is adopted.
> > > > >
> > > > > > or just a new requirement document?
> > > > >
> > > > > Correct. It is a new document for both the DPV and DPD
requirements.
> > > > >
> > > > > There is also a companion document for the DSV requirements.
> > > > > We will only discuss the DSV requirements document in detail when
> > > > > the DPV / DPD requirements document has completed the WG last
call.
> > > > > Denis

============================================================================
================
This e-mail, its content and any files transmitted with it are intended
solely for the addressee(s) and are PRIVILEGED and 
CONFIDENTIAL.  Access by any other party is unauthorized without the express
prior written permission of the sender.  If 
you have received this e-mail in error you may not copy, disclose to any
third party or use the contents, attachments or 
information in any way, Please delete all copies of the e-mail and the
attachment(s), if any and notify the sender. 
Thank You.
============================================================================
================

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 17 Jan 2002 11:05:14 +0100

Russ,

> certificates (or PGP certificates for that matter) at a later date.  

We are not talking of solutions at this time, but only of requirements. 
So the question is whether we add in the requirements document some text 
to cover attribute certificates. If we do, which text ?

We have not say, at this time, whether SCVP or some flavor of it, will be
the protocol that answers to these requirements.

Denis

> We need to make sure that there is a constituency for the protocols 
> we develop for the standards track.
> 
> Russ
>

---

From: "Housley, Russ" <[email-masked]>
Date: Thu, 17 Jan 2002 08:56:48 -0500

>to cover attribute certificates. If we do, which text ?

I raised this question in Salt Lake City.  The group did not want to 
address DPV for attribute certificates at this time.  The point that I was 
trying to make above is that the protocol design allows us to easily add 
this support in the future.

>the protocol that answers to these requirements.

It is not a requirement!

Russ

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 17 Jan 2002 15:12:26 +0100

> address DPV for attribute certificates at this time.  

Good, I did not remembered, 
... since the meeting report has not yet been distributed to the list. :-(

> The point that I was

No protocol has been elected at this time, so this sentence is still not
appropriate. Let us close this debate.

Denis

---

From: Petra Barzin <[email-masked]>
Date: Thu, 17 Jan 2002 17:15:43 +0100

Denis,

in Germany there are implementations of attribute certificates.

But they are not relevant for us now. Nevertheless I would like

to see that the protocol design allows us to use it for attribute

certificates as well when they might become a requirement.

In the requirement document you already talk about "any kind of

certificate". My proposal is: just add the different types in brackets.

3. Rational and benefits for DPV (Delegated Path Validation)

DPV allows to perform a real time validation for a time T for any kind
of certificate and any kind of security service.

The DPV/DPD draft only allows for X.509 public key certificates.

I guess you will update this when the requirement document is stable,

don't you?

- Petra

Denis Pinkas schrieb:

Russ,

So the question is whether we add in the requirements document some
text

We have not say, at this time, whether SCVP or some flavor of it, will
be

Denis

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 17 Jan 2002 17:29:38 +0100

Petra,

See my response to Russ on this topic. We are not going to make any
requirement for Attribute Certificates at this time or "when the document is
stable".

Denis

---

From: Petra Barzin <[email-masked]>
Date: Sat, 19 Jan 2002 17:32:23 +0100

Denis,

I carefully read draft-ietf-pkix-dpv-dpd-00.txt because we are

probably going to use it in order to build such a PKI server.

I noticed some typos in the draft and would like to suggest some

changes.

Best regards - Petra

chapter 5.2. Detailed Protocol

The terms imported from elsewhere are: Extensions,
CertificateSerialNumber, SubjectPublicKeyInfo, Name,
AlgorithmIdentifier, CRLReason, CompleteCertificateRefs,
CompleteRevocationRefs.

Three more terms need to be imported:

OtherCertID, CertificateValues, RevocationValues

chapter 5.2.1. Request

ValPolicyID :: = CHOICE {
policybyOId               OBJECT IDENTIFIER,
policybyURN               NAME }

What is the ASN.1 term "NAME"?  I only know Name, which is

a Distinguished Name. Anyhow, I'd suggest to use a GeneralName

instead of NAME:

policybyURN
GeneralName

The value for valPolicyHash SHALL be computed on the
hash of the DER encoding of ValidationPolicyDef when ...

I guess you meant:

... DER encoding of ValPolicyDef, don't you?

ValPolLocations :: = SEQUENCE OF Name

Again, I'd suggest to use a GeneralName:

ValPolLocations :: = SEQUENCE OF GeneralName

Move the definition to chapter 5.2.2.  Response Syntax

where it is used.

validationPolicyRef is a reference to the validation
policy to be used.

I guess, it should be:

valPolicyRef is a reference to ...

Later on in the same paragraph:

... It is composed of an OID or a URN, the hash
algorithm to be used to compute the hash value of
the policy and the hash value of the policy.

add at the end of the sentence:

and optionally the locations where the policy may be retrieved from.

chapter 5.2.2.  Response Syntax

The value for returnedRefsHash SHALL be computed
on the hash of the DER encoding of CertPathRefs.

Just a typo. I think it should be:

The value for pathReferencesHash SHALL ...

To make it easier to understand you could add at the end of the sentence:

... CertPathRefs which are part of the DPVResponse.

The same for the next sentence:

The value for returnedValuesHash SHALL be computed
on the hash of the DER encoding of CertPathValues

The value for pathValuesHash SHALL ...

Again you could add at the end of the sentence:

... CertPathValues which are part of the DPVResponse.

pathReferencesHash is a hash computed over the references of the path
(both the references of the certificates used and the references of
the revocation information used). It may also include a sequence of
time-stamps, if this has been requested in the request. Since only
the hash is included in the signature, this allows to keep signatures
short and does not mandate to know the values of the references of the
path to verify the dPVResponseStatus from the response.

... this allows to keep the whole response short and ...

The same for the next paragrah!

requestExtensions is a way to allow additional elements to be
added later on, if needed.

responseExtensions is a way...

chapter 6.2. Detailed Protocol

One more terms needs to be imported:

OtherCertID

chapter 8.2. Response

TbsDefResponse       ::= SEQUENCE {
tbsResponseData                VPDefResponseData,
signatureAlgorithm             AlgorithmIdentifier   OPTIONAL,
signature                      BIT STRING            OPTIONAL,
certs                  [0]     EXPLICIT SEQUENCE OF Certificate
OPTIONAL }

It should be:

TbsVPDefResponse       ::=
SEQUENCE {