[OAUTH-WG] Re: SD-JWT and Unlinkability

[Watson Ladd]

But is what they implement secure?

We added lots of appendices to TLS 1.3 to help authors of under standards
understand what they had to say to get a secure result.

Adding unactionable mitigations doesn't help anyone including the authors
of the other documents you think will define this.

On Tue, Sep 24, 2024, 2:19 AM Kristina Yasuda 
wrote:

> SD-JWT document has a clearly defined scope and one can implement
> “something useful”that is meant to be in scope by reading only SD-JWT
> document.
>
> Also please see my other response about SD-JWT not being meant only for
> issuer-holder-verifier model. There might be usages of SD-JWT outside that
> model that do not need batch issuance. Like, theoretically, using sd-JWT as
> a content of an access token for whatever reason.
>
> Once again, “what we can do is to add a text saying more clearly that the
> details of batch issuance are defined elsewhere and what kind of details
> need to be defined in that document”.
>
>
> On Tue, Sep 24, 2024 at 11:10 AM Dick Hardt  wrote:
>
>> I understood your point. :)
>>
>> As a reader, I had no idea I was supposed to look elsewhere for guidance
>> on either unlinkability, explicit typing, or decoy digests.
>>
>> My other point is the document should stand on its own and not require
>> other documents to do something useful.
>>
>> On Tue, Sep 24, 2024 at 10:01 AM Kristina Yasuda <
>> yasudakrist...@gmail.com> wrote:
>>
>>> And my point is that SD-JWT document is a wrong place to look for such
>>> actionable language. The intention is not and should not be to define a
>>> stand alone batch issuance protocol in SD-JWT document.
>>>
>>> What we can do is to add a text saying more clearly that the details of
>>> batch issuance are defined elsewhere and what kind of details need to be
>>> defined in that document.
>>>
>>> Best,
>>> Kristina
>>>
>>>
>>>
>>> On Tue, Sep 24, 2024 at 9:22 AM Dick Hardt  wrote:
>>>
 My feedback is that the current language on batch issuance is not
 actionable, and that this document should stand on its own

 If the reader is supposed to take guidance from other documents, then
 you should refer to those other documents, but I would have that in
 addition to specific guidance.

 On Mon, Sep 23, 2024 at 10:03 PM Kristina Yasuda <
 yasudakrist...@gmail.com> wrote:

> > there is no guidance on how many to issue, nor how a holder chooses
> when to reissue the same ones
> > the question about users randomly selecting some to store and some
> to reject.
>
> These are great points, however, just like JWT/JWS specifications do
> not define how to manage the lifecycle of those, SD-JWT document is
> not a right place to discuss them. What you call a "hack" is not
> meant to be fully specified in SD-JWT document itself. Please review
> documents such as OpenID4VCI to improve various aspects of
> batch (re)issuance.
>
> On another note, and not sure this was your original point, but I can
> recall that originally, we had a text in the document that there are other
> ways to achieve verifier/verifier unlinkability, other than batch 
> issuance,
> mainly using advanced cryptography (aka ZKPs). Then, upon receiving
> feedback that such text is not really actionable or implementable, because
> it was not well established how to use ZKP with SD-JWTs, we removed
> sentences alluding to the mechanisms that are not batch issuance.
> However, I think that might be changing, looking at the work
> cryptographers at Google have been demonstrating recently. I think we are
> eagerly waiting for that work to be published and peer reviewed.
> To sum up, I think we could add back into the SD-JWT document a
> sentence saying there are ways other than batch issuance to achieve
> verifier-verifier unlinkability.
>
> Best,
> Kristina
>
>
> On Sat, Sep 21, 2024 at 5:56 PM Dick Hardt 
> wrote:
>
>> I understand it has become the accepted approach. It still comes
>> across as a hack, and there is no guidance on how many to issue, nor how 
>> a
>> holder chooses when to reissue the same ones.
>>
>> I'm amused by the decision to use implicit typing in a disclosure to
>> save a few bytes, but we will send dozens of credentials to minimize the
>> chance of linking :)
>>
>> On Sat, Sep 21, 2024 at 4:29 PM Daniel Fett 
>> wrote:
>>
>>> Hi Dick,
>>>
>>> Batch credential (not claims) issuing has become the default
>>> approach to circumvent the inherent limitations of salted-hash-based
>>> credentials formats. This was neither invented by us, nor is it
>>> unreasonable to ask implementers to do it. Protocols such as OpenID4VCI
>>> support it.
>>>
>>> -Daniel
>>> Am 21.09.24 um 06:42 schrieb Dick Hardt:
>>>
>>> Is it really going to be practical to batch issue claims, and have
>

[OAUTH-WG] Re: How to get the benefits of BBS+, without its drawbacks while using conventional cryptography ? (Was SD-JWT and Unlinkability)

[Watson Ladd]

Hello,

Multiple issuers creating a single credential is not stock BBS,
although I'm sure there is a paper out there somewhere on it.

It is possible to show a signature with a commited key (my SAC 2021
paper, or invoke SNARK but see the corrections that came out from
other authors as well) and then show equality of commited values. This
is orthogonal to the method of showing the commitment is in the
credential. However, these methods have all the same drawbacks you
mention for BBS.

if you're suggesting showing in the clear the TEE identity key, then
we need frequent reissuance to preserve unlinkability. This has
availability impacts. Furthemore issuer-holder matters.

Sincerely,
Watson

On Mon, Sep 23, 2024 at 12:02 AM Denis  wrote:
>
> Batches of digital credentials prevent collaborating Verifiers to link 
> accesses from the same End-User.
>
> However, there is another advantage which would be worthwhile to mention: 
> getting the benefits of BBS+ ... without its drawbacks
> (poor performances, large key sizes, large memory sizes, high computational 
> power required, not "green" and not resistant to quantum attacks).
>
> There exist use cases where claims contained in digital credentials issued by 
> different Issuers need to be presented to one Verifier.
>
> Using BBS +, when a Holder requests a digital credential to several digital 
> credential issuers, for each request, it uses a different blinded link secret
> and hence each issued digital credential will contain a different blinded 
> link secret. This value does not allow anybody to correlate digital 
> credentials
> issued by different digital credential issuers for the same Holder.
>
> An important benefit of the use of link secrets is the ability for a Holder 
> to demonstrate to a Verifier that credentials issued by different digital 
> credential issuers
> were indeed issued to the same Holder.
>
> When using the "traditional SD-JWT" model, the Holder generates one key pair 
> for each Issuer. In this way, a digital credential issued by the Issuer A
> cannot be linked between collaborative Verifiers to a digital credential 
> issued by the Issuer B. So far, so good.
>
> Now, let us suppose that Issuer A is a government, while Issuer B is a 
> University. An End-User would like to demonstrate to a Verifier
> that that he lives in California and that he got one diploma (among several) 
> from the University.
>
> For that specific use case, the Holder will generate one new key pair and use 
> the same private key to request a digital credential from each Issuer.
> The two issued digital credentials will contain the same public key and, 
> using the corresponding private key, the Holder will be able to demonstrate
> to one Verifier that the two presentations of the digital credentials 
> originate from the same Holder.
>
> Since that key pair will only be used once towards a single Verifier, a 
> linkage between different collaborative Verifiers using the framing of the 
> claims is not possible.
>
> This means that you can have your cake and it eat !
>
> Obviously, this means that the key pair SHALL be generated by a TA running in 
> a TEE that is part of the Holder (application).
> Both Issuers and Verifiers MUST be able to know these characteristics. See 
> one of my earlier comments:
>
> The key pair SHALL be generated by a secure cryptographic application that is 
> part of the Holder and the characteristics
> of that application SHALL be included in SD-JWT using the claim "scac" 
> (secure cryptographic application characteristics).
>
> Section 5.1.2 (Key Binding) currently states:
>
>It is out of the scope of this document to describe how the Holder key 
> pair is established.
>
> This section should be reconsidered and rewritten.
>
> Denis
>
> I understand it has become the accepted approach. It still comes across as a 
> hack, and there is no guidance on how many to issue, nor how a holder chooses 
> when to reissue the same ones.
>
> I'm amused by the decision to use implicit typing in a disclosure to save a 
> few bytes, but we will send dozens of credentials to minimize the chance of 
> linking :)
>
> On Sat, Sep 21, 2024 at 4:29 PM Daniel Fett  wrote:
>>
>> Hi Dick,
>>
>> Batch credential (not claims) issuing has become the default approach to 
>> circumvent the inherent limitations of salted-hash-based credentials 
>> formats. This was neither invented by us, nor is it unreasonable to ask 
>> implementers to do it. Protocols such as OpenID4VCI support it.
>>
>> -Daniel
>>
>> Am 21.09.24 um 06:42 schrieb Dick Hardt:
>>
>> Is it really going to be practical to batch issue claims, and have the 
>> holder randomly choose between them on presentation?
>>
>> As an implementer, what is the right number of claims to be in a batch?
>>
>> This section of the draft reads as a hack to add a new capability 
>> (unlinkability) to a mechanism that did not have that as a design objective.
>>
>> This is going to be like the "alg":"null" for S

[OAUTH-WG] Re: Call for adoption - PIKA

[Watson Ladd]

On Tue, Sep 17, 2024 at 1:02 PM Vladimir Dzhuvinov
 wrote:
