ftp.rsa.com/2014.05.ftp.rsa.com.tar/ftp.rsa.com/pub/pkcs/98workshop/summary.txt

Text File | 2014-05-02 | 18KB | 430 lines

         Meeting minutes from the 1998 PKCS Workshop
                San Mateo, CA


PKCS #1: RSA Cryptography Standard

  Jessica Staddon (RSA Laboratories) presented the PKCS #1 v2 document and
Mihir Bellare (UC Davis) described the PSS signature scheme of which he is a
co-inventor.

  General consensus was as follows:

    * Document is acceptable, though some simplification of the text may be
helpful, and a second mask generation function based on HMAC would be
useful.

    * For signature schemes with appendix, PSS is preferred, provided that
licensing fee is nominal (e.g., < $500 for handling). FDH is an alternative.
There was no significant interest in X9.31 signatures as part of PKCS.

    * For PSS, some further technical work is needed, such as how to include
an algorithm ID in the RSA input (this could be a general way to include
additional parameters). Also, a construction where hashing is deterministic,
and recommendation for deterministic generation of the seed.

    * No significant interest in signature schemes with message recovery,
enhanced encryption schemes, or key validation methods at this point.
Possible interest in a specifying a key wrapping mechanism based on the
encryption schemes.

    * A companion document giving usage guidance is recommended. It would
cover issues such as key size, public exponent, key generation, typical
protocols, and variants such as multiple prime factors or prime factors of
different lengths. This could be updated more frequently than PKCS #1
itself.


PKCS #13: Elliptic Curve Cryptography Standard

  Burt Kaliski (RSA Laboratories) presented a proposal for PKCS #13 v1. In
general, the proposal was considered reasonable, and a PKCS for ECC
appropriate. A profile of existing standards as a basis for interoperability
without patent encumbrances, is the goal. The fewer choices, the better.


PKCS #12: Public-Key User Information Syntax Standard

  Blake Ramsdell (Worldtalk) gave a critique of PKCS #12 based on Peter
Gutmann's previously published comments.

  General consensus:

    * PKCS #12 v1.x document needs to be completed, reflecting actual
implementation. Options that are not supported by implementations
should be removed for simplicity. Some clarifications are needed, and
recommended practices should be noted.

    * A clean slate for PKCS #12 v2.0. PKCS #5 v2 can be the reference for
password-based encryption. One possibility is to define a storage format for
user information, not just an interchange format. Some synergy with PKCS #15
(IC Card File Format Recommendations) is worth considering in this regard.


PKCS #15: ICC File Format Standard

  Magnus Nystr÷m presented the PKCS#15 proposal and the reason for
this proposal. Hans Nilsson, AU-Systems presented the Swedish SEIS
project and the new Swedish electronic identification standard.
Finally, Scott Guthery, Microsoft related the DC/SC effort to PKCS#15
and the SEIS work.

  A summary of the discussion that followed:

    * Magnus Nystr÷m led the PKCS#15 discussion. He started by asking
the attendants whether they felt this was something important enough
to create a PKCS for. Several votes in favor (or strongly in favor) of
this where heard, none against.

    * Should ASN.1/DER (or PER) be used or is a simpler TLV (or TLS)
model is better? Advantages for the former is the richness of the
language, the existence of 3rd party parsers and ease of
extensions. Disadvantages are ineffective coding and concerns about
longer update times. Furthermore, DER parsers isn't always present in
environments where a card can be used (e.g. cellular phone).  The
conclusion of the debate was that RSA Labs should probably try to
stick with ASN.1 but try to simplify the ASN.1 and make it more
'application-friendly' (easy to do card updates as more or less
'atomic' operations).

    * PKCS#15 and PKCS#11: Magnus noted that PKCS#15 builds on
PKCS#11, but that PKCS#11 implementations is not required for
applications making use of PKCS#15. This is perhaps mostly important
in restricted environments, such as cellular phones or during desktop
boot-up sequences. As a consequence of this, PKCS#15 will not be
restricted to certain limitations which exists in PKCS#11 today, like
lack of support for multiple PINs. It is anticipated that several
enhancements to PKCS#11 will be made as a result of the PKCS#15 work,
however.

    * Several attendants, among them Eric Rescorla, noted that
