comments inline. speaking as a regular ol’ wg member On May 18, 2016, at 12:20 PM, Brian Haberman <[email protected]> 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… There was at one point in the history of resource certificates the idea that EE certs could be used multiple times. (EE certs even had their own manifests!) The signed object definition encapsulated the EE cert used to verify the signature. That revocation of the signed object could be accomplished by revoking the EE cert. Which meant that the EE cert should be used just to sign that one object, as Stephen says. (otherwise chaos ensues) As the only defined use of EE certs at the time of the publication of 6487 was the use to verify signed objects, the text about EE certs was reduced to just that necessary to support the single-use. This is different. The validity of the rpsl object is not tied to the validity of the EE cert. The comments from the wg were that this draft should talk about the syntax of the new attribute, not the authorization/semantics. So revocation of the EE cert in this case would/might not have the effect of revoking the rpsl object. I personally don’t think it likely that it ever will, but that’s IMHO only. So it is a moot question as to whether the single-use is a part of “the RPKI approach” for this rpsl-sig use. > >> >> If there's no benefit, it seems like that adds a bunch of >> CA code just for fun (or "compliance" maybe;-) curious: how would this single-use requirement add anything to the CA code? If the requirement is in 6487, the CA code would already have the checks. I ask only because I might be missing something. > > 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. I think you mean 6487? You have already suggested removing the SIA requirement from 6487 for the EE certs rpsl-sig uses, so these EE certs are already a different sort of EE cert. Other special requirements as necessary. —Sandy, speaking as a regular ol’ wg member
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