>
> I frankly don't see how the central premise of PIKA - the reliance on a TLS 
> web domain certificate - can be made to work in practice.
>
>
> Reasons: Infrastructure in the real world, mixing of concerns, conflict with 
> CA policies and CAB Forum requirements, NIST etc guidance compliance issues.
>
>
> The argument - JWKs are already published at an HTTPS URL - so let's take the 
> private key from the web reverse proxy (assuming there is no HSM) and start 
> signing JWTs at some application with it - how I would be able to make this 
> argument at some company X.
>
> When we look at how infrastructure is setup and administered - even if we 
> here in the OAuth WG decide to say "using the private TLS key for other 
> purposes is entirely okay" - there are significant practical issues with 
> this. It's not just a matter of being theoretically able to cross from the 
> app layer into the TLS layer. These two layers are typically managed by 
> different departments in orgs, and there are good reasons to isolate them. I 
> can't imagine being able to go to the admins and say, make me a copy of the 
> private key so I can sign JWTs with it, or let me install this service on 
> your infra to sign my JWTs.

Like it or not the Web PKI is the only system to prove domain control
via cryptographic means that exists. You can of course get another
cert for use for only this purpose: signing with the web servers cert
is not required in the current draft.

>
> Let's also think about the potential legal and compliance issues.
>
> CAs that issue certs that prove web domain control have policies. These 
> policies are linked to the EKU values in the certs. Using the cert to sign 
> stuff other than that expressly identified in the CA policy and the 
> extKeyUsage fields can be seen as breaking those policies.

We've resolved this issue with Delegated Credentials, there's no
reason to think we can't do the same here. It really isn't a problem.

>
> https://letsencrypt.org/documents/LE-SA-v1.3-September-21-2022.pdf
>
> 3.6 Installation and Use of Your Certificate
>
> The purpose of Your Certificate is to authenticate and encrypt Internet 
> communications.
>
> I'd also suggest to go and check whether the CA / Browser Forum, in its 
> "Baseline Requirements for the Issuance and
> Management of Publicly‐Trusted TLS Server Certificates" does not stipulate an 
> overarching policy for CAs that generally prohibits issue of TLS certs with 
> additional EKU values.

Mozilla's CA policy specifically envisions the potential use of a root
certificate to sign intermediates that don't have the ServerAuth EKU
but could have a different one for this.
>
> Orgs that seek compliance with NIST and similar guidance are likely to see 
> issue with this approach too. Documents like NIST Special Publication 800-57 
> / Recommendation for Key Management.
>
> I'm not in favour of adopting this spec as it is in the WG. Let's consider 
> the practical situation apart from what seems technically possible.
>
> I made a diff between drafts 01 & 02 and noticed that in 02 the policy issues 
> of using CA TLS certs for PIKA were probably recognised to some degree, in 
> the "5.2. Signing Key Compromise" section.
>
> https://author-tools.ietf.org/iddiff?url1=draft-barnes-oauth-pika-00&url2=draft-barnes-oauth-pika-01&difftype=--html
>
> Apart from the "5.2. Signing Key Compromise" section, draft 02 that is now 
> proposed for adoption is identical to the original 01 that wasn't adopted in 
> June. It's okay to explain the intent to resubmit without changes, just as 
> it's okay to disagree on a particular adoption. I get it that the topic of 
> PIKA feels contentious.
>
>
> Vladimir Dzhuvinov


-- 
Astra mortemque praestare gradatim

___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: WGLC for SD-JWT

[Watson Ladd]

On Fri, Sep 13, 2024 at 10:17 AM Brian Campbell
 wrote:
>
> Watson,
>
> Thank you for your comments during the Vancouver meeting and subsequently on 
> the mailing list. Your input helped initiate some valuable discussions, and 
> I’ve incorporated additional text into the Unlinkability subsection under the 
> Privacy Considerations to reflect the general consensus that emerged.

There's certainly been a lot of discussion, but I think a general
consensus is rather more nebulous.

>
> I appreciate your role in sparking this conversation, which has undoubtedly 
> improved the document. I’d also like to respectfully remind everyone that the 
> content of these documents is meant to represent the rough consensus of the 
> working group, rather than any single individual’s perspective.

I agree: i'd like to see more people weigh in specifically on how 11.3
can be useful to them in mitigating the risks, in part to ensure that
what is produced is really representative. However, I do expect IESG
will take a careful look at this and the overall systemwide
challenges.

>
> Respectfully,
> Brian
>
>
> On Wed, Sep 4, 2024 at 3:20 PM Watson Ladd  wrote:
>>
>> The privacy considerations section does not have enough RFC 2119
>> language in the Unlinkability section. There is no workable guidance
>> on how to mitigate these risks. Presentation to users is not a
>> workable solution: please learn from how browsers have suffered a lot
>> at this. It's also very prolix. This is in contrast to 11.1 and 11.2.
>>
>> Sincerely,
>> Watson
>>
>> On Tue, Sep 3, 2024 at 3:40 AM Rifaat Shekh-Yusef
>>  wrote:
>> >
>> > All,
>> >
>> > As per the discussion in Vancouver, this is a WG Last Call for the SD-JWT 
>> > document.
>> > https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-11.html
>> >
>> > Please, review this document and reply on the mailing list if you have any 
>> > comments or concerns, by Sep 17th.
>> >
>> > Regards,
>> >   Rifaat & Hannes
>> > ___
>> > OAuth mailing list -- oauth@ietf.org
>> > To unsubscribe send an email to oauth-le...@ietf.org
>>
>>
>>
>> --
>> Astra mortemque praestare gradatim
>>
>> ___
>> OAuth mailing list -- oauth@ietf.org
>> To unsubscribe send an email to oauth-le...@ietf.org
>
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
> material for the sole use of the intended recipient(s). Any review, use, 
> distribution or disclosure by others is strictly prohibited.  If you have 
> received this communication in error, please notify the sender immediately by 
> e-mail and delete the message and any file attachments from your computer. 
> Thank you.



-- 
Astra mortemque praestare gradatim

___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: WGLC for SD-JWT

[Watson Ladd]

The privacy considerations section does not have enough RFC 2119
language in the Unlinkability section. There is no workable guidance
on how to mitigate these risks. Presentation to users is not a
workable solution: please learn from how browsers have suffered a lot
at this. It's also very prolix. This is in contrast to 11.1 and 11.2.

Sincerely,
Watson

On Tue, Sep 3, 2024 at 3:40 AM Rifaat Shekh-Yusef
 wrote:
>
> All,
>
> As per the discussion in Vancouver, this is a WG Last Call for the SD-JWT 
> document.
> https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-11.html
>
> Please, review this document and reply on the mailing list if you have any 
> comments or concerns, by Sep 17th.
>
> Regards,
>   Rifaat & Hannes
> ___
> OAuth mailing list -- oauth@ietf.org
> To unsubscribe send an email to oauth-le...@ietf.org



-- 
Astra mortemque praestare gradatim

___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] oauth-selective-disclosure-jwt Pull 451 is insufficient

[Watson Ladd]

Hello,

I would like to point out that the issuer verifier problem still
remains open, even given the text in 11.

The text is directionally wrong. It discusses how the issuer and
verifier must be trusted, not what they can do together, and than only
says that deployers must be aware and educate users. There's nothing
actionable here, and user education doesn't work. Users cannot make
security decisions of this nature, as we know from decades and decades
of experience.

Can we please get text that informs our readers what the issue is and
what the risks are?

Sincerely,
Watson Ladd
-- 
Astra mortemque praestare gradatim

___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: We cannot trust Issuers

[Watson Ladd]

As said I offer it as a starting point. There might be some value in
the existing text, but I found it distracted from clear presentation
of the problem. What's the problem with using MUST? We have to give
people who use these documents clear guidance.

I think the tautology is obvious: if SD-JWT doesn't offer the property
X that is required, it MUST NOT be used when X is required. and that's
exactly what should appear.

