Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-rpsl-sig-11: (with DISCUSS and COMMENT)

[Stephen Farrell <[e-mail]>]

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
> 
>