Russ,
I would be very much better disposed to the argument you make if I
had not heard it from the original author of SCVP before.
Back when OCSP was initially developed it used a simple syntax. This
was then changed to ASN.1 by Ambarish, a change that was directly and
specifically justified by the need for 'extensibility'.
So when a few years later the proposal for SCVP is made one would
assume that the extensibility features designed into OCSP would be used. But
no, instead we have a completely new platform.
So no, I will not for a minute accept greater extensibility as a
justification for SCVP. Not even if the authors give me a signed affidavit
saying that this is the last time they will introduce a greenfield
specification rather than re-use the one they introduced only a short time
earlier.
The issue we come down to is of platform reuse. Supporting two
platforms with almost idential but not quite identical semantics is a
nightmare. With OCSP and XKMS there are clear points of comparison. However
there is little chance that XKMS semantics will be accidentally transported
into OCSP or vice versa. With OCSP and SCVP it appears to me to be almost
inevitable that we end up with "OCVP" and "SCSP" implementations that create
mix 'n match hybrids of the specifications.
The only objection I have heard to building SCVP on OCSP that
appears to me that could justify a new platform is that it is alleged that
OCSP does not support quite the right retreival semantics. I say could
because the justification would only exist if OCSP could not be fixed.
In fact ensuring that OCSP gets 'fixed' as necessary is the reason
that I believe platform reuse is essential. If we keep introducing new
platforms each time we want to address a new aspect of Online Certificate
processing we will never get any of them right.
The other issue to consider is that PKIX already has a reputation
for proliferating protocols. There are groups that are proposing to develop
profiles of the PKIX profile of X.509.
Phill
Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@xxxxxxxxxxxx
781 245 6996 x227
> -----Original Message-----
> From: Housley, Russ [mailto:rhousley@xxxxxxxxxxxxxxx]
> Sent: Wednesday, January 16, 2002 9:40 AM
> To: Petra Barzin; Denis Pinkas
> Cc: ietf-pkix@xxxxxxx
> Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-01.txt
>
>
>
> 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.
> ==============================================================
> ==============
> ================
>
Attachment:
Phillip Hallam-Baker (E-mail).vcf
Description: Binary data