[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-01.txt
Russ,
> 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 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
>
> 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.
> ============================================================================
> ================