RE: [ekmi-sksml] CMS for key packaging

["Roddy, Sue A." <s.roddy@radium.ncsc.mil>]

Arshad - I'm in the process of converting the syntax to XML - I submitted
the ASN.1 version solely to represent the capabilities we are advocating,
not the syntax.

Excuse any "protocol breach" (literally or figuratively) that I may have
committed. I'm also constructing some bullets on why the (X)CMS for
keypackages might be of value or attractive to the committee.

regards
Sandi

Sandi Roddy
I5 Technical Leader for IA Infrastructure Transformation
National Security Agency



-----Original Message-----
From: Arshad Noor [mailto:arshad.noor@strongauth.com]
Sent: Friday, April 06, 2007 12:46 PM
To: 'ekmi-sksml@lists.oasis-open.org'
Subject: Re: [ekmi-sksml] CMS for key packaging


Sandi,

Thank you for the DRAFT RFC on "Symmetric Key Package Content
Type".  I have a few comments:

1) OASIS, to the best of my knowledge, rightly or wrongly, has
    focused only on XML-based standards.  This could be a
    reflection of the fact that the IETF already focuses on ASN.1
    based protocols and OASIS may have felt that they didn't need
    to duplicate that area of focus.

    However, I think they focus purely on XML-based standards only
    because the market has stated its preference.  While current
    applications based on ASN work perfectly well, there has been
    no denying that ASN is one of the hardest syntaxes to learn or
    understand; with all my years of learning, I still struggle
    with it; a significantly better person than I - David Hook -
    one of the prime committers of the BouncyCastle JCE provider
    compared it to "Klingon". :-)

2) That said, I would like to understand why an XML-based protocol
    may not meet the US DoD's needs.  If there are libraries that
    take care of the parsing, assembly, communication, etc. and
    hand the application precisely the data/object they need to work
    with (just like the ASN libraries do) why will not XML work?

    For instance, an application that needs to decrypt data, only
    needs to get the symmetric key as an opaque blob, and then call
    the appropriate functions in the library to perform the crypto
    operation.  If the underlying libraries take care of calling a
    network service, authenticating to it, getting the symmetric key,
    verifying it, extracting it and then making it available to the
    higher-order application, why does it matter that the structure
    in which the message is transported is ASN vs. XML?  The higher
    order application doesn't deal with either data-structure in
    either case.

    But, there is no doubt that every new tool, technology and
    innovation in computing has an XML interface today, because
    people find it easier to work with, understand and learn.

So, it would be really helpful to this TC/SC to understand what
benefits the Abstract Syntax Notation provides that cannot be
addressed by an XML-based data-structure.

Thanks.

Arshad Noor
StrongAuth, Inc.


Roddy, Sue A. wrote:
> While this is written in ASN.1, the concepts of CMS as a wrapper and the
> notion of content type for key packages (symmetric) is one we'd like to
> propose for consideration.
> 
> File attached - as noted, the intent is to take to the IETF in July which
> does mean some loss of author control,  but I'd still like some feedback.
> 
> Also - we are actively looking for tools that convert ASN.1 standards into
> XML - any ideas?
> 
> regards
> Sandi
> 
>  <<draft-ietf-turner-symmetrickeyformat-ekmiv1.doc>> 
> 
> Sandi Roddy
> I5 Technical Leader for IA Infrastructure Transformation
> National Security Agency
>