KeyType shouldn't it support text

jon
2012-08-01
2012-09-11
  • jon
    jon
    2012-08-01

    I am looking through the implementation of CardMe and noticed the KeyType. I
    am still not that familiar with the CardMe source so excuse me if I'm missing
    something, but it appears that the KeyType only accepts binary keys. If so, it
    should also accept a plain text key.

    3.7.2 KEY Type Definition

    " If the value is a text value, then the default encoding of 8bit is used and
    no explicit ENCODING parameter is needed."

    Thought I'd mention it, if it helps and again excuse me if I'm
    misunderstanding something.

     
  • George_H
    George_H
    2012-08-01

    You bring up a good point, when cardme was designed at the time it wasn't
    clear what a text value key looked like. I've always seen keys as Base64
    encoded text and nothing else. So we kind of stuck to that.

    Although I would be curious to see a vcard example with a key that is 8bit
    encoded and not a Binary type. If you could provide a valid vcard example i'll
    be more than happy to support it.

     
  • jon
    jon
    2012-08-01

    8 bit encoding is just a fancy way of saying 'plain text'. While I can't find
    a formal definition (its in there somewhere I'm sure) look at the definition
    section in the RFC for anything that is plain text and you'll see "Type
    encoding: 8bit"

    "3.1.1 FN Type Definition" => Type encoding: 8bit

    UID Type Definition => Type encoding: 8bit

    I believe 8 bit is just a fancy way of saying 'ascii' with the extended
    character codes i.e. 2^8 = 256 characters

     
  • George_H
    George_H
    2012-08-01

    text-value is defined as just ASCII text as you stated. But cardme is doing
    that, when cardme writes a vcard out it outputs the Key as Base64 text which
    is in 8bit. We use the ENCODING=b just as a hint that this text should be
    decoded into bytes.

    But lets say there is no encoding parameter and it is just TYPE=TEXT, ok...
    how does the key look like ? You see what I am getting at? You'd have to
    represent your key as text, you're 99% likely to base64 encoded the key to
    text.

    I don't know if someone wants to represent their key as hex 0x000 whatever
    separated by spaces... that'll definitely be weird but it would work.

    Are you encountering a situation where you need to access your key as text
    while your vcard is represented as a Java object? or your key is represented
    as text that is not base64 ?

     
  • Yes I noticed that too. RFC 2426 states that the value of the KEY type can
    either be text or encoded binary data (i.e. base64). It doesn't give an
    example of what a plain-text key looks like.

    At first I thought they might be referring to a URL, because all the other
    binary types (LOGO, PHOTO, and SOUND) are allowed to use URLs instead of
    binary data. However, the formal grammar for the KEY type (p.35-36) says that
    URLs are not allowed, assuming I am reading it right.

    The 2.1 specs are equally enigmatic. They don't explain what "clear-text"
    means exactly.

    If the representation is a binary format, then the public key must be
    further encoded. The default format is clear-text. If a binary format is used,
    then it is specified by the property parameter.

     
  • jon
    jon
    2012-08-02

    This discussion is a bit odd to me, and perhaps that is because I'm
    misunderstand the purpose of CardMe. Is CardMe meant to be something that can
    processes/represent any valid vcard as a Java object, or is it meant to
    represent only vcards that it has created?

    If it is intended to do the first or both, then it needs to be able to
    represent the key as text because that is in the RFC.

    As a base 64 the minimum is :

    KEY;ENCODING=b:base64_encoded_data_here

    But lets say there is no encoding parameter and it is just TYPE=TEXT, ok...
    how does the key look like ?

    I don't have a valid vcard with a plain text key, but the RFC has the details.
    A plain text KEY would not include the ENCODING parameter and would be like
    any other 8bit encoded value . (i.e. "If the value is a text value, then the
    default encoding of 8bit is used and no explicit ENCODING parameter is
    needed." )

    KEY:thisIsSomeASCIKey

    In both cases the TYPE parameter is optional and if included should (not
    must) be an "IANA registered public key or authentication certificate
    format". It also says "The parameter type can also specify a non-standard
    format." which is somewhat redundant because the initial 'should' just stated
    that. So in the end TYPE may or may not be specified and if specified could be
    anything.

    Think of creating a vcard: the user uploads a digital certificate file for use
    as the key (KEY;ENCODING=b:xxx) or they pasted some text in a text box
    (KEY:myprivatekey). The key could be from some proprietary system that uses
    plain text keys... we don't know. The TYPE is only known if the user specifies
    it or some logic is used based on file type.

    The opposite would be diplaying the vcard to the user. They would download the
    key for use externally (since it is a binary file basically) or the vcard
    would show them the text they originally entered.

    My usage is that I sync/get vcards from a server and need to represent those
    as Java objects. I have no control of which options are included in the vcard
    so the Java object must be able to represent any valid vcard as-is. I also
    need to be able to convert that Java object back into a text vcard again,
    preferably exactly like it was before, with any new changes.

    In the case that the KEY was originally entered as 'text' then yes I need to
    know so that when I get the key out of the Java object, I know if I need to
    treat it as a file or can display it as-is as a String.

    Personally, in the case of the KeyType, I'd represent the Key internally as a
    String, using something like the following (not taking into account the TYPE)

    setKey( byte binaryKey ) {

    this.isBinary = true;

    this.key = Base64.encodeBase64( binaryKey); //<== apache commons codec library

    }

    setKey( String textKey) {

    this.isBinary = false;

    this.key = textKey;

    }

     
  • jon
    jon
    2012-08-02

    I think a good example of a plain text key is PGP. Many people share/use PGP
    public keys as plain text. So if were to make my own vcard, I'd just paste my
    PGP key into my personal vcard as text.

    look at METHOD#2 found at www.ephesus.com/Encryption/RetrieveKeys.html

    a PGP key ... ( I removed the http from the URL's otherwise the post is
    rejected as spam)

    alumnus.caltech.edu/~madler/pgp.html

    So the vcard entry would be (roughly without thinking of escaping) with no
    need to base64 code it

    KEY: -----BEGIN PGP PUBLIC KEY BLOCK-----

    Version: GnuPG v1.0.6 (Darwin)

    Comment: For info see http://www.gnupg.org

    mQGiBDuVqKgRBAD5Mcvdc41W5lpeZvYplEuyEBXwmxnUryE2KaCG1C06sGyqgiec

    taTApkk=

    =OOMX

    -----END PGP PUBLIC KEY BLOCK-----

    or alternatively with a TYPE

    KEY;TYPE=PGP:KEY: -----BEGIN PGP PUBLIC KEY BLOCK-----

    Version: GnuPG v1.0.6 (Darwin)

    Comment: For info see http://www.gnupg.org

    mQGiBDuVqKgRBAD5Mcvdc41W5lpeZvYplEuyEBXwmxnUryE2KaCG1C06sGyqgiec

    taTApkk=

    =OOMX

    -----END PGP PUBLIC KEY BLOCK-----

     
  • George_H
    George_H
    2012-08-03

    Jon321, I see your point and we'll add the required support for cardme to
    accept plain text values for Key.

    Is CardMe meant to be something that can processes/represent any valid vcard
    as a Java object, or is it meant to represent only vcards that it has created?

    It is supposed to do both and more. There are applications that output vcards
    using their own formats and rules so we also try to support those with
    compatibility modes.

    My usage is that I sync/get vcards from a server and need to represent those
    as Java objects. I have no control of which options are included in the vcard
    so the Java object must be able to represent any valid vcard as-is. I also
    need to be able to convert that Java object back into a text vcard again,
    preferably exactly like it was before, with any new changes.

    Glad you mentioned that, this is one of the goals of CardMe is to be able to
    read/write VCards to and from various applications.

    One of the reasons the KeyType was not being stored as text was because
    cryptographic keys were encoded as Base64 text all the time. At the time I
    wasn't going so deep into the RFC, I would try to support everything but at
    the same time I focused on trying to get it working on many apps. Also your
    the first one to bring this issue up so now we know :)

    So yeah, I don't see an issue with having the KeyType store its value as text
    in a string. It will be either array of bytes or string. We'll also enforce
    the use of the parameter types, if the type is set to text but the user tries
    to set binary data, then an exception will be thrown.

    I'll add this on the new feature tracker.

     
  • George_H
    George_H
    2012-08-07

    Jon321, how urgent is this feature?

    I ask because I am working on cardme 0.4.0 which will include some major
    changes and improvements. I may get to do your feature later during the month.
    If this is preventing your work then I can give this higher priority.