ftp.rsa.com/2014.05.ftp.rsa.com.tar/ftp.rsa.com/pub/pkcs/01conference/minutes.txt

Text File | 2014-05-02 | 8KB | 168 lines

    Minutes from the Ad-hoc PKCS Workshop, April 10, 2001
        ----------------------------------------------

1. Opening of meeting

Burt Kaliski, RSA Laboratories, welcomed everyone and presented the
agenda. About 30 attendees, attendee list at the end of this note.

2. PKCS #15

2.1 Suggested enhancements to PKCS #15

Peter Gutmann presented some issues with the current version of PKCS
#15 and gave suggestions for improvements.

The first issue is due to the fact that data objects does not have an
identifier which means that it is impossible to cross-reference them
from, e.g. private key objects. Peter's suggestion was to add an 'iD'
to the commonDataObjects type.

The second issue Peter discussed related to "internal objects",
e.g. objects which could exist in a hardware token without being
visible to the end-user, but would be visible in a soft version of a
PKCS #15 token, due to the fact that token specific information does
not exist. Peter's suggestion was to add an "internal" flag to the
commonObjectAttributes flags. It was noted that the solution would not
stop users from determining the existence of these objects even if
they will be unable to access them though (namespace issue).

Finally, Peter presented a proposal regarding the storage of secret
keys protected by being wrapped. Peter's suggestion is to store these
keys directly in the recipientInfo structure, and possibly indicate
this with a new ObjectValue choice. The primary motivation for this is
the fact that it's easy to store a wrapped key in the RecipientInfo
but in some cases impossible to store it as Encrypted/EnvelopedData,
since a token may not allow export of the key in plaintext. In
addition it reduces the number of layers with one. Russ Housley noted
that the latter motivation may not be worth it per se since usually
not too many symmetrical keys will be stored this way.

2.2 Certificate enrollment information

Nada Kapidzic Cicovic, Entegrity, proposed storage of certificate
enrollment information in, e.g. a PKCS #15 data object. The purpose of
this would be to simplify enrollment from any CMP (or CMC) capable
client. The proposal has also been presented to IETF's working group
"SACRED". Bob Relyea, Netscape, argued that he would like to see some
split between things which would go into PKCS #15 and some which would
go into the library implementation, arguing that the token [or token
manufacturer] can not make all decisions. Resolution seemed to be to
let the library/browser have default values but first look in the
token for the information. Going forward, Nada will prepare a written
proposal of the data object interface and submit both to
[e-mail] and [e-mail].

3. PKCS #11

3.1 Support for "advanced" tokens in PKCS #11

Stefan Andersson, Ericsson, presented work related to the concept of
mobile phones as "personal trusted devices," devices carrying a user's
PKI credentials and capable of not only signing and decrypting but
also displaying messages that are about to sign. In combination with a
short-range radio technique such as Bluetooth, this can be used
e.g. for signing of emails on a PC.

The current design of PKCS #11 presents a problem here; it is on a too
low level to acommodate a token which is capable of forming a PKCS #7
SignedAttributes structure on its own and subsequently sign and hash
it. Preferably this would be left to the phone since it needs to
verify that the text to be displayed corresponds to the digest to sign
in any case. Bob Relyea made a remark about phones not being able to
display all sorts of contents anyway. Stefan and Magnus commented that
this can be solved by, e.g. the phone inserting a signed attribute
indicating what content was actually displayed to the user (e.g. when
dealing with multipart MIME messages). Bob Relya noted that PKCS #11
does not even have a well-defined suppport for offline authentication
yet. There was also a question if this really is feasible with today's
phones, and how much PKCS #7 code that would have to be on the
phone. It was noted that a working implementation of this was shown
at the RSA conference using an Ericsson R520 telephone. Aram Perez,
Wave Systems, raised the possibility of XML signatures. Russ Housley
expressed the opinion that this might very well be an important part
of future local transactions. It was decided to continue the
discussion on the cryptoki mailing list, perhaps also with a written
proposal from interested parties.

3.2 PKCS #11 v2.11

Matthew Wood, Intel, presented the current status of this
project. Matt expects to have a final document ready for publication within
a month or two. The "secondary authentication" mechanisms has been
deprecated and instead a "dual-slot" method based in contributions by
Magnus Alstr÷m, SmartTrust, is being adopted. Further, PIN expiration
behavior has been defined. Some PKCS #15-related modifications
(e.g. trusted certificates and trusted public keys) has been made too,
and a range of new mechanisms has been added (including AES, X9.31
RSA, X9.42 DH, X9.63 ECC, SSL3 master secret derivation (non-RSA), TLS
master secret generation, RSA-PSS). There are still some remaning
(minor) issues - e.g. if SO shall be allowed to set the CKA_TRUSTED
attribute. Matt thanked everyone who had contributed to the work.
There was a question regarding SHA-2 mechanisms and AES modes, but it
was noted that these could presumably be added as amendments.

3.3 PKCS #11 v3.0

This was an early and fairly brief discussion on this forthcoming
project. Matt Wood made a proposal to split the document into
two separate parts - Data structures & API and - Mechanisms and
Parameters. The reason for this is, of course, the size of the current
document. By having separate parts, it would also be easier to
accommodate separate editors.

4. AOB

4.1 Conformance

Sinisa Cicovic, Entegrity, discussed the possibility of using
Entegrity's PKCS #11 workbench to test profiles against. It is
currently licensed as source code, but Entegrity could also imagine a
more generous licensing policy, i.e. offer this toolkit for free - but
would then rather not have ownership and responsibility for
maintenance.  Somebody would need to manage and moderate it,
however. Topic to be discussed further at the next PKCS Forum.

5. Closing remarks

Burt asked for views on where and when to have the next PKCS
Forum. Several participants suggested to have it earlier than the
previously announced September timeframe, perhaps in June. Burt agreed
to check the possibility of this. Finally, he thanked everyone for
their attention and contributions.

Attendees:

Magnus Nystrom, RSA
Burt Kaliski, RSA
Simon McMahon, ERACOM
David Hook, Wumpus Consulting
Ross Green, ERACOM
Krister Walfridsson, Precise Biometrics
Lutz Behnke, TC TrustCenter
Russ Housley, RSA
Peter Yee, SPYRUS
Claus Svensson, SmartTrust
Jean-Marc Robert, Gemplus
Shin Lee, Rainbow Technologies
Laszlo Elfeto, Rainbow Technologies
Bob Relyea, Netscape Communications Corp.
Simon Blake-Wilson, Certicom
Hung Uo, Litronic Inc.
Weimin Yang, Litronic
Aram PΘrez, Wave Systems
Marion Shimoda, Intel
Stefan Andersson, Ericsson
Hazem Hassan, Datakey
Christian Gehrmann, Ericsson Inc.
Jan-Ove Larsson, RSA
Peter de Laval, Sectra Communications
Kazumi Saito, Mitsubishi Electric Corp.
Rich Nicholas, Getronics Government
Peter Gutmann, University of Auckland
Nada Kapidzic Cicovic, Entegrity Solutions
Bill Oliver, WinMagic Inc.
Thi Nguyen-Huu, WinMagic Inc.
Sinisa Cicovic, Entegrity Solutions
Matt Wood, Intel