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

[Stephen Farrell <[e-mail]>]

On 19/05/16 08:43, Tim Bruijnzeels wrote:
> Hi all,
> 
> Actually, yes, I agree with George on in-line.
> 
> In-line would have my preference. Include the entire EE certificate
> in the signature field. This way it does not need to be fetched
> separately, and it does not need to appear in a repository or a
> manifest. Mandate that the EE certificate is signed by CA certificate
> in the RPKI (i.e. no longer chain possible). The EE certificate
> should have an AIA and AKI that can then be easily referenced against
> known CA certificates that a validator found.

Were I designing that I'd have a separate new attribute that
could contain one or more certs and I'd say that if the c=
field/URI in the signature attribute is empty (or has some
specified value such as "inband") then that means "look
at the cert-bucket attribute in this file."

The cert-bucket would then be expected to contain a base64
encoded cert chain. Consumers of that attribute would have
to ensure that nothing in it affects the local trust point
store but can otherwise throw the lot into their cert path
processing engine.

Assuming that the signatures on these files aren't very
long-lived you can probably input the cert-bucket attribute
into the signature. If signatures commonly need to be ok
to verify even after certificate expiry (e.g. if a new
cert was issued for the same key pair in an update operation)
then you'd not want the cert-bucket in the signature maybe.

There're various non-compelling but goodish reasons to do it
that way. Maybe the best ones are around making it easy to
use existing tooling (openssl etc) for the verifier.

I'm not sure what benefit ensues from insisting that the EE
cert very strictly adhere to all ithe RPKI rules, but I
reckon you do want to be able to use the same PKI for sure.
So were it me, I'd try craft text saying "you're very likely
to want to use an RPKI CA for issuing the cert used to
verify the signature attribute so your code MUST support
doing that, but there can be other equally standard PKI
options too that are useful to support."

> 
> So in short: a validator can do its normal top-down validation for a
> TA. And to perform bottom-up validation of a signed RPSL object the
> process of validating the EE cert would be fairly simple -> find a CA
> cert with SKI matching the AKI of the EE, verify the signature of the
> EE (proof of possession), verify the CRL. Omitting the other checks
> here - would be good to specify this explicitly in the document, but
> for the discussion here seems excessive.

Yep.

Cheers,
S.

> 
> I think there was some discussion around this earlier and back then
> the thought was that we wouldn't want to make the RPSL objects
> bigger. However, I don't know if that should be a concern. The way I
> see it looking at our own whois implementation I imagine that this
> field could actually only be shown to RPs when they supply an
> additional flag, if size is a concern. And in our web UI (ad-hoc
> queries by humans) we would not show the signature field as is, but
> process it and highlight signed fields somehow.
> 
> Tim
> 
> 
>> On 19 May 2016, at 00:39, George Michaelson <[e-mail]>
>> wrote:
>> 
>> I would rather the sigs were signed by ee certs which were in the 
>> blob, than have to make an external reference and I would rather
>> we varied the compliance needs to remove a pointless external ref.
>> 
>> If there has to be a ref, I think making it mandated to a specific 
>> scheme is over specifying, especially in a context where we might 
>> begin to understand *where you get cryptographic materials from is 
>> less important than proving who said them*.
>> 
>> Rsync is a bad fit. for the actual signing cert, Inline is better.
>> It can refer to whatever chain it likes.
>> 
>> -G
>> 
>> On Thu, May 19, 2016 at 1:02 AM, Brian Haberman 
>> <[e-mail]> wrote:
>>> Hi Tim,
>>> 
>>> On 5/18/16 10:32 AM, Tim Bruijnzeels wrote:
>>>> Hi,
>>>> 
>>>>> On 18 May 2016, at 15:08, Brian Haberman
>>>>> <[e-mail]> wrote:
>>>>> 
>>>>> Hi Terry,
>>>>> 
>>>>> On 5/17/16 11:37 PM, Terry Manderson wrote:
>>>>>> Terry Manderson 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:
>>>>>> ----------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>>
>>>
>>>>>> 
Thank you for putting substantial effort into this document.
>>>>>> 
>>>>>> I have a few discusses. I hope they can be resolved
>>>>>> quickly.
>>>>>> 
>>>>>> In Section 2.1. The reference to the aligned certificate
>>>>>> which has the same private key that signed the RPSL object
>>>>>> is mandatory, and defined by a RSYNC URL or a HTTP(S) URL.
>>>>>> My question surrounds the "or". The architecture of RPKI
>>>>>> (IIRC) is centered around RSYNC, and thus SIA/AIA values
>>>>>> MUST have a RSYNC URL, and MAY have other types. By this
>>>>>> are you leaving it to the issuing party to control the RPKI
>>>>>> Distribution mechanisms of the Replying Party? I am quite
>>>>>> comfortable with "or" personally, however this facet of
>>>>>> fetching the RPSL Certificate to validate the private key
>>>>>> usage is seemingly orthogonal to the RPKI architecture of
>>>>>> RSYNC preferred and should be called out if 'or' is the
>>>>>> clear intention. Or, has the consensus of the WG moved on 
>>>>>> from being wedded to RSYNC?
>>>>> 
>>>>> I am not aware of the WG moving away from their rsync
>>>>> leanings...
>>>> 
>>>> My take on this: for the moment I would stick to rsync as it's 
>>>> required and EE certificates appearing in the rsync repository,
>>>> and leave out http(s).
>>>> 
>>> 
>>> If the consensus is to remove mention of an http(s) URI, I can
>>> live with that. The current state of affairs within the SIDR
>>> documentation is such that only an rsync URI will be feasible in
>>> the near future. I don't believe that the mention of an http(s)
>>> URI in this context affects that one way or the other.
>>> 
>>> Regards, Brian
>>> 
>>> 
>>> 
>>> _______________________________________________ sidr mailing
>>> list [e-mail] https://www.ietf.org/mailman/listinfo/sidr
>>> 
>> 
>> _______________________________________________ sidr mailing list 
>> [e-mail] https://www.ietf.org/mailman/listinfo/sidr
>