[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: fast review of draft-ietf-pkix-ocsp-06.txt
Peter,
Great catches - comments follow:
Peter Sylvester wrote:
>
> hello,
>
> some remarks about the lastest OCSP draft:
>
> - It seems that the remarks about not knowing the public
> key of an issuer are not addressed.
>
> It seems sufficient to ME to allow that the
> hash of the issure private key MAY be a length 0 octet string,
> something like that, or one might add the public
> key of the OCSP responder instead.
>
> Thoughts?
>
I actually think OCVP is a bigger thing than just making the hash
of the issuer's PUBLIC key NULL. That whole topic should be
addressed at one shot
>
> - the remark
>
> " Response extensions may be used to
> convey additional information on assertions made by the responder
> regarding the status of the certificate such as positive statement
> about issuance, validity, etc."
>
> should be removed behind all possible responses since extensions
> can also be used to indicate additional interpretations for
> revoked, notknown.
>
>
> - > The response "certRequired" is returned in cases where the server
> > requires the client to supply the certificate data itself in order to
> > construct a response.
>
> This paragraph should be removed
>
> etc for the ASN.1 response code
> certRequired (4), --Must supply certificate
Agreed - will be fixed. Thanks for catching this
>
> - A.1.1 : "Where privacy is a
> requirement, OCSP transactions exchanged using HTTP SHOULD be protected
> using either TLS or SSL."
>
> Shouldn't the SHOULD be a MAY ?
>
> one could also use a VPN for example
Agreed.
>
> Or just add 'or by lower layer protection'.
>
> have fun.
--
---------------------------------------------------------------------
Ambarish Malpani
Architect 650.567.5457
ValiCert, Inc. ambarish@valicert.com
1215 Terra Bella Ave. http://www.valicert.com
Mountain View, CA 94043-1833