henry.story at bblfish.net
Wed Oct 6 01:58:13 CEST 2010
On 6 Oct 2010, at 00:54, Nathan wrote:
> Henry Story wrote:
>> All browsers I have seen show the public key mod/exponent in detail.
>> It may not be a lot of users seeing that, but it does make things transparent.
>> ASN.1 is not transparent that is for sure.
> Is this about matching a public key in your profile up to a certificate in your browser?
Also I like to understand what is going on under the hood myself. With the
way we have it now, I feel very confident. It's clean.
>>>> For debugging this was very helpful to get us going, and I think
>>>> can be helpful also in the longer term.
>>>> DER or PEM are really deeply opaque.
>>> I can understand how the information is valuable to debugging, but I'm not sure that that is the measure we should be using to determine what format to go with.
>> Transparency has advantages it increases confidence, and that is especially valuable
>> in a space like cryptography that is already opaque.
> agreed, I won't argue over whether people see a PEM-encoded public key or an exponent / modulus in hex as transparent though
>> But that was not the only reason. Other reasons include that it fits in with XML-DSIG's way of doing things, that it will be useful to map to/from other formats,
>> that it is neutral with respect to PGP/X.509,
> XMLDSIG: agreed, and this is why I voted for both options, but not at the cost of WebID, if a PEM in a single triple makes webid accessible and easily deployable at web-scale then it's a no contest,
yes, so that case had not been completely made to me it seemed. We are moving complexity
from one place to another, from the XML to the ASN.1. One of those is very well defined (ASN.1 DER)
but very tedious to deal with.
> other ways of signing things can be defined (and are) + almost every library I've ever seen that supports signing / encrypting / sealing data with public keys accepts PEM or DERs, in fact, never have I seen a library which accepts modulus and exponent.
Well it is true that when one looks on the web the tools are all written in terms of those.
But I wonder how much this all is just because of ASN.1 that those tools hide so much.
Of course those libraries all must be using public/private keys to sign and encrypt, as that
is what the maths requires.
Here is some code
But I get the point.
> PGP: What's the point in being neutral when we define TLS which is X.509 / RSA, and PGP can't be used? The protocol is tied to RSA and can't be used with PGP..
WOT which I used initially was PGP based, and those folk tend to be a lot more into web-of-trust,
so it was partly that.
A couple more points:
- WebID is not tied to RSA. We just have not found the need to use DSA yet, and so we did not bother specifying that.
- RSA and DSA work with PGP.
But currently we are gaining the most benefit from TLS of course.
>> (I think it may even be shorter, as we don't need all the other stuff in the certificate)
>>>>> I don't think there are many humans
>>>>> that will look at a really huge number instead of some base64-encoded
>>>>> characters and take away something different away from it. You don't
>>>>> need to know that huge number for any reason -- it might as well be
>>>>> opaque as far as human eyes are concerned (and again, cryptography tools
>>>>> that actually use the number will already implement DER).
>>>> Well I often look at keys first and last chars and a few middle chars
>>>> when doing a quick test.
>>> Maybe, but I'd expect you to be in a tiny minority of humans (read: developers only) that would do that in the future. Developers need good tools to debug this stuff, but that's just a matter of having good tools, I think. And ... if the tools for displaying this information for verification are already available... etc.
>> A very small portion of people read html, and yet that it was easy to read was a big advantage.
> Can't really compare HTML to an exponent+modulus inside some RDF which could be in RDF/XML, RDFa or other..
>> I also thought that politically mod/exp means that we are not taking sides in PGP / X.509
>> space... Furthermore we did have implementations in all the languages up to now.
> we are in the protocol though, it's TLS / RSA specific..
Those are three distinct things (as I understand it)
- RSA/DSA are public key algorithms as I understand. (It's not RSA specific (as mentioned above))
- DER/X.509/PGP are ways of encoding and signing profile information - equivalent to XML-SIG if you want.
- TLS is a connection protocol, that can negotiate a number of key algorithms (I think it is open
>> But it is also true that publishing the whole certificate in one relation could be easier.
>> You could also publish the certificate with the subject alternative name all by itself too.
> unsure where this is coming from? why publish the full certificate?
It would work - if you publish the PEM at the location. It would be extreemly easy to
deploy and also to explain. No need to even learn XML, RDF or anything, and it will work with
all the tools out of the box. Perhaps it is worth investigation this option more. Just for the
fact that it would be so dead simple to explain to security people. Perhaps if they GET that
without the need to get into RDF we'd already have some extra buzz.
It also makes for some interesting parallels.
Publishing a PEM file would be like publishing a signed foaf file with the following limitations:
a. you can only have one public key
b. very complex and difficult extensibility - certainly nothing that out of the box tools
make easily available
c. no linked data, other than perhaps a link to the Issuer
With the cert ontology you can describe such a certificate (RDF: Resource Description
Framework) easily. If you do describe such a file you'll notice that that you would
have something like this
<> a foaf:PersonalProfileDocument;
:me foaf:mbox <mailto:henry.story at gmail.com> . # that's for the other SAN
:me xx:pubKey [ rsa:modulus "..."; rsa:public_exponent "..." ] .
And the above would be signed. (In publishing foaf we don't need to sign the doc
because that is done on the fly by the SSL user agent. )
And the point there was that when we do that we don't put an DER encoded public key
in the foaf description if we are to describe the X.509 cert.
The DER Contains a public key, so to put the whole DER back into the foaf is a bit
over the top. In the same way with the cert ontology we should be able to describe
a PGP key. We can describe both those cases easily, so we gain in generality.
Now we can of course publish the DER. But that is really
only for some practical reasons such as:
- tools for signing work with these PEMs out of the box
(what advantages does that give us? Just asking here for examples)
- It is really so much easier to publish PEMs than public keys
as we have done. (But our code is working already!)
(It is true that the literal extensions we added did make things a lot more flexible,
but the point was to make sure we could deal with anything)
- Some people will just grok it more
(but will they not be the same people who in any case will have trouble
with RDF and so will go and hide in the skirts of the Portable Documents crowd)
Now I don't mind in fact if we do it as we have now and danbri's full certificate link.
Then we can see what people gravitate towards.
> could be an option via conneg or via a link / pointer (as done in WOT) - but unsure why you mention now.
Yes, that would be fun. This would be the simplest way to get things going.
Just dump your full PEM at the URI location. Perhaps the file could even contain
a number of PEMs for users with a number of public keys. No need to learn XML or
RDF here :-)
Social Web Architect
More information about the foaf-protocols