Subject: [TLS] TLS1.2: focus on non X.509 certs, cert URLs, authoirzation spaces, registration practices

From: <[email-masked]>
Date: Sun, 31 Dec 2006 10:56:22 -0800

Some more comments per the call on TLS 1.2 I-D. 

These are getting a bit more practical.

1. DSS SIGNED RSA IK 

Is TLS 1.2 introducing the idea that DSS signed cert can contain an RSA IK?

We read that in the enhanced Certificate Request that

           "Certificate types rsa_sign and dss_sign SHOULD contain
           certificates signed with the same algorithm. However, this is
           not required. This is a holdover from TLS 1.0 and 1.1."

Is the "holdover" that TLS 1.2 still may have to accommodate DSSsignedRSAIKs (from
earlier eras), 

Or is the holdover the opposite: TLS1.2 MAY now process DSSsignedRSAIKs (that wont work
well with systems from earlier eras)?

2. CLIENT CERTS: ClientCertificateType, authorization spaces

In summary the value encoding of each element of certificate_authorities should
be a function of certificate_types. This will help the client choose the appropriate
type of certificate (X.509 or not ), when populating the value of certCertChainType 
when using certificate URL message.

Background follows in a) and b)

a) TLS 1.0 ClientCertificateType removed some SSL3 enum values. TLS1.1 put them back (along with
the scheme denoting ranges of types, each controlled by different authorities (including private)).

In TLS 1.1 however, we suddenly get constrained in 2006 re the encoding of the DNs. The field has to 
be DER encoded, now. In SSL and TLS1.0 it was an opaque type (I.e. the format/encoding is defined 
by the ClientCertificateType). (Tell Peter DER, and he assumes he has to type check it, now, as DER,
raising an exception if it fails the encoding rules for each attribute type's value; this is a lot of code!)

Given certificate URL in TLS1.2, the CA field need refer to X.509 no longer. Thus, the pre-TLS1.1 convention
should be put back: DistinguisedName values can be encoded in a manner suitable for the cert type. 
(In the SAML world, we may encode a DN as a URI, for example.)

b) Given the major change in semantics due to TLS for these CA DNs (which got more and more
onerous, if you chart them), the DN is no longer cert selector: it's a signal of "desired authorization space".
Given this change, we even more clearly need non-DER-encoded DNs for CAs. SAML2 and WS-Fed Federation 
ids constitute the type of authorization spaces being implied, and don't get described in terms of 
DER-encoded DNs. Whilst they use X.509 certs behind the scenes, the trust model underlying
these authorization spaces is unlinked from KMI, PKI, CA roots etc.

I don't mind keeping the name certificate_authorities. its just a field name in a spec; it doesn't
go on the wire.

3. REGISTERING CertChainType

      enum {
             individual_certs(0), pkipath(1), (255)
         } CertChainType;

Can we do for CertChainType what was done earlier, for ClientCertificateType 

I.e. SUGGESTED TEXT OF " CertChainType values are divided into three groups:

              1. Values from 0 (zero) through 63 decimal (0x3F) inclusive are
                 reserved for IETF Standards Track protocols.

              2. Values from 64 decimal (0x40) through 223 decimal (0xDF)
                 inclusive are reserved for assignment for non-Standards
                 Track methods.

              3. Values from 224 decimal (0xE0) through 255 decimal (0xFF)
                 inclusive are reserved for private use.

           Additional information describing the role of IANA in the
           allocation of CertChainType code points is described
           in Section 11."

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

---

From: EKR <[email-masked]>
Date: Sun, 31 Dec 2006 11:07:21 -0800

> well with systems from earlier eras)?

The former.

> a) TLS 1.0 ClientCertificateType removed some SSL3 enum
> values. TLS1.1 put them back (along with the scheme denoting ranges
> of types, each controlled by different authorities (including
> private)).

Well, sort of.

TLS 1.0 had:
       enum {
           rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
           (255)
       } ClientCertificateType;

However, people were using other values. Those values are not standardized
by the IETF. So, we added them to the enum marked RESERVED to avoid reuse.

> In TLS 1.1 however, we suddenly get constrained in 2006 re the
> encoding of the DNs. The field has to be DER encoded, now. In SSL
> and TLS1.0 it was an opaque type (I.e. the format/encoding is
> defined by the ClientCertificateType).