On Wed, Jul 31, 2024, 4:58 PM Brian Campbell  wrote:
>
> I guess I had envisioned suggestions that didn't delete a bunch of existing 
> valuable and useful text. Rather I was expecting (or maybe just hoping) for 
> thoughtful suggestions adding to what's already written that, as I'd said, 
> better frame the risks and difficulties around Issuer/Verifier Unlinkability 
> (perhaps especially with respect to something like a government issuer 
> compelling collusion from verifiers). I'm also not a big fan of broad strokes 
> RFC 2119 language in privacy considerations.
>
> On Wed, Jul 31, 2024 at 11:31 AM Watson Ladd  wrote:
>>
>> I've opened 
>> https://github.com/oauth-wg/oauth-selective-disclosure-jwt/pull/448
>> as a step torwads this.
>>
>> On Wed, Jul 31, 2024 at 5:31 AM Brian Campbell
>>  wrote:
>> >
>> >
>> >
>> > On Tue, Jul 23, 2024 at 11:15 AM Leif Johansson  wrote:
>> >>
>> >> On Mon, 2024-07-22 at 19:43 -0400, Richard Barnes wrote:
>> >> > I would observe that any solution based on garden-variety digital
>> >> > signature (not something zero-knowledge like BBS / JWP) will have
>> >> > problems with issuer/verifier collusion.  One-time tokens and batch
>> >> > issuance don't help.  There is no such thing as SD-JWT with
>> >> > issuer/verifier collusion resistance.  At best you could have SD-JWP.
>> >> >
>> >> > I don't think this needs to be a blocker on SD-JWT.  There are use
>> >> > cases that don't require issuer/verifier collusion resistance.  We
>> >> > should be clear on the security considerations and warn people away
>> >> > who care about issuer/verifier collusion resistance, and accelerate
>> >> > work on SD-JWP if that's an important property to folks.
>> >> >
>> >>
>> >>
>> >> +1 on this
>> >
>> >
>> > I'm generally a +1 on this too.  There is an attempt at a discussion 
>> > around unlinkablity in the privacy considerations at 
>> > https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-unlinkability
>> >  currently. Concrete suggestions to that text about how to better frame 
>> > the risks and difficulties around Issuer/Verifier Unlinkability (perhaps 
>> > especially with respect to something like a government issuer compelling 
>> > collusion from verifiers) would be welcome for consideration.
>> >
>> > CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
>> > material for the sole use of the intended recipient(s). Any review, use, 
>> > distribution or disclosure by others is strictly prohibited.  If you have 
>> > received this communication in error, please notify the sender immediately 
>> > by e-mail and delete the message and any file attachments from your 
>> > computer. Thank you.
>>
>>
>>
>> --
>> Astra mortemque praestare gradatim
>
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
> material for the sole use of the intended recipient(s). Any review, use, 
> distribution or disclosure by others is strictly prohibited.  If you have 
> received this communication in error, please notify the sender immediately by 
> e-mail and delete the message and any file attachments from your computer. 
> Thank you.

___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: We cannot trust Issuers

[Watson Ladd]

I've opened https://github.com/oauth-wg/oauth-selective-disclosure-jwt/pull/448
as a step torwads this.

On Wed, Jul 31, 2024 at 5:31 AM Brian Campbell
 wrote:
>
>
>
> On Tue, Jul 23, 2024 at 11:15 AM Leif Johansson  wrote:
>>
>> On Mon, 2024-07-22 at 19:43 -0400, Richard Barnes wrote:
>> > I would observe that any solution based on garden-variety digital
>> > signature (not something zero-knowledge like BBS / JWP) will have
>> > problems with issuer/verifier collusion.  One-time tokens and batch
>> > issuance don't help.  There is no such thing as SD-JWT with
>> > issuer/verifier collusion resistance.  At best you could have SD-JWP.
>> >
>> > I don't think this needs to be a blocker on SD-JWT.  There are use
>> > cases that don't require issuer/verifier collusion resistance.  We
>> > should be clear on the security considerations and warn people away
>> > who care about issuer/verifier collusion resistance, and accelerate
>> > work on SD-JWP if that's an important property to folks.
>> >
>>
>>
>> +1 on this
>
>
> I'm generally a +1 on this too.  There is an attempt at a discussion around 
> unlinkablity in the privacy considerations at 
> https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-unlinkability
>  currently. Concrete suggestions to that text about how to better frame the 
> risks and difficulties around Issuer/Verifier Unlinkability (perhaps 
> especially with respect to something like a government issuer compelling 
> collusion from verifiers) would be welcome for consideration.
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
> material for the sole use of the intended recipient(s). Any review, use, 
> distribution or disclosure by others is strictly prohibited.  If you have 
> received this communication in error, please notify the sender immediately by 
> e-mail and delete the message and any file attachments from your computer. 
> Thank you.



-- 
Astra mortemque praestare gradatim

___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: We cannot trust Issuers

[Watson Ladd]

And the draft doesn't have a sufficiently strong statement saying this tech
(which has significant limitations: every TEE has fallen due to side
channels) is needed for relevant application scenarios.

I'm not saying this work shouldn't continue: I'm saying that we need to
ensure we get the privacy and security considerations right, and make clear
the limitations and that users shouldn't be mislead about the degree of
anonymity they have. The applications being envisioned are dangerous.

Sincerely,
Watson Ladd

On Mon, Jul 22, 2024, 6:51 PM Wayne Chang  wrote:

> Hi Watson,
>
> Here’s an approach based on TEEs that can in theory create unlinkability
> for things like mdocs and SD-JWTs while also conforming to FIPS 140-2/-3.
> No new crypto, and PQC-friendly.
>
>
> https://blog.spruceid.com/provably-forgotten-signatures-adding-privacy-to-digital-identity/
>
> Best,
> - Wayne
>
> On Mon, Jul 22, 2024 at 16:26 Watson Ladd  wrote:
>
>>
>>
>> On Mon, Jul 22, 2024, 3:30 PM John Bradley  wrote:
>>
>>> I agree that single-use proof keys and batch issuance are a must.
>>>
>>> Issuer verifier collusion is admittedly a problem.   To address that we
>>> do need different cryptographic methods.
>>>
>>> MDOC also has the same issue.
>>>
>>> We should document the risk, but short of stopping EUID and mobile
>>> driver's license deployment, we have limited options.
>>>
>>
>> The problem only appears when the drivers license or EUID is used in a
>> way that makes the user think their data is private. You don't have to
>> support UX that lies to the user.
>>
>>
>>> Hopefully, we can make quick progress on JWP.
>>>
>>> John B.
>>>
>>> On Mon, Jul 22, 2024 at 2:14 PM Watson Ladd 
>>> wrote:
>>>
>>>> Dear Oauth,
>>>>
>>>> I'm disappointed to see SD-JWT work continue with inadequate privacy
>>>> considerations. The fact is an Issuer can link any showings to
>>>> issuance of the credential. This is not foregrounded sufficiently in
>>>> privacy considerations, nor do we discuss how to ensure users are
>>>> aware. We really need to use more RFC 2119 language and highlight
>>>> these issues. Section 11.1 about local storage which has never been an
>>>> IETF concern before is far more prescriptive than 11.4, and that's not
>>>> a good thing. To be clear, the threat model must include an issuer
>>>> that is a government issuing credentials that if used to verify age on
>>>> certain websites or via a digital wallet on site, and learned about by
>>>> the issuer who may have access to data from the site, will result in
>>>> imprisonment or execution. This is not a hypothetical scenario.
>>>>
>>>> Users and UX designers will have intuitions that do not match the
>>>> reality and that result in bad decisions being made. That's on us. A
>>>> driver's license doesn't leave a trace of where you showed it, but the
>>>> SD-JWT does.
>>>>
>>>> At a minimum I think we mandate batch issuance and one time usage
>>>> using RFC 2119 language. We need to say in clear, unambiguous English
>>>> that this mechanism enables an issuer to connect every presentation of
>>>> a credential to the issuance.
>>>>
>>>> Sincerely,
>>>> Watson Ladd
>>>>
>>>> --
>>>> Astra mortemque praestare gradatim
>>>>
>>>> ___
>>>> OAuth mailing list -- oauth@ietf.org
>>>> To unsubscribe send an email to oauth-le...@ietf.org
>>>>
>>> ___
>> OAuth mailing list -- oauth@ietf.org
>> To unsubscribe send an email to oauth-le...@ietf.org
>>
>
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: We cannot trust Issuers

[Watson Ladd]

On Mon, Jul 22, 2024, 3:30 PM John Bradley  wrote:

> I agree that single-use proof keys and batch issuance are a must.
>
> Issuer verifier collusion is admittedly a problem.   To address that we do
> need different cryptographic methods.
>
> MDOC also has the same issue.
>
> We should document the risk, but short of stopping EUID and mobile
> driver's license deployment, we have limited options.
>

The problem only appears when the drivers license or EUID is used in a way
that makes the user think their data is private. You don't have to support
UX that lies to the user.


> Hopefully, we can make quick progress on JWP.
>
> John B.
>
> On Mon, Jul 22, 2024 at 2:14 PM Watson Ladd  wrote:
>
>> Dear Oauth,
>>
>> I'm disappointed to see SD-JWT work continue with inadequate privacy
>> considerations. The fact is an Issuer can link any showings to
>> issuance of the credential. This is not foregrounded sufficiently in
>> privacy considerations, nor do we discuss how to ensure users are
>> aware. We really need to use more RFC 2119 language and highlight
>> these issues. Section 11.1 about local storage which has never been an
>> IETF concern before is far more prescriptive than 11.4, and that's not
>> a good thing. To be clear, the threat model must include an issuer
>> that is a government issuing credentials that if used to verify age on
>> certain websites or via a digital wallet on site, and learned about by
>> the issuer who may have access to data from the site, will result in
>> imprisonment or execution. This is not a hypothetical scenario.
>>
>> Users and UX designers will have intuitions that do not match the
>> reality and that result in bad decisions being made. That's on us. A
>> driver's license doesn't leave a trace of where you showed it, but the
>> SD-JWT does.
>>
>> At a minimum I think we mandate batch issuance and one time usage
>> using RFC 2119 language. We need to say in clear, unambiguous English
>> that this mechanism enables an issuer to connect every presentation of
>> a credential to the issuance.
>>
>> Sincerely,
>> Watson Ladd
>>
>> --
>> Astra mortemque praestare gradatim
>>
>> ___
>> OAuth mailing list -- oauth@ietf.org
>> To unsubscribe send an email to oauth-le...@ietf.org
>>
>
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] We cannot trust Issuers

[Watson Ladd]

Dear Oauth,

I'm disappointed to see SD-JWT work continue with inadequate privacy
considerations. The fact is an Issuer can link any showings to
issuance of the credential. This is not foregrounded sufficiently in
privacy considerations, nor do we discuss how to ensure users are
aware. We really need to use more RFC 2119 language and highlight
these issues. Section 11.1 about local storage which has never been an
IETF concern before is far more prescriptive than 11.4, and that's not
a good thing. To be clear, the threat model must include an issuer
that is a government issuing credentials that if used to verify age on
certain websites or via a digital wallet on site, and learned about by
the issuer who may have access to data from the site, will result in
imprisonment or execution. This is not a hypothetical scenario.

Users and UX designers will have intuitions that do not match the
reality and that result in bad decisions being made. That's on us. A
driver's license doesn't leave a trace of where you showed it, but the
SD-JWT does.

At a minimum I think we mandate batch issuance and one time usage
using RFC 2119 language. We need to say in clear, unambiguous English
that this mechanism enables an issuer to connect every presentation of
a credential to the issuance.

Sincerely,
Watson Ladd

-- 
Astra mortemque praestare gradatim

___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: Call for adoption - PIKA

[Watson Ladd]

On Tue, Jun 25, 2024 at 2:56 PM Michael Jones
 wrote:
>
> The other critique I voiced of the approach is that the application-level 
> X.509 certificate can be used to secure the HOST part of the issuer, but not 
> the entire issuer, since in general, the issuer will contain a PATH.  Yes, 
> the service hosting the issuers controls all the paths, as Richard replied 
> earlier, but it’s not the service who is the attacker that this enables.  The 
> attackers that not securing the PATH enables are the tenants themselves.
>
>
>
> An attacker could host a tenant at the service and get an X.509 certificate 
> securing the HOST part of its issuer.  However, because a legitimate tenant 
> at another path shares the same HOST, the attacker can copy its X.509 
> certificate chain and utilize a substitution attack to make unauthorized 
> statements about the victim tenant – statements that were not made by the 
> hosting service.
>
>
>
> This attack was not addressed, and I believe is intrinsic to the decision not 
> to protect the entire issuer value.
>
>
>
> I believe that adopting this draft would result in this attack occurring in 
> practice.

To be clear, drafts get modified by the WG after adoption so adoption
is not the same thing as WGLC.

However, I'm not sure I understand your attack scenario. If we have a
"tenant" distinguished by a path, there is already a security issue
with giving it the X509 certificate. It could then imitate any other
tenant on that server already. That's why we use reverse proxies and
put the certificate only on the proxying machines.

Sincerely,
Watson



-- 
Astra mortemque praestare gradatim

___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: [ID-align] Re: Re: Re: Fwd: Internet Terminology Glossary

[Watson Ladd]

On Thu, Jun 13, 2024 at 2:20 PM Dick Hardt  wrote:
>
>
>
> On Thu, Jun 13, 2024 at 1:37 PM Denis  wrote:
>>
>>
>> The two following sentences seem to be contradictory:
>>
>> The glossary will contain: terms and definitions used in finalized 
>> documents; and references to new terms and definitions being proposed in 
>> draft documents.
>>
>> New definitions for existing terms, or new terms being used in draft 
>> documents will not be published in the Glossary until the document has been 
>> finalized.
>
>
> We need to improve this language, sorry for the confusion.
>
> Definitions that have not been finalized by being in a finalized document 
> will not be in the glossary. There will be a reference in the glossary to the 
> document that is drafting a new definition.
>
> This would enable someone looking at the glossary to know that a WG is 
> creating a new definition, and they would then share their input on what that 
> new definition is.

Is this a glossary or a concordance?

>
> --
> ID-align mailing list -- id-al...@ietf.org
> To unsubscribe send an email to id-align-le...@ietf.org



-- 
Astra mortemque praestare gradatim

___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: Call for adoption - PIKA

[Watson Ladd]

On Mon, Jun 10, 2024, 9:33 PM Michael Jones  wrote:
>
> Watson, you wrote "An X509 certificate is the only way to link a DNS name to 
> a key at a given point in time".  However, that's not true.  For over a dozen 
> years, OpenID Connect has used a .well-known endpoint rooted at the issuer 
> URL from which keys are retrieved (using the jwks_uri parameter) that are 
> used to validate the signature by the issuer.  No application-level X.509 
> required.  The OAuth Authorization Server Metadata spec uses the same 
> mechanism.
>
> And Watson, you wrote "I don't understand your proposal."  I would propose to 
> likewise define a .well-known endpoint for this specification used to 
> retrieve keys used to validate the issuer signature.  It's a well-established 
> pattern that should be used here too.

The third sentence in the abstract of the draft explains why this
won't work for certain applications, namely that the server might not
be available when the signature needs verification. Again, are there
particular application platforms you are worried about not having X509
implementations?

Sincerely,
Watson Ladd

___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: Call for adoption - PIKA

[Watson Ladd]

On Mon, Jun 10, 2024 at 8:33 PM Michael Jones
 wrote:
>
> We all know that TLS certificates are handled by platform layers used by 
> applications and not the applications themselves.  There is no code that 
> understands X.509 certificates in most applications that use TLS.  They are 
> not equivalent in complexity.
>
>
>
> The draft would require adding code directly understanding the structure and 
> fields of X.509 to applications using it.  Eliminate that, and I’ll support 
> adoption.

I don't understand your proposal. An X509 certificate is the only way
to link a DNS name to a key at a given point in time as we can
leverage the Web PKI. Absent that, what do you do?

Also, I'm not sure what you mean by platform layers. Many of them
expose a function to verify a signature with a key in an X509 cert or
verify a cert chain, even outside the context of TLS. Are there
particular ones that would have a problem you are concerned about?

Sincerely,
Watson Ladd

___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: Invitation: OAuth WG Virtual Interim - FedCM @ Tue May 7, 2024 12pm - 1pm (EDT) (oauth@ietf.org)

[Watson Ladd]

On Thu, May 9, 2024 at 7:24 AM Neil Madden  wrote:
>
> On 9 May 2024, at 00:06, Sam Goto  wrote:
>
> [...]
>>
>>
>> I guess, flipping this around, we might ask what is the legitimate purpose 
>> for which browsers need to access the user’s name, email address (both 
>> requires) and other identifying information? I’d have thought an identifier 
>> (possibly randomised) and some user-supplied account nickname would be 
>> sufficient.
>
>
> That's easier to answer: the browser needs name/email/picture to construct an 
> account chooser, which is the UX that tested best with users by a far margin.
>
> Static/unpersonalized permission prompts - example in Safari, example in 
> Chrome - perform extremely poorly (in comparison to account choosers), 
> although have other benefits too (namely ergonomics and extensibility), so 
> Chrome (and others) expose that too in the form of the Storage Access API.
>
>
>
> Yeah, that's what I suspected. Did you do research that specifically called 
> out email addresses as a must-have?

I'm sort of mystified here by the objection.

What exactly is the alternative where the user agent doesn't have
access to all of the data passing through it? In particular user
emails are everywhere in the User Agent. It's in the autofill
settings, the webmail interface, every signup form filled out etc,
etc.

To be absolutely clear today the information generally appears in big
bold text to confirm the user wants to pass it to the RP, and those
letters are made to appear on screen through a process the User Agent
is very involved in. It also got typed in by the user (or autofilled
by the user agent) when signing into the IdPs. Usually there are UI
ways to confirm what account you are signed into that depend on
similar APIs. And everything the user does is done through the User
Agent. Is there some exotic setup that I'm ignoring here?

I'm just very confused as to why this is a problem.

Sincerely,
Watson Ladd

>
> PS - although this is an OAuth group, you may also want to look at things 
> like Dropbox's Chooser/Saver widgets 
> (https://www.dropbox.com/developers/chooser), which provide fine-grained 
> permissions to access specific files/folders using a file dialog UX rather 
> than a redirect-based flow. I appreciate that may not be your initial focus, 
> but one for the "mood board" as it were...
>
> -- Neil
> ___
> OAuth mailing list -- oauth@ietf.org
> To unsubscribe send an email to oauth-le...@ietf.org



-- 
Astra mortemque praestare gradatim

___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

Re: [OAUTH-WG] Signed JWK Sets

[Watson Ladd]

On Sun, Mar 17, 2024 at 5:32 PM Richard Barnes  wrote:
>
> Hi Watson,
>
> I appreciate the concerns with regard to re-using Web PKI certs for cases 
> such as these.  Care is required, but I think there is a path here.
>
> 1. Clearly there are cross-protocol concerns.  I expect that most usage here 
> in reality would be based on ECDSA / EdDSA, not RSA, which helps.  I would be 
> comfortable with security considerations recommending that a key pair / 
> certificate used for signing these things be used for no other purpose.
>
> 2. Validity times are definitely a challenge for the container signing use 
> case, but from the conversations I've had with that community, they are 
> taking an orthogonal approach.  As I tried to sketch in the document, they 
> are establishing authorities that will vouch that a signed thing existed at a 
> given time, so that a relying party can safely rewind their clock and 
> validate as if it were that time.  See, e.g., SigStore 
> , which has roughly this shape if you squint right.

That should work out: might want a security considerations saying this.

>
> 3. I don't think there's actually any disconnect between HTTPS authentication 
> and proof of authority.  The Web PKI is about authenticating domain names, 
> which is what both use cases require.

Only with certain validation methods. Others like agreed upon change
to site content have a narrower scope and the BRs reflect this
subtlety. To be honest you're probably safe and I am not the expert
here.

Sincerely,
Watson

--
Astra mortemque praestare gradatim

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signed JWK Sets

[Watson Ladd]

On Sat, Mar 16, 2024 at 10:56 PM Richard Barnes  wrote:
>
> Hi all,
>
> A few of us have been considering use cases for JWTs related to Verifiable 
> Credentials and container signing, which require better "proof of authority" 
> for JWT signing keys.  Sharon Goldberg and I wrote up a quick specification 
> for how to sign a JWK set, and how you might extend discovery mechanisms to 
> present such a signed JWK set:
>
> https://github.com/bifurcation/redistributable-jwks/blob/main/draft-barnes-oauth-redistributable-jwks.md
>
> (Just in GitHub for now; will publish as an I-D when the window reopens 
> tomorrow.)
>
> If we could get this functionality added to OAuth / OIDC, it would make these 
> use cases work a lot better.  As a prelude toward proposing working group 
> adoption, it would be great to know if this design seems helpful to other 
> folks as well.  Obviously, happy to answer any questions / comments.

I have concerns about this proposal. First we need to ban any use of
RSA-1.5 encryption (aka TLS 1.2) with the certificates used here. This
is not really possible in TLS as commonly implemented for reasons, and
can't be determined from the certificate alone (unless it's RSA-PSS
certificate with special stuff that hopefully is honored or ECDSA).
Then there's a philosphical issue to reusing keys for different
purposes that requires domain separation ala TLS 1.3, and likely some
X509 extensions as well to really nail it.