although the 'format' layer could be interoperable with the help of
PKCS#15, the actual card layer will still be card-specific. Hans
Nilsson of Sweden mentioned the ISM (Instruction Sequence Mapping)
file initiative from Sweden, which defines how to map certain
standardized generic commands to card specific ones. Due to certain
problems, the ISM file was however later withdrawn from the swedish
work. The general consensus of the meeting seemed to be that we should
not spend time and energy on improving the ISM. In due time, smart
cards will probably support ISO 7816-8 (or something similar) and in
the meantime, a reasonable solution could be to make provisions in the
format for stating which 'generic' commands a particular card
supports.

    * One attendee mentioned that implementing PKCS#11 on a card
obviates any need for a low-level format specification like
PKCS#15. Magnus' response to this was that the current proposal is
aimed for the most common card types today, ISO 7816 -based cards, but
that he didn't rule out the possibility to include other card types in
the future. One suggestion to instead use vendor-supplied PKCS#11
drivers (or CSP drivers) was rejected since this means that these
drivers has to be installed on all platforms on which a user may wish
to use his card. Furthermore, independent card initialization and
personalization requires an open card format.

    * Since PKCS#15 also will support pure memory cards, Magnus raised
the idea given (by someone else) yesterday, that PKCS#15 also could be
the successor of PKCS#12, thereby giving one uniform format
description for 'personal credentials'. Several voices in favor of
this suggestion where heard, but the outcome of this also depends on
the chosen encoding. Clearly, ASN.1/[DP}ER is the preferred choice in
this case.

    * There was a discussion about support for certificates other than
end-user public key certificates. As an example of this, users having
trusted CA certificates on their smart cards would in practice carry
their 'trust' with them. Magnus will try to include the notion of CA
certificates as well as attribute certificates (suggestion by Roland
Lockhart, Entrust) into PKCS#15. Bob Relyea, Netscape, mentioned the
Netscape proposal regarding trust objects.

One attendee was concerned that current cards won't be able to store
several certificates due to memory constraints. The issue of
certificate compression was discussed, but general consensus was that
good compression algorithms are already patented. The notion of
'adjoint certificates' (common certificate fields are only stored once
on the card) was also discussed, but no conclusion was reached in this
matter.

    * Hans Nilsson wanted PKCS#15 to include a clarification and
mapping of the key usage bits to X.509 key usage bits. This is also an
issue for PKCS#11. Magnus agreed to look into this.

    * Scott Guthery, Microsoft argued against specifying access
controls in PKCS#15, since this is the card issuers responsibility.
Magnus agreed and will move this to an informative appendix.

    * Ernst-Michael Hamann suggested that PKCS#15 would include
definitions of IDOs. With the possible exception of username/password
objects the meeting rejected this proposal for being too application
specific.

    * The meeting ended with a decision that further discussions will
take place on the cryptoki list. RSA will post a revised draft to the
list within one month. The goal is still to have v1.0 finished during
Q1 1999.


PKCS#11: Cryptographic Token Interface Standard

  Matthew Wood of Intel held a presentation describing Intel's
encapsulation of PKCS#11 within the CDSA framework and the mutual
authentication model used therein.

  Ernst-Michael Hamann of IBM Germany presented a proposal for
extending PKCS#11 with, among other things, a new attribute for keys
indicating that every usage of the key requires a new card holder
verification. The proposal has been posted to [e-mail].

  Magnus Nystr÷m of RSA Labs led the discussion about proposed
enhancements and experiences from implementations. The discussion
centered about a) finding the most pressing issues and thereby being
able to prioritize the work, and b) how to proceed with the work.  The
result of a) is shown below. b) was finally settled on Friday, October
9, when it was decided (see below) that -unless there is any
administrative problems- Matthew Wood will be the editor of PKCS#11
v2.1 - a backwards compatible revision of PKCS#11 v2.01 based on
proposals from the workshop. The general view was that a majority of
the proposed changes should be able to implement without destroying
backwards compatibility.

  The day ended with four show-and-tell demonstrations, from

    * IBM Card Solutions Germany (Card personalization and
      applications thereof)
    * Xeti Inc, Los Altos, CA (PKIX Java toolkit)
    * Intel Corp (PKCS#11 inside CDSA 2.0)
    * Zergo, Australia (CA service)

  A summary of the discussions:

    * 'Simple' Fixes:

      - Short token serial numbers (16 bytes). Possible fix: Change to
        BCD-encoding.

      - TOKEN_INIT-flag, stating that the token indeed has been
        initialized. This has been suggested by [e-mail] and
        the proposal has been posted to [e-mail]

      - C_OpenToken() or C_InitializeToken() function (easier w
        regards to C_GetTokenInfo() and needed for Fortezza) also
        change C_GetTokenInfo() to use a session instead of a token
        (Ed's note: Hmm. This probably breaks backwards
        compatibility. Probably need C_GetTokenInfobyTokenHandle()
        instead).

      - Missing and unspecified return codes like for instance
        CKR_BAD_ARGUMENT when NULL input to, e.g., C_Digest().

      - Change CK_CHAR to UTF8 - does not destroy backwards
        compatibility, but is more user friendly for e.g. Asian users.

      - Enable SO to change (some of) user's PINs (e.g. introduce
        C_SetUserPin())

      - CKF_PROTECTED_AUTHENTICATION path for slots, not tokens? Or both?

    * 'Larger' issues

      - PIN area

         Multiple PINs: More or less needed in certain applications,
         e.g. non-repudiation. Needs cross-reference between PINs and
         protected objects.

         Should we introduce PIN objects?
         (Is there a risk of 'dangling' object references?)

        New attributes for PINs? (Suggested by [e-mail]:
       a) CKF_PIN_COUNT_LOW
       b) CKF_PIN_FINAL_TRY
       c) CKF_PIN_LOCKED
       d) CKF_PIN_NEEDS_CHANGE)

        PIN management (lifecycle) (CKF_PIN_EXPIRATION_DATE)

      - Certificates area

        Introduce new type of certificates:
           a) CA certificates (could be a new attribute for existing
              certificates)
           b) Attribute certificates (new subclass)

        Use compression of certificates??

        Add trust attributes to certificates (like : 'I trust this
        cert as an issuing authority certificate' or 'I trust this
        end-user certificate')

      - Mechanisms

        Extensions for the Fortezza cards:
           a) C_CreateObject() (Fortezza LoadX generates 2 objects)
           b) C_DeriveKey/C_GenerateRandomMech() to generate Ra and Rb
              Fortezza pointers
           c) CKM_KEA_DSA_KEY_PAIR_GEN - generate KEA and DSA keys at
              same time

        TLS/SSL key generation

      - New functions

        C_SignInit() or C_SignInitSecure() for keys with a (proposed) new
        attribute CKA_SIGN_SECURE. The intention is that a PIN will be
        needed each time the key is being used ([e-mail]).
        Allow for key splitting/secret sharing (like BSAFE 4.0?)

      - Profiles

        PKCS#11 is large and complex, there is a need for defined
        profiles, subsets of PKCS#11 needed for different kinds of
        applications. Perhaps also test vectors to verify against.

      - Clarifications

        There is a need to clarify how PKCS#11 implementations should
        handle the case of multiple applications operating on one token,
        especially with regards to object management.

        Clarify mapping between PKCS#11 key usage and X509 key usage (or
        extend PKCS#11 in this respect)

      - Trust issues

        Mutual authentication as a means of solving the export license
        problem (suggested by [e-mail])

        Introducing trust objects - See Netscape's proposal posted to
        the  mailing list.

      - Data objects
        Some consensus on (perhaps) defining one data object
        consisting of user name and password for a particular
        application, but nothing else.

      - Initial configuration information
        There is a need to declare initial configuration
        ([e-mail])


