Subject: RE: [TLS] Re: Two notes on TLS 1.2 after implementing it in GnuTLS

From: <[email-masked]>
Date: Mon, 4 Dec 2006 11:32:38 +0200

Stephen Henson wrote:

> As I think has been mentioned some implementations generate the
> DigestInfo structure using a cut+paste operation from a binary blob.
> Others perform cut, paste and compare for the verify operation.

Yes; for example IEEE 1363a-2004 specifies the hash identifier for
SHA-1 as fixed hex string "3021300906052b0e03021a05000414" instead 
of talking about OIDs and DER encoding.

<snip>
> Some existing examples, such as smart cards, cannot change the format
> they use and would be rendered non compliant if we make their format
> illegal.
> 
> All the examples I've seen using that technique (and a few specs)
> require that a NULL parameter is present and not omitted but I can't
> rule out some which may omit parameters.

It's good to note that smart cards that do only RSASSA-PKCS1-v1_5 
with omitted parameters are already non-compliant with TLS, since
all existing versions of TLS use a custom signature scheme instead 
of normal PKCS#1 signatures.

But I do agree that it would be a good idea to be compatible with
existing RSA smart cards, tokens, and other difficult-to-change
implementations.  Does anyone else have more information about what
existing implementations do?  Is formatting the hash to DigestInfo
structure usually done in the token, or the library calling it
(presumably easier to change)?

Best regards,
Pasi

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Mike <[email-masked]>
Date: Wed, 06 Dec 2006 10:20:39 -0800

While not exactly the same thing, RFC 4055 discusses using various
SHA digest algorithms in an AlgorithmIdentifier.  In it, it says you
must accept either encoding, with or without NULL parameters:

    There are two possible encodings for the AlgorithmIdentifier
    parameters field associated with these object identifiers.  The two
    alternatives arise from the loss of the OPTIONAL associated with the
    algorithm identifier parameters when the 1988 syntax for
    AlgorithmIdentifier was translated into the 1997 syntax.  Later the
    OPTIONAL was recovered via a defect report, but by then many people
    thought that algorithm parameters were mandatory.  Because of this
    history some implementations encode parameters as a NULL element
    while others omit them entirely.  The correct encoding is to omit the
    parameters field; however, when RSASSA-PSS and RSAES-OAEP were
    defined, it was done using the NULL parameters rather than absent
    parameters.

    All implementations MUST accept both NULL and absent parameters as
    legal and equivalent encodings.

Mike