goto bottom:-) On 18/05/16 17:20, Brian Haberman wrote: > Hiya Stephen, > > On 5/18/16 12:09 PM, Stephen Farrell wrote: >> >> Hiya, >> >> On 18/05/16 17:06, Brian Haberman wrote: >>> Hiya Stephen, >>> >>> On 5/18/16 11:51 AM, Stephen Farrell wrote: >>>> Stephen Farrell has entered the following ballot position for >>>> draft-ietf-sidr-rpsl-sig-11: 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/iesg/statement/discuss-criteria.html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>> >>>> >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/draft-ietf-sidr-rpsl-sig/ >>>> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> DISCUSS: >>>> ---------------------------------------------------------------------- >>>> >>>> >>>> I'd like to check one thing - this may be needed for strict >>>> compliance with RPKI thing but it seems kinda weird to also >>>> impose that here, but anyway... >>>> >>>> Is 3.2 step 1 needed? That seems like useless complexity >>>> here. If it is needed, how does the verifier check that >>>> it's really a single-use? I don't see the point TBH. >>>> >>> >>> This text was driven by the statement in RFC 6487 (Section 3) that says: >>> >>> The private key associated with an EE certificate is used to sign a >>> single RPKI signed object, i.e., the EE certificate is used to >>> validate only one object. >>> >>> Step 1 in 3.2 is there so that this approach follows the above directive >>> on the use of the RPKI infrastructure/certificates. >> >> Well... sure. But what is the benefit here? IIRC that was > > I *think* the benefit is supposed to be compliance with the RPKI approach... > >> something related to making more fine-grained revocation >> possible or something which doesn't seem that useful here >> since a verifier will likely already have processed stuff >> already or am I mixed up? > > I don't think you are mixed up, but I will let others in SIDR chime in...
Yeah, be good if someone could justify doing that. Maybe there's a good reason, though I'm not seeing it. > >> >> If there's no benefit, it seems like that adds a bunch of >> CA code just for fun (or "compliance" maybe;-) > > I could very easily see dropping step 1 from 3.2 and simply augmenting > the intro sentence with something about certs/keys generated per 3487. My guess is that that'd lead signing implementers to not generate new and possibly useless certs. I guess I'd be ok with that but it seems a bit unfair of us to be sorta kinda not telling 'em that they ought have the code for that. (The verifier doesn't know/care in this case afaics, though of course that means that the once-only aspect is also a bit "pretendy" too I suppose.) Anyway, yeah, maybe having someone more up to speed on sidr than I say why this makes sense here is the best next step so that we don't muck up or take the pretendy route? Cheers, S. > > Regards, > Brian > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