Secondly there are a bunch of layer 8 question with the Web PKI this
raises. The web PKI is moving to short term issuance and possibly
removal of revocation entirely if certificates can be sufficiently
short term. For signatures on containers this is inappropriate: a
verification that a container is the correct container needs to be
possible long after 90 days or a week, and this means the keying
material that was used to make that signature must be held secure
afterwards. This runs straight up into what we're trying to do to
improve the Web PKI, and using the Web PKI for other things often
leads to pain.

Thirdly the web PKI issuance methods make sense from a web
perspective, but not necessarily from a codesigning perspective. What
we want to validate is different. Organizationally websites and
codesigning often belong in different places. At the same time there's
a barrier to alternatives, especially the ones that don't exist (see
also Roughtime for my personal experience with this). These issues get
real thorny real fast.

Sincerely,
Watson Ladd


-- 
Astra mortemque praestare gradatim

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] R: [SPICE] OAuth Digital Credential Status Attestations (typo)

[Watson Ladd]

It could be a resused one obtained from a different context. Does that
matter? Depends on application. There's also a question of what it
means the subject processed it: people don't process VCs, their
computers do. (Hence the terminology of User Agent, not user, in the
W3C)



On Sun, Jan 21, 2024 at 4:46 PM Tom Jones  wrote:
>
> I should have added - if you get a verifiable presentation from a wallet with 
> a verifiable credential - it is my understanding that the VP is proof 
> possession - in the sense that the VC has been processed by the subject to 
> create the VP.
>
> I started to collect some information about that here - but it is far from 
> complete. 
> https://tcwiki.azurewebsites.net/index.php?title=Verifiable_Presentation#Full_Text_or_Meme
>
> ..tom
>
>
> On Sun, Jan 21, 2024 at 1:03 PM Tom Jones  
> wrote:
>>
>> Technically oauth is about authorization not authentication. And technically 
>> attestation is provided by rats and not oauth. So if you think that you are 
>> confused, so is everyone else at this point.
>>
>> thx ..Tom (mobile)
>>
>> On Sun, Jan 21, 2024, 11:51 AM  wrote:
>>>
>>> Hi Tom et al.
>>>
>>> Earlier this or last week someone wrote about the possibility of looking at 
>>> things from a relying party's perspective.
>>>
>>> As a relying party I need a method for a user to prove who and what they 
>>> are or have. Hence the user needs to present evidence as proof of who they 
>>> are and in what capacity or holding they are presenting.
>>>
>>> I have been very involed in SSI and verfiable credentials (VC). Which is 
>>> becoming a major way of presentiing evidence as proof.
>>>
>>> VCs are cryptographic proofs for a relying party. However the relying party 
>>> also needs proof of who is presenting.  WShen you combine the two you now 
>>> address proof of possession problem which has been the underlying weakness 
>>> of public key cryptography.
>>>
>>> I was not trying to be misleading. I  was responding to the discussion 
>>> below regarding " digital proof, digital credential, secure and privacy 
>>> preserving fashion, collusion between holders, collection limitation, 
>>> privacy principles, unlinkability between verifiers and more.
>>>
>>> I have done a lot of work in this area and believe have addressed the proof 
>>> of possession issue of public key cryptography because I can 
>>> cryptographically and privately bind a users biometrics with both their 
>>> public and private keys and can embed the same with veriable credentials. 
>>> Whereas when I see the OAuth work it seems to be trying to create an audit 
>>> trail rather than solving the proof of posession by the original 
>>> client/wallet initiating the transaction.
>>>
>>> As I said I was not trying to be misleading. At the same time I do not see 
>>> the current OAuth track as solving this underlying proof of possesion 
>>> problem that is needed by the relying party.
>>>
>>> Best
>>>
>>> Don
>>>
>>> And for the record I am not a technologist. I am a person who tries to 
>>> solve business problems.
>>>
>>>
>>>
>>> On 2024-01-21 11:08, Tom Jones wrote:
>>>
>>> yes - i see that's what you are doing and think it is not only wrong, but 
>>> misleading.
>>> Somehow words like trust and proof are given technological definitions by 
>>> technologists that do not reflect the words existing meaning, but seek to 
>>> gain reflected credence by their use in technological contexts. .  (like  
>>> proof -> a cryptographic ability that is verifiable)
>>> Perhaps you don't care that these are incorrect uses of the word?
>>>
>>> ..tom
>>>
>>> On Fri, Jan 19, 2024 at 10:46 AM  wrote:
>>>
>>> You present evidence as proof.
>>>
>>>
>>> On 2024-01-19 12:50, Tom Jones wrote:
>>>
>>>
>>> Proof seems to be yet another term for which we already have other terms.
>>> Can anyone explain the difference between:
>>> proof
>>> presentation
>>> evidence.
>>>
>>> ..tom
>>>
>>> On Fri, Jan 19, 2024 at 4:28 AM Denis  wrote:
>>>
>>> Hi Giuseppe,
>>>
>>> Ciao Denis,
>>>
>>> Thank you! By points.
>>>
>>> First, I still have a vocabulary problem. The text states:
>>>
>>> A digital credential may be presented to a verifier long after it has been 
>>> issued.
>>>
>>> It should rather say: A digital proof (derived from a digital credential) 
>>> may be presented to a verifier.
>>>
>>> Then, the text states:
>>>
>>> Verifier:
>>>
>>> Entity that relies on the validity of the Digital Credentials presented to 
>>> it.
>>>
>>>
>>> I should rather say:
>>>
>>> Verifier:
>>>
>>>   Entity that relies on the validity of the digital proof presented 
>>> to it.
>>>
>>>
>>>
>>> OAuth Status List can be accessed by a Verifier when an internet connection 
>>> is present.
>>>
>>> This does not correspond to the flows of the figure.
>>>
>>>
>>> the section enumerates the differences between oauth status list and oauth 
>>> status attestations.
>>> The subject of the sentence is then the oauth status list, below I report 
>>> the original text i

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-selective-disclosure-jwt-06.txt

[Watson Ladd]

On Mon, Nov 6, 2023 at 5:46 AM Neil Madden  wrote:

>
> How about the following:
>
> —
> An Issuer MUST NOT allow any security-critical claim to be selectively 
> disclosable. The exact list of “security-critical” claims will depend on the 
> application, and SHOULD be listed by any application-specific profile of 
> SD-JWT. The following is a list of standard claim names that SHOULD be 
> considered as security-critical by any SD-JWT Issuer:
>
>  * “iss” (Issuer)
>  * “aud” (Audience), although issuers may want to allow individual entries in 
> the array to be selectively-disclosable
>  * “exp” (Expiration Time)
>  * “nbf” (Not Before)
>  * “iat” (Issued At)
>  * “jti” (JWT ID)
>
> In addition, the “cnf” (Confirmation Key) claim MUST NOT be selectively 
> disclosable.
> ---
> 

I think these fields can have significant unanticipated privacy
impacts. Expiry and issuance times can have very high entropy.

>
> Best wishes,
>
> Neil
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



-- 
Astra mortemque praestare gradatim

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Relationship between SPICE and OAuth

[Watson Ladd]

I think we need to move all the VC and SD-JWT stuff into SPICE. A lot
of security considerations can't be analyzed in isolation from the
whole system, and that's not something the OAUTH framework can really
consider or necessarily the assumption of participants.

Sincerely,
Watson


-- 
Astra mortemque praestare gradatim

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Reservations and observations about draft JWT and CWT Status List

[Watson Ladd]

