From alex.gaynor at gmail.com  Fri Oct 18 12:03:03 2024
From: alex.gaynor at gmail.com (Alex Gaynor)
Date: Fri, 18 Oct 2024 12:03:03 -0400
Subject: [Cryptography-dev] PyCA cryptography 43.0.3 released
Message-ID: <CAFRnB2VHZw2ZRuf4T4cTwg-ssQWv7m5f1E+cvA+iUmq9Gh27Yg@mail.gmail.com>

PyCA cryptography 43.0.3 has been released to PyPI. cryptography
includes both high level recipes and low level interfaces to common
cryptographic algorithms such as symmetric ciphers, asymmetric
algorithms, message digests, X.509, key derivation functions, and much
more. We support Python 3.7+, and PyPy3 7.3.10+.

Changelog (https://cryptography.io/en/latest/changelog/#v43-0-3):
* Fixed compilation when using LibreSSL 4.0.0.

(Astute readers will note that this is listed as a change in 43.0.2,
that release was aborted prior to uploading to PyPI due to twine check
failures.)

Alex

-- 
All that is necessary for evil to succeed is for good people to do nothing.

From oleg.hoefling at gmail.com  Tue Oct 29 21:54:29 2024
From: oleg.hoefling at gmail.com (=?UTF-8?Q?Oleg_H=C3=B6fling?=)
Date: Wed, 30 Oct 2024 02:54:29 +0100
Subject: [Cryptography-dev] Adding support for Admissions extension
Message-ID: <CANspKnt4M2G2YdO7azx2i7oZ2ij_Zy6-aXwNDPOKZHxsq5U97w@mail.gmail.com>

Dear devs,

there is an X509 extension named `Admissions`, supported e.g. by OpenSSL (
https://docs.openssl.org/master/man3/ADMISSIONS/) and BouncyCastle (
https://people.eecs.berkeley.edu/~jonah/bc/index.html?org/bouncycastle/asn1/isismtt/x509/AdmissionSyntax.html).
Would you be interested in `cryptography` supporting it as well? This is an
extension that is used in german public healthcare and legal sectors, and I
am working for one of them :-) I really enjoy working with `cryptography`
for reading out and persisting X509 certificates, but dealing with the
`Admissions` extension requires me adding extra dependencies and writing
extra code using other libraries I do not enjoy this much.

If you agree that it could be a viable addition to the project, I would
gladly contribute the necessary bits myself. I made a proof-of-concept
implementation for the Admissions extension in my fork of `cryptography` to
have something to discuss:

https://github.com/pyca/cryptography/compare/main...hoefling:cryptography:admission-extension?expand=1

Example script that creates a certificate with an admission extension that
has some dummy values:
https://gist.github.com/hoefling/fa290eb33b24a2e5405cf9cdeeda03bc

Of course, this is far from the state where it can be reviewed, should be
split into smaller patches, is missing tests and docs etc etc.

If you reject the idea, I would try and put the code in a separate library
that depends on `cryptography` and connect them together somehow. I would
be grateful for any advices on that matter - maybe you already had a case
with a third party extension for `cryptography` being built.

Last but not least - I really enjoyed hacking the working prototype
together and fiddling with the Rust backend, kudos for having such a clear
and concise API design!

Kind regards,

Oleg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/cryptography-dev/attachments/20241030/03f886af/attachment.html>

From paul.l.kehrer at gmail.com  Tue Oct 29 22:28:51 2024
From: paul.l.kehrer at gmail.com (Paul Kehrer)
Date: Tue, 29 Oct 2024 19:28:51 -0700
Subject: [Cryptography-dev] Adding support for Admissions extension
In-Reply-To: <CANspKnt4M2G2YdO7azx2i7oZ2ij_Zy6-aXwNDPOKZHxsq5U97w@mail.gmail.com>
References: <CANspKnt4M2G2YdO7azx2i7oZ2ij_Zy6-aXwNDPOKZHxsq5U97w@mail.gmail.com>
Message-ID: <5CBF1DEE-D373-467B-ABB6-5B1D5E136461@gmail.com>

Is there a published spec that defines the ASN.1 syntax for these extensions (maybe from BSI)? We generally like to have a specification that we can use as a source of truth. For x509 I don?t have any objection to adding this assuming a spec exists.

-Paul

> On Oct 29, 2024, at 6:54?PM, Oleg H?fling via Cryptography-dev <cryptography-dev at python.org> wrote:
> 
> ?
> Dear devs,
> 
> there is an X509 extension named `Admissions`, supported e.g. by OpenSSL (https://docs.openssl.org/master/man3/ADMISSIONS/) and BouncyCastle (https://people.eecs.berkeley.edu/~jonah/bc/index.html?org/bouncycastle/asn1/isismtt/x509/AdmissionSyntax.html). Would you be interested in `cryptography` supporting it as well? This is an extension that is used in german public healthcare and legal sectors, and I am working for one of them :-) I really enjoy working with `cryptography` for reading out and persisting X509 certificates, but dealing with the `Admissions` extension requires me adding extra dependencies and writing extra code using other libraries I do not enjoy this much.
> 
> If you agree that it could be a viable addition to the project, I would gladly contribute the necessary bits myself. I made a proof-of-concept implementation for the Admissions extension in my fork of `cryptography` to have something to discuss:
> 
> https://github.com/pyca/cryptography/compare/main...hoefling:cryptography:admission-extension?expand=1
> 
> Example script that creates a certificate with an admission extension that has some dummy values: https://gist.github.com/hoefling/fa290eb33b24a2e5405cf9cdeeda03bc
> 
> Of course, this is far from the state where it can be reviewed, should be split into smaller patches, is missing tests and docs etc etc.
> 
> If you reject the idea, I would try and put the code in a separate library that depends on `cryptography` and connect them together somehow. I would be grateful for any advices on that matter - maybe you already had a case with a third party extension for `cryptography` being built.
> 
> Last but not least - I really enjoyed hacking the working prototype together and fiddling with the Rust backend, kudos for having such a clear and concise API design!
> 
> Kind regards,
> 
> Oleg
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/cryptography-dev/attachments/20241029/fe6a770f/attachment.html>

From rgm at htt-consult.com  Tue Oct 29 22:57:02 2024
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Tue, 29 Oct 2024 22:57:02 -0400
Subject: [Cryptography-dev] Adding support for Admissions extension
In-Reply-To: <5CBF1DEE-D373-467B-ABB6-5B1D5E136461@gmail.com>
References: <CANspKnt4M2G2YdO7azx2i7oZ2ij_Zy6-aXwNDPOKZHxsq5U97w@mail.gmail.com>
 <5CBF1DEE-D373-467B-ABB6-5B1D5E136461@gmail.com>
Message-ID: <6b589070-e04c-45e2-b664-b5f98b369865@htt-consult.com>

Can you do a print out of such a cert with say:

openssl x509 -in whatever.pem -text -noout

?

And perhaps an ASN.1 dump:


openssl asn1parse -i -in whatever.pem

I am curious as to what this extension looks like.? It is not in rfc5280 
and wonder if it was ever published in an rfc (which is the common 
practice when pushing a new extension for common use).

BTW, I worked in the IETF PKIX workgroup back in the day...

On 10/29/24 22:28, Paul Kehrer via Cryptography-dev wrote:
> Is there a published spec that defines the ASN.1 syntax for these 
> extensions (maybe from BSI)? We generally like to have a specification 
> that we can use as a source of truth. For x509 I don?t have any 
> objection to adding this assuming a spec exists.
>
> -Paul
>
>> On Oct 29, 2024, at 6:54?PM, Oleg H?fling via Cryptography-dev 
>> <cryptography-dev at python.org> wrote:
>>
>> ?
>> Dear devs,
>>
>> there is an X509 extension named `Admissions`, supported e.g. by 
>> OpenSSL (https://docs.openssl.org/master/man3/ADMISSIONS/) and 
>> BouncyCastle 
>> (https://people.eecs.berkeley.edu/~jonah/bc/index.html?org/bouncycastle/asn1/isismtt/x509/AdmissionSyntax.html). 
>> Would you be interested in `cryptography` supporting it as well? This 
>> is an extension that is used in german public healthcare and legal 
>> sectors, and I am working for one of them :-) I really enjoy working 
>> with `cryptography` for reading out and persisting X509 certificates, 
>> but dealing with the `Admissions` extension requires me adding extra 
>> dependencies and writing extra code using other libraries I do not 
>> enjoy this much.
>>
>> If you agree that it could be a viable addition to the project, I 
>> would gladly contribute the necessary bits myself. I made a 
>> proof-of-concept implementation for the Admissions extension in my 
>> fork of `cryptography` to have something to discuss:
>>
>> https://github.com/pyca/cryptography/compare/main...hoefling:cryptography:admission-extension?expand=1
>>
>> Example script that creates a certificate with an admission extension 
>> that has some dummy values: 
>> https://gist.github.com/hoefling/fa290eb33b24a2e5405cf9cdeeda03bc
>>
>> Of course, this is far from the state where it can be reviewed, 
>> should be split into smaller patches, is missing tests and docs etc etc.
>>
>> If you reject the idea, I would try and put the code in a separate 
>> library that depends on `cryptography` and connect them together 
>> somehow. I would be grateful for any advices on that matter - maybe 
>> you already had a case with a third party extension for 
>> `cryptography` being built.
>>
>> Last but not least - I really enjoyed hacking the working prototype 
>> together and fiddling with the Rust backend, kudos for having such a 
>> clear and concise API design!
>>
>> Kind regards,
>>
>> Oleg
>> _______________________________________________
>> Cryptography-dev mailing list
>> Cryptography-dev at python.org
>> https://mail.python.org/mailman/listinfo/cryptography-dev
>
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev


From oleg.hoefling at gmail.com  Wed Oct 30 09:06:11 2024
From: oleg.hoefling at gmail.com (=?UTF-8?Q?Oleg_H=C3=B6fling?=)
Date: Wed, 30 Oct 2024 14:06:11 +0100
Subject: [Cryptography-dev] Adding support for Admissions extension
In-Reply-To: <6b589070-e04c-45e2-b664-b5f98b369865@htt-consult.com>
References: <CANspKnt4M2G2YdO7azx2i7oZ2ij_Zy6-aXwNDPOKZHxsq5U97w@mail.gmail.com>
 <5CBF1DEE-D373-467B-ABB6-5B1D5E136461@gmail.com>
 <6b589070-e04c-45e2-b664-b5f98b369865@htt-consult.com>
Message-ID: <CANspKnsAXvbjzzNT0J7LBLC-T_4TDTXiVOuyQ5kyTdZwrt7ypA@mail.gmail.com>

I hope I won't be fired for publishing the certificates out in the wild :-)
so I'll try to black out the unrelated parts. BIO print:
```
openssl x509 -in certfile -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: XXX (0xXXX)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=DE, O=Orga, OU=OrgaUnit, CN=Authority
        Validity
            Not Before: Oct 16 10:31:30 2024 GMT
            Not After : Jul 22 10:22:29 2026 GMT
        Subject: C=DE, serialNumber=99.99999999999 + GN=spam + SN=eggs +
CN=bacon
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    XXX
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Extended Key Usage:
                TLS Web Client Authentication, E-mail Protection
            X509v3 Authority Key Identifier:
                XXX
            Professional Information or basis for Admission:
                admissionAuthority:
                  DirName:C = DE, O = Authority
                Entry 1:
                  Profession Info Entry 1:
                    registrationNumber: 9-99.9.9999999999.99.999
                    Info Entries:
                      Apotheker/-in
                    Profession OIDs:
                      undefined (1.2.276.0.76.4.32)

            Authority Information Access:
                OCSP - URI:http://example.com
            X509v3 Certificate Policies:
                Policy: 1.2.276.0.76.4.145
                  CPS:
https://www.abda.de/themen/positionen-und-initiativen/telematik/hba/
                Policy: 1.2.276.0.76.4.75
            X509v3 CRL Distribution Points:
                Full Name:
                  URI:ldap://
example.com/CN=XXX,O=XXX,C=DE?certificaterevocationlist
            X509v3 Subject Key Identifier:
                XXX
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Subject Alternative Name:
                email:spam at eggs.com
            X509v3 Basic Constraints: critical
                CA:FALSE
    Signature Algorithm: sha256WithRSAEncryption
    Signature Value:
        XXX
```
The OIDs in the 1.2.276.0.76.4 range are available in public in the spec
https://gemspec.gematik.de/downloads/gemSpec/gemSpec_OID/gemSpec_OID_V3.17.0.pdf

ASN.1 dump:
```
    0:d=0  hl=4 l=1614 cons: SEQUENCE
    4:d=1  hl=4 l=1334 cons:  SEQUENCE
    8:d=2  hl=2 l=   3 cons:   cont [ 0 ]
   10:d=3  hl=2 l=   1 prim:    INTEGER           :02
   13:d=2  hl=2 l=   3 prim:   INTEGER           :XXX
   18:d=2  hl=2 l=  13 cons:   SEQUENCE
   20:d=3  hl=2 l=   9 prim:    OBJECT            :sha256WithRSAEncryption
   31:d=3  hl=2 l=   0 prim:    NULL
   33:d=2  hl=3 l= 140 cons:   SEQUENCE
   36:d=3  hl=2 l=  11 cons:    SET
   38:d=4  hl=2 l=   9 cons:     SEQUENCE
   40:d=5  hl=2 l=   3 prim:      OBJECT            :countryName
   45:d=5  hl=2 l=   2 prim:      PRINTABLESTRING   :DE
   49:d=3  hl=2 l=  31 cons:    SET
   51:d=4  hl=2 l=  29 cons:     SEQUENCE
   53:d=5  hl=2 l=   3 prim:      OBJECT            :organizationName
   58:d=5  hl=2 l=  22 prim:      UTF8STRING        :Orga
   82:d=3  hl=2 l=  56 cons:    SET
   84:d=4  hl=2 l=  54 cons:     SEQUENCE
   86:d=5  hl=2 l=   3 prim:      OBJECT            :organizationalUnitName
   91:d=5  hl=2 l=  47 prim:      UTF8STRING        :OrgaUnit
  140:d=3  hl=2 l=  34 cons:    SET
  142:d=4  hl=2 l=  32 cons:     SEQUENCE
  144:d=5  hl=2 l=   3 prim:      OBJECT            :commonName
  149:d=5  hl=2 l=  25 prim:      UTF8STRING        :Authority
  176:d=2  hl=2 l=  30 cons:   SEQUENCE
  178:d=3  hl=2 l=  13 prim:    UTCTIME           :241016103130Z
  193:d=3  hl=2 l=  13 prim:    UTCTIME           :260722102229Z
  208:d=2  hl=3 l= 211 cons:   SEQUENCE
  211:d=3  hl=2 l=  11 cons:    SET
  213:d=4  hl=2 l=   9 cons:     SEQUENCE
  215:d=5  hl=2 l=   3 prim:      OBJECT            :countryName
  220:d=5  hl=2 l=   2 prim:      PRINTABLESTRING   :DE
  224:d=3  hl=3 l= 195 cons:    SET
  227:d=4  hl=2 l=  30 cons:     SEQUENCE
  229:d=5  hl=2 l=   3 prim:      OBJECT            :serialNumber
  234:d=5  hl=2 l=  23 prim:      PRINTABLESTRING   :99.99999999999
  259:d=4  hl=2 l=  30 cons:     SEQUENCE
  261:d=5  hl=2 l=   3 prim:      OBJECT            :givenName
  266:d=5  hl=2 l=  23 prim:      UTF8STRING        :spam
  291:d=4  hl=2 l=  48 cons:     SEQUENCE
  293:d=5  hl=2 l=   3 prim:      OBJECT            :surname
  298:d=5  hl=2 l=  41 prim:      UTF8STRING        :eggs
  341:d=4  hl=2 l=  79 cons:     SEQUENCE
  343:d=5  hl=2 l=   3 prim:      OBJECT            :commonName
  348:d=5  hl=2 l=  72 prim:      UTF8STRING        :bacon
  422:d=2  hl=4 l= 290 cons:   SEQUENCE
  426:d=3  hl=2 l=  13 cons:    SEQUENCE
  428:d=4  hl=2 l=   9 prim:     OBJECT            :rsaEncryption
  439:d=4  hl=2 l=   0 prim:     NULL
  441:d=3  hl=4 l= 271 prim:    BIT STRING
  716:d=2  hl=4 l= 622 cons:   cont [ 3 ]
  720:d=3  hl=4 l= 618 cons:    SEQUENCE
  724:d=4  hl=2 l=  29 cons:     SEQUENCE
  726:d=5  hl=2 l=   3 prim:      OBJECT            :X509v3 Extended Key
Usage
  731:d=5  hl=2 l=  22 prim:      OCTET STRING      [HEX
DUMP]:301406082B0601050507030206082B06010505070304
  755:d=4  hl=2 l=  31 cons:     SEQUENCE
  757:d=5  hl=2 l=   3 prim:      OBJECT            :X509v3 Authority Key
Identifier
  762:d=5  hl=2 l=  24 prim:      OCTET STRING      [HEX DUMP]:XXX
  788:d=4  hl=2 l= 126 cons:     SEQUENCE
  790:d=5  hl=2 l=   5 prim:      OBJECT            :Professional
Information or basis for Admission
  797:d=5  hl=2 l= 117 prim:      OCTET STRING      [HEX
DUMP]:3073A4333031310B300906035504061302444531223020060355040A0C1941706F7468656B65726B616D6D6572204E6F7264726865696E303C303A30383036300F0C0D41706F7468656B65722F2D696E300906072A8214004C04201318332D31302E332E323135343131313038332E31302E323234
  916:d=4  hl=2 l=  59 cons:     SEQUENCE
  918:d=5  hl=2 l=   8 prim:      OBJECT            :Authority Information
Access
  928:d=5  hl=2 l=  47 prim:      OCTET STRING      [HEX DUMP]:XXX
  977:d=4  hl=2 l= 116 cons:     SEQUENCE
  979:d=5  hl=2 l=   3 prim:      OBJECT            :X509v3 Certificate
Policies
  984:d=5  hl=2 l= 109 prim:      OCTET STRING      [HEX
DUMP]:306B305E06082A8214004C0481113052305006082B06010505070201164468747470733A2F2F7777772E616264612E64652F7468656D656E2F706F736974696F6E656E2D756E642D696E69746961746976656E2F74656C656D6174696B2F6862612F300906072A8214004C044B
 1095:d=4  hl=3 l= 137 cons:     SEQUENCE
 1098:d=5  hl=2 l=   3 prim:      OBJECT            :X509v3 CRL
Distribution Points
 1103:d=5  hl=3 l= 129 prim:      OCTET STRING      [HEX DUMP]:XXX
 1235:d=4  hl=2 l=  29 cons:     SEQUENCE
 1237:d=5  hl=2 l=   3 prim:      OBJECT            :X509v3 Subject Key
Identifier
 1242:d=5  hl=2 l=  22 prim:      OCTET STRING      [HEX DUMP]:XXX
 1266:d=4  hl=2 l=  14 cons:     SEQUENCE
 1268:d=5  hl=2 l=   3 prim:      OBJECT            :X509v3 Key Usage
 1273:d=5  hl=2 l=   1 prim:      BOOLEAN           :255
 1276:d=5  hl=2 l=   4 prim:      OCTET STRING      [HEX DUMP]:030205A0
 1282:d=4  hl=2 l=  44 cons:     SEQUENCE
 1284:d=5  hl=2 l=   3 prim:      OBJECT            :X509v3 Subject
Alternative Name
 1289:d=5  hl=2 l=  37 prim:      OCTET STRING      [HEX DUMP]:XXX
 1328:d=4  hl=2 l=  12 cons:     SEQUENCE
 1330:d=5  hl=2 l=   3 prim:      OBJECT            :X509v3 Basic
Constraints
 1335:d=5  hl=2 l=   1 prim:      BOOLEAN           :255
 1338:d=5  hl=2 l=   2 prim:      OCTET STRING      [HEX DUMP]:3000
 1342:d=1  hl=2 l=  13 cons:  SEQUENCE
 1344:d=2  hl=2 l=   9 prim:   OBJECT            :sha256WithRSAEncryption
 1355:d=2  hl=2 l=   0 prim:   NULL
 1357:d=1  hl=4 l= 257 prim:  BIT STRING
```

Am Mi., 30. Okt. 2024 um 04:06 Uhr schrieb Robert Moskowitz <
rgm at htt-consult.com>:

> Can you do a print out of such a cert with say:
>
> openssl x509 -in whatever.pem -text -noout
>
> ?
>
> And perhaps an ASN.1 dump:
>
>
> openssl asn1parse -i -in whatever.pem
>
> I am curious as to what this extension looks like.  It is not in rfc5280
> and wonder if it was ever published in an rfc (which is the common
> practice when pushing a new extension for common use).
>
> BTW, I worked in the IETF PKIX workgroup back in the day...
>
> On 10/29/24 22:28, Paul Kehrer via Cryptography-dev wrote:
> > Is there a published spec that defines the ASN.1 syntax for these
> > extensions (maybe from BSI)? We generally like to have a specification
> > that we can use as a source of truth. For x509 I don?t have any
> > objection to adding this assuming a spec exists.
> >
> > -Paul
> >
> >> On Oct 29, 2024, at 6:54?PM, Oleg H?fling via Cryptography-dev
> >> <cryptography-dev at python.org> wrote:
> >>
> >> ?
> >> Dear devs,
> >>
> >> there is an X509 extension named `Admissions`, supported e.g. by
> >> OpenSSL (https://docs.openssl.org/master/man3/ADMISSIONS/) and
> >> BouncyCastle
> >> (
> https://people.eecs.berkeley.edu/~jonah/bc/index.html?org/bouncycastle/asn1/isismtt/x509/AdmissionSyntax.html).
>
> >> Would you be interested in `cryptography` supporting it as well? This
> >> is an extension that is used in german public healthcare and legal
> >> sectors, and I am working for one of them :-) I really enjoy working
> >> with `cryptography` for reading out and persisting X509 certificates,
> >> but dealing with the `Admissions` extension requires me adding extra
> >> dependencies and writing extra code using other libraries I do not
> >> enjoy this much.
> >>
> >> If you agree that it could be a viable addition to the project, I
> >> would gladly contribute the necessary bits myself. I made a
> >> proof-of-concept implementation for the Admissions extension in my
> >> fork of `cryptography` to have something to discuss:
> >>
> >>
> https://github.com/pyca/cryptography/compare/main...hoefling:cryptography:admission-extension?expand=1
> >>
> >> Example script that creates a certificate with an admission extension
> >> that has some dummy values:
> >> https://gist.github.com/hoefling/fa290eb33b24a2e5405cf9cdeeda03bc
> >>
> >> Of course, this is far from the state where it can be reviewed,
> >> should be split into smaller patches, is missing tests and docs etc etc.
> >>
> >> If you reject the idea, I would try and put the code in a separate
> >> library that depends on `cryptography` and connect them together
> >> somehow. I would be grateful for any advices on that matter - maybe
> >> you already had a case with a third party extension for
> >> `cryptography` being built.
> >>
> >> Last but not least - I really enjoyed hacking the working prototype
> >> together and fiddling with the Rust backend, kudos for having such a
> >> clear and concise API design!
> >>
> >> Kind regards,
> >>
> >> Oleg
> >> _______________________________________________
> >> Cryptography-dev mailing list
> >> Cryptography-dev at python.org
> >> https://mail.python.org/mailman/listinfo/cryptography-dev
> >
> > _______________________________________________
> > Cryptography-dev mailing list
> > Cryptography-dev at python.org
> > https://mail.python.org/mailman/listinfo/cryptography-dev
>
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/cryptography-dev/attachments/20241030/afc382e6/attachment-0001.html>

From rgm at htt-consult.com  Wed Oct 30 09:36:22 2024
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Wed, 30 Oct 2024 09:36:22 -0400
Subject: [Cryptography-dev] Adding support for Admissions extension
In-Reply-To: <CANspKnsAXvbjzzNT0J7LBLC-T_4TDTXiVOuyQ5kyTdZwrt7ypA@mail.gmail.com>
References: <CANspKnt4M2G2YdO7azx2i7oZ2ij_Zy6-aXwNDPOKZHxsq5U97w@mail.gmail.com>
 <5CBF1DEE-D373-467B-ABB6-5B1D5E136461@gmail.com>
 <6b589070-e04c-45e2-b664-b5f98b369865@htt-consult.com>
 <CANspKnsAXvbjzzNT0J7LBLC-T_4TDTXiVOuyQ5kyTdZwrt7ypA@mail.gmail.com>
Message-ID: <ab01590f-08c7-458d-8c59-1568b0ade77a@htt-consult.com>

Well, to some extent certificates are suppose to be public.? But then I 
often deal with those that are kept out of the public's view...

It looks like this is an ITU standard from at least 2010. Unfortunately 
the dump is not showing the actual OID for the "Professional Information 
or basis for Admission:".? But I did see that it's content is suppose to 
be generalName.

In many ways I kind of hate putting such information into the cert and 
that it should be external to the cert management structure. That is how 
we do it in Aviation, but Health Care always seemed to have its own set 
of drivers.

Given how this seems to be an ITU standard (would be nice to have the 
exact one(s)), and it seems to "just" be using generalName, it seems 
valid for the powers that be here to add its support.

Like I said, I don't like this approach, but it was done long ago. I 
have to send certs over very constrained wireless links and cringe on 
how policy people think they can override laws of Physics (20Kg in a 1Kg 
bag kind of stuff).

Professionally, this is good to know.? It is NOT in the Aviation 
Certificate Policy we are doing in ICAO.? But it may creep in via 
EUROCONTROL people.? I will have to dig into this at the upcoming ICAO 
meeting.

And just an aside that using RSA 2048 is not such a good idea for use 
anymore (and in Health Care?).? I am using EdDSA25519.? It has some 
resistance to attacks that ECDSA does not have, it fits over our 
wireless links, and is stronger than your 2048 keys.? But then we have 
legacy 4096 keys in Aviation and have to include support for them in our CP.



On 10/30/24 09:06, Oleg H?fling via Cryptography-dev wrote:
> I hope I won't be fired for publishing the certificates out in the 
> wild :-) so I'll try to black out the unrelated parts. BIO print:
> ```
> openssl x509 -in certfile -noout -text
> Certificate:
> ? ? Data:
> ? ? ? ? Version: 3 (0x2)
> ? ? ? ? Serial Number: XXX (0xXXX)
> ? ? ? ? Signature Algorithm: sha256WithRSAEncryption
> ? ? ? ? Issuer: C=DE, O=Orga, OU=OrgaUnit, CN=Authority
> ? ? ? ? Validity
> ? ? ? ? ? ? Not Before: Oct 16 10:31:30 2024 GMT
> ? ? ? ? ? ? Not After : Jul 22 10:22:29 2026 GMT
> ? ? ? ? Subject: C=DE, serialNumber=99.99999999999 + GN=spam + SN=eggs 
> + CN=bacon
> ? ? ? ? Subject Public Key Info:
> ? ? ? ? ? ? Public Key Algorithm: rsaEncryption
> ? ? ? ? ? ? ? ? Public-Key: (2048 bit)
> ? ? ? ? ? ? ? ? Modulus:
> ? ? ? ? ? ? ? ? ? ? XXX
> ? ? ? ? ? ? ? ? Exponent: 65537 (0x10001)
> ? ? ? ? X509v3 extensions:
> ? ? ? ? ? ? X509v3 Extended Key Usage:
> ? ? ? ? ? ? ? ? TLS Web Client Authentication, E-mail Protection
> ? ? ? ? ? ? X509v3 Authority Key Identifier:
> ? ? ? ? ? ? ? ? XXX
> ? ? ? ? ? ? Professional Information or basis for Admission:
> ? ? ? ? ? ? ? ? admissionAuthority:
> ? ? ? ? ? ? ? ? ? DirName:C = DE, O = Authority
> ? ? ? ? ? ? ? ? Entry 1:
> ? ? ? ? ? ? ? ? ? Profession Info Entry 1:
> ? ? ? ? ? ? ? ? ? ? registrationNumber: 9-99.9.9999999999.99.999
> ? ? ? ? ? ? ? ? ? ? Info Entries:
> ? ? ? ? ? ? ? ? ? ? ? Apotheker/-in
> ? ? ? ? ? ? ? ? ? ? Profession OIDs:
> ? ? ? ? ? ? ? ? ? ? ? undefined (1.2.276.0.76.4.32)
>
> ? ? ? ? ? ? Authority Information Access:
> ? ? ? ? ? ? ? ? OCSP - URI:http://example.com
> ? ? ? ? ? ? X509v3 Certificate Policies:
> ? ? ? ? ? ? ? ? Policy: 1.2.276.0.76.4.145
> ? ? ? ? ? ? ? ? ? CPS: 
> https://www.abda.de/themen/positionen-und-initiativen/telematik/hba/
> ? ? ? ? ? ? ? ? Policy: 1.2.276.0.76.4.75
> ? ? ? ? ? ? X509v3 CRL Distribution Points:
> ? ? ? ? ? ? ? ? Full Name:
> ? ? ? ? ? ? ? ? ? 
> URI:ldap://example.com/CN=XXX,O=XXX,C=DE?certificaterevocationlist 
> <http://example.com/CN=XXX,O=XXX,C=DE?certificaterevocationlist>
> ? ? ? ? ? ? X509v3 Subject Key Identifier:
> ? ? ? ? ? ? ? ? XXX
> ? ? ? ? ? ? X509v3 Key Usage: critical
> ? ? ? ? ? ? ? ? Digital Signature, Key Encipherment
> ? ? ? ? ? ? X509v3 Subject Alternative Name:
> email:spam at eggs.com <mailto:email%3Aspam at eggs.com>
> ? ? ? ? ? ? X509v3 Basic Constraints: critical
> ? ? ? ? ? ? ? ? CA:FALSE
> ? ? Signature Algorithm: sha256WithRSAEncryption
> ? ? Signature Value:
> ? ? ? ? XXX
> ```
> The OIDs in the 1.2.276.0.76.4 range are available in public in the 
> spec 
> https://gemspec.gematik.de/downloads/gemSpec/gemSpec_OID/gemSpec_OID_V3.17.0.pdf
>
> ASN.1 dump:
> ```
> ? ? 0:d=0 ?hl=4 l=1614 cons: SEQUENCE
> ? ? 4:d=1 ?hl=4 l=1334 cons: ?SEQUENCE
> ? ? 8:d=2 ?hl=2 l= ? 3 cons: ? cont [ 0 ]
> ? ?10:d=3 ?hl=2 l= ? 1 prim: ? ?INTEGER ? ? ? ? ? :02
> ? ?13:d=2 ?hl=2 l= ? 3 prim: ? INTEGER ? ? ? ? ? :XXX
> ? ?18:d=2 ?hl=2 l= ?13 cons: ? SEQUENCE
> ? ?20:d=3 ?hl=2 l= ? 9 prim: ? ?OBJECT ?:sha256WithRSAEncryption
> ? ?31:d=3 ?hl=2 l= ? 0 prim: ? ?NULL
> ? ?33:d=2 ?hl=3 l= 140 cons: ? SEQUENCE
> ? ?36:d=3 ?hl=2 l= ?11 cons: ? ?SET
> ? ?38:d=4 ?hl=2 l= ? 9 cons: ? ? SEQUENCE
> ? ?40:d=5 ?hl=2 l= ? 3 prim: ? ? ?OBJECT ?:countryName
> ? ?45:d=5 ?hl=2 l= ? 2 prim: ? ? ?PRINTABLESTRING ? :DE
> ? ?49:d=3 ?hl=2 l= ?31 cons: ? ?SET
> ? ?51:d=4 ?hl=2 l= ?29 cons: ? ? SEQUENCE
> ? ?53:d=5 ?hl=2 l= ? 3 prim: ? ? ?OBJECT ?:organizationName
> ? ?58:d=5 ?hl=2 l= ?22 prim: ? ? ?UTF8STRING ? ? ? ?:Orga
> ? ?82:d=3 ?hl=2 l= ?56 cons: ? ?SET
> ? ?84:d=4 ?hl=2 l= ?54 cons: ? ? SEQUENCE
> ? ?86:d=5 ?hl=2 l= ? 3 prim: ? ? ?OBJECT ?:organizationalUnitName
> ? ?91:d=5 ?hl=2 l= ?47 prim: ? ? ?UTF8STRING ?:OrgaUnit
> ? 140:d=3 ?hl=2 l= ?34 cons: ? ?SET
> ? 142:d=4 ?hl=2 l= ?32 cons: ? ? SEQUENCE
> ? 144:d=5 ?hl=2 l= ? 3 prim: ? ? ?OBJECT ?:commonName
> ? 149:d=5 ?hl=2 l= ?25 prim: ? ? ?UTF8STRING ?:Authority
> ? 176:d=2 ?hl=2 l= ?30 cons: ? SEQUENCE
> ? 178:d=3 ?hl=2 l= ?13 prim: ? ?UTCTIME :241016103130Z
> ? 193:d=3 ?hl=2 l= ?13 prim: ? ?UTCTIME :260722102229Z
> ? 208:d=2 ?hl=3 l= 211 cons: ? SEQUENCE
> ? 211:d=3 ?hl=2 l= ?11 cons: ? ?SET
> ? 213:d=4 ?hl=2 l= ? 9 cons: ? ? SEQUENCE
> ? 215:d=5 ?hl=2 l= ? 3 prim: ? ? ?OBJECT ?:countryName
> ? 220:d=5 ?hl=2 l= ? 2 prim: ? ? ?PRINTABLESTRING ? :DE
> ? 224:d=3 ?hl=3 l= 195 cons: ? ?SET
> ? 227:d=4 ?hl=2 l= ?30 cons: ? ? SEQUENCE
> ? 229:d=5 ?hl=2 l= ? 3 prim: ? ? ?OBJECT ?:serialNumber
> ? 234:d=5 ?hl=2 l= ?23 prim: ? ? ?PRINTABLESTRING :99.99999999999
> ? 259:d=4 ?hl=2 l= ?30 cons: ? ? SEQUENCE
> ? 261:d=5 ?hl=2 l= ? 3 prim: ? ? ?OBJECT ?:givenName
> ? 266:d=5 ?hl=2 l= ?23 prim: ? ? ?UTF8STRING ? ? ? ?:spam
> ? 291:d=4 ?hl=2 l= ?48 cons: ? ? SEQUENCE
> ? 293:d=5 ?hl=2 l= ? 3 prim: ? ? ?OBJECT ? ? ? ? ? ?:surname
> ? 298:d=5 ?hl=2 l= ?41 prim: ? ? ?UTF8STRING ? ? ? ?:eggs
> ? 341:d=4 ?hl=2 l= ?79 cons: ? ? SEQUENCE
> ? 343:d=5 ?hl=2 l= ? 3 prim: ? ? ?OBJECT ?:commonName
> ? 348:d=5 ?hl=2 l= ?72 prim: ? ? ?UTF8STRING ? ? ? ?:bacon
> ? 422:d=2 ?hl=4 l= 290 cons: ? SEQUENCE
> ? 426:d=3 ?hl=2 l= ?13 cons: ? ?SEQUENCE
> ? 428:d=4 ?hl=2 l= ? 9 prim: ? ? OBJECT ?:rsaEncryption
> ? 439:d=4 ?hl=2 l= ? 0 prim: ? ? NULL
> ? 441:d=3 ?hl=4 l= 271 prim: ? ?BIT STRING
> ? 716:d=2 ?hl=4 l= 622 cons: ? cont [ 3 ]
> ? 720:d=3 ?hl=4 l= 618 cons: ? ?SEQUENCE
> ? 724:d=4 ?hl=2 l= ?29 cons: ? ? SEQUENCE
> ? 726:d=5 ?hl=2 l= ? 3 prim: ? ? ?OBJECT ? ? ? ? ? ?:X509v3 Extended 
> Key Usage
> ? 731:d=5 ?hl=2 l= ?22 prim: ? ? ?OCTET STRING ? ? ?[HEX 
> DUMP]:301406082B0601050507030206082B06010505070304
> ? 755:d=4 ?hl=2 l= ?31 cons: ? ? SEQUENCE
> ? 757:d=5 ?hl=2 l= ? 3 prim: ? ? ?OBJECT ? ? ? ? ? ?:X509v3 Authority 
> Key Identifier
> ? 762:d=5 ?hl=2 l= ?24 prim: ? ? ?OCTET STRING ? ? ?[HEX DUMP]:XXX
> ? 788:d=4 ?hl=2 l= 126 cons: ? ? SEQUENCE
> ? 790:d=5 ?hl=2 l= ? 5 prim: ? ? ?OBJECT ?:Professional Information or 
> basis for Admission
> ? 797:d=5 ?hl=2 l= 117 prim: ? ? ?OCTET STRING ? ? ?[HEX 
> DUMP]:3073A4333031310B300906035504061302444531223020060355040A0C1941706F7468656B65726B616D6D6572204E6F7264726865696E303C303A30383036300F0C0D41706F7468656B65722F2D696E300906072A8214004C04201318332D31302E332E323135343131313038332E31302E323234
> ? 916:d=4 ?hl=2 l= ?59 cons: ? ? SEQUENCE
> ? 918:d=5 ?hl=2 l= ? 8 prim: ? ? ?OBJECT ?:Authority Information Access
> ? 928:d=5 ?hl=2 l= ?47 prim: ? ? ?OCTET STRING ? ? ?[HEX DUMP]:XXX
> ? 977:d=4 ?hl=2 l= 116 cons: ? ? SEQUENCE
> ? 979:d=5 ?hl=2 l= ? 3 prim: ? ? ?OBJECT ? ? ? ? ? ?:X509v3 
> Certificate Policies
> ? 984:d=5 ?hl=2 l= 109 prim: ? ? ?OCTET STRING ? ? ?[HEX 
> DUMP]:306B305E06082A8214004C0481113052305006082B06010505070201164468747470733A2F2F7777772E616264612E64652F7468656D656E2F706F736974696F6E656E2D756E642D696E69746961746976656E2F74656C656D6174696B2F6862612F300906072A8214004C044B
> ?1095:d=4 ?hl=3 l= 137 cons: ? ? SEQUENCE
> ?1098:d=5 ?hl=2 l= ? 3 prim: ? ? ?OBJECT ? ? ? ? ? ?:X509v3 CRL 
> Distribution Points
> ?1103:d=5 ?hl=3 l= 129 prim: ? ? ?OCTET STRING ? ? ?[HEX DUMP]:XXX
> ?1235:d=4 ?hl=2 l= ?29 cons: ? ? SEQUENCE
> ?1237:d=5 ?hl=2 l= ? 3 prim: ? ? ?OBJECT ? ? ? ? ? ?:X509v3 Subject 
> Key Identifier
> ?1242:d=5 ?hl=2 l= ?22 prim: ? ? ?OCTET STRING ? ? ?[HEX DUMP]:XXX
> ?1266:d=4 ?hl=2 l= ?14 cons: ? ? SEQUENCE
> ?1268:d=5 ?hl=2 l= ? 3 prim: ? ? ?OBJECT ? ? ? ? ? ?:X509v3 Key Usage
> ?1273:d=5 ?hl=2 l= ? 1 prim: ? ? ?BOOLEAN ? ? ? ? ? :255
> ?1276:d=5 ?hl=2 l= ? 4 prim: ? ? ?OCTET STRING ? ? ?[HEX DUMP]:030205A0
> ?1282:d=4 ?hl=2 l= ?44 cons: ? ? SEQUENCE
> ?1284:d=5 ?hl=2 l= ? 3 prim: ? ? ?OBJECT ? ? ? ? ? ?:X509v3 Subject 
> Alternative Name
> ?1289:d=5 ?hl=2 l= ?37 prim: ? ? ?OCTET STRING ? ? ?[HEX DUMP]:XXX
> ?1328:d=4 ?hl=2 l= ?12 cons: ? ? SEQUENCE
> ?1330:d=5 ?hl=2 l= ? 3 prim: ? ? ?OBJECT ? ? ? ? ? ?:X509v3 Basic 
> Constraints
> ?1335:d=5 ?hl=2 l= ? 1 prim: ? ? ?BOOLEAN ? ? ? ? ? :255
> ?1338:d=5 ?hl=2 l= ? 2 prim: ? ? ?OCTET STRING ? ? ?[HEX DUMP]:3000
> ?1342:d=1 ?hl=2 l= ?13 cons: ?SEQUENCE
> ?1344:d=2 ?hl=2 l= ? 9 prim: ? OBJECT ?:sha256WithRSAEncryption
> ?1355:d=2 ?hl=2 l= ? 0 prim: ? NULL
> ?1357:d=1 ?hl=4 l= 257 prim: ?BIT STRING
> ```
>
> Am Mi., 30. Okt. 2024 um 04:06?Uhr schrieb Robert Moskowitz 
> <rgm at htt-consult.com>:
>
>     Can you do a print out of such a cert with say:
>
>     openssl x509 -in whatever.pem -text -noout
>
>     ?
>
>     And perhaps an ASN.1 dump:
>
>
>     openssl asn1parse -i -in whatever.pem
>
>     I am curious as to what this extension looks like.? It is not in
>     rfc5280
>     and wonder if it was ever published in an rfc (which is the common
>     practice when pushing a new extension for common use).
>
>     BTW, I worked in the IETF PKIX workgroup back in the day...
>
>     On 10/29/24 22:28, Paul Kehrer via Cryptography-dev wrote:
>     > Is there a published spec that defines the ASN.1 syntax for these
>     > extensions (maybe from BSI)? We generally like to have a
>     specification
>     > that we can use as a source of truth. For x509 I don?t have any
>     > objection to adding this assuming a spec exists.
>     >
>     > -Paul
>     >
>     >> On Oct 29, 2024, at 6:54?PM, Oleg H?fling via Cryptography-dev
>     >> <cryptography-dev at python.org> wrote:
>     >>
>     >> ?
>     >> Dear devs,
>     >>
>     >> there is an X509 extension named `Admissions`, supported e.g. by
>     >> OpenSSL (https://docs.openssl.org/master/man3/ADMISSIONS/) and
>     >> BouncyCastle
>     >>
>     (https://people.eecs.berkeley.edu/~jonah/bc/index.html?org/bouncycastle/asn1/isismtt/x509/AdmissionSyntax.html).
>
>     >> Would you be interested in `cryptography` supporting it as
>     well? This
>     >> is an extension that is used in german public healthcare and legal
>     >> sectors, and I am working for one of them :-) I really enjoy
>     working
>     >> with `cryptography` for reading out and persisting X509
>     certificates,
>     >> but dealing with the `Admissions` extension requires me adding
>     extra
>     >> dependencies and writing extra code using other libraries I do not
>     >> enjoy this much.
>     >>
>     >> If you agree that it could be a viable addition to the project, I
>     >> would gladly contribute the necessary bits myself. I made a
>     >> proof-of-concept implementation for the Admissions extension in my
>     >> fork of `cryptography` to have something to discuss:
>     >>
>     >>
>     https://github.com/pyca/cryptography/compare/main...hoefling:cryptography:admission-extension?expand=1
>     >>
>     >> Example script that creates a certificate with an admission
>     extension
>     >> that has some dummy values:
>     >> https://gist.github.com/hoefling/fa290eb33b24a2e5405cf9cdeeda03bc
>     >>
>     >> Of course, this is far from the state where it can be reviewed,
>     >> should be split into smaller patches, is missing tests and docs
>     etc etc.
>     >>
>     >> If you reject the idea, I would try and put the code in a separate
>     >> library that depends on `cryptography` and connect them together
>     >> somehow. I would be grateful for any advices on that matter -
>     maybe
>     >> you already had a case with a third party extension for
>     >> `cryptography` being built.
>     >>
>     >> Last but not least - I really enjoyed hacking the working
>     prototype
>     >> together and fiddling with the Rust backend, kudos for having
>     such a
>     >> clear and concise API design!
>     >>
>     >> Kind regards,
>     >>
>     >> Oleg
>     >> _______________________________________________
>     >> Cryptography-dev mailing list
>     >> Cryptography-dev at python.org
>     >> https://mail.python.org/mailman/listinfo/cryptography-dev
>     >
>     > _______________________________________________
>     > Cryptography-dev mailing list
>     > Cryptography-dev at python.org
>     > https://mail.python.org/mailman/listinfo/cryptography-dev
>
>     _______________________________________________
>     Cryptography-dev mailing list
>     Cryptography-dev at python.org
>     https://mail.python.org/mailman/listinfo/cryptography-dev
>
>
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/cryptography-dev/attachments/20241030/8d5aa868/attachment-0001.html>

From paul.l.kehrer at gmail.com  Wed Oct 30 10:04:34 2024
From: paul.l.kehrer at gmail.com (Paul Kehrer)
Date: Wed, 30 Oct 2024 07:04:34 -0700
Subject: [Cryptography-dev] Adding support for Admissions extension
In-Reply-To: <E8B2261E-EED3-40BE-A2AD-E7D1AFC92C35@gmail.com>
References: <E8B2261E-EED3-40BE-A2AD-E7D1AFC92C35@gmail.com>
Message-ID: <52E1C180-A1E5-4E32-A27A-BAD394A7B9BD@gmail.com>

An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/cryptography-dev/attachments/20241030/3ee4041f/attachment.html>

From rgm at htt-consult.com  Wed Oct 30 10:32:29 2024
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Wed, 30 Oct 2024 10:32:29 -0400
Subject: [Cryptography-dev] Adding support for Admissions extension
In-Reply-To: <52E1C180-A1E5-4E32-A27A-BAD394A7B9BD@gmail.com>
References: <E8B2261E-EED3-40BE-A2AD-E7D1AFC92C35@gmail.com>
 <52E1C180-A1E5-4E32-A27A-BAD394A7B9BD@gmail.com>
Message-ID: <435cf2ac-b52e-4cff-aae2-ae91a87bd207@htt-consult.com>

As much as I hate ASN.1 (also shared by people on the ASN.1 committee 
back then), you got to love how easy it is to add things in ASN.1.

Perhaps one of the first "Object Oriented Data Model"?

On 10/30/24 10:04, Paul Kehrer via Cryptography-dev wrote:
> Re-sending to list since I accidentally sent this solely to Oleg! 
> Sorry about that Oleg.
>
> -Paul
>
>> On Oct 30, 2024, at 7:02?AM, Paul Kehrer <paul.l.kehrer at gmail.com> wrote:
>>
>> ?
>> We would be willing to take support for this since it?s just some 
>> asn.1 definitions and there?s a specification associated with it. If 
>> the diff is larger than 400 lines then for ease of review we?ll 
>> likely want to break this into multiple PRs, but otherwise feel free 
>> to submit and we can discuss!
>>
>> -Paul
>>
>>> On Oct 30, 2024, at 5:51?AM, Oleg H?fling <oleg.hoefling at gmail.com> 
>>> wrote:
>>>
>>> ?
>>> The spec I have at hand ist the 
>>> https://fachportal.gematik.de/fachportal-import/files/gemSpec_PKI_V2.10.2.pdf 
>>> which lists the Admission under section?4.8.3.2. Unfortunately, this 
>>> spec: 1. is written in german language and 2. is not complete, e.g. 
>>> it does not provide the ASN.1 syntax for the NamingAuthority. It is 
>>> however based on the Common PKI v2 specification which does provide 
>>> the complete ASN.1 spec (Table 29 and 29b). Link: 
>>> https://www.elektronische-vertrauensdienste.de/EVD/SharedDocuments/Downloads/QES/Common_PKI_v2.0_02.html 
>>> It is hosted by the Bundesnetzagentur as part of the eIDAS 
>>> regulation and not BSI, however I see that BSI mentions Common PKI 
>>> in its glossary here: 
>>> https://www.bsi.bund.de/DE/Themen/Oeffentliche-Verwaltung/Moderner-Staat/ElektronischeSignatur/Glossar/glossar_node.html 
>>>
>>> Don't shoot the messenger, but this is all I have at hand.
>>>
>>> Kind regards,
>>>
>>> Oleg
>>>
>>> Am Mi., 30. Okt. 2024 um 03:29?Uhr schrieb Paul Kehrer 
>>> <paul.l.kehrer at gmail.com>:
>>>
>>>     Is there a published spec that defines the ASN.1 syntax for
>>>     these extensions (maybe from BSI)? We generally like to have a
>>>     specification that we can use as a source of truth. For x509 I
>>>     don?t have any objection to adding this assuming a spec exists.
>>>
>>>     -Paul
>>>
>>>>     On Oct 29, 2024, at 6:54?PM, Oleg H?fling via Cryptography-dev
>>>>     <cryptography-dev at python.org> wrote:
>>>>
>>>>     ?
>>>>     Dear devs,
>>>>
>>>>     there is an X509 extension named `Admissions`, supported e.g.
>>>>     by OpenSSL (https://docs.openssl.org/master/man3/ADMISSIONS/)
>>>>     and BouncyCastle
>>>>     (https://people.eecs.berkeley.edu/~jonah/bc/index.html?org/bouncycastle/asn1/isismtt/x509/AdmissionSyntax.html).
>>>>     Would you be interested in `cryptography` supporting it as
>>>>     well? This is an extension that is used in german public
>>>>     healthcare and legal sectors, and I am working for one of them
>>>>     :-) I really enjoy working with `cryptography` for reading out
>>>>     and persisting X509 certificates, but dealing with the
>>>>     `Admissions` extension requires me adding extra dependencies
>>>>     and writing extra code using other libraries I do not enjoy
>>>>     this much.
>>>>
>>>>     If you agree that it could be a viable addition to the project,
>>>>     I would gladly contribute the necessary bits myself. I made a
>>>>     proof-of-concept implementation for the Admissions extension in
>>>>     my fork of `cryptography` to have something to discuss:
>>>>
>>>>     https://github.com/pyca/cryptography/compare/main...hoefling:cryptography:admission-extension?expand=1
>>>>
>>>>     Example script that creates a certificate with an admission
>>>>     extension that has some dummy values:
>>>>     https://gist.github.com/hoefling/fa290eb33b24a2e5405cf9cdeeda03bc
>>>>
>>>>     Of course, this is far from the state where it can be reviewed,
>>>>     should be split into smaller patches, is missing tests and docs
>>>>     etc etc.
>>>>
>>>>     If you reject the idea, I would try and put the code in a
>>>>     separate library that depends on `cryptography` and connect
>>>>     them together somehow. I would be grateful for any advices on
>>>>     that matter - maybe you already had a case with a third party
>>>>     extension for `cryptography` being built.
>>>>
>>>>     Last but not least - I really enjoyed hacking the working
>>>>     prototype together and fiddling with the Rust backend, kudos
>>>>     for having such a clear and concise API design!
>>>>
>>>>     Kind regards,
>>>>
>>>>     Oleg
>>>>     _______________________________________________
>>>>     Cryptography-dev mailing list
>>>>     Cryptography-dev at python.org
>>>>     https://mail.python.org/mailman/listinfo/cryptography-dev
>>>
>
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/cryptography-dev/attachments/20241030/37331f27/attachment-0001.html>

From oleg.hoefling at gmail.com  Wed Oct 30 10:53:29 2024
From: oleg.hoefling at gmail.com (=?UTF-8?Q?Oleg_H=C3=B6fling?=)
Date: Wed, 30 Oct 2024 15:53:29 +0100
Subject: [Cryptography-dev] Adding support for Admissions extension
In-Reply-To: <52E1C180-A1E5-4E32-A27A-BAD394A7B9BD@gmail.com>
References: <E8B2261E-EED3-40BE-A2AD-E7D1AFC92C35@gmail.com>
 <52E1C180-A1E5-4E32-A27A-BAD394A7B9BD@gmail.com>
Message-ID: <CANspKntCFpq8EohoSDDYyp4nfjjkjrPg=DigCjOf5XavqESBeg@mail.gmail.com>

Yay, this is awesome, thank you! I think the current branch will definitely
need splitting, most likely I will submit the changes in three separate
PRs: the types first (in `x509.extensions` on Python side and in
`x509::extensions` on the Rust side), then the parsing, then the encoding
(this implementation part I am least confident in anyway). Before
submitting the parser and encoder, I will also try to deliver certificates
for testing, so it is possible to have meaningful tests using real world
data.

Thanks again and kind regards,

Oleg

Am Mi., 30. Okt. 2024 um 15:05 Uhr schrieb Paul Kehrer via Cryptography-dev
<cryptography-dev at python.org>:

> Re-sending to list since I accidentally sent this solely to Oleg! Sorry
> about that Oleg.
>
> -Paul
>
> On Oct 30, 2024, at 7:02?AM, Paul Kehrer <paul.l.kehrer at gmail.com> wrote:
>
> ?
> We would be willing to take support for this since it?s just some asn.1
> definitions and there?s a specification associated with it. If the diff is
> larger than 400 lines then for ease of review we?ll likely want to break
> this into multiple PRs, but otherwise feel free to submit and we can
> discuss!
>
> -Paul
>
> On Oct 30, 2024, at 5:51?AM, Oleg H?fling <oleg.hoefling at gmail.com> wrote:
>
> ?
> The spec I have at hand ist the
> https://fachportal.gematik.de/fachportal-import/files/gemSpec_PKI_V2.10.2.pdf
> which lists the Admission under section 4.8.3.2. Unfortunately, this spec:
> 1. is written in german language and 2. is not complete, e.g. it does not
> provide the ASN.1 syntax for the NamingAuthority. It is however based on
> the Common PKI v2 specification which does provide the complete ASN.1 spec
> (Table 29 and 29b). Link:
> https://www.elektronische-vertrauensdienste.de/EVD/SharedDocuments/Downloads/QES/Common_PKI_v2.0_02.html
> It is hosted by the Bundesnetzagentur as part of the eIDAS regulation and
> not BSI, however I see that BSI mentions Common PKI in its glossary here:
> https://www.bsi.bund.de/DE/Themen/Oeffentliche-Verwaltung/Moderner-Staat/ElektronischeSignatur/Glossar/glossar_node.html
> Don't shoot the messenger, but this is all I have at hand.
>
> Kind regards,
>
> Oleg
>
> Am Mi., 30. Okt. 2024 um 03:29 Uhr schrieb Paul Kehrer <
> paul.l.kehrer at gmail.com>:
>
>> Is there a published spec that defines the ASN.1 syntax for these
>> extensions (maybe from BSI)? We generally like to have a specification that
>> we can use as a source of truth. For x509 I don?t have any objection to
>> adding this assuming a spec exists.
>>
>> -Paul
>>
>> On Oct 29, 2024, at 6:54?PM, Oleg H?fling via Cryptography-dev <
>> cryptography-dev at python.org> wrote:
>>
>> ?
>> Dear devs,
>>
>> there is an X509 extension named `Admissions`, supported e.g. by OpenSSL (
>> https://docs.openssl.org/master/man3/ADMISSIONS/) and BouncyCastle (
>> https://people.eecs.berkeley.edu/~jonah/bc/index.html?org/bouncycastle/asn1/isismtt/x509/AdmissionSyntax.html).
>> Would you be interested in `cryptography` supporting it as well? This is an
>> extension that is used in german public healthcare and legal sectors, and I
>> am working for one of them :-) I really enjoy working with `cryptography`
>> for reading out and persisting X509 certificates, but dealing with the
>> `Admissions` extension requires me adding extra dependencies and writing
>> extra code using other libraries I do not enjoy this much.
>>
>> If you agree that it could be a viable addition to the project, I would
>> gladly contribute the necessary bits myself. I made a proof-of-concept
>> implementation for the Admissions extension in my fork of `cryptography` to
>> have something to discuss:
>>
>>
>> https://github.com/pyca/cryptography/compare/main...hoefling:cryptography:admission-extension?expand=1
>>
>> Example script that creates a certificate with an admission extension
>> that has some dummy values:
>> https://gist.github.com/hoefling/fa290eb33b24a2e5405cf9cdeeda03bc
>>
>> Of course, this is far from the state where it can be reviewed, should be
>> split into smaller patches, is missing tests and docs etc etc.
>>
>> If you reject the idea, I would try and put the code in a separate
>> library that depends on `cryptography` and connect them together somehow. I
>> would be grateful for any advices on that matter - maybe you already had a
>> case with a third party extension for `cryptography` being built.
>>
>> Last but not least - I really enjoyed hacking the working prototype
>> together and fiddling with the Rust backend, kudos for having such a clear
>> and concise API design!
>>
>> Kind regards,
>>
>> Oleg
>> _______________________________________________
>> Cryptography-dev mailing list
>> Cryptography-dev at python.org
>> https://mail.python.org/mailman/listinfo/cryptography-dev
>>
>> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/cryptography-dev/attachments/20241030/6d8782e7/attachment.html>