PKCS #5: Password-Based Cryptography Standard

  Burt Kaliski (RSA Laboratories) presented a draft of PKCS #5 v2.

  General consensus:

  * Approach and methods are generally appropriate, though some
consideration should be given to non-parallel methods for implementing the
iteration count (i.e., instead of exclusive-or of independent outputs of the
underlying pseudorandom function, compute the outputs iteratively).

  * The possibility that multiple keys may be derived from the same salt
should be mentioned. For instance, an integrity-protection key and a
confidentiality key might be derived from a password with a single PBKDF
operation.

  * A usage document might cover issues such as "pepper" and non-random
salts.

  One other suggestion: define a standard method for constructing
password-check values for verifying passwords.


PKCS #14: Pseudorandom Generation Methods

  Bob Baldwin (RSA Data Security) gave a comprehensive proposal for PKCS
#14. The proposal was considered reasonable; a mailing list was to be formed
to develop the PKCS #14 document.

PKCS Workplan and process:

  Burt Kaliski led a general discussion of the PKCS process and also
agreed on a work plan for the coming year.

In general, participants expressed satisfaction with the current process;
value was perceived in the production of documents that are readily
available to a wide audience in a reasonable timeframe. Formal standards
processes are helpful for long-term development of standards, but not
necessarily as an alternative to the current set of PKCS documents.

PKCS was also seen as having value in promoting technologies that are not
encumbered by patents, but this need not be its highest priority.

Burt also presented a proposal for a new PKCS based on protocols developed
by RSA Laboratories for user authentication in Security Dynamics products.
The protocol, which runs over a secure transport layer such as SSL, can
support a variety of authentication methods including challenge-response
authentication, time-based authentication, and biometrics. There was no
immediate interest in developing this further as a PKCS.

The tentative work plan agreed for the next year is as follows. In general,
the goal is to accomplish most of this by the next workshop (tentatively
Fall 1999), unless an earlier date is specified.

PKCS #1             * resolve signature schemes / PSS
RSA Cryptography    * write usage guidelines
                    * editor: Jessica Staddon

PKCS #3             * revise similar to PKCS #13
Diffie-Hellman      * proposal at next workshop

PKCS #5             * revise per workshop discussion
Password-Based      * new draft 11/98, final 1/99
Cryptography        * write usage guidelines
                    * editor: Burt Kaliski

PKCS #6             * drop in favor of X.509 v3
Extended
Certificate Syntax

PKCS #7             * maintain as historical document
Cryptographic       * point to IETF S/MIME
Message Syntax

PKCS #8             * update with new references
Private-Key         * write usage guidelines
Information Syntax      (e.g., other key types)

PKCS #9             * record current practice
Selected Attributes * purpose: support PKCS documents

PKCS #10            * maintain as historical document
Certificate Request * point to IETF PKIX
Syntax

PKCS #11            * revise per workshop discussion
Cryptographic Token * develop mechanism ID registrations
Interface           * list of changes 11/98
                    * editor: Matthew Wood

PKCS #12            * record current practice
User Information    * editor: Blake Ramsdell
Syntax              * draft final version 11/98
            * final version 1/99
            * possible future merge with #15

PKCS #13            * draft per workshop discussion
Elliptic Curve      * after PKCS #5
Cryptography        * editor: Burt Kaliski

PKCS #14            * draft per workshop discussion
Pseudorandom        * final 5/99
Generation          * editor: Bob Baldwin

PKCS #15            * revise per workshop discussion
IC Card File Format * new drafts 11/98, 1/99, final 3/99
                    * editor: Magnus Nystr÷m

Matthew Wood and Blake Ramsdell will be providing outside editorial support
to RSA Laboratories, coordinating the revisions to their respective
documents. The final decision on the documents will remain with RSA
Laboratories, under the usual consensus process for other documents, and the
documents will be available under the usual terms. Matt and Blake's help is
much appreciated.

Meeting notes collected by
Burt Kaliski and Magnus Nystr÷m