On Mon, Oct 2, 2023, 11:56 PM Denis  wrote:
>
> Hi Justin,
>
> Your premise relies on a feature of JSON that does not exist. JSON does not 
> provide well-defined behavior for repeated names within an object:
>
> When the names within an object are not
> unique, the behavior of software that receives such an object is
> unpredictable.
>
> You should also cite the next two sentences which are:
>
>Many implementations report the last name/value pair only.  Other 
> implementations report an error or fail
>to parse the object, and some implementations report all of the 
> name/value pairs, including duplicates.
>
> A specification might require to use implementations that report all of the 
> name/value pairs, including duplicates.

That's not sticking to JSON semantics. Extending JSON to be a
multifunction or worse a sequence of key value pairs changes the
semantics. If you use JSON stick to RFC 8259 as it interoperates not
gratuitously cause problems.

Justin is right.

Sincerely,
Watson Ladd

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] SD-JWT does not meet standard security definitions

[Watson Ladd]

On Thu, Aug 24, 2023, 1:32 PM Kristina Yasuda
 wrote:
>
> First of all, BBS and SD-JWT are not comparable apple to apple. BBS is a 
> signature scheme and it needs to be combined with few other things like JWP 
> or BBS data integrity proof type (https://www.w3.org/TR/vc-di-bbs/) with 
> JSON-LD payload. While SD-JWT is a mechanism that can be used with any crypto 
> suite.

Agreed: the relevant comparison is at the level of systems based on
these formats. That makes it more difficult to have a discussion of
the security of the overall system when these documents go in other
places, and this might not be the right vehicle for it.

>
> Second, how to do batch issuance of the credential (honestly, of any 
> credential format: not just SD-JWT VCs but also mdocs and JWT-VCs) and 
> whether it can be done low cost is out of scope of the credential format (or 
> any of its components) specification itself. Btw when using OpenID4VCI (an 
> extension of oauth), batch issuing SD-JWTs does not need a blind signature 
> and I do not know what you mean by exhaustion of the supply of tokens, there 
> are only access token and refresh token involved in a usual manner.

So the issuer knows what it signed? Then it's capable of linking all
presentations to each other because the signature and message is shown
to each verifier even if different commitments are opened each time.
That's a serious problem. Separately, if each SD-JWT is one use only,
then the issuer needs to be available for refresh once the tokens are
all used, which is a troublesome proposition. It's a very different
model from a one time issuance. VC usecases are likely to lend
themselves to things that don't look like oauth in terms of
availability, and as we learned from OCSP running services that must
be up is hard.

I want to be clear: the threat model that's applicable to real people
across the web has the issuer working with data sent to the verifiers
to try to determine what the holder did. This is extremely unlike real
world credential presentation where e.g. showing my drivers license to
a bouncer doesn't mean the DMV knows what bar I went to. We have very
clear guidance in RFC 8890 from the IAB that we are supposed to take
these risks seriously, and privilege them over other considerations.
The applications to Digital Wallets when combined with a push for Age
Verification are exactly the sort of thing where people will make
expedient choices (use SD-JWT with what's being issued) in a way that
creates an enormous privacy risk that is not obvious to end users.

Sincerely,
Watson Ladd

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] SD-JWT does not meet standard security definitions

[Watson Ladd]

On Thu, Aug 24, 2023 at 3:44 AM Daniel Fett  wrote:
>
> Thanks, Hannes.
>
> The fact that technologies like AnonCreds are based on such old principles, 
> yet they are not uniformly standardized, often times limited to a few 
> implementations that may or may not be secure, are full of security footguns, 
> lack hardware support, and are just extremely hard or impossible to deploy 
> speaks for itself.
>
> That's why things like SD-JWT exist and gain traction.
>
> Yes, you have to jump through hoops to get unlinkability, but it is not 
> impossible, and it seems to be a good tradeoff for many.

Is there a document describing this that we can compare to the BBS
version? Because it's a lot harder than you think: you need a blind
signature and cut and choose for the credential openings (or
rerandomization via structure preserving signatures, hello pairings),
you need to deal with exhaustion of the supply of tokens, your
issuance process has to be repeatable at low cost, so that's also
getting messy, and then the hardware binding has its own special
problems. None of that is in this draft, and I think it would be a lot
better if we spelled it out here or someplace else to get a better
sense of the tradeoffs.

I would also like to point out that if end users don't like the
privacy aspects, they simply won't use this technology. That's a very
serious deployment issue.

Sincerely,
Watson Ladd

-- 
Astra mortemque praestare gradatim

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] SD-JWT does not meet standard security definitions

[Watson Ladd]

On Wed, Aug 23, 2023 at 5:25 PM Orie Steele  wrote:
>
> Hey Watson,
>
> There are 2 properties that credential  subjects are looking for in new 
> credential formats:
>
> 1. Selective Disclosure
> 2. Unlinkability

What's the definition of selective disclosure without unlinkability? I
do see that e.g. a bowl of carrots might be the sort of thing where we
don't care about the difference. But then we need to make clear that
sort of widespread usage some are going to push for where it's human
credentials is a bad idea. While SD might make sense without
unlinkability, you end up giving away everything you ever said, plus
some without it.
>
> Ideally we would get both of these for JWT and CWT, with new algorithms, and 
> both compact and flat encodings.
>
> Ideally, we would have more than 1 crypto system powering these, so for 
> example pairing friendly curves and lattices.
>
> BBS is still making it's way through cfrg, and lattice systems for this kind 
> of thing are not even at cfrg yet.
>
> I agree that sd-jwt takes a pragmatic approach that balances the needs of the 
> credential subject, with the capabilities of the issuer and verifier 
> ecosystem.

RFC 8890 is relevant here. We're not supposed to balance the needs of
credential subjects with the capabilities that will in large part be
defined by choices we've made. We're supposed to put the needs of the
credential subjects first, and after all they are the ones who can
decide to walk away. Particularly on the web there's a very
challenging privacy model that SD-JWT will not meet.

>
> This is similar to the challenge of "post quantum or quantum ready" systems 
> for signing and encryption.
>
> Will not making kyber-x25519 or dilithium-es384 make NIST or CFRG move faster?

The reason to have kyber-x25519 has very little to do with
certification. But that's irrelevant here.
>
> Will not making sd-jwt make BBS, CFRG and JWP move faster?
>
> There is always opportunity cost.
>
> Personally, I think it's fine to create sd-jwt while also working on things 
> that immediately improve on it.

We've learnt the hard way that it is extremely difficult to get rid of
stupid things. The original RC4 usenet announcement was followed up
with a break in a month. We didn't get rid of it until a few years
ago. Was it exploited? Yup. RIP wepcrack being more convenient than
trying to type in those ugly passwords.
>
> If you are more interested in seeing JWP or it's future COSE cousin solve 
> this problem, that's also something I am interested in.

It's not enough to have a secure way. It is enough to have the only
way be secure. To be clear, I think this can be made to work if we
sufficiently caveat the applications, but I don't think the current
doc gets there, and I'm afraid publication will be taken as permission
to do bad things.

>
> I hope that some of the interfaces and flows from sd-jwt can be reused for 
> JWP/CWP.
>
> One of the challenges for multi message proof systems is handling nesting / 
> hierarchy.
>
> In sd-jwt, this manifests as the recursive payload traversal algorithm.
>
> In the past we've used json pointer dictionaries and streaming json to solve 
> this, for other selective disclosure schemes ( using merkle proofs).
>
> I wonder if others have considered unlinkability, and selective disclosure in 
> the context of streaming serializations?

I'm not sure I understand the issue here: care to say more? (Maybe
offlist if its been rehashed ad nauseam)
>
> I like sd-jwt, and it was easy to implement, but it's not going to be the 
> last credential format.
>
> Regards,
>
> OS

-- 
Astra mortemque praestare gradatim

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] SD-JWT does not meet standard security definitions

[Watson Ladd]

On Wed, Aug 23, 2023, 1:35 PM David Waite  wrote:
>
>
> There are credentials where the user will always have an identifier, per 
> policy of the type of credential/credential issuer. Not all credentials are 
> anonymous credentials.

But if the credentials aren't anonymous why make SD-JWT?

To sharpen this: let's say we have a user sitting down and about to
verify their age to a website. It's easy to explain what the website
will learn, even in the face of collusion, when using BBS. It's also
easy to explain what they will learn if the credential isn't
anonymous. What happens with SD-JWT? It's much closer to the
non-anonymous case, with a persistent user identifier known to the
issuer and accessed by every website the credential is used at. Maybe
there are places where these limits are useful, but I don't see them
from the intro.

>
> There are certainly privacy-centric protocols (such as privacypass) which 
> support single-use unlinkability, which is what SD-JWTs are targetting.

I don't think you even get that without a blind signing protocol: the
issuer can see what root it signed otherwise and use it to connect to
redemption. Privacypass has blind signing and sigle-use anyway, but
there's still some issues with selective disclosure. I did put forward
a similar idea of selective metadata opening based on opening
commitments, but the details really matter. We also ended up with a
very significant architectural constraint on the number of issuers
because it wasn't possible to hide the issuer (or at least it wasn't
solved) and who issued was an anonymity leak.

>
> Since you used U-Prove as an example - it also only provides unlinkability on 
> single-use. Lysyanskaya (separately from [CL01]) describes a linkable 
> anonymous credentials scheme in [BL13].
>
> There are issuers who simply are not going to trust their reputation against 
> risk of forgery (or other attacks) from using less-proven cryptographic 
> algorithms. The issuers may also be operating under explicit guidance on what 
> cryptography they are allowed to use (e.g. from NIST). Issuing a ’stack’ of 
> credentials for single use unlinkability is worth reducing risks and meeting 
> imposed requirements..

