Re: [Last-Call] Secdir last call review of draft-ietf-stir-passport-rcd-21

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Vincent,

Thanks for the review, responses inline:

> On Oct 12, 2022, at 9:13 AM, Vincent Roca via Datatracker <noreply@xxxxxxxx> wrote:
> 
> Reviewer: Vincent Roca
> Review result: Not Ready
> 
> Hello,
> 
> I have reviewed 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 primarily for the benefit of the security area
> directors. Document editors and WG chairs should treat these comments just
> like any other last call comments.
> 
> Summary: not ready
> 
> Globally, the security considerations section addresses all topics that come to
> my mind, given my understanding. The only comment I have is WRT the last
> paragraph of section 18.1. The wording: "Excluding this claim", seems ambiguous
> to me since I don't understand if it refers to the "rcdi claim" or "an entry in
> mustExclude". Also, I don't understand the core problem (why does a mustExclude
> tag compromize integrity protection). I think the issue deserves more details.
> Finally, isn't "MUST NOT" more appropriate than "SHOULD NOT" since the
> consequences of not following this rule are major.

So i do agree this last paragraph is confusing where its essentially meant to be a stating the obvious type of comment.  I believe it was actually written when RFC9118 was created specifically to address Section 18 related security concerns.  My proposal is to just remove that paragraph.  There is nothing preventing someone from using mustExclude for ‘rcdi’ which is why i didn’t say MUST NOT. This scenario simply would not make much sense since injecting an ‘rcdi’ is an extremely ineffective form of attack by the nature of the claim. I think it just refers to what would be essentially the logical conclusion of any implementer of the spec. I think the former paragraph in 18.1 covers what is required for general guidance around the use of JWTClaimConstraints to maintain integrity and constraint of the content of the claims via the certificate.

> 
> A few, minor, additional comments:
> - Section 18, 1st sentence: s/its identities/it is identities/

Fixed with ’the identities'

> - Section 18, 2nd paragraph: I don't understand "over in a using protocol",
> please fix typo. -

Fixed with 'Baseline PASSporT has no particular confidentiality requirement, as the information it signs in many current base communications protocols, for example SIP, is information that carried in the clear anyway.'

> Section 18, 3rd paragraph: s/availbility/availability/

Fixed

> 
> Cheers,
> 
> Vincent
> 
> 
> 

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux