Re: [Privacy-pass] Roman Danyliw's Discuss on draft-ietf-privacypass-protocol-14: (with DISCUSS and COMMENT)

[Roman Danyliw <[e-mail]>]

Hi Chris!

Thanks for the quick follow-up explanations and pull request.  The latter looks good to me for merge and addressing my feedback.

I bit more inline …

From: Christopher Wood <[e-mail]>
Sent: Friday, September 22, 2023 5:10 PM
To: Roman Danyliw <[e-mail]>
Cc: The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: Roman Danyliw's Discuss on draft-ietf-privacypass-protocol-14: (with DISCUSS and COMMENT)

Thanks for the thorough review, as always, Roman. We addressed your comments in the following PR:

   https://github.com/ietf-wg-privacypass/base-drafts/pull/494

Please see inline below for responses to specific feedback.

Best,
Chris


On Sep 20, 2023, at 6:13 PM, Roman Danyliw via Datatracker <[e-mail]<mailto:[e-mail]>> wrote:

Roman Danyliw has entered the following ballot position for
draft-ietf-privacypass-protocol-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-privacypass-protocol/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Two things related to references ...

** Section 7.  Given the deferment of security and privacy considerations to
[ARCHITECTURE] and [CONSISTENCY], both seem to be a normative references.

Making the architecture a normative reference seems fine, but the referenced consistency document doesn’t rise to the same bar. That document provides guidance for how someone might implement a consistency mechanism, but it doesn’t actually specify a protocol. In this way, I consider it to be an informational reference.

[Roman] Re-reading the details of [CONSISTENCY] I agree -- I was wrong here, thanks for explaining.  I was largely keying on the language used to introduce this reference which seemed to suggest a relevance that it didn’t have (i.e., “Notable considerations include those pertaining to Issuer Public Key rotation and consistency, where consistency is as described in [CONSISTENCY<https://datatracker.ietf.org/doc/html/draft-ietf-privacypass-key-consistency-01>], and Issuer selection”).

** The reference for the format of SPKI (for RSA key material) doesn’t seem
right based on my read of the ASN.1 references.

-- Section 6.5
  The key identifier for a keypair (skI, pkI), denoted token_key_id, is
  computed as SHA256(encoded_key), where encoded_key is a DER-encoded
  SubjectPublicKeyInfo (SPKI) object carrying pkI.  The SPKI object
  MUST use the RSASSA-PSS OID [RFC5756], which specifies the hash
  algorithm and salt size.

-- Section 8.2.2 says:
  *  Token Key Encoding: Serialized as a DER-encoded
     SubjectPublicKeyInfo (SPKI) object using the RSASSA-PSS OID
     [RFC5756]

SubjectPublicKeyInfo (SPKI) seems to be defined in RFC5280.  Additionally, RFC
4055 provides the “algorithm” OBJECT IDENTIFIER as id-RSASSA-PSS, “parameters”
are RSASSA-PSS-params, and the “subjectPublicKey” is RSAPublicKey.

Wow, indeed, the current references do not seem correct! I believe the PR correctly references the necessary definitions, and also makes an attempt to use the proper terms. I will ask for review from people more familiar with the X.509 details to ensure it’s correct and matches what is deployed today.

[Roman] Sounds like a plan.  Credit to Russ Housley too who I had double check my suspicion about the ASN.1.

[snip]

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

    [snip]

** Appendix B.2.  Test Vector #2.  I had trouble verifying the token of the
second test vector in the example.  I didn’t try any other example.  I tried
the following:

What are you trying to do here? The token is a Token structure, which openssl won’t be able to parse. Are you trying to verify the signature of the token using the public key in the test vector?

[Roman] I mistakenly was interpreting that this token is simple SPKI structure (which this is not).  Thanks for clarifying my issue.

Thanks,
Roman