Not really, no. RFC 2246 indicated that DistinguishedName was
derived from X509. I.e., it always had to contain a DistinguishedName.
4346 merely clarifies what was already standard practice, that it should
be encoded as DER (as opposed to, say, XER).

-Ekr

---

From: <[email-masked]>
Date: Sun, 31 Dec 2006 11:29:28 -0800

In 7.4.5 certificate_types, we seem - by enumerating certain enum values - to
be limiting the values of ClientCertificateType that a server may indicate, and thus 
a client may  "offer" 

Surely this should be any value from ClientCertificateType, including those from
the private range!?

"           A list of the types of certificate types which the client may
           offer.
              rsa_sign        a certificate containing an RSA key
              dss_sign        a certificate containing a DSS key
              rsa_fixed_dh    a certificate signed with RSA and containing
                              a static DH key.
              dss_fixed_dh    a certificate signed with DSS and containing
                              a static DH key
"
_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: <[email-masked]>
Date: Sun, 31 Dec 2006 12:44:38 -0800

We disagreed earlier on whether the spec required that a
(std) RSA cipersuite MUST send a certificate. I argued that it
wasn't necessary for the case of renegotiate given the DAO
of the confidentiality service; and we disagreed on that rationale,
even.

So, I've been attempting to accommodate:-

which would the list prefer:-

(a) a self-signed (static) cert
(b) an unsigned (static) cert
(c) a message with no content

I feel very comfortable with (a) for re-negotiation scenarios, within a 
decent ciphersuite. I can quote Eric's book (p.220), at least: "However, its 
is of course possible to use self-signed (and hence unverified) certificates 
and get the effect of an anonymous connection with any SSL mode."

If I recall, TLS-PSK also mentions the self-signed cert practice.

---

From: Mike <[email-masked]>
Date: Sun, 31 Dec 2006 17:11:05 -0800

> type's value; this is a lot of code!)

I don't think you need to validate the DER encoding (or not) of the
distinguished names.  Just compare them to your own and if you find
a match, it must be DER encoded.  If you don't find a match, maybe
it wasn't DER encoded, or maybe your DN isn't supported.  Either way
you know what to do.

Mike

---

From: <[email-masked]>
Date: Sun, 31 Dec 2006 18:49:56 -0800

I agree; that's very practical and simple. The declaration is also opaque. 
So, what you say is what one SHOULD do, using formal reasoning, too. Its not 
the problem of the protocol state machine; its FOR a message/value handling 
module to deal with. The protocol machine is NOT ALLOWED to interpret an 
opaque byte.

The certificates in the traditional messages can still be BER, as far as I 
can tell. But, again, they are opaques. Most if not all the other recent 
imports of ASN.1 into the standard are required to be DER on the wire.

Once CA certs and trust anchors etc are cached, presumably upon signature 
verification (which necessarily includes DER recoding), the index of the 
cache can be a suitably hashed-DER-form of the issuerDN, for
efficient search.

--------------

There is an interesting legal side-argument there, for TLS Evidence. If the 
SSL Record Layer
is signing handshakes, it necessarily is signing uninterpreted bytes, vs 
signing "information".

it would be funny if when pinging the whitehouse.gov SSL server, one could 
be getting the formal
record in the national archives to have a digitally signed rendition of 
"long live Sadaam's stockpile; good riddance to Pinochet & torture" etc etc, 
as present in the uninterpreted data. One could be disclosing one's patent 
idea, in the cert fields, more usefully. Its going to get signed and data 
retained, even before the https application gets to decode it as syntactic 
rubbish. Stick your social security number in it, claim it as PII, add a 
copyright notice, claim it as IP, add a securid OTP to the clientHello.nonce 
and time, claim its timestamped, and viola! free storage for posterity at 
govt expense.

Strange things happen, when you don't carefully type check everything in 
security protocols, in my (highly ASN.1-centric) implementation experience. 
But there we are; that's what the spec says; this
is what do therefore do.

----- Original Message -----
From: "Mike" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, December 31, 2006 5:11 PM
Subject: Re: [TLS] TLS1.2: focus on non X.509 certs, cert URLs, 
authoirzationspaces, registration practices