Re: [Fwd: new draft (draft-arsenault-sacred-reqs-00.txt)]

[Dale Gustafson <dale.gustafson@xxxxxxxx>]

Hi All,

Al and Stephen should be commended for their excellent work on this draft.

Please see a couple of additional comments, below.

Best Regards,

Dale Gustafson

---------------------------------------------------------------------------------

1.1 Background and Motivation

Presently, roaming is most often accomplished by exporting a key and certificate (as a PKCS#12 file) from one PC and
importing it to some other PC.  Current versions of Netscape Communicator support a more elegant (application-specific)
“roaming” capability that can be used to transfer desktop settings, the email address book, URL bookmarks, you-name-it,
to another PC (also running Netscape) through a roaming server.  See { Edit | Preferences | Roaming Access | Item
Selection } in current versions of Netscape Communicator.  Moreover, smart cards may not work well in a PKI environment
when configured as read-only (sometimes called "write-once") devices, as is being alluded to here.

In any event, in this document the emphasis should be placed on "interoperability" -- articulating the need for a
standard protocol or protocols and standard secure credential data formats. I suggest replacing the last four paragraphs
of this section with something like ...

It is envisioned that making credentials securely available to “roaming” users (in an interoperable fashion) will provide
substantial value to network owners, administrators, and end users.  The intent is that this value be provided largely
independent of which hardware device is used to access the secure credential and what type of storage media the secure
credential is written to.  Each different credential storage device, be it desktop or laptop PC computer memory, a 3.5
inch flexible diskette, a hard disk file, a cell phone, a smart card, (or whatever) will have very different security
characteristics and, perhaps, very different protocol handling capabilities.  Users will be able to securely and reliably
move their credentials between different locations, different Internet devices, and different storage media as needed.

---------------------------------------------------------------------------------

> 2.3 Credential Formats

...

>    <<Open issue: Should we place any structure on credentials or really
>    just regard them as octet strings? The latter is simpler, except
>    that perhaps a password is used both to authenticate to a credential
>    server *and* to encrypt the private parts of a pkcs#12 file.>>

Ideally, credential protocols and data formats will be architected in an extensible fashion that ensures each defined
element is clearly identified (within the protocol and within the credential) and also allows new formats and versions to
be added over time.  One or more methods of extending the protocol or data format are designed in at the outset.  The
real art form here is in making things both sufficiently well structured and sufficiently open-ended such that product
builders can utilize this new standard without arbitrarily forcing a redesign of products that are currently in the
market or in the R&D pipeline.  While I agree this could make security analysis more complex, it doesn't necessarily make
it impractical -- it's a concern to be kept in mind throughout but not necessarily a show-stopper.

The credential format, the download and upload protocols, and the credential storage device’s unique capabilities may be
highly interrelated in some cases.  Shouldn't we say something about that in this section ?

---------------------------------------------------------------------------------

> 5. Security Considerations

The current wording tends to downplay the benefits of the standardization work ahead -- which is clearly an important
step forward.  I would like to think this work will enable substantial progress beyond the current state of the art.

I suggest we save this discussion until it can be stated more specifically in subsequent documents and replace the
existing section 5 with the standard clause ...

5. Security Considerations

This entire document is about security.