Re: [RFC] Certificate validation helper

On 04.07.2012 13:07, Alex Rousskov wrote:
> On 07/03/2012 06:54 PM, Amos Jeffries wrote:
>> On 04.07.2012 12:11, Alex Rousskov wrote:
>>> On 07/03/2012 04:56 PM, Amos Jeffries wrote:
>>>> On 03.07.2012 14:59, Alex Rousskov wrote:
>>>>> On 07/02/2012 06:20 PM, Amos Jeffries wrote:
>>>>>>
>>>>>> I am in the process of modifying the helper API for consistency
>>>>>> across
>>>>>> all helpers starting with 3.3. It would be great if you could
>>>>>> design
>>>>>> your helper to use a generic output format for data sent back to
>>>>>> Squid:
>>>>>>
>>>>>> [channel-ID] (OK/ERR/BH) [key-pairs] <terminator>
>>>>>
>>>>> OK, but not all helper communication is line-based. We may need
>>>>> to send
>>>>> PEM-encoded certificates back (and ssl_crtd already does that).
>>>>> That
>>>>> requires sending multiline blocks of data.
>>>>>
>>>>> If you want to generalize that, consider adding body start/end
>>>>> terminators.
>>>>
>>>> I know. That is why I omit the word "line" and specify
>>>> <terminator>
>>>> instead of <EOL>.
>>>
>>>
>>> The proposed format is missing the body itself, unless you want to
>>> force
>>> all helpers to use key=value format for blobs such as PEM-encoded
>>> certificates.
>>
>> Oops. yes. The HelperReply object has to include a field <blob> of
>> type
>> char* specific to each helper (for certs and bodies blobs, messages,
>> etc.) which includes everything between the first undentifiable
>> key-pair
>> and the terminator. It is required for backward compatibility even
>> if I
>> was set on key-pair always. So it may as well be formalised.
>
> Why should the body include key-value pairs?

Huh? which body are you referring to now?

>
>> [channel-ID] (OK/ERR/BH) [key-pairs] <blob> <terminator>
>
> How will the generic code be able to tell where key-pairs end and
> blob
> begins?

The generic code will have a format for key-pair of ( 1#token "="
1#(token / quoted-string) ) [to be finalized still] with a set of known
key names. If the bytes being parsed do not match that format and keys
its not part of the key-pairs.

In that sense it is not completely "generic", but more cross-helper
shared key-pairs being accepted back without barfing. Some will of
course be accepted but unused by certain helpers handler code (ie a
url=FOO from authenticators).

NOTE:
  Existing code has a shared parser pulling off [channel-ID] and passing
the remainder as char* to the helpers callback.

  What I'm doing in patch-#1 is making that shared parser pathway also
handle the OK/ERR/... result field shared by almost all the helpers
(redirectors exception) and converting the char* callback parameter to
an object (result, <blob>). Some issues being resolved around char* vs
String vs MemBuf (vs Sbuf?) for blob. Sort of settling on MemBuf for the
ssl_crtd \0 handling requirements.

  The plan for patch-#2 is to discuss key-pair syntax (which we seem to
have started), and move some particular key-pair parsing from helper
handlers into the shared one. Opening up user=, tag=, password=, log=,
message= keys to non-ACL helper responses will be VERY useful for RADIUS
and systems needing to maintain cross-helper request state.

>
>>> Ideally, there will be a way for generic helper parsers to
>>> detect and extract the body. To reach that ideal, there should be a
>>> common format that includes the body.
>>>
>>
>> Yes.
>>
>> Pedant: There are only 2 helpers out of 14 that send certificate
>> bodies.
>> This new one and ssl_crtd. Why define a "body" field just for them?
>
> It is certainly not needed if you do not want to have one
> parser/format
> for all helpers. We can continue to craft custom code for each new
> helper that needs to send bodies if you think that is the best
> approach.
>

Um, we seem to be getting off on different paths.
I *do* want a shared parser for as many details as possible ideally all
details as key-pair. I'm asking why you want a special field locking one
position in just for certificate body?

Defining a "foo=" key would possibly be useful. Even a custom value
micro-format for that key-pair. The key-pairs are ALL optional when
overall cross-helper needs are considered.

>
>> With [key-pair] before any helper-specific <blob>, we can add a
>> key-pair
>> "cert=<foo>" for generic certificate passing around if/when
>> necessary.
>
> This approach does not work well because <foo> may include spaces/'='
> and, hence, be confused with more key-pairs.

We are going to have to create a generic parser for HTTP header
field-values with this same syntax of key-pairs. With quoted-string and
url-encoding already requirements on some helpers re-using the same
parser routine to output key-pair and field-value is not going to be an
issue.

>
>
> If you want one format for all, you probably need something like
>
>
> [channel-ID] (OK/ERR/BH) [key-pairs] [BS <body>] <terminator>
>
> where "BS" is some special marker that starts all bodies and cannot
> be
> found in key-pairs. Since any body-carrying message is likely to have
> new lines (and, hence, would need a non-newline terminator), this BS
> sequence could be something like "body:\n", I guess.

We REQUIRE a format that does not rely on new special markers like that
in order to cope with the existing helpers responses in a
backward-compatible way without additional user configuration.

Or would you advocate moving the external_acl_type "protocol=N.N"
config option into the helper child object for use by all helpers on
determining what key-pairs and format is accepted?

Amos
Received on Wed Jul 04 2012 - 02:10:19 MDT