What exactly does "less proven" mean here? if anything far more people
look at very neat schemes than boring ones, given the incentives of
publication. Furthermore the TPM implemented and deployed schemes like
EAA based on pairings decades ago. If issuers aren't going to
participate in a BBS ecosystem, but would in a SD-JWT one, and end up
not if we don't standardize SD-JWT, that's fine by me.

I don't understand what risks are being reduced, and if we're saying
that you should issue a stack we need to analyze that system as a
whole and its security properties, not just one bit in isolation.
Again you need blind signing to prevent linkability at the root, so
that's a rather tricky thing for stuff that isn't just RSA and
requires changes to implementations (and isn't necessarily in line
with NIST). Then you have an availability risk where it's not just one
interaction that's required for usage, and the reissuance process
(because you are not going to drag everyone back to the get their
stuff verified when they run out) creates an entirely different
operation risk as that's another way to get a credential.

The privacy impact of these stacks also assumes that the Issuer isn't
behaving maliciously, or learns things from the consumption rate.
That's not a great assumption.
>
>
> The need for more confidence on anonymous credential algorithms is also a 
> strong motivator around the BBS efforts.

I'm not sure what the relevance of this to the downsides of SD-JWT is.
If anything this suggests pushing the BSS ones through.

>
>
> As for availability it really
> doesn't take many implementations to have enough for almost all
> purposes, and those who aren't served can make their own.
>
>
> I would discourage nearly everyone from writing their own cryptography 
> implementations - it is a very distinct skill set and mistakes tend toward 
> the highest levels of severity.

Who exactly has an environment where any of the already existing
pairing implementations, or a forthcoming BBS signature scheme
wouldn't be available? The GSMA seems to indicate that this isn't a
problem even on sim cards.

> -DW

Sincerely,
Watson Ladd

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] SD-JWT does not meet standard security definitions

[Watson Ladd]

On Wed, Aug 23, 2023 at 10:02 AM David Waite
 wrote:

> > On Aug 23, 2023, at 10:16 AM, Watson Ladd  wrote:
> >
> > On Wed, Aug 23, 2023, 3:35 AM Daniel Fett  wrote:
> >>
> >> Hi Watson,
> >>
> >> can you please be specific about the "standard, 22 year old security 
> >> definitions" and "schemes of this type"?
> >>
> >> Not having to make assumptions would certainly help to have a useful 
> >> discussion.
> >
> > Unlinkability as defined in CL01
> > (https://link.springer.com/chapter/10.1007/3-540-44987-6_7) . The
> > security considerations section of the draft does explicitly admit
> > this shortcoming.
>
> Could you elaborate more on what you think is standard (and in what context) 
> and what do you consider “schemes of this type”
>
> For example, are you talking about properties for anonymous credentials from 
> the academic space as set by [Chaum85] or perhaps [CL01]? Or maybe are you 
> talking toward some existing requirements specified by a regulated space?
>
> Assuming you are speaking primarily to multi-use unlinkability, there are 
> efforts within the broader IETF ecosystem around that -  such as an effort to 
> describe BBS usage within the CFRG, and proposals/efforts to leverage that 
> within privacypass and jose. Those obviously will not have the benefit of 
> being able to be implemented on top of broadly available and accepted 
> cryptographic operations. I would refer to these as trade-offs rather than 
> shortcomings.

Why should users accept worse privacy just because it means we can use
"accepted" cryptographic operations? It's a tradeoff where the costs
that are most salient to decision makers (the need for
"acceptability", e.g. their own ability to make decisisons) are at
odds with the privacy cost to users, and where it ultimately rests on
an illusion that primitives matter most. As for availability it really
doesn't take many implementations to have enough for almost all
purposes, and those who aren't served can make their own.

We learnt long ago in TLS that providing one good option and many bad
ones was not a good idea, as people will use the bad ones.  I'd like
us not to make the same mistake here.

Sincerely,
Watson Ladd

>
> -DW




--
Astra mortemque praestare gradatim

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] SD-JWT does not meet standard security definitions

[Watson Ladd]

On Wed, Aug 23, 2023, 3:35 AM Daniel Fett  wrote:
>
> Hi Watson,
>
> can you please be specific about the "standard, 22 year old security 
> definitions" and "schemes of this type"?
>
> Not having to make assumptions would certainly help to have a useful 
> discussion.

Unlinkability as defined in CL01
(https://link.springer.com/chapter/10.1007/3-540-44987-6_7) . The
security considerations section of the draft does explicitly admit
this shortcoming.
>
> -Daniel
>

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] SD-JWT does not meet standard security definitions

[Watson Ladd]

Dear all,

I read with alarm that the EU Digital Wallet is mandating SD-JWT,
perhaps under the illusion that it meets the standard, 22 year old
security definition for schemes of this type. It of course doesn't, as
said quite clearly in the security considerations section 10.4 and
10.5. Why on earth are we pursing this "solution" when actual
solutions to the problems presented have existed for 19 years? There's
been substantial research on this area, as seen in Microsoft's U-Prove
system just to name one instance.

This is apparently an article of discussion on the EU Digital Wallet
project as well, but I think the IETF needs to have its own discussion
of the issues here and not just say "well, it would be nice if we had
an RFC for this" especially given the negative privacy impacts.

Sincerely,
Watson Ladd

PS: they appear quite aware, but apparently convening the right
committee to approve the signature scheme is too hard. Anyway, not
relevant to us in the IETF.
-- 
Astra mortemque praestare gradatim

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Secdir last call review of draft-ietf-oauth-jwsreq-30

[Watson Ladd]

On Wed, Mar 17, 2021 at 2:47 PM Mike Jones  wrote:
>
> I’ve created the pull request 
> https://bitbucket.org/Nat/oauth-jwsreq/pull-requests/14/ applying the 
> proposed changes below to the draft.  Unless suggestions for changes are 
> received, we’ll merge this and publish -31 to address Watson’s comments.

I think these changes as addres my concerns. I wish that we could
further restrict to a known-good, easily implementable profile, but we
can't get everything we want.

Sincerely,
Watson Ladd

>
>
>
>-- Mike
>
>
>
> From: Mike Jones
> Sent: Friday, February 26, 2021 12:55 PM
> To: 'Watson Ladd' ; Nat Sakimura ; 
> Roman Danyliw 
> Cc: secdir ; IETF oauth WG ; 
> last-c...@ietf.org; draft-ietf-oauth-jwsreq@ietf.org
> Subject: Re: Secdir last call review of draft-ietf-oauth-jwsreq-30
>
>
>
> Thanks again for your review, Watson.  My replies to your comments below are 
> prefixed by "Mike>".
>
>
>
> -Original Message-
> From: Watson Ladd 
> Sent: Tuesday, December 15, 2020 9:01 PM
> To: Nat Sakimura 
> Cc: secdir ; IETF oauth WG ; 
> last-c...@ietf.org; draft-ietf-oauth-jwsreq@ietf.org
> Subject: [EXTERNAL] Re: Secdir last call review of draft-ietf-oauth-jwsreq-30
>
>
>
> On Sat, Oct 31, 2020 at 6:13 AM Nat Sakimura  wrote:
>
> >
>
> > Hi Watson,
>
> >
>
> > Thanks very much for the review. I thought I have sent my response
>
> > earlier, which I actually did not. It was sitting in my draft box. I
>
> > apologize for it.
>
>
>
> My apologies for missing it in my inbox for a number of months.
>
> >
>
> > My responses inline:
>
> >
>
> > On Sat, Sep 26, 2020 at 9:46 AM Watson Ladd via Datatracker
>
> >  wrote:
>
> > >
>
> > > Reviewer: Watson Ladd
>
> > > Review result: Serious Issues
>
> > >
>
> > > I generated this review of this document as part of the security
>
> > > directorate's ongoing effort to review all IETF documents being
>
> > > processed by the IESG.  These comments were written with the intent
>
> > > of improving security requirements and considerations in IETF
>
> > > drafts.  Comments not addressed in last call may be included in AD
>
> > > reviews during the IESG review.  Document editors and WG chairs should 
> > > treat these comments just like any other last call comments.
>
> > >
>
> > > Two minor issues: On page 4, "This offers an additional degree of
>
> > > privacy protection." should be reworded. I don't think it makes
>
> > > sense in context, where authenticity was discussed.
>
> >
>
> >
>
> > In the course of the edit, explanation about two distinct privacy
>
> > benefits was collated in one sentence and has become very difficult to
>
> > parse.
>
> >
>
> > What it is trying to express as privacy benefits are the following.
>
> >
>
> > 1) The authorization request content is sent to the AS in the
>
> > backchannel so it will not be exposed through the browser to the eyes
>
> > of an active or passive outsider observing what is going on in the
>
> > browser.  In the RFC6749 framework case, the authorization request
>
> > goes through the browser redirect and it could leak to the adversary
>
> > via WPAD/PAC Attack, referrer, browser history, etc. Also, if the
>
> > browser was infected by an adversary controlled malware, the content
>
> > can be sniffed by the adversary. In the case of JAR, it does not
>
> > happen. This is one privacy benefit it is trying to explain.
>
> >
>
> > 2) The location that the authorization request is getting pushed to
>
> > does not have to be the AS. A trusted third party that examines the
>
> > content for the conformance to the collection minimization principle
>
> > may act as the party that accepts the authorization request and issues
>
> > the request_uri. AS can then just evaluate the domain part of
>
> > request_uri to evaluate that the authorization request is conformant
>
> > to this principle. This is another privacy benefit from the point of
>
> > view of the individual user.
>
>
>
> I'm fine with any fix to the sentence that makes sense. Don't think we need 
> to insert the above but I very much appreciate the explanation.
>
>
>
> Mike> Given that its meaning is fairly inscrutable, and that the two benefits 
> described by Nat above are partially relat

