Draft: draft-gpew-priv-ppm

Commentary: When constructing HPKE contexts , we now include both sender and recipient roles , and the application label also includes the PPM version . I used here because we recently submitted  of and so the next submitted draft , which would include this change , will be . I also backported the definition of struct HpkeCiphertext from the interop PR because it makes everything tidier and should be non - controversial we can get a head - start on bringing those changes into main . 
 Fixed , thank you ! I also rewrote the relevant paragraph to acknowledge that there 's two encrypted input shares and that the leader should examine the HPKE config ID of the one intended for itself . Further , I recall pointing out to me that should this draft get adopted by the WG , we 'll reset to something like , so is the more appropriate application label . 
 There 's one more instance of that needs to be changed to . Otherwise , LGTM .
Paragraph (version A):
"aggregator_config_id" is equal to "HpkeConfig.id", where
"HpkeConfig" is the key config of the aggregator receiving the
input share.
Paragraph (version A):
"enc" is the HPKE encapsulated key, used by the aggregator to
decrypt its input share.
Paragraph (version A):
"payload" is the encrypted input share.
Paragraph (version A):
where "input_share" is the aggregator's input share and "nonce" and
"extensions" are the corresponding fields of "Report".
Paragraph (version B):
where "pk" is the aggregator's public key and "server_role" is the
Role of the intended recipient ("0x02" for the leader and "0x03" for
the helper).  In general, the info string for computing the HPKE
context is suffixed by two bytes, the first of which identifies the
role of the sender and the second of which identifies the role of the
intended recipient.
Paragraph (version B):
where "input_share" is the aggregator's input share and "nonce" and
"extensions" are the corresponding fields of "Report".  Clients MUST
NOT use the same "enc" for multiple reports.
Paragraph (version A):
The leader responds to requests with out-of-date "HpkeConfig.id"
values, indicated by "EncryptedInputShare.config_id", with status 400
and an error of type 'outdatedConfig'.  Clients SHOULD invalidate any
cached aggregator "HpkeConfig" and retry with a freshly generated
Report.  If this retried report does not succeed, clients MUST abort
and discontinue retrying.
Paragraph (version B):
The leader responds to requests whose leader encrypted input share
uses an out-of-date "HpkeConfig.id" value, indicated by
"HpkeCiphertext.config_id", with status 400 and an error of type
'outdatedConfig'.  Clients SHOULD invalidate any cached aggregator
"HpkeConfig" and retry with a freshly generated Report.  If this
retried report does not succeed, clients MUST abort and discontinue
retrying.
Paragraph (version A):
The "nonce" and "extensions" fields have the same value as those in
the report uploaded by the client.  Similarly, the "helper_share"
field is the "EncryptedInputShare" from the "Report" whose index in
"Report.encrypted_input_shares" is equal to the index of
"[aggregator]" in the task's aggregator endpoints.  [OPEN ISSUE: We
usually only need to send this in the first aggregate request.  Shall
we exclude it in subsequent requests somehow?]  The remainder of the
structure is dedicated to VDAF-specific request parameters.
Paragraph (version B):
The "nonce" and "extensions" fields have the same value as those in
the report uploaded by the client.  Similarly, the "helper_share"
field is the "HpkeCiphertext" from the "Report" whose index in
"Report.encrypted_input_shares" is equal to the index of
"[aggregator]" in the task's aggregator endpoints.  [OPEN ISSUE: We
usually only need to send this in the first aggregate request.  Shall
we exclude it in subsequent requests somehow?]  The remainder of the
structure is dedicated to VDAF-specific request parameters.
Paragraph (version A):
where "sk" is the HPKE secret key, "task_id" is
"AggregateReq.task_id" and "server_role" is the role of the server
("0x01" for the leader and "0x00" for the helper). "nonce" and
"extensions" are obtained from the corresponding fields in
"AggregateSubReq".  If decryption fails, then the sub-response
consists of a "decryption error" alert.  [See issue#57.]  Otherwise,
the helper handles the request for its plaintext input share
"input_share" and updates its state as specified by the PPM protocol.
Paragraph (version B):
where "sk" is the HPKE secret key, "task_id" is
"AggregateReq.task_id" and "server_role" is the role of the server
("0x02" for the leader and "0x03" for the helper; "0x01", the client
role, is used as the sender). "nonce" and "extensions" are obtained
from the corresponding fields in "AggregateSubReq".  If decryption
fails, then the sub-response consists of a "decryption error" alert.
[See issue#57.]  Otherwise, the helper handles the request for its
plaintext input share "input_share" and updates its state as
specified by the PPM protocol.
Paragraph (version A):
where "pk" is the HPKE public key encoded by the collector's HPKE key
configuration, "task_id" is "AggregateShareReq.task_id" and
"server_role" is the role of the server ("0x01" for the leader and
"0x00" for the helper).  "agg_share" is the serialized
"AggregateShare", and "batch_interval" is obtained from the
"AggregateShareReq".
Paragraph (version A):
"collector_hpke_config_id" is "collector_config.id" from the task
parameters corresponding to "CollectReq.task_id".
Paragraph (version A):
"enc" is the HPKE encapsulated key, used by the collector to
decrypt the aggregate share.
Paragraph (version A):
"payload" is an encrypted "AggregateShare".
Paragraph (version B):
where "pk" is the HPKE public key encoded by the collector's HPKE key
configuration and "task_id" is "AggregateShareReq.task_id".
"agg_share" is the serialized "AggregateShare", and "batch_interval"
is obtained from the "AggregateShareReq".
Paragraph (version B):
This encryption prevents the leader from learning the actual result,
as it only has its own share and not the helper's share, which is
encrypted for the collector.  The helper responds to the leader with
HTTP status 200 OK and a body consisting of an "HpkeCiphertext" where
"config_id" is set to the collector's HPKE config ID, "enc" is set to
the encapsulated HPKE context "enc" and "ciphertext" is
"encrypted_agg_share".
Paragraph (version A):
Once all the necessary reports have been prepared, the leader obtains
the helper's encrypted aggregate share for the batch interval by
sending an "AggregateShareReq" to the helper as described in
aggregate-share-request.  The leader then computes its own aggregate
share by aggregating all of the prepared output shares that fall
within the batch interval.
Paragraph (version A):
"shares" is a vector of "EncryptedAggregateShare"s, as described
in aggregate-share-request, except that for the leader's share,
the "task_id" and "batch_interval" used to encrypt the
"AggregateShare" are obtained from the "CollectReq".
Paragraph (version B):
where "pk" is the collector's public key.
Paragraph (version B):
The "encrypted_agg_shares" field is the vector of encrypted aggregate
shares.  They MUST appear in the same order as the aggregator
endpoints list of the task parameters.
Paragraph (version A):
where "sk" is the HPKE secret key, "task_id" is
"AggregateReq.task_id" and "server_role" is the role of the server
that send the aggregate share ("0x01" for the leader and "0x00" for
the helper). "batch_interval" is the "Interval" from the
"CollectReq".  The collector then unshards the aggregate shares into
an aggregate result using the VDAF's "agg_shares_to_result"
algorithm.
Paragraph (version B):
where "sk" is the HPKE secret key, "task_id" is
"AggregateReq.task_id" and "server_role" is the role of the server
that sent the aggregate share ("0x02" for the leader and "0x03" for
the helper). "batch_interval" is the "Interval" from the
"CollectReq".  The collector then unshards the aggregate shares into
an aggregate result using the VDAF's "agg_shares_to_result"
algorithm.