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

[Stephen Farrell <[e-mail]>]

Hi Sandy,

On 18/05/16 22:12, Sandra Murphy wrote:
> comments inline.  speaking as a regular ol’ wg member
> 
> On May 18, 2016, at 12:20 PM, Brian Haberman
> <[e-mail]> 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.

But that means that there is no reason to include the requirement
here then or am I missing something? Deleting that "step" in the
signing process would seem like a good idea so. (Assuming that
current implementers, if any, are fine with that.)

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

What I was trying to say was that requiring signers of this to
include all the CA code is the problem/oddity, esp if there's no
real benefit.

So the single-use thing doesn't add to the CA code, it adds a
need for the CA code in the wrong place.

And I guess if the spec says "once only" then I can well imagine
some poor verifier implementer keeping some kind of cache and
checking it'd not seen a signature before or something like that.
And that'd also be kinda pointless code too I think.

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

Great - so no need to do the single-use thing here then? But I
may not be grokking all the consequences of the above so please
do correct me if I'm wrong.

Cheers,
S.


> 
> —Sandy, speaking as a regular ol’ wg member
> 
>