Subject: AD review comments for draft-ietf-pkix-scvp-27

From: Sam Hartman <[email-masked]>
Date: Mon, 07 Aug 2006 17:04:21 -0400

Hello.

As part of the publication process for draft-ietf-pkix-scvp-27 I have
reviewed the draft as the AD bringing it to the IESG.

I've found a few issues that I believe need to be handled before the
draft can be last called at the IETF level.  In many cases
clarifications of text will be sufficient to address these issues.
There are a few concerns about interoperability though.

Section 3: The text does not state a good reason why
anyExtendedKeyUsage is not sufficient for a cert to be used to sign
scvp requests.  Please either provide such a reason or require
servers to accept this keyPurposeID.  If you believe that some
environments may have a good reason to reject anyExtendedKeyUsage but
others will not, then state that servers SHOULD accept the usage and describe these differences.

>   All SCVP clients MUST support SignedData for signed requests and
>   responses.  SCVP clients SHOULD support AuthenticatedData for MAC
>   protected requests and responses.

What are the requirements for servers?

How does a client obtain the server's key agreement public key?  The
section 3 text says that the client must do so but does not describe
how.  Is a normative mechanism required here?  If not, you still need
to describe possible methods.

Section 3.1

The text claims the version must be increased for any change in syntax
or semantics.  Do I need to increase the version number when I define
an extension?  If not, please note this.

Section 3.2 The ASN.1 tagging for the Query type looks strange.  There
is no context tag 0; not all optional fields are tagged.  What is the
style being used here?

In 3.2.4.5 and 3.2.4.6, if the server does not support these flags,
must it error if they are set or can it ignore them?  The text is
unclear.  Later text implies that the server should generate an error
if these features are requested but they are not available; if so,
please clarify this text.

Section 3.2.4.9 does not provide sufficient semantics to meet the
needs of common applications.  For example
draft-ietf-cat-kerberos-pk-init requires that pk-init certificates
have the ExtendedKeyUsage extension in some cases.  SCVP itself does
not currently permit the anyExtendedKeyUsage value, so SCVP doesn't
even provide good enough extendedKeyUsage handling to validate SCVP
server certificates.  At a minimum support is required for cases where
EKU needs to be present and where anyKeyUsage is not acceptable.

Are all clients guaranteed to interoperate with all servers?  It seems
there is an incomplete overlap between DPD and DPV and it is not clear
that servers are required to support one of these configurations.
It's not clear that this meets RFC 2026's definition of
interoperability.  If so, that needs to be fixed.

Section 4:

>    1. A success response to a request made over a protected transport
>       such as TLS.  These responses SHOULD NOT be protected by the
>       server.

Why is that a should?  IT seems useful to protect such responses so
that for example they can be included by relaying scvp servers in
their responses while still preserving authentication.  In general,
TLS does not provide data origin authentication to third parties, but
protected responses do.

Section 6.1:

>   The syntax and semantics of the vpResponseVersion item are the same
>   as cvRequestVersion as described in section 3.1.  The
>   vpResponseVersion used MUST be the same as the vpRequestVersion
>   unless the client has used a value greater than the values the
>   server supports.  If the client submits a vpRequestVersion greater
>   than the version supported by the server, the server MUST return a
>   vpResponseVersion using the highest version number the server
>   supports as the version number.

Why is the above text necessary?  Shouldn't clients use the oldest
vpversion in their request to discover what vpversions the server
supports?  The above text is potentially hard to implement because it
assumes that future validation policy requests are backward compatible when parsed by an old parser.

i'm also not convinced that the above text is implementable given the
current ASN.1 syntax with a modern ASN.1 toolchain--one that treats
extra fields in a sequence as an error.  You can definitely implement
parsing all the versions you support by trying to parse each version
separately, but I'm not convinced that with such a tool chain you can
implement parsing part of a structure that is newer than you support.

How does a client discover what WantBacks and Checks a server
supports?

MIME

* the change controller for all IETF standards track mime
 registrations should be the IESG 

There is a required parameter (format) on all the mime types that is
 neither documented nor used in the HTTP samples.  I suspect this is
 not actually desired..

I think vp-request and vp-response are too generic of subtype names; 
 you can try to convince the ietf-types folks that they should  accept
 this but I suspect you will run into trouble.