[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PKIX1 definition of a certificate



> From: Stephen Kent <kent@bbn.com>
>
> Peter,
> 
> 	The defintion cited is not appropriate since, as you note, it
> unenecssarily and inappropriately brings encrytpion into the picture.  Our
> definition should cite only the use of a signature algorithm to bind a
> public key to a set of attributes, specifically the attributes defined in
> the spec (including extensions).



I agree that the definition is inappropriate, but since X.509 still
drags encryption into the picture, PKIX has little choice but to follow
suit.

Since DSA has been around at least since 1993, it seems that there would
have been ample opportunity to amend X.509 to accommodate both reversible
(RSA) and irreversible (DSA) signature algorithms.  But the current X.509
still defines signatures in terms of encryption:

  ENCRYPTED-HASH { ToBeSigned } ::= BIT STRING ( CONSTRAINED BY {
    -- must be the result of applying a hashing procedure to the
    -- DER-encoded octets of a value of -- ToBeSigned -- and then
    -- applying an encipherment procedure to those octets -- } )

  SIGNATURE { ToBeSigned } ::= SEQUENCE {
    algorithmIdentifier AlgorithmIdentifier,
    encrypted           ENCRYPTED-HASH { ToBeSigned }}



ISO/ITU folks:  Is there any chance that the 2001 version of X.509
could acknowledge the existence of irreversible signature algorithms,
since it's apparently too late to get them into the 1997 version?

Out of necessity, users of DSS certificates have been forced to
interpret the words "encrypted" and "encipherment" as including
mathematical techniques which have no inverse "decryption" operation,
even though such doublespeak is repugnant to those who expect standards
to be written in clear and unambiguous language.

No wonder there's so much confusion about making a distinction between
signature and encryption keys.