[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposed Up/Down protocol description
> 2. URL structure
> ----------------
>
> > Doc says nothing about URL structure. Should it?
>
> We don't believe so. The URL is the place you perform the POST
> operation to. Addinging query arguments to the URL will not affect the
> operation of this protocol (i.e. they are non-meaningful). The content
> POSTed to this URL is "well formed" binary CMS (with content type of
> "application/x-rpki")
I was thinking about REST-like URLs, not query arguments. In
particular, I had been considering for a while now that I might try to
make things easier for the parent by using a URL that names the child
so that the parent can trivially figure out which business trust
anchor to use. I suppose I can extract that information from the XML
instead since it's not encrypted, just seemed like it might be easier
to structure the URL.
But it's not a critical point, since the child uses whatever URL the
parent tells it to use via business-context negotiation.
exactly - you could still use a dedicated URL per child if you want
> 4. Checking Requirements
> ------------------------
>
> > I seem to recall some discussion in the 2nd floor lobby in Tallinn
> > about what the checking requirements here really are. This morphed
> > into a discussion of replay protection; I'm reasonably happy with
> > where the replay protection discussion went, but suspect we may have
> > neglected to pop the stack and finish the original discussion.
>
> We've talked this though and think that the following sequence of
> checks would work as a description of checking requirements:
>
> 1. Check that the CMS is well-formed
> 2. Check that the XML is well-formed
> 3. Verify the digital signature using the public key provided
> in the certificate carried in the CMS
> 4. Check that the XML sender and rcipient attributes reference
> a known client and this system respectively.
> 5. Validate the CMS-provided certificate using the Business PKI
> that is associated with the sender
> 6. Use the XML msg_ref and CMS Signing_Time attribute values to
> detect that this message is correctly in sequence
>
> Errors in steps 1 through 5 would
generate an HTTP 400 Bad Data response
> An error in Step 6 would generate a well-formed protocol error response
> as described in the msg-ref processing algorithm
>
> The checks should generally be applied in the order specified, with the
> possible exception of steps 3 and 4.
I would almost certainly reverse the order of 3 and 4 unless using a
REST URL scheme, since I hae to look at the XML sender to figure out
which trust anchor I should check the CMS against. 3 and 5 are really
a single operation as far as I'm concerned, the question is "do the
signature and certificates in the CMS wrapper validate back to the
correct business trust anchor?"
But I think we're in at least rough agreement here.
ok - I can change the order of 3 and 4
> 5. Namespace URN
> ----------------
>
> >> 3.1 Common Message format
> >>
> >> <message xmlns="urn:uuid:f345d68f-225c-48b7-8abd-8c2373c68f4d"
> >> sender="sender name"
> >> recipient = "recipient name"
> >> msg_ref="reference"
> >> type="message type">
> >
> > Please find a better URN. Personally, I would be fine with
> > http://urn.nro.org/wombat.rpki.1; don't care all that much but this
> > UUID thing a bit too whacky for me.
>
> We're a little wary of using an nro.net namespace this week - it seems
> to have gone out of fashion all of a sudden! We would like to propose
> a URL drawn out of APNIC space that if ever pasted into a browser
> leads to some generally useful documentation links. We'd like to
> propose the URN: "http://www.apnic.net/specs/rescerts/up-down/";
No offense but I ain't touching inter-RIR political issues.
wise
:-)
I personally am fine with the proposed URN so long as APNIC promises
that it is stable (which I assume presumtively that you do). If
political issues make this problematic, I'll be happy to offer a
hactrn.net URN, or can probably get authorization to offer an isc.org
URN in very short order.
we promise that the url will be stable.
I would have thought that the URN should include a version number (and
yes, I know that you disccuss this later, am not sure I'm convinced on
this point yet).
Byron has responded to this.
> 6. msg_ref value sequence
> -------------------------
>
> >> msg_ref :
> >> value is set by the sender when generating a query. The
> >> corresponding response message contains the same msg_ref value. A
> >> sender must ensure that different
msg_refs are used for each query,
> >> and the receiver must ensure that duplicate requests are detected
> >> and rejected.
> >
> > A few paragraphs further down it becomes clear that this has to be a
> > positive decimal number, and that it has to be monotonically
> > increasing within the reset_interval of the replay protection
> > mechanism. Should say at least some of that here.
>
> Agreed - "The msg_ref value is a positive integer value in a strictly
> monotonically increasing sequence" would be the wording I would add
> here.
Close. It only needs to be monotonically increasing within the
reset_interval: there's no harm in having it be monotonically
increasing for longer intervals but the protocol doesn't care.
sure!
> 7. namespace and versioning
> ---------------------------
>
> We've discussed this at some length, and come up with the following:
>
> - propose to remove the version information from the content type
> (leaving the content type of "aplication/x-rpki")
>
> - propose to keep any version number out of the namespace identifier
>
> - propose to restore the "version" attribute of the message element
> and define its value as "1" for this specification.
It would be easier to evaluate these recommendations if you shared the
reasoning by which you reached them. :)
> - note that there may be a requirement for explicit version
> negotiation in future versions of this protocol, but defer the
> specification of any such negotiation until the next version
"Once you start down the dark path, forever will it dominate your
destiny, consume you it will...."
> - allow implementations to accept any message, irrespective of the
> version value as long as the recipient understands the namespace
> and the recipient understands all elements and attributes that are
> used in the message.
That's probably ok. Other opinions?
One good (and ancient) example of relatively sane protocol versioning
specification is RFC 1058, the RIPv1 spec, section 3.4 of which says:
Before processing the datagrams in detail, certain general format
checks must be made. These depend upon the version number field in
the datagram, as follows:
0 Datagrams whose version number is zero are to be ignored.
These are from a previous version of the protocol [...].
1 Datagrams whose version number is one are to be processed
as described in the rest of this specification. All fields
that are described above as "must be zero" are to be checked.
If any such field contains a non-zero value, the entire
message is to be ignored.
>1 Datagrams whose version number are greater than one are
to be processed as described in the rest of this
specification. All fields that are described above as
"must be zero" are to be ignored. Future versions of the
protocol may put data into these fields. Version 1
implementations are to ignore this extra data and process
only the fields specified in this document.
In other words: If it's a higher version number than you understand,
you process the fields you recognize and ignore everything else.
Unstated corollary: old fields may not be reused for new purposes. In
the pathological case of needing to do a completely incompatable
change to the protocol without just starting over as a new protocol,
abandon all of the old fields except for the version number.
Your proposed rule here is stricter than that, so I don't think your
proposed rule will cause a problem.
ok - I _think_ we are in agreement then!
> 9. msg-ref time interval values and algorithm review
> ----------------------------------------------------
>
> > This algorithm description needs more eyeballs.
>
> Agreed! Is this something that could be undertaken at the meetings to
> be held at the NANOG venue?
Yes, replay protection algorithm is definitely in scope for the attack
profile discussion.
thanks!
> 13. Consistent syntax for resource_set_ attributes
> --------------------------------------------------
>
> > Why are the last three optional? When should they be present, when
> > should they not be present? Needs more explanation.
>
> And noted - additional text will be added
Then I'll reserve judgement until I see the additional text. :)
ok
> 15. Certificate Revocation
> --------------------------
>
> > But I have another issue with this section and the corresponding
> > response section: this isn't really about -certificate- revocation,
> > it's about -key- revocation. Well, revocation isn't quite the right
> > word either, but I can't think of a better one offhand.
>
> It is about certificate revocation, in that in attempting to get rid
> of all material that uses a particular key, a set of certificates that
> refer to the public part of that key need to be revoked. The term
> "certificate revocation" is not used in the protocol, its just a
> section heading in this text. Perhaps if more text is added to note
> that individual certificates cannot be revoked upon request, but
> instead a set of certificates that share a common subject's public key
> can be revoked in a single reuqest?
I think explanation would help. Use of "certificate revocation" in
the section headings (and a few other places, I think) keeps making
people think that this is about revoking an indicated set of
certificates, which it is not and never has been. Certificate
revocation per se happens as a side effect of other protocol actions.
What this particular protocol exchange is really about is retiring a
keypair, that is, we expect that its common (sole?) use will be as
part of key rollover operations.
> 16. Error Responses
> ------------------
>
> We've had some lengthy discussions on element vs attribute, and what we
> are proposing here is based on deferring to our in-house XML expertise.
> It appears that there is a strong element of style involved here, and
> evidently explicit elements are favoured.
By someone. :)
But I don't feel strongly in this case, as this is an isolated corner
of the spec where the choice does not affect anything else.
> > No description of description, but in this case I would really prefer
> > just to get rid of description entirely. "Mail not delivered: not a
> > typewriter".
> >
> >> If the HTTP request that triggered this error response includes an
> >> Accept-Language header as defined in section 14.4 of the HTTP/1.1
> >> specification [RFC2616] then the server will make a best effort to
> >> include a second description element
using the highest ranked preferred
> >> language of the client. The en-US
description will always be included.
> >
> > Thank you for providing such a nice example of -why- I do not want the
> > description. Think protocol elements, not human readable text.
>
> Again this has been a topic of discussion here, and there are proponents
> that make the case that XML is indeed human readable text and that this is
> a positive attribute.
>
> I suppose that we could make this element optional for implementations
> if you prefer. Would this be an acceptable way forward?
I can live with that as a compromise if somebody really feels we need
to keep the human readable text. It would need to be so optional that
I can write a conforming implementation that never sends it when
acting as a parent and completely ignores it when acting as a child.
I would claim, however, that this is a machine-to-machine protocol not
intended for human beings to read, and that including human readable
error messages just because the presentation language is capable of
expressing them is confused thinking (although presumably well
intended). There's has been a fair amount of work done on design of
"internationalized" ("i18n") application protocols of late, and my
current understanding is that it is a bad idea to confuse machine
readable protocols with human readable protocols. See, eg, John
Klensin's plenary presentation at the Prague IETF meeting.
So:
- As stated above, I can live with a compromise here, but
- I remain convinced that human readable error messages in this kind
of protocol are at best extraneous and may be actively harmful to
the extent that they encourage programmers to sneak useful
information into the human readable text rather than updating the
registry of error codes.
With no intention of offending, the less said about attempting to
generate human readable error messages in multiple scripts and
languages based on HTTP Accept-Language headers, the better.
"Votre message n'a pas été fourni: Not a typewriter".
ok - so if it says:
description : value is a text field. This element
MAY be present. It's value has no defined meaning
within the scope of this protocol.
Implementations may assume that some form
of human-readable text may be used here.
> 17. Registry of Error Codes
> ---------------------------
>
> >> [[A registry of defined error codes
appears to be appropriate to reference
> >> here.]]
> >
> > Ahem. Try
> >
> >
> > A registry of defined error codes MUST appear here.
> >
> > That is: the error code registry is part of the specification. It's
> > ok for it to grow as we discover more errors, but it's protocol.
>
> ok, agreed.
Thank you!
thanks,
Geoff
