Re: [sidr] Working Group Last Call - draft-ietf-sidr-rescerts-provisioning-05.txt

[Rob Austein <sra at isc.org>]

At Sun, 1 Nov 2009 17:56:37 -0800, Terry Manderson wrote:
> 
> > to allow for audit: if one is paranoid, one can archive a copy of
> > every CMS message and use it (along with archived PKI material) to
> > prove at some later date that the action was properly authorized.  So
> > I view CMS as the main security mechanism here, and the one that's
> > most closely aligned with the underlying semantics.
> 
> Right, I also have a similar PoV. Although, and it may be an academic
> distinction - my reading is that if the XML operations are not truly
> idempotent then the 'CMS Signing Time' would have been a more pragmatic
> implementation.

Don't think I follow.  CMS profile for this draft specifies use of
signing time (and, optionally, binary time).  You need a signature
that covers both the timestamp and the dated material to be audited,
which this profile provides.

Am I missing something?

> So if you do authentication and authorisation in the CMS, why do you need 2
> way identification at the HTTPS layer if it's just for privacy?

TLS without checking signatures gives you a secure channel to an
unknown entity.  Professor Moriarty speaks TLS too.

> > The protocol nesting is tedious but straightforward:
> > 
> >    IP(TCP(TLS(HTTP(CMS(XML(up-down))))))
> 
> So, given that ASN.1 is fully capable of describing the data going back and
> forth (up/down). Why add the extra XML blob?

Primarily because there is running code using XML, secondarily because
XML is somewhat easier to code and debug.

> thinking from a different point of view - noting that the draft is
> using HTTPS with identification of server and client, for replay and
> privacy - why not consider the W3Cs XML Signature Syntax?

Considered and rejected, because it's broken.  The XML world doesn't
really have the concept of a single canonical format, and the attempt
to reconcile that world view with the requirements of digital
signatures resulted in a protocol in which otherwise valid signatures
can fail to validate because of disagreements about the canonical form
of the signed data.