Re: [OAUTH-WG] Secdir last call review of draft-ietf-oauth-jwsreq-30

[Watson Ladd]

I.
>
> > It is this simple. As such, it would also inherit some of the
>
> > shortcomings in RFC6749. However, it is not this document to address
>
> > them. It should be done by other documents so that the result can be
>
> > encoded using the mechanisms provided in this document.
>
>
>
> This is not a simple matter. JWT has a long and twisted history with some 
> pervasive errors in common libraries, and is a fairly large standard. OAuth 
> 2.0 is also large. Ensuring that the mapping has the right properties is 
> going to be a mess. If the encoding does not respect the semantics we have a 
> serious security issue. If implementors assume the encoding provides 
> properties it does not, we again have a security issue.
>
>
>
> Mike> See my previous comments on past JWT implementation errors and the 
> writing of the JWT BCP [RFC 8725] to address these.

JWT provides certain properties. OAUTH 2.0 assumes certain properties.
Are the properties required by OAUTH 2.0 those provided by this
draft's use of JWT? That's independent of generic problems of JWT but
very specific. By way of analogy if you use HMAC as a signature scheme
you're going to have a bad time, even though HMAC is secure, because
its properties are not those of a signature scheme. That's true no
matter how much you insist your HMAC implementation is correct.

>
>
>
> > It is quite surprising that this fact is not getting appreciated and
>
> > is taking such a long time to complete.
>
> > Maybe I should delete all the explanation text and leave it with just
>
> > the core text. Explanation and justification text for defining
>
> > additional bindings probably are just distractions now as it is now
>
> > appreciated and used all over the world unlike when the project was
>
> > started.
>
>
>
> Mike> I would propose that we make only necessary changes to the draft at 
> this point.  Let's finish this long-overdue specification!
>
>
>
> >
>
> > >
>
> > > Sincerely,
>
> > > Watson Ladd
>
> > >
>
> >
>
> > Thanks again for your detailed comments.
>
> >
>
> > Best wishes,
>
> >
>
> > --
>
> > Nat Sakimura
>
> > NAT.Consulting LLC
>
>
>
> Mike> I now plan to create edits incorporating the proposed resolutions above 
> for review.
>
>
>
>Best wishes,
>
>-- Mike
>
>
>
> --
>
> Astra mortemque praestare gradatim



--
Astra mortemque praestare gradatim

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Secdir last call review of draft-ietf-oauth-jwsreq-30

[Watson Ladd]

On Sat, Oct 31, 2020 at 6:13 AM Nat Sakimura  wrote:
>
> Hi Watson,
>
> Thanks very much for the review. I thought I have sent my response
> earlier, which I actually did not. It was sitting in my draft box. I
> apologize for it.

My apologies for missing it in my inbox for a number of months.
>
> My responses inline:
>
> On Sat, Sep 26, 2020 at 9:46 AM Watson Ladd via Datatracker
>  wrote:
> >
> > Reviewer: Watson Ladd
> > Review result: Serious Issues
> >
> > I generated this review of this document as part of the security 
> > directorate's
> > ongoing effort to review all IETF documents being processed by the IESG.  
> > These
> > comments were written with the intent of improving security requirements and
> > considerations in IETF drafts.  Comments not addressed in last call may be
> > included in AD reviews during the IESG review.  Document editors and WG 
> > chairs
> > should treat these comments just like any other last call comments.
> >
> > Two minor issues: On page 4, "This offers an additional degree of privacy
> > protection." should be reworded. I don't think it makes sense in context, 
> > where
> > authenticity was discussed.
>
>
> In the course of the edit, explanation about two distinct privacy
> benefits was collated in one sentence and has become very difficult to
> parse.
>
> What it is trying to express as privacy benefits are the following.
>
> 1) The authorization request content is sent to the AS in the
> backchannel so it will not be exposed through the browser to the eyes
> of an active or passive outsider observing what is going on in the
> browser.  In the RFC6749 framework case, the authorization request
> goes through the browser redirect and it could leak to the adversary
> via WPAD/PAC Attack, referrer, browser history, etc. Also, if the
> browser was infected by an adversary controlled malware, the content
> can be sniffed by the adversary. In the case of JAR, it does not
> happen. This is one privacy benefit it is trying to explain.
>
> 2) The location that the authorization request is getting pushed to
> does not have to be the AS. A trusted third party that examines the
> content for the conformance to the collection minimization principle
> may act as the party that accepts the authorization request and issues
> the request_uri. AS can then just evaluate the domain part of
> request_uri to evaluate that the authorization request is conformant
> to this principle. This is another privacy benefit from the point of
> view of the individual user.

I'm fine with any fix to the sentence that makes sense. Don't think we
need to insert the above but I very much appreciate the explanation.

>
>
> > It took me a while to understand what the by reference method is: maybe the
> > intro should say via URL instead of by reference.
>
>
> request_uri can be URL or a handle such as URN. That is why the "by
> reference" word is being used, per the suggestion of the WG.

I'm fine with that, just noting my confusion.

>
> >
> >
> > And now for the thorny issues with this draft. Signatures and encryption are
> > different. And encrypting a signed blob doesn't mean the signer encrypted 
> > it.
> > Then there are a plethora of methods specified in the draft  to authenticate
> > the blob, which will give different results in maliciously constructed
> > examples. The security considerations section should discuss what the 
> > encrypted
> > vs signed choices give in the way of security, and it doesn't. This makes me
> > worry.
>
> We don’t expect the encryption to ensure authenticity, that’s what the
> signatures are used for.

This needs to be very clearly spelled out in the text. Lots of people
will not understand this. The wording of section 10.2 is at best
ambivalent, with multiple alternatives presented as acceptable.

>

>
> I didn't quite get what is meant by "plethora of methods specified in
> the draft to authenticate the blob ... "
> There is a bit of text about authenticating the source (=client) but
> not much on the blob itself.
> The discussion around the signature and/or encryption is covered in
> RFC7519 (JWT), the format that the request object assumes.
> This is required reading when implementing this spec, so WG thought it
> is not worth repeating here.
> Attacks etc. on the signature and encryption are covered in RFC7515
> and RFC7516 respectively.

Well, the draft happens to include the following text:
   "The Authorization Server MUST validate the signature of the JSON Web
   Signature [RFC7515] signed Request Object.  The signature MUST

[OAUTH-WG] Secdir last call review of draft-ietf-oauth-jwsreq-30

[Watson Ladd via Datatracker]

Reviewer: Watson Ladd
Review result: Serious Issues

I generated this review of this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving security requirements and
considerations in IETF drafts.  Comments not addressed in last call may be
included in AD reviews during the IESG review.  Document editors and WG chairs
should treat these comments just like any other last call comments.

Two minor issues: On page 4, "This offers an additional degree of privacy
protection." should be reworded. I don't think it makes sense in context, where
authenticity was discussed.

It took me a while to understand what the by reference method is: maybe the
intro should say via URL instead of by reference.

And now for the thorny isssues with this draft. Signatures and encryption are
different. And encrypting a signed blob doesn't mean the signer encrypted it.
Then there are a plethora of methods specified in the draft  to authenticate
the blob, which will give different results in maliciously constructed
examples. The security considerations section should discuss what the encrypted
vs signed choices give in the way of security, and it doesn't. This makes me
worry.

Looking at the cited reference for attacks, I see the fix is to include
information about which IPD was used by the RP. But the draft before us doesn't
mandate that. It's not clear than how the cited attack is prevented by the
draft. Saying that the communication through the user-agent is subject to
manipulation, and this prevents it, ignores that the attacker in that position
sees a lot more. The user-agent as resource owner modifying the requested
resources is a very funny sort of attack: can't they do what they want with the
resources since they control the access?

Key management is ignored. This is a very important issue, especially
considering the potential problems with the reuse of JWT. I'd like to see a
recommendation that keys be separated by intended uses, rather than limiting
particular fields in an ad-hoc manner.

Then we have section 11. What section 11 introduces is an entire new dramatis
personae, the Trust Framework Provider, with no prior discussion of what it is
or a reference to where it is defined and a good number of statements about how
it works that aren't really  clear what they mean from the document to me.

My biggest concern is that these issues are signs that the problem this draft
is trying to solve and the mechanisms to solve it haven't been analyzed as
thoroughly as they should have been. Without that sort of thorough analysis
it's not certain that the mechanisms actually solve the problem and it's not
clear what the recommendations to implementors have to be to preserve those
properties.

Obviously this draft has had a long and tortured history with multiple reviews,
 and what I'm suggesting needs to happen is a lot of work. But it's essential
in any security protocol to do this analysis and be clear about what is, and
what is not, protected by the protocol.

Sincerely,
Watson Ladd


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth