[foaf-protocols] rsa public key defintition

Akbar Hossain akkiehossain at googlemail.com
Thu Dec 17 08:58:37 CET 2009

I am sure the irony of fowling up on a leading zero is not lost.


Love Brunos suggestion of using reallybig numbers too.

Thanks for sharing.

On 12/17/09, Akbar Hossain <akkiehossain at googlemail.com> wrote:
> Oops i mean the first option. Which is numbered 0.
> Sorry
> On 12/17/09, Akbar Hossain <akkiehossain at googlemail.com> wrote:
>> 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
>> undesired behaviour.
>> 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.
>> Thanks
>> 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
>>> 1..infinity).
>>> (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):
>>>>                    00:bc:62:3d...
>>>> - Firefox displays it as:
>>>>    Modulus (2048 bit):
>>>>                    bc:62:3d...
>>>> 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
>>>>> the
>>>>> constraint guaranteeing uniqueness of that mapping, due to the
>>>>> inverse
>>>>> functional condition between the DER canonicalization of
>>>>> distinguished
>>>>> 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
>>>>> currently
>>>>> 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
>>>> <http://lists.foaf-project.org/pipermail/foaf-protocols/2009-December/001068.html
>>>> >.
>>>> 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
>>>>> type
>>>>> 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
>>>>> assurance
>>>>> security is always about the design of type systems and proving
>>>>> information
>>>>> flow theorems. (At higher assurance levels, one has to prove that
>>>>> the zero
>>>>> has fine-grained semantics (consistent with the design) and its
>>>>> entropy
>>>>> cannot flow except where you have declared (consistent with
>>>>> confidentiality
>>>>> 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
>>>> <http://lists.foaf-project.org/pipermail/foaf-protocols/2009-December/001134.html
>>>> > 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,
>>>> Bruno.
>>>>> [Peter Williams] Best wishes,
>>>>> Bruno.
>>>>> Story Henry wrote:
>>>>>> On 11 Dec 2009, at 16:19, Peter Williams wrote:
>>>>>>>  <owl:DatatypeProperty rdf:about="cert#ISO8825-integer-DER-value">
>>>>>>>       <rdf:type
>>>>>>> rdf:resource="http://www.w3.org/2002/07/owl#InverseFunctionalProperty
>>>>>>> "/>
>>>>>>>       <comment>
>>>>>>>   The encoding of an integer as a base256 encoded string as it
>>>>>>> appears
>>>>> in
>>>>>>> the human
>>>>>>>   readable versions of X509 keys as shown
>>>>>>> &#60;http://en.wikipedia.org/wiki/X509&#62;
>>>>>>>   The integer value is the 2s complement form of the number,
>>>>>>> satisfying
>>>>>>> the DER canonicalization rule for primitive integer values. The
>>>>>>> strings
>>>>> are
>>>>>>> thus of the form '00:b4:31:98:0a' (a positive number with
>>>>>>> significant
>>>>>>> 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
>>>>>>> between
>>>>> the
>>>>>>> base256 digits. Each base256 digit shall be expressed in a
>>>>>>> minimum of 2
>>>>> hex
>>>>>>> digits, where each hex digit can be either upper or lower case. The
>>>>> minimum
>>>>>>> number of significant base256 digits shall be used. The ':' are
>>>>>>> optional.
>>>>>>>   </comment>         <domain rdf:resource="cert#Integer"/>
>>>>>>>       <range rdf:resource="http://www.w3.org/2001/
>>>>>>> XMLSchema#String"/>
>>>>>>>       <seeAlso
>>>>> rdf:resource="http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules
>>>>> "/>
>>>>>>>       <seeAlso rdf:resource="http://en.wikipedia.org/wiki/X509"/>
>>>>>>>       <vs:term_status>unstable</vs:term_status>
>>>>>>>   </owl:DatatypeProperty>
>>>>>> Very nice Peter!
>>>>>> That sounds like a good proposal.
>>>>>>> Cert#RSAPublicModulus and cert#RSAPublicExponent should be
>>>>>>> defined in
>>>>> terms
>>>>>>> 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
>>>>> cert:ISO8825-integer-DER-value.
>>>>>> Your property is well defined. If people want to copy and paste
>>>>>> values
>>>>> 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
>>>>> comparisons
>>>>> 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
>>>>> there.
>>>>>> Henry
>>> _______________________________________________
>>> foaf-protocols mailing list
>>> foaf-protocols at lists.foaf-project.org
>>> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
>> --
>> Sent from my mobile device
> --
> Sent from my mobile device

Sent from my mobile device

More information about the foaf-protocols mailing list