[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SCVP 16 comments deadline
Trevor,
The deadline communicated at the DC meeting for making comments on SCVP
16 was Nov 30th which has now passed. I have had only three people send
me comments to date. SCVP 17 will be closing very shortly so this is the
last reminder.
Thank for the remainder. I missed the initial announcement.
My comments are below.
1. Typo. There are two IPR statements related to RFC 3668 on the first
page. Delete one.
“ By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668”.
2. Page 11. Typos. First paragraph on top of the page.
Replace “signers” by “signer’s”.
3. Page 11. Typo. First paragraph on top of the page. Last sentence.
Replace “certificate” by “certificates”.
4. Page 13. Typo. Section 3.1.2 “checks”
The two following lines are in fact one line:
Change:
- Build a validated certification path to a trust anchor; and
- Do revocation status checks on the certification path.
into:
- Build a validated certification path to a trust anchor and
do revocation status checks on the certification path.
5. Page 15. Typo. Section 3.1.4 validationPolicy
This is the error left intentionally by the editor to know who read the
document. The following sentence is duplicated: “ The validationPolicy
item, defines the validation policy”. Please delete one sentence.
6. Page 24. Typo. Section 3.1.5.9 keyUsages
Change “keyUasge” into “keyUsage”.
7. Page 27. Typo. Section 3.1.8 valididationTime
Last line of the first paragraph. Change “servers” into “server’s”
8. Page 32. Typo. Section 3.5 dhPublicKey
Change: Diffie-Hellamn into Diffie-Hellman.
9. Page 32. Typo. Section 3.5 dhPublicKey
Fifth line. Change “an does” into “and does”
10. Page 32. Typo. Section 3.5 dhPublicKey
Delete: (see section Error! Reference source not found.)
11. Page 33. Typo. Section 4. Validation Response
After the eight items. The following sentence has a grammar problem:
“Successful responses are be made when the server has fully complied
with the request”.
12. Page 52. Typo. Section 6 Validation Policy Response
The second sentence is incorrect. It is:
The valPolResponse MAY not unique to any valPolRequest, …”
Change into:
“The valPolResponse MAY not be unique to any valPolRequest, …”
13. The abstract does not reflect accurately the content of the
document.
“certificate handling” is too vague.
Proposed abstract:
SCVP allows a client to delegate certificate path construction and
certificate path validation to a server. The path construction or
validation (i.e. making sure that none of the certificates of the
path is revoked) is made according to a validation policy which
contains one or more trust anchors. It allows to simplify client
implementations and to use a set of predefined validation policies.
14. Section 1.3
The text on validation policy is new. There is no concept of “mutually
agreed” validation policy between the client on the server. The server
supports a set of validation policies which may or may not fit the need
of the client.
Change the second sentence of section 1.3 which is:
“ In SCVP, a validation policy can be either mutually
agreed between client and server, and subsequently referenced in
request, or explicitly expressed in the request by passing all of
the necessary parameters.”
into:
“ In SCVP, the validation policy to be used by the server can be either
fully referenced in the request by the client (and thus no additional
parameter is necessary), referenced in the request by the client with
additional parameters or supported by default by the server if the
client does not reference it.”
15. Section 1.3. The second paragraph needs to be reworded. Currently,
it is the following:
“ Policy definitions can be quite long and complex, and some policies
may allow for the setting of a few parameters such as a set of
trust anchors. The request can therefore be simplified if these
previously agreed policy dependent parameters are referenced in the
request by a mutually agreed OBJECT IDENTIFIER (OID) or URL value.
The referenced value indicates either a partial or full set of
parameters. The client can therefore omit these agreed parameters
from the request, only passing any parameters which are not
specified by the previously agreed policy. Therefore in the
simplest form, with validation polices which define every parameter
necessary, a SCVP request need only contain the certificate to be
validated, the validation policy and any run-time parameters for
the request”.
Proposed rewording:
“ Policy definitions can be quite long and complex, and some policies
may allow for the setting of a few parameters. The request can
therefore be very simple if OBJECT IDENTIFIERS (OIDs) are used to
specify both the algorithm to be used and all the associated
parameters of the validation policy. The request can be more complex
if the validation policy fixes many of the parameters but allows the
client to specify some of them. When the validation policy defines
every parameter necessary, a SCVP request needs only to contain the
certificate to be validated, the referenced validation policy and any
run-time parameters for the request. In its simplest form, a SCVP
request contains the certificate to be validated and any run-time
parameters for the request. In that case the server uses a default
validation policy”.
16. Section 1.3. Paragraph 3.
The text is missing the fact that at least one validation policy must
be supported by the server. This is the default policy which is used
when the client omits to specify it.
The current text is the following:
“SCVP server also publishes its default validation policy settings.
The default policy can be requested for validation and the client
can override any default value in the request if required. The
default values are also used when processing requests which
reference a validation policy other than the default one that does
not contain the full set of parameters necessary for validation and
the client has also omitted the missing values in the request.
Therefore a client can also simplify the request by omitting a
parameter from a request if the default value published by the
server is acceptable”.
Replace it with:
“ A SCVP server must support a default validation policy which will
be used if the client does not specify any in its request. A server
publishes the references of the validation policies it supports.
When these policies have parameters that may be overridden, the
default value for these parameters are communicated by the server as
well. The client can simplify the request by omitting a parameter
from a request if the default value published by the server for a
given validation policy reference is acceptable. However if there is
a desire to demonstrate to someone else that a specific validation
policy with all its parameters has been used, it will need to ask the
server for the inclusion of the full validation policy with all the
parameters in the response”.
17. On top of page 7, the relationship between the validation policy
and the basic certification path algorithm is not explained. Then in
section 1.4 The concept of validation algorithm is introduced but its
relationship with the validation policy is not explained. This is
confusing.
Later on when observing the ASN.1 syntax it may be discovered that two
OIDs are being used:
- one for the validation policy (ValidationPolRef) and
- one for the validation algorithm (ValidationAlg).
This is overcomplicated and unnecessary.
An important simplification is obtained if, as the previous text
states, there is an OID to defined the validation policy and there may
be or may not be additional parameters.
We could then have:
valPolByOID::= SEQUENCE {
valPolId OBJECT IDENTIFIER,
parameters ANY DEFINED BY ValPolId OPTIONAL }
Specifying a path processing compliant with section 6.1 of RFC 3280
would be possible (notice however that the text from RFC 3280 is too
vague to support the case where a CRL is not signed by the CA).
It would be desirable to be able to communicate easily and in a
standard way the parameters that may be set in section 6.1 from RFC
3280. In addition, key usage should be added to that list.
The document should then define a bundle of all these previous useful
parameters and allow for the addition of other parameters.
It is thus proposed to define an OID for a validation policy compliant
with section 6.1 of RFC 3280 (some differences with section 6 from
3280bis, i.e. adding precision, may be expected)
It is thus proposed to modify the text starting from :
“ The inputs to the basic certification path processing algorithm
used by SCVP are defined by [PKIX-1] in section 6.1.1 and comprise”
up to the end of section 1.3 with the following:
“For clients able to specify the parameters of a validation policy, it
may be useful to define a standard data structure (using a bundle) able
to support the parameters of the basic certification path processing
algorithm defined by in section 6.1.1 from [PKIX-1] :
- a set of Trust Anchors (by value or by reference),
- the initial Certificate Policy set,
- initial Certificate Policy mapping setting,
- initial any-Policy setting,
- initial explicit Certificate Policy setting.
as well as :
- the usage of the key contained in the certificate (e.g., key
encipherment, key agreement, signature)
This will be done using a bundle which encapsulates all these
parameters.
Other application-specific purposes parameters may be added”.
18. Section 1.4 is about a “Validation Algorithm”. Given what was said
before, the header of this section should be changed. If we make a
subsection 1.3.1 called “1.3.1. General” for encapsulating the previous
text, then we can introduce a new section 1.3.2 called:
“1.3.2. Validation policy according to section 6.1 of RFC 3280”
Some of the text present in the current section 1.4 has been used to
build the new text that is proposed below:
“1.3.2. Validation policy according to section 6.1 of RFC 3280
SCVP defines a specific validation policy which implements the
certification path validation algorithm as defined in section 6.1 of
[PKIX-1]. This specific validation policy, called “rfc-3280 basic
validation policy” uses the parameters defined in the bundle
mentioned above.
Note that this algorithm does not support in its full generality the
algorithm described in section 6.2 of [PKIX-1] since, when more than
one trust anchor is being defined, all the conditions that are
specified apply to all trust anchors, whereas section 6.2 allows to
have different conditions for every trust anchor.
The rfc-3280 basic validation policy may be the default validation
policy supported by the server, but does not need to”.
19. Section 2 “Protocol Overview”
In order to allow for interoperability and testing a common protocol
needs to be supported. It should be defined.
20. Section 3 “Validation Request”
The unsigned request form is not explained and there is a confusion for
the signed request which indeed authenticates the client and is thus
not anonymous. The current text is :
“A signed
request is used to authenticate the client to the server or to
provide an anonymous client integrity over the request-response
pair.”
It should be rephrased as:
“An unsigned request provides an anonymous client integrity over
the request since the hash of the request or the full request is
incorporated in the response. A signed request is used to
authenticate the client to the server”.
21. Page 13. Section 3.1.2 “checks”
The following sentence adds nothing and should be removed:
“A server may still choose to
perform revocation status checks when performing path construction,
although this information cannot be returned to the client.”
22. Page 15. Section 3.1.3 “wantBack”
The text states:
- Proof of revocation status for each certificate in the AC
issuer certification path;
It would be important to refer the section of the RFC which explains
how to
check the “revocation status for each certificate in the AC issuer
certification path”.
23. Page 15. Section 3.1.3 “wantBack”
The text states:
The client can also request a non-cached response to the request by
including wantback id-swb-non-cached-resp in the request.
The default behavior should be the reverse: fresh information is
provided, unless the client accept cached information. The item should
be changed into:
id-swb-cached-resp
24. Page 15. Section 3.1.3 “wantBack”
The text states:
id-swb-pkc-all-valid-cert-paths OBJECT IDENTIFIER ::= { id-swb 13}
It should be mentioned that this item is only possible for DPD.
25. Page 16. Section 3.1.4 validationPolicy
The following sentence is talking of an agreement whereas such
agreement does not exist. Delete the sentence:
“The client and server can optionally agree on a set of parameters
which may fully or partially define a validation policy”.
26. Page 16. Section 3.1.4 validationPolicy
The text states:
"If a partial set of parameters has been agreed upon,
then the client supplies a reference to the policy plus whatever
parameters are necessary to complete the request in this item.
This should be replaced with:
“If the validation policy does not define all parameters necessary
for processing an SCVP request, then the client need to supply these
parameters”.
27. Page 16. Section 3.1.4 validationPolicy
The syntax of the validationPolicy item is defined as:
ValidationPolicy ::= SEQUENCE {
validationPolRef ValidationPolRef,
validationAlg [0] ValidationAlg OPTIONAL,
userPolicySet [1] SEQUENCE SIZE (1..MAX) OF OBJECT
IDENTIFIER OPTIONAL,
inhibitPolicyMapping [2] BOOLEAN OPTIONAL,
requireExplicitPolicy [3] BOOLEAN OPTIONAL,
inhibitAnyPolicy [4] BOOLEAN OPTIONAL,
isCA [5] BOOLEAN OPTIONAL,
trustAnchors [6] TrustAnchors OPTIONAL,
keyUsages [7] SEQUENCE SIZE (1..MAX) OF KeyUsage
OPTIONAL,
extendedKeyUsages [8] ExtKeyUsageSyntax OPTIONAL}
This structure is quite odd, because it only allows to pass additional
parameters as parameters of the validationAlg. Suppressing the
validationAlg item add adding validationParamExtensions would be a
simpler and cleaner way.
Each validation policies uses its own parameters.
We should have something like :
ValPolByOID ::= SEQUENCE {
valPolgId OBJECT IDENTIFIER,
parameters ANY DEFINED BY valPolId OPTIONAL }
More details follow.
28. It is highly debatable if URIs should be supported or not to
reference a validation policy. URIs are not stable over time and thus
unless there are dereferenced and a hash value is computed over them,
it is insecure to use them. There is a discussion in the security
consideration section, but no warning and no pointer here. If we keep
them, we should warn the user.
If the WG should decides that they should be supported (and if the IESG
agrees) on page 17, the ASN.1 description should then be:
ValidationPolicy ::= CHOICE {
valPolByOID [0] ValPolByOID,
valPolByURI [1] ValPolByURI }
ValPolByOID ::= SEQUENCE {
valPolgId OBJECT IDENTIFIER,
parameters ANY DEFINED BY valPolId OPTIONAL }
ValPolByURI ::= SEQUENCE {
uri IA5String,
hashAlgo OBJECT IDENTIFIER,
hashValue OCTET STRING}
29. It is proposed to define the following bundle:
ValidationParamBundle ::= SEQUENCE {
certificatePolicySet [0] SEQUENCE SIZE (1..MAX) OF OBJECT
IDENTIFIER OPTIONAL,
inhibitPolicyMapping [1] BOOLEAN OPTIONAL,
requireExplicitPolicy [2] BOOLEAN OPTIONAL,
inhibitAnyPolicy [3] BOOLEAN OPTIONAL,
isCA [4] BOOLEAN OPTIONAL,
trustAnchors [5] TrustAnchors OPTIONAL,
keyUsages [6] SEQUENCE SIZE (1..MAX) OF KeyUsage
OPTIONAL,
extendedKeyUsages [7] ExtKeyUsageSyntax OPTIONAL
extensions [8] EXPLICIT Extensions OPTIONAL }
Note that userPolicySet” is unclear and has been changed into
“certificatePolicySet”.
The text would need to be aligned with the new structure and, of course
the parameters of the rfc-3280 basic validation policy will simply
include the bundle above as its parameters.
It should also be mentioned somewhere in the document that the support
of the rfc-3280 basic validation policy is not mandatory for
conformance but, if supported then the bundle needs to be supported.
30. Page 17. Section 3.1.5 validationAlg should be deleted.
31. Page 17. Section 3.1.5.1 Default Validation Algorithm should be
deleted and replaced by a section later on the “rfc-3280 basic
validation policy”, which should have its OID defined under the scvp
tree for OIDs.
32. Page 17. Section 3.1.5.1. Some text of this section might be re-
sued to build a new section on the rfc-3280 basic validation policy.
Note that the last sentence at the bottom of page 17, should be
removed. This sentence is: “The default validation policy MUST use the
basic validation algorithm”. Any default validation policy can be used.
33. Page 17. Section 3.1.5.2 validationAlg (same title as 3.1.5 !)
should be as well deleted.
34. Page 20. Section 3.1.5.2.3 Name Validation Algorithm
This goal of this section seems to introduce an additional test to the
basic “rfc-3280 basic validation policy”. It would come naturally as an
extension of ValidationParamBundle, rather than as a parameter of the
validationAlgo which has been proposed to be removed. The text should
be modified accordingly.
35. Page 21. Section 3.1.5.2.3 Name Validation Algorithm
NameValidationAlgParms ::= SEQUENCE {
keyPurposeId KeyPurposeId,
validationNames GeneralNames }
This construct is artificial since KeyPurposeId is about the Extended
Key Usage and has nothing to do with name validation.
It could indeed be interesting to test the Extended Key Usage extension
of a certificate, but this should be supported as an extension of
ValidationParamBundle. The text should be modified accordingly.
36. Page 22. Section 3.1.5.3 userPolicySet
userPolicySet should be changed everywhere into certificatePolicySet.
37. Page 22. Section 3.1.5.3 userPolicySet
The text has many sentences like:
SCVP clients SHOULD support userPolicySet item in requests, and
SCVP servers MUST support userPolicySet item in requests.
These requirements only apply for the rfc-3280 basic validation policy,
and this should be clearly mentioned.
38. Page 22. Section 3.1.5.4 inhibitPolicyMapping
The text states:
By default the server allows policy mapping as
part of certification path validation.
For simplicity, this should be the reverse. Replace with:
“By default the server does not perform policy mapping as
part of certification path validation. If the client wants the
server to support policy mapping, allowPolicyMapping must be set
to TRUE in the request”.
39. Page 24. Section 3.1.5.8 trustAnchors
The text states:
“A certificate reference can be used to identify the
trust anchor by certificate hash and optionally a distinguished
name with serial number”.
This is not consistent with the ASN.1 definition of PKCReference which
is:
PKCReference ::= CHOICE {
cert [0] Certificate,
pkcRef [1] ESSCertID }
Please correct.
40. Page 25. Section 3.1.6 responseRefHash
The text states:
“By default, the server includes a hash
of the request in the response. If the client wants the server to
include the full request in the response, responseRefHash is set to
FALSE.”
The server shall always include a hash of the request in the response.
This is an easy way to allow to test the integrity of the request.
Since the full description of the validation policy may be much longer
a flag should be used to say that the full validation policy is not
returned unless requested. It is thus proposed to have instead the
following:
“3.1.6.1 fullRequestInResponse
The fullRequestInResponse controls if the client wants the server
to include the full request in the response. By default,
fullRequestInResponse is set to FALSE. If the client wants back
the full request then it must set this parameter to TRUE. The main
reason a client would request the server to include the full request
in the response is to archive the request-response exchange in a
single object. That is, the client wants to archive a single object
which includes both request and response”.
41. Page 26. Section 3.1.6.2 responseValidationPolByRef
This item should be renamed: fullValPolInResponse
The text should be changed into:
“The fullValPolInResponse controls whether the response includes the
identifier of the validation policy with all the parameters that have
been used by the server, i.e. all the variable parameters independent
from the fact that there were specified by the client or defaulted if
not specified. By default, fullValPolInResponse is set to FALSE. If the
client wants the full validation policy to be included, then
fullValPolInResponse is set to TRUE. The main reason a client would
request the server to include validation policy to be included by value
is to archive the request-response exchange in a single object. That
is, the client wants to archive the CVResponse and have it include
every aspect of the validation policy.”
The ResponseFlags should be changed as follows:
ResponseFlags ::= SEQUENCE {
fullRequestInResponse BOOLEAN DEFAULT FALSE,
fullValPolInResponse BOOLEAN DEFAULT FALSE,
signResponse BOOLEAN DEFAULT TRUE }
42. Page 28. Section 3.1.9 intermediateCerts. Minor.
Change:
The optional intermediateCerts item helps the SCVP server create
valid certification paths.
into:
The optional intermediateCerts item may help the SCVP server to
create
valid certification paths.
43. Page 29. Section 3.1.11. producedAt
Last sentence. Change:
SCVP server SHOULD support the producedAt values in the request.
into:
SCVP server MAY support the producedAt values in the request.
Reason: cached responses should not need to be implemented in order to
be compliant with the specification.
44. Page 32. Section 3.5 dhPublicKey
The text states:
“For the server to compute the shared
secret, it must lean the public values the client generates,
therefore the client MUST include this in the request if it uses
this mechanism to integrity protect the request-response pair.”
Replace:
“to integrity protect the request-response pair”
with :
“to authenticate and integrity protect the first response and
authenticate and integrity protect subsequent request-response pairs”.
45. Page 32. Section 3.6 SCVP Request Authentication
The text states:
“It is a matter of local policy what validation policy is used by
the server when validating requests”.
This sentence could be misinterpreted because the word “validating” is
being used. Change into:
It is a matter of local policy what validation policy is used by
the server when authentication requests”.
46. Page 35. Section 4. Validation Response
The CVResponse is defined as follows:
CVResponse ::= SEQUENCE {
cvResponseVersion cvResponseVersion INTEGER,
policyID INTEGER,
producedAt GeneralizedTime,
....
On the next page the test states:
“The policy ID used by the SCVP server when it processed the request.
See section 6.4 for details.”
In section 6.4 the text states:
“6.4 defaultPolicyID
An integer that uniquely represents the version of the default
validation policy as represented by the trustAnchors, …”
This is not understandable, over-engineering and very complicated.
Please delete this item.
47. Page 35. Section 4. Validation Response
The CVResponse contains:
requestRef [1] RequestReference OPTIONAL,
Remove “OPTIONAL” since it is very beneficial to mandate this item
since it allows to make sure that the request has not be modified if
the response is integrity protected. The computation is fast and easy
and the hash value does not overload the response.
48. Page 38. Section 4.5 respValidationPolicy
The definition of this item is overcomplicated and not tailored to
support any kind of validation policy.
If the client does not specify the validation policy or if the client
specifies a validation policy which has default parameters, then the
full description of the validation policy shall be given back.
If the client specifies a validation policy which has no default
parameters, then the reference and parameters, if any, of the
validation policy are in the request.
The full description of the validation policy shall be given back in
any case, if the fullValPolInResponse Boolean in ResponseFlags is set.
respValidationPolicy :: = ValidationPolicy
49. Page 41. Section 4.6 requestRef
As stated earlier, requestRef should be mandatory and always be a hash
of the request.
In addition a fullRequest OPTIONAL parameter should be added as an
optional item for CVResponse.
The full description of the validation policy shall be given back in
any case, if the fullRequestInResponse Boolean in ResponseFlags is set.
Change the text and the syntax accordingly.
50. Page 41. Section 4.6 requestRef
The text states:
“The requestRef item allows the client to associate a response with
a request”
This is wrong. This does not protect against a replay.
Change with:
“When the response is authenticated, the requestRef item allows the
client to make sure that the request was not modified in transit”.
51. Page 41. Section 4.6 requestRef
The text states:
“ The requestNonce provides an alternative mechanism for
matching requests and responses if the client has selected to
include a full response.”
This is wrong. This is not an alternative for matching requests and
responses.
Replace with:
“The requestNonce allows to protect against replay, even if time
synchronization is not good between the client and the server”.
52. Page 42. Section 4.6.1 requestHash
The text states:
“ The requestNonce provides an alternative mechanism for matching
requests and responses”.
This is wrong. See above. Delete.
53. Page 45. Section 4.10.4 replyChecks
ReplyCheck is defined as:
ReplyCheck ::= SEQUENCE {
check OBJECT IDENTIFIER,
status INTEGER }
It should be defined as:
ReplyCheck ::= SEQUENCE {
check OBJECT IDENTIFIER,
status INTEGER DEFAULT 0}
54. Page 46. Section 4.10.4 replyChecks
The text states
“The status value for public key certification path building to a
trusted root along with complete status checking, { id-stc 3 }, can
be one of the following:
0: Good
1: Revoked
2: Revocation Offline
3: Revocation Unavailable
It is unclear to understand the benefits that a client can have from
the difference between “Revocation Offline” and “Revocation
Unavailable”. In addition, these wordings do not match the explanations
of what there are.
A much more important response is missing: suspended. Suspended is a
variation of revoked, but the client then knows it may attempt another
try later on.
It is thus suggested to change it into:
0: Good
1: Revoked
2: Suspended
3: Revocation info unavailable”
55. Page 46. Section 4.10.4 replyChecks
The same comment applies for the status value for AC issuer
certification path.
56. Page 48. Section 4.10.6 validationAlg
For reasons given before, delete validationAlg.
57. Page 48. Section 4.10.8 nextUpdate
If CRLs are used, should this field contain the value of the next
update field for the smallest value of all the CRLs ? What is the real
benefit of supporting this element besides added complexity ? It is
suggested to delete that item.
58. Page 49. Section 4.11 responseNonce
The text states:
“The responseNonce item contains an identifier to binds the request
to the response.”
This is incorrect. The nonce is to detect replay.
Change into:
“The responseNonce item contains a unique number which allows to detect
replay”.
59. Page 51. Section 5 Server Policy Request
The text states:
“A SCVP client uses the valPolRequest item to request the list of
validation policies supported by the SCVP server.”
This is not a correct description of what this request is doing. When
looking at the ASN.1 it is doing much more. So the question is whether
two requests should be provided or one. In the later case, it is
important to advertise correctly what the request is doing.
60. Page 52. Section 6 Validation Policy Response
The ASN.1 of the VPResponse is over-complicated.
The first three items are overengineering:
vpResponseVersion INTEGER,
maxCVResponseVersion INTEGER,
maxVPResponseVersion INTEGER,
Further more they are mandatory. Please delete.
61. Page 52. Section 6 Validation Policy Response
The ASN.1 of the VPResponse is over-complicated.
defaultPolicyID INTEGER,
This item does not make sense. When an OID references a validation
policy, there is no concept of versioning. Another version will simply
get another OID (hopefully in the same branch). Please delete.
62. Page 52. Section 6 Validation Policy Response
The ASN.1 of the VPResponse is over-complicated.
validationPolices SEQUENCE OF ValidationPolRef,
validationAlgs SEQUENCE OF OBJECT IDENTIFIER,
validationAlgs is unnecessary. Please delete.
validationPolicies (not validationPolices) is the main component. See
below for a full proposal for restructuring VPResponse.
63. Page 52. Section 6 Validation Policy Response
authPolicies SEQUENCE OF AuthPolicy,
responseTypes ResponseTypes,
dhPublicKeyInfo SEQUENCE OF DHPublicKeyInfo,
are elements which have nothing to do with the list of validation
policies, and they are mandatory ! Either group them in one OPTIONAL
item or define another command to get them.
64. Page 52. Section 6 Validation Policy Response
defaultPolicyValues ValidationPolValues,
This is simply the set of parameters which are related to the rfc-3280
basic validation policy. This set could be used by other validation
policies. Please delete.
65. Page 52. Section 6 Validation Policy Response
What follows is a sketch for a proposal for VPResponse.
VPResponse ::= SEQUENCE {
requestNonce OCTET STRING OPTIONAL
thisUpdate GeneralizedTime,
nextUpdate GeneralizedTime OPTIONAL,
validationPolicies SEQUENCE OF ValidationPolicy,
serverParams ServerParams OPTIONAL }
ServerParams ::= SEQUENCE {
responseTypes ResponseTypes,
authPolicies [0] SEQUENCE OF AuthPolicy OPTIONAL,
dhPublicKeyInfo [1] SEQUENCE OF DHPublicKeyInfo OPTIONAL,
clockSkew [2] INTEGER OPTIONAL }
Note: it is re-called that ValidationPolicy should be redefined as:
ValidationPolicy ::= CHOICE {
valPolByOID [0] ValPolByOID,
valPolByURI [1] ValPolByURI }
ValPolByOID ::= SEQUENCE {
valPolgId OBJECT IDENTIFIER,
parameters ANY DEFINED BY valPolId OPTIONAL }
ValPolByURI ::= SEQUENCE {
uri IA5String,
hashAlgo OBJECT IDENTIFIER,
hashValue OCTET STRING}
66. Page 56. Section 7 SCVP Server Relay
This section is incomplete and lacking explanations. Please explain how
relaying is achieved.
67. Page 65. Section 9 Security Considerations
In the second paragraph, there is a discussion about the use of URIs to
reference validation policies.
Firstly, if URIs are going to stay, a pointer to the security
consideration section should be present in the main body of the
document.
Secondly, the text should mention the need for the ability to
dereference the URI and the need to compute a hash, while the main body
of the document should explain the computation of a hash on the content
of the URI.
68. Page 65. Section 9 Security Considerations
The text states:
“It can also do this by using the Diffie-hellman keys to sign the
request”.
Replace “sign” by “authenticate”.
END OF COMMENTS