[foaf-protocols] rsa public key defintition
akkiehossain at googlemail.com
Thu Dec 17 07:54:02 CET 2009
Perhaps if we can put a few test certificates somewhere. I will add a
(conformance) test script to libAuthentication on foaf.me and
openid4.me. (Possibly ahead of the spec).
I think peter this could work along the lines of the request you made.
To have a script which accepts a foaf file (webid) and certificate
file passed in. A variant of simplelogin i guess.
If a few people do the same we can check each others for interop atleast.
I am happy to set up a place for the test certs.
Or let me know the location of the certificate files with desired and
Of the options remaining i would favour option 1. For now. With an
alternative to allow people to add the com plete public key in der as
per the script i sent out earlier.
On 12/16/09, Peter Williams <home_pw at msn.com> wrote:
> If I Mint a cert with serial number -1 (as I'm entitled), how do you
> want to handle this in the cert/rdf vocabulary?
> Cert:decimal and cert:hex cannot be used (since they bear what in
> 1980s open systems notation folks call a value constraint of
> (I assume rdf positive integer does not include 0)
> On Dec 15, 2009, at 3:21 PM, Bruno Harbulot <Bruno.Harbulot at manchester.ac.uk
> > wrote:
>> Hi Peter,
>> Peter Williams wrote:
>>> My understanding was that the definition is purely formal, existing
>>> to cast
>>> an ASN.1 integer into a cert:integer.
>> I'm not sure if we were talking about the same thing. By design,
>> both ASN.1 INTEGER and cert:integer can represent any integer,
>> irrespectively of a range limitation (n-bits), so notionally,
>> they're the same concept. ASN.1 INTEGER is outside the scope of RDF,
>> whereas cert:integer is inside.
>> What I thought we were talking about is an encoding issue, so as to
>> be able to read and write those number from a text format (from/to
>> the RDF format). I think we might actually be talking along the same
>> lines, though; I'll just try to clarify what I think the problem is
>> as follows...
>> The bytes read from the certificate only take their meaning from the
>> context in which they are used. In this case, it's the ASN.1
>> structure that tells us that the sequence OpenSSL (and a few other
>> tools) present as '00:80' is in fact the number 128, since we tend
>> to write down decimal numbers.
>> For the encoding stage, we're still free to choose how to encode a
>> positive integer into RDF (that's what we're trying to define right
>> now). String encoding is what we're talking about with cert:decimal
>> and cert:hex which have rdf:range <http://www.w3.org/2001/XMLSchema#String
>> >. In this case, what we commonly refer to as 128 can also be
>> encoded simply as string '80', so long as we define this string
>> encoding to target positive hexadecimal integers (and thus expect
>> the decoders to treat them as such).
>> If a tool reads byte 00 followed by byte 80 in the DER encoding of
>> the certificate (in the modulus part), it will know that, because it
>> is an ASN.1 INTEGER, it will use it as a positive integer (e.g.
>> modelled as BigInteger in Java). In contrast, reading byte 80 would
>> make it use it as a negative integer, since it would decode and
>> interpret it as an ASN.1 INTEGER.
>> Similarly, in RDF, if a tool reads string '80' as the object of the
>> cert:hex predicate, assuming that we define cert:hex to allow only
>> for positive numbers, this will also mean 128 (whether that's a
>> BigInteger or anything else). The internal representation then
>> doesn't matter much.
>> In Java, one can create a public key using BigInteger.valueOf(128L)
>> to set the modulus, pass that object to the library that produces
>> PEM or DER files and the encoding within them will indeed have the
>> leading byte 00, as per definition of those formats.
>> I currently have a working certificate on foaf.me with the leading
>> bit set to 1 (so the number would be considered as negative is
>> treated as signed).
>> - https://foaf.me/simpleLogin.php displays it as:
>> [modulus] => BC623D.....
>> - openssl x509 -text displays it as:
>> Modulus (2048 bit):
>> - Firefox displays it as:
>> Modulus (2048 bit):
>> The point here is that it's just a way for us to read once it's been
>> extracted from the DER format and converted to whatever internal
>> model these tools use.
>>> You will never see it in an rdf document ever - in practice.
>>> All it does is capture the need to convert signed to unsigned,
>>> before doing
>>> the comparison. How that is done is not stated , but the process
>>> has been
>>> formalized by the nature of the subproperty typing within owl (and
>>> constraint guaranteeing uniqueness of that mapping, due to the
>>> functional condition between the DER canonicalization of
>>> values and cert:integers).
>> I think you're indeed highlighting the problem here: do we want an
>> inverse function condition between ASN.1 INTEGER and cert:integers.
>> If not, defining cert:hex, cert:base64, etc. to model only positive
>> numbers sounds fine. If we want to allow for negative numbers too,
>> we do indeed need an encoding that supports this and the leading
>> '00' in the string would seem like a suitable encoding (but we could
>> just as well have '+' and '-', although that would be more likely to
>> make the implementation mode difficult).
>>> Its stated the requirement ...for correctness. That requirement is
>>> underformalized - leading to interoperability issues in the 2 main
>>> implementations that exist today. From this, if one wanted, test
>>> cases could
>>> be formulated that stress implementations for the code.
>> Could you clarify what doesn't work? I might have missed something
>> in a previous e-mail. I presume you're referring to the problem
>> described here
>> This sounds more like a bug in the implementation rather than a
>> problem in the encoding specification (although we shouldn't exclude
>> one or the other at the moment). Would you mind sending me your
>> certificate in PEM format so that I can try to debug it?
>>> Yes - its whole bunch of formalism allowing a reasoner to build a
>>> system on the fly, for a problem that any digital electronics
>>> engineer since
>>> 1939 would do with hard logic. But, in the security space coming
>>> forward to
>>> 2010, it's also professional security engineering. It's one of
>>> things that
>>> allows one to demonstrate assurance of the crypto modules. Higher
>>> security is always about the design of type systems and proving
>>> flow theorems. (At higher assurance levels, one has to prove that
>>> the zero
>>> has fine-grained semantics (consistent with the design) and its
>>> cannot flow except where you have declared (consistent with
>>> and need-to-know))
>> OK, so this is about reasoning about bits rather than integers (as a
>> formalism), thus coming back to how numbers are implemented on the
>> chip. That's a fair point indeed, but I'm not sure how we can model
>> that formalism in RDF.
>> This is about what you talked about in
>> > if I understand correctly. It's about the fact that 0x0001 is not
>> in fact 1, but rather one of a finite set of numbers on which we've
>> defined operations, one bit meaning the sign (if using a signed-
>> aware operator) and one extra bit for the overflow.
>> I'm not sure how this applies to the DER encoding, though. For
>> example, let's say I have a 2048-bit hardware token of some sort.
>> It's likely that the tools will let me export the public key it
>> contains in DER form. If the modulus of this public key is greater
>> than or equal to 2^2047, its DER encoding will start with byte 00.
>> That ASN.1 INTEGER will thus be 2056-bit long, with the extra 00;
>> yet, the key size will still be 2048.
>> Does this mean we would need to keep the otherwise non-significant
>> 0s when serialising into RDF or perhaps have an extra property for
>> the length of the modulus (this is slightly independent of the
>> leading 00 to avoid sign problems)?
>> Best wishes,
>>> [Peter Williams] Best wishes,
>>> Story Henry wrote:
>>>> On 11 Dec 2009, at 16:19, Peter Williams wrote:
>>>>> <owl:DatatypeProperty rdf:about="cert#ISO8825-integer-DER-value">
>>>>> The encoding of an integer as a base256 encoded string as it
>>>>> the human
>>>>> readable versions of X509 keys as shown
>>>>> The integer value is the 2s complement form of the number,
>>>>> the DER canonicalization rule for primitive integer values. The
>>>>> thus of the form '00:b4:31:98:0a' (a positive number with
>>>>> leading 00 digit), 'b4:31:98:0a' (a negative number) and
>>>>> '74:31:98:0a' (a
>>>>> positive number). These strings can have newlines and spaces in
>>>>> base256 digits. Each base256 digit shall be expressed in a
>>>>> minimum of 2
>>>>> digits, where each hex digit can be either upper or lower case. The
>>>>> number of significant base256 digits shall be used. The ':' are
>>>>> </comment> <domain rdf:resource="cert#Integer"/>
>>>>> <range rdf:resource="http://www.w3.org/2001/
>>>>> <seeAlso rdf:resource="http://en.wikipedia.org/wiki/X509"/>
>>>> Very nice Peter!
>>>> That sounds like a good proposal.
>>>>> Cert#RSAPublicModulus and cert#RSAPublicExponent should be
>>>>> defined in
>>>>> of cert#ISO8825-integer-DER-value
>>>> you mean rsa:modulus and rsa:public_exponent ?
>>>> Those are relations from rsa:RSAPulicKey-s to cert:Integer-s
>>>> remember. So
>>> there is no need to define these two relations in terms of
>>>> Your property is well defined. If people want to copy and paste
>>> directly from X509 keys, they should use that. I think we just need a
>>> slightly better name.
>>>> People who write foaf+ssl tools to verify those SHOULD not do string
>>> comparisons. They should transform those into Integers and do
>>> between those integers.
>>>> This is what the Java Crypto libraries do. You have to do crypto
>>>> at that
>>> level, or else you will get lost in the huge crowd of formats out
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org
Sent from my mobile device
More information about the foaf-protocols