[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SCVP Draft 17: Summary of changes
> >
> >Not only in mathematics a red herring may neither be red nor a herring. An empty
> >set trivially full fills any condition.
> >
> You asked me the reason that I encoded keyUsages the way that I did and
> so I explained. Just because you don't agree with my reasoning is no
> reason to be insulting.
Insulting? I do not intend to insult anyone here, but
I forgot to mention that I cited from Morris Hirsch's book of
differential topology.
> Of course, if the working group indicates a preference for a different
> encoding, I will change it, but I have not heard anyone else suggest
> that this needs to be changed.
Tim and you have explicitly asked not to propose changes in ASN.1.
Did I ask to change it? I only made another explanation of a different
way to specify the same thing with a shorter encoding, but since the
semantics is equivalent ...
see also (*1*) below
> >I had actually been tempted to change requestorRef to be a sequence of
> >GeneralName since GeneralName seemed to be more appropriate than OCTET
> >STRING for something that was supposed to hold an identifier. A side
> >effect of this change is that it would have specified the encodings for
> >the identifiers as well. However, there was a comment submitted for
> >draft 16 indicating a need to be able to use a hash value as an
> >identifier in requestorRef, an option that would have been effectively
> >precluded if OCTET STRING had been changed to GeneralName. Since I
> >could not justify preventing use of a hash value and one can easily
> >encode any GeneralName value in an OCTET STRING, I left the syntax for
> >requestorRef unchanged.
> >
> >
> >
> >Since you could not justify it, well then, yes, that's important ... :)
> >And, you didn't even feel that this would have been worth to be
> >discussed a little bit.
> >
> >
> As I see it, my responsibility as an editor is to do my best to ensure
> that the final document is technically correct and represents rough
> working group consensus. That means that I should not be making changes
> to the protocol simply for stylistic reasons just because one person
> would prefer to see the change made, even if that person is me.
'stylistic' is the important word here?
> >There is nothing in 3379 that requires that you must be able to encode
> >a hash value.
> >
> >
> That's probably true, but not the point. Its not as if I unilaterally
> changed the protocol to enable the encoding of hash values in
> requestorRef. I'm just saying that I would have been in favor of making
> such a change, but could not because I had reason to believe that some
> members of the working group would be against such a change, whereas I
> didn't know of anyone who felt that the change was needed.
The change from a octet string containing a sequence of zero terminated
octet string into a sequence of octet string was made by Trevor.
The message referenced below accnoledged that this was a first step,
BUT that the explanatary text contain useless restriction left
over from the previous version. The desire to code a hash is an example
to illustrate the error, not more.
The real point is that several times in the past I had asked exactly
what you had thought about, i.e. to use a construct that at
least allow GeneralName to represent participating entities.
> I am really confused by your argument that I should have made a
> unilateral change simply because the option that I would have been
> removing is not mandated by 3379. First, as you have said before, just
> because something is not mandated by 3379 does not mean that it can't be
> included in SCVP. Second, YOU are the one who expressed a desire to be
> able to encode a hash value in requestorRef
> (http://www.imc.org/ietf-pkix/mail-archive/msg01739.html).
This was a reference to the restrictions about the content,
i.e. no zeros. I could have said as well that any encoded value
needs an extra escaping rule to protect for hex 0.
I had sugggested also at some time ago a
sequence of choice { octet string , generalname }
as a compromise in order to avoid a potential problem with the
content of an octet string that might be required by someone.
- without any success
- but then a change to a sequence to octet strings,
- then the introduction of one requestername
- then requesternames.
If I am considered to be the only one who wants to
encode a hash value, I can do this without the need of
an octet string, so you can safely replace requesterRef by
a GeneralName.
> >>I think this is more of a theoretical concern than a practical concern.
> >>The odds that two servers that are part of the same SCVP relay network
> >>would select different identifiers for use in requestorRef, but that as
> >>a result of using different encoding techniques the encoded versions of
> >>their names are the same are extremely small.
> >>
> >>
> >
> >There are also various ways to encode a hash value into a GeneralName,
> >so it is wrong that this has been effectively precluded. Waht IS actually
> >precluded is that these identifiers can have a structure following any
> >global name space and you have no collisions using encoding.
> >
> While it is trivial to convert something that would have been encoded as
> GeneralName to an OCTET STRING (just place the DER encoding of the name
> in the octet string), I am not aware of any currently defined method for
> encoding a hash value in GeneralName. Certainly one could define an
> attribute for inclusion in a directoryName or one could define a new
> name form to go in otherName, but that doesn't seem very practical.
Since it is a hash with an algo, one can use the well known
messageDigest which is roughly speaking close to an attribute which
you could formally put into a RDN.
> >> believe that SCVP already includes all of the basic fields needed to
> >>support relay. I don't believe that the base document needs to say any
> >>more. When a server implements relay, it sends out an CVRequest and
> >>gets back a CVResponse just as a normal client would. Guidance on what
> >>queries a server should send and what it should do with the response is
> >>just that. Guidance on how to use a particular feature does not need to
> >>be in the base standard, it can be in a separate informational
> >>document. If there is a desire for SCVP servers that implement relay to
> >>exchange auxiliary information, that information can always be included
> >>in non-critical response extensions. So, I can not see any reason to
> >>hold up the base standard. There are too many people who need this
> >>standard to be completed and who can use it even without guidance on how
> >>to implement relay.
> >>
> >>
> >
> >There is no exchange of AUXILIARY information. The requirements say
> >clearly that the client can request that the server returns ALL
> >information. The base text allows for relaying.
> >
> >The current text does not honor this requierement of 3379.
> >
> >
> Please specify exactly where in 3379 there is a requirement that the
> current text does not honor. I do see the following in section 4.2:
>
> - Optional parameters in the protocol request and/or response MAY be
> provide support for relaying, re-direction or multicasting. DPV
> clients that ignore any such optional parameters MUST be able to
> use the DPV service. DPV servers that ignore any such optional
> parameters MUST still be able to offer the DPV service
>
> To me, this means that any information in the request or response that
> is specific to relay MUST be auxiliary information in that the recipient
> must be able to process the message even if this information is ignored.
The "third" "other" relying party is NOT a dpv client. The requester of
the dpv response is a client. It can process the result because all
what it does is to authenticate the result and see whether it is good.
> >what you are suggesting, is to totally ignore relaying in the base
> >document which is contrary to what had been announced by Trevor, i.e.
> >to specify how a relay would act, nothing had been changed.
> >After having discussed that this is needed several months ago,
> >and with agreement from Trevor, it is really surprising that
> >you haven't made your observation earlier.
> >
> >
> If Trevor agreed to make a change to the document that was not made, I
> am not aware of it. If there was a prior agreement to make a change to
> the document and the change was not made, then I'll work with Trevor to
> add the necessary text. I am expressing my own opinions on this matter
> based on my knowledge of the situation.
I include an excerpt from a message from 10th of december 2004, after
draft 16. And there is also a corresponding comment from Denis.
* > * > * Chapter 7: Denis is right that the spec does not describe how
* > relaying
* > * > is
* > * > * performed, i.e. how a response is created from a response
received
* > * > from
* > * > * another
* > * > * server by a 'proxy'.
* > * > [TF] What specifically are you looking for?
* > *
* > * A working specification that includes:
* > *
* > * - how a request received is transformed into a new request by a
relay,
* > * which fields are copied, or not, or may.
* > * - how the response is transformed into a response to the original
* > request
* > * there are SEVERAL options, in particulat the one that addresses
* > * the requirement of allowing a response as part of another one.
* > [TF] OK. I will add that.
* good.
*
* Would it be possible to send a draft to the list before it get graved
into
* electronic marble.
> >Thus, as you admit, the text does not at all contain information about how
> >
> >- a relay should take a request from a client and transform it into
> > a request to another server;
> > At least it is already said one modification is to add the loop
> > control.
> >
> >
> Support for loop detection is mandated by 3379:
>
> - When a server supports a relay mechanism, a mechanism to detect
> loops or repetition MUST be provided.
>
> So, it is clear that this must be included in the protocol. In SCVP, it
> is included in such a way that it can be ignored by clients and servers
> that do not support relay.
>
> There no reason for the standard to state how to transform a request
> from a client into a request to another server. The protocol already
The text for loop control is a demonstration that the contrary is true.
The transformation may be simple, but still you have:
- A relaying server prepares a request by taking all parameters from
the received request, and:
- modifies the loop control parms
- modifies the requesterName (sets itself, or not?)
> specifies the rules for generating requests and the rules for generating
> responses. These rules apply whether the requester is the end client or
> a relaying server. How the server computes the response is a local
> matter and thus not something that needs to be standardized. The
> contents of the response do need to be standardized and they are. If a
> server wants to call upon the resources of another SCVP server to help
> answer a question, it may do that, but the contents of that request
> message are irrelevant as long as the request conforms to the rules
> specified in section 3 for SCVP requests.
>
> An SCVP server that receives a DPV request could in turn send either a
> DPV or DPD request to another server. The request could ask for
> revocation status checking if that was required by the client or the
> server could ask for just the certification path and then perform
> revocation status checking itself. As long as it provides the correct
> response to the client, it does not matter.
Dependingh on a paricular policy, the only correct answer can be one that
includes all the information provided by external sources that have contributed
to make the DPV response.
> So, any information about how to transform a request from a client into
> a request to another server would be informative not normative, and so
> it does not need to be included in the base standard.
- An optional feature does not mean that it is not normative when used.
- Currently there is no way for a server to include a response from
another server ASIS, including its signature.
The remote server acts as a civil law notary type, the third
party is a judge that only validates whether the notary has
validated the certificate, and does not perform any validation.
- If a DPV server validates a certificate, it may only provide
a yes and no answer, and a statement from the remote server
also with a yes and no answer. No path, no revocation info.
It is my
> understanding that Tim Polk has proposed that you write a separate,
> informative document describing how relay can be used.
???
> >- the result of the request could be returned as is with just the
> > security envelope changed. But then the client does not have
> > the important information required to show to a third party.
> >
> >
> What information would the client be required to show to a third party
> that is not provided. In the case of DPD, the client is performing the
A way to authenticate the response, the third party is not required
to trust the client's local server but only a response from let's say
'public notary service'.
> validation itself and so would certainly have any evidence needed to
> show to a third party. In the case of DPV, the client is indicating
> that it trusts the server. If the signed response from the server is
> not sufficient evidence to show to a third party, then the client needs
> to request more information from the server (e.g., require the server to
> include the certification path in the response). What does relay have
The local server may not be in the trust space of the third party.
> to do with this? What if the server you sent to request to didn't even
> use relay to compute the response? Are you saying that a server might
> be REQUIRED to use relay in order to generate a response, not because
> the server is unable to compute the response on its own but because some
> evidence would be created as a result of performing relay that is needed
> by the client to later show to a third party and that evidence could not
> be created without relay? If so, then I do not see anything in 3379 to
> justify this type of requirement. If not, then I don't see how it could
The requirement's text says clearly:
Such
information may (not necessarily exclusively) consist of a
certification path, revocation status information from authorized CRL
issuers or authorized OCSP responders, revocation status information
from CRL issuers or OCSP responders trusted under the validation
policy, time-stamp tokens from TSAs responders trusted under the
validation policy, or a DPV response from a DPV server that is
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
trusted under the validation policy. When the certificate is valid
according to the validation policy, the server MUST, upon request,
include that information in the response. However, the server MAY
omit that information when the certificate is invalid or when it
cannot determine the validity.
This means that it is possible for a server to use another one for
whatever purpose, and, if so (and why and how is a local matter), but
it is not a local matter to have the possibility to include the answer,
and this is not the case today.
> be in the case that relay was used that the client would be required to
> have information about the relay to show to a third party.
The signature of the remote server's DPV response is not shown, i.e.
there is no way for the third party to authenticate the information.
- You have still not responded to my question why it is necessary to
have returned information encapsulated in octet strings requiring
another invocation of a parser for the octet strings.
I had said this long ago: *1*
- There are octet strings that carry undefined global information
without encoding guidance.
- There are ANY defined by structures
- There are octet string containing other asn1 structures
- there is the EXTENSION logic (=previous + critical)
Three different techniques are used for similar purposes, where
is any justification or logic for these differences?
- Given that a server can now return more than one requesterName,
I ask for a change that allow a sequence also in a request,
so that one has at least some change to note more than one
client identity. This allow to note participating entities
in a relaying environment.
- It seems that you have not seem that in my recent message about
asn1 styles there was a remark to make a policyId optional in
case of a fatal server error.
Peter