[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [TLS] TLS1.2: focus on non X.509 certs, cert URLs, authoirzationspaces, registration practices
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" <mike-list@xxxxxxxxx>
To: <tls@xxxxxxxx>
Sent: Sunday, December 31, 2006 5:11 PM
Subject: Re: [TLS] TLS1.2: focus on non X.509 certs, cert URLs,
authoirzationspaces, registration practices
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!)
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
_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls