profile
viewpoint

agl/critbit 281

Critbit trees in C

agl/curve25519-donna 258

Implementations of a fast Elliptic-curve Diffie-Hellman primitive

agl/ed25519 170

ed25519 for Go

agl/jbig2enc 156

JBIG2 Encoder

agl/ctgrind 131

Checking that functions are constant time with Valgrind

agl/crlset-tools 112

Tools for dealing with Chrome's CRLSets

agl/dnssec-tls-tools 33

DNSSEC/TLS tools

agl/dnscurve 23

Tools for DNS curve implementation

agl/certificatetransparency 18

Certificate Transparency stuff

pull request commentmit-plv/fiat-crypto

Multi-license under MIT OR Apache-2.0 OR BSD-1-Clause

Approved on behalf of Google to relicense as all of MIT, Apache-2.0, and BSD-1-Clause.

JasonGross

comment created time in 2 days

PullRequestReviewEvent

push eventgoogle/boringssl

David Benjamin

commit sha 3743aafdacff2f7b083615a043a37101f740fa53

Add SSL_CIPHER_get_protocol_id. This was introduced in OpenSSL 1.1.1, and wpa_supplicant expects us to have it. We had this same function as SSL_CIPHER_get_value (to match SSL_get_cipher_by_value). Align with upstream's name. It seems we also had a ssl_cipher_get_value lying around, so fold them together. (I've retained the assert in ssl_cipher_get_value as it seems reasonable enough; casting a hypothetical SSLv2 cipher ID to uint16_t would not behave correctly.) Change-Id: Ifbec460435bbc483f2c3de988522e321f2708172 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42966 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

BoringSSL Robot

commit sha 1ce6682c7f6cfe0426ed54a37c10775bea9d3502

update master-with-bazel from master branch

view details

push time in 4 days

push eventgoogle/boringssl

David Benjamin

commit sha 3743aafdacff2f7b083615a043a37101f740fa53

Add SSL_CIPHER_get_protocol_id. This was introduced in OpenSSL 1.1.1, and wpa_supplicant expects us to have it. We had this same function as SSL_CIPHER_get_value (to match SSL_get_cipher_by_value). Align with upstream's name. It seems we also had a ssl_cipher_get_value lying around, so fold them together. (I've retained the assert in ssl_cipher_get_value as it seems reasonable enough; casting a hypothetical SSLv2 cipher ID to uint16_t would not behave correctly.) Change-Id: Ifbec460435bbc483f2c3de988522e321f2708172 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42966 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

push time in 4 days

push eventgoogle/boringssl

Steven Valdez

commit sha 9adcb0aa7eb946bea9197276121412ef68776315

Add TrustTokenV2. Changes: - Remove point prefixes. - Don't verify SRR on the client. TODO: - Replace SRR generation with RR generation on issuer. - Add finalized PrivacyPass version. Change-Id: Ibfb04aaba2cf669639af77299da22ab668175edb Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42824 Commit-Queue: Steven Valdez <svaldez@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

BoringSSL Robot

commit sha db97c4af97835d540a6b0b9be7658a18bb702a3e

update master-with-bazel from master branch

view details

push time in 4 days

push eventgoogle/boringssl

Steven Valdez

commit sha 9adcb0aa7eb946bea9197276121412ef68776315

Add TrustTokenV2. Changes: - Remove point prefixes. - Don't verify SRR on the client. TODO: - Replace SRR generation with RR generation on issuer. - Add finalized PrivacyPass version. Change-Id: Ibfb04aaba2cf669639af77299da22ab668175edb Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42824 Commit-Queue: Steven Valdez <svaldez@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

push time in 4 days

push eventgoogle/boringssl

David Benjamin

commit sha ee4af9e94e7766afe739f6aa433f10b1b404c991

Add X509_get_pathlen and X509_REVOKED_get0_extensions. Conscrypt will need these functions. Also fix a bug in X509_get_extension_flags's error-handling. While I'm here, add X509_CRL_get0_extensions for completeness. Nothing uses this yet, but this could later be an alternative to avoid Conscrypt's mess with templates. Change-Id: I9393b75fcf53346535e6a4712355be081baa630d Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42744 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

BoringSSL Robot

commit sha 266a6d3b9be6b228c92f86992159fd0ea7157e77

update master-with-bazel from master branch

view details

push time in 7 days

push eventgoogle/boringssl

David Benjamin

commit sha ee4af9e94e7766afe739f6aa433f10b1b404c991

Add X509_get_pathlen and X509_REVOKED_get0_extensions. Conscrypt will need these functions. Also fix a bug in X509_get_extension_flags's error-handling. While I'm here, add X509_CRL_get0_extensions for completeness. Nothing uses this yet, but this could later be an alternative to avoid Conscrypt's mess with templates. Change-Id: I9393b75fcf53346535e6a4712355be081baa630d Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42744 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

push time in 7 days

push eventgoogle/boringssl

Adam Langley

commit sha 5eeaf3029dab6b7264522c57a7a2acb461c0a434

Add some accommodations for FreeRDP Change-Id: Iad962fd50ede78eb94e10ba2438163509c4587e0 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42924 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

push time in 7 days

push eventgoogle/boringssl

Adam Langley

commit sha 5eeaf3029dab6b7264522c57a7a2acb461c0a434

Add some accommodations for FreeRDP Change-Id: Iad962fd50ede78eb94e10ba2438163509c4587e0 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42924 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

BoringSSL Robot

commit sha b5cab4f43c52b2372a48fb4ddfb8f9ab15a43719

update master-with-bazel from master branch

view details

push time in 7 days

push eventgoogle/boringssl

David Benjamin

commit sha ca3f243cf0cf1dd50b79f3385154ffb6c7261073

Require non-NULL store in X509_STORE_CTX_init. X509_STORE_CTX_init is documented upstream to allow a NULL store and has logic to account for it. However, attempting to use such an X509_STORE_CTX crashes in X509_verify_cert due to the additional_untrusted logic we added. Moreover, before that change, it still crashes because X509_STORE_CTX_get1_issuer (the default get_issuer hook) assumes ctx->ctx (the store) is non-null. This was also true in upstream but later fixed in https://github.com/openssl/openssl/pull/6001. However, without a store, there is no trust anchor, so this is not very useful. Reject NULL stores in X509_STORE_CTX_init and remove the logic allowing for a NULL one. Thanks to Danny Halawi for catching this. Update-Note: X509_STORE_CTX_init will now fail when the store is NULL, rather than report success, only to crash later in X509_verify_cert. Breakage should thus be limited to code which was passing in a NULL store but never used the resulting X509_STORE_CTX. Change-Id: I9db0289612cc245a8d62d6fa647d6b56b2daabda Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42728 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

push time in 8 days

push eventgoogle/boringssl

David Benjamin

commit sha 6d70353ca8bc55b54f19af00fb7d9b074208ff1c

Const-correct X509V3_CONF_METHOD. This is needed to fix all the config APIs to take const char *. I've split it out as it's the only incompatible half of the change. Update-Note: External definitions of X509V3_CONF_METHOD will need fix the types of their functions. There should not be any of these (probably hide this struct), but if there are, this aligns with upstream OpenSSL. Change-Id: I6e760cfbca5d3f408215b8f3744acd1fd7f31391 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42727 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

David Benjamin

commit sha ca3f243cf0cf1dd50b79f3385154ffb6c7261073

Require non-NULL store in X509_STORE_CTX_init. X509_STORE_CTX_init is documented upstream to allow a NULL store and has logic to account for it. However, attempting to use such an X509_STORE_CTX crashes in X509_verify_cert due to the additional_untrusted logic we added. Moreover, before that change, it still crashes because X509_STORE_CTX_get1_issuer (the default get_issuer hook) assumes ctx->ctx (the store) is non-null. This was also true in upstream but later fixed in https://github.com/openssl/openssl/pull/6001. However, without a store, there is no trust anchor, so this is not very useful. Reject NULL stores in X509_STORE_CTX_init and remove the logic allowing for a NULL one. Thanks to Danny Halawi for catching this. Update-Note: X509_STORE_CTX_init will now fail when the store is NULL, rather than report success, only to crash later in X509_verify_cert. Breakage should thus be limited to code which was passing in a NULL store but never used the resulting X509_STORE_CTX. Change-Id: I9db0289612cc245a8d62d6fa647d6b56b2daabda Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42728 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

BoringSSL Robot

commit sha eeb04297c715b3853515ecba686c9b9746b1cb08

update master-with-bazel from master branch

view details

push time in 8 days

push eventgoogle/boringssl

David Benjamin

commit sha 6247347edd347b5a5c14b2a50a9c77659e77c24d

Avoid unions in X509_NAME logic. Cast between T* and ASN1_VALUE* directly, rather than messing with unions. This is necessary to avoid UB in C++ and is a strict aliasing violation in C too. (While C does allow type-punning in unions, pointers to union fields have weird rules. I suspect most of our unions should be reworked.) Change-Id: Ibe274a7df5d5826f8c5f335255d196e9b7587105 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42726 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

David Benjamin

commit sha 6d70353ca8bc55b54f19af00fb7d9b074208ff1c

Const-correct X509V3_CONF_METHOD. This is needed to fix all the config APIs to take const char *. I've split it out as it's the only incompatible half of the change. Update-Note: External definitions of X509V3_CONF_METHOD will need fix the types of their functions. There should not be any of these (probably hide this struct), but if there are, this aligns with upstream OpenSSL. Change-Id: I6e760cfbca5d3f408215b8f3744acd1fd7f31391 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42727 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

push time in 8 days

push eventgoogle/boringssl

David Benjamin

commit sha 6247347edd347b5a5c14b2a50a9c77659e77c24d

Avoid unions in X509_NAME logic. Cast between T* and ASN1_VALUE* directly, rather than messing with unions. This is necessary to avoid UB in C++ and is a strict aliasing violation in C too. (While C does allow type-punning in unions, pointers to union fields have weird rules. I suspect most of our unions should be reworked.) Change-Id: Ibe274a7df5d5826f8c5f335255d196e9b7587105 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42726 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

BoringSSL Robot

commit sha dc4e0886762e7287e3c81a19d51a09709c9bed35

update master-with-bazel from master branch

view details

push time in 8 days

push eventagl/webauthn

Adam Langley

commit sha ebe2e4a2fe3e10dd4b2fd0e2516938536b24562c

Update index.bs Co-authored-by: =JeffH <jdhodges@google.com>

view details

push time in 9 days

PullRequestReviewEvent

push eventgoogle/boringssl

David Benjamin

commit sha 49e9f67d8b7cbeb3953b5548ad1009d15947a523

Bump OPENSSL_VERSION_NUMBER to 1.1.1. With TLS 1.3 and Ed25519 support, we're much closer to OpenSSL 1.1.1 these days than OpenSSL 1.1.0. I've also added a test to keep OPENSSL_VERSION_NUMBER and OPENSSL_VERSION_TEXT in sync. Update-Note: Some OPENSSL_VERSION_NUMBER/OPENSSL_IS_BORINGSSL checks may need to be updated. Hopefully even more can go away. Bug: 367 Change-Id: Idaa238b74f35993c9c03fec31f1346c15cf82968 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42864 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

BoringSSL Robot

commit sha d77fd374030288702032b4167b3910315eca3181

update master-with-bazel from master branch

view details

push time in 9 days

push eventgoogle/boringssl

David Benjamin

commit sha 49e9f67d8b7cbeb3953b5548ad1009d15947a523

Bump OPENSSL_VERSION_NUMBER to 1.1.1. With TLS 1.3 and Ed25519 support, we're much closer to OpenSSL 1.1.1 these days than OpenSSL 1.1.0. I've also added a test to keep OPENSSL_VERSION_NUMBER and OPENSSL_VERSION_TEXT in sync. Update-Note: Some OPENSSL_VERSION_NUMBER/OPENSSL_IS_BORINGSSL checks may need to be updated. Hopefully even more can go away. Bug: 367 Change-Id: Idaa238b74f35993c9c03fec31f1346c15cf82968 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42864 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

push time in 9 days

push eventgoogle/boringssl

David Benjamin

commit sha a82cfdf08370bc4fd945f21c66d7dee3c4b7bd48

Document more of x509.h. Change-Id: Idda4d1e822c63ae341154c5c12953519fee04e4f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42725 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

BoringSSL Robot

commit sha 16b396e6b7f4b433139b2288ba3afe8ed230c425

update master-with-bazel from master branch

view details

push time in 10 days

push eventgoogle/boringssl

David Benjamin

commit sha a82cfdf08370bc4fd945f21c66d7dee3c4b7bd48

Document more of x509.h. Change-Id: Idda4d1e822c63ae341154c5c12953519fee04e4f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42725 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

push time in 10 days

push eventgoogle/boringssl

David Benjamin

commit sha 662bfad81002086c217a9042ed459efd5e0bf82c

Fix potential leak in bssl::Array::Shrink. We don't currently use this type anywhere with a nontrivial destructor, so this doesn't matter right now. But handle this correctly in case we ever do. (One of these days, we should sort out using the STL and Abseil in here...) Change-Id: I6a198ccf87f953cedcdbe658fa508a3b79d47305 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42825 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

BoringSSL Robot

commit sha 1770f647c954d9014c3faf896c2462c18db11a01

update master-with-bazel from master branch

view details

push time in 10 days

push eventgoogle/boringssl

David Benjamin

commit sha 662bfad81002086c217a9042ed459efd5e0bf82c

Fix potential leak in bssl::Array::Shrink. We don't currently use this type anywhere with a nontrivial destructor, so this doesn't matter right now. But handle this correctly in case we ever do. (One of these days, we should sort out using the STL and Abseil in here...) Change-Id: I6a198ccf87f953cedcdbe658fa508a3b79d47305 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42825 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

push time in 10 days

push eventgoogle/boringssl

David Benjamin

commit sha 6ad3b46b24ea45afb609a2852f6dc16f52840583

Remove ASN1_STRING_length_set. This function is unused and quite unsafe. Update-Note: Use ASN1_STRING_set instead, though this function appears to be unused. Change-Id: Ie6f4dec4b9e11ebde95b322ef91e1b8d63fbb8af Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42724 Reviewed-by: Adam Langley <agl@google.com>

view details

BoringSSL Robot

commit sha ac0451c738ea479212e57b84d1429cabc50b3162

update master-with-bazel from master branch

view details

push time in 10 days

push eventgoogle/boringssl

David Benjamin

commit sha 6ad3b46b24ea45afb609a2852f6dc16f52840583

Remove ASN1_STRING_length_set. This function is unused and quite unsafe. Update-Note: Use ASN1_STRING_set instead, though this function appears to be unused. Change-Id: Ie6f4dec4b9e11ebde95b322ef91e1b8d63fbb8af Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42724 Reviewed-by: Adam Langley <agl@google.com>

view details

push time in 10 days

push eventgoogle/boringssl

David Benjamin

commit sha 0cafd6290dc696918132d43536206abadcfc3ab5

Switch Mac CI and CQ bots to macOS 10.15. The bots in the luci.flex.{ci,try} pools were updated recently. We don't have very strong opinions on macOS version, so 10.15 works too. Bug: chromium:1128042, chromium:1128044 Change-Id: Iecddd59545f4b1749f2ebb52192b17aaee8d72db Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42844 Reviewed-by: David Benjamin <davidben@google.com>

view details

push time in 10 days

issue commentgolang/go

dev.boringcrypto: crypto/tls: in boring.go, RSA key sizes restricted to 2048 and 3072

Having looked into this, it doesn't appear that allowing other modulus sizes is strictly compliant with the current validation. However, future validations can be updated to take advantage of the increased flexibility now allowed by the IG. We expect to do this, but have no timelines to announce and do not currently have a revalidation in progress.

riraccuia

comment created time in 10 days

pull request commentw3c/webauthn

Add note about fixed/empty user handles

As someone seeing this paragraph without context, it's rather unclear. Would it be possible to specify what the username is "fixed" across here

Good point. Let me try again. How's it now?

agl

comment created time in 11 days

push eventagl/webauthn

Adam Langley

commit sha d1d774f635a65c5c04911207e07c5e187c5577e3

Reword

view details

push time in 11 days

PR opened w3c/webauthn

Add note about fixed/empty user handles

See fido-alliance/fido-2-specs#951

+2 -0

0 comment

1 changed file

pr created time in 11 days

create barnchagl/webauthn

branch : userid

created branch time in 11 days

Pull request review commentw3c/webauthn

Make largeBlobs explicit during create.

 Note: In order to interoperate, user agents storing large blobs on authenticator :: `largeBlob`  : Operation applicability-:: [=authentication extension|Authentication=]+:: [=registration extension|Registration=] and [=authentication extension|authentication=]  : Client extension input ::  <xmp class="idl">     partial dictionary AuthenticationExtensionsClientInputs {         AuthenticationExtensionsLargeBlobInputs largeBlob;     }; +    enum LargeBlobSupport {+      "required",+      "preferred",+    };+     dictionary AuthenticationExtensionsLargeBlobInputs {+        DOMString support;         boolean read;         ArrayBuffer write;     };     </xmp>      <div dfn-type="dict-member" dfn-for="AuthenticationExtensionsLargeBlobInputs">+        :   <dfn>support</dfn>+        ::  A DOMString that takes one of the values of {{LargeBlobSupport}}. (See [[#sct-domstring-backwards-compatibility]].) Only valid during [=registration extension|registration=].+         :   <dfn>read</dfn>-        ::  A boolean that indicates that the [=[RP]=] would like to fetch the previously-written blob associated with the asserted credential.+        ::  A boolean that indicates that the [=[RP]=] would like to fetch the previously-written blob associated with the asserted credential. Only valid during [=authentication extension|authentication=].          :   <dfn>write</dfn>-        ::  An opaque byte string that the [=[RP]=] wishes to store with the existing credential.+        ::  An opaque byte string that the [=[RP]=] wishes to store with the existing credential. Only valid during [=authentication extension|authentication=].     </div> +: Client extension processing ([=registration extension|registration=])+::+       1. If {{AuthenticationExtensionsLargeBlobInputs/read}} or {{AuthenticationExtensionsLargeBlobInputs/write}} is present:+           1. Return a {{DOMException}} whose name is “{{NotSupportedError}}”.+       1. If {{AuthenticationExtensionsLargeBlobInputs/support}} is present and has the value “required”:+           1. Set {{AuthenticationExtensionsLargeBlobOutputs/supported}} to [TRUE].+           1. When creating the credential, prior to evaluating the [=authenticator attachment modality=], [=iteration/continue=] (i.e. ignore the authenticator) if the authenticator is not capable of storing large blobs.+       1. Otherwise:

Done.

agl

comment created time in 11 days

PullRequestReviewEvent

push eventagl/webauthn

Adam Langley

commit sha ea23052ec7e5ce5658f193e5d0b46f05814ef5ba

Address more comments

view details

push time in 11 days

pull request commentw3c/webauthn

Make largeBlobs explicit during create.

It looks to me like one can include both read and write in a largeBlob extension, and the read may succeed (tho there's no signal if it does not), and the write will be silently ignored. is that what's intended? further modest comments below...

Have explicitly banned that. Have also clarified how a read failure is indicated.

agl

comment created time in 11 days

push eventagl/webauthn

Adam Langley

commit sha a238e53a93e9afac9cc38bbd51a5a0cbc6534d77

Apply suggestion from code review Co-authored-by: =JeffH <jdhodges@google.com>

view details

push time in 11 days

push eventagl/webauthn

Adam Langley

commit sha dc1d8e78a37961be0a5d8b86186446723739d79e

Apply suggestion from code review Co-authored-by: =JeffH <jdhodges@google.com>

view details

push time in 11 days

push eventagl/webauthn

Adam Langley

commit sha 37b62209d53b75f56f9e41a37fe5f6e35043be9c

Apply suggestions from code review Co-authored-by: Emil Lundberg <emil@emlun.se>

view details

push time in 11 days

push eventagl/webauthn

Adam Langley

commit sha f34620920b15150524f9b8ad9d19bbe9faf3a26f

Apply suggestions from code review Co-authored-by: Emil Lundberg <emil@emlun.se> Co-authored-by: =JeffH <jdhodges@google.com>

view details

push time in 11 days

push eventgoogle/boringssl

Adam Langley

commit sha 6a263ce483b9ff03c7998bcae031ed42f092368e

Revert "Check AlgorithmIdentifier parameters for RSA and ECDSA signatures." This reverts commit 9dd9d4fc242f31584f5a42e41e63d132c790421f. BUG=b/167375496,342 Original change's description: > Check AlgorithmIdentifier parameters for RSA and ECDSA signatures. > > This aligns with the Chromium certificate verifier, which allows NULL or > empty for RSA and requires empty for ECDSA. > > Bug: 342 > Change-Id: I34acf68f63b4d133dd47b73144b2f27224c499ee > Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41804 > Reviewed-by: Adam Langley <agl@google.com> > Commit-Queue: David Benjamin <davidben@google.com> TBR=agl@google.com,davidben@google.com # Not skipping CQ checks because original CL landed > 1 day ago. Change-Id: If8f136a09fea68e64c9f4f9ffae88b6209ede124 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42804 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

BoringSSL Robot

commit sha 3d440a3493fda30b1aa98a1aea0207dda271b4e6

update master-with-bazel from master branch

view details

push time in 14 days

push eventgoogle/boringssl

Adam Langley

commit sha 6a263ce483b9ff03c7998bcae031ed42f092368e

Revert "Check AlgorithmIdentifier parameters for RSA and ECDSA signatures." This reverts commit 9dd9d4fc242f31584f5a42e41e63d132c790421f. BUG=b/167375496,342 Original change's description: > Check AlgorithmIdentifier parameters for RSA and ECDSA signatures. > > This aligns with the Chromium certificate verifier, which allows NULL or > empty for RSA and requires empty for ECDSA. > > Bug: 342 > Change-Id: I34acf68f63b4d133dd47b73144b2f27224c499ee > Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41804 > Reviewed-by: Adam Langley <agl@google.com> > Commit-Queue: David Benjamin <davidben@google.com> TBR=agl@google.com,davidben@google.com # Not skipping CQ checks because original CL landed > 1 day ago. Change-Id: If8f136a09fea68e64c9f4f9ffae88b6209ede124 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42804 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

push time in 14 days

PullRequestReviewEvent

push eventw3c/webauthn

Nina Satragno

commit sha 7107ed7158e408580536a64103fe9b2dc3ead52e

Virtual authenticators extension support Add support for authenticator extensions on WebDriver virtual authenticators. Fixes 1471

view details

Nina Satragno

commit sha ed745df114d5f0d69edcd746aa735fe702e947dd

Address comments.

view details

Nina Satragno

commit sha ea9ad168c21d928e6855ee1d802cce054d0e0ddb

Address comments.

view details

Adam Langley

commit sha ff9c5b03d2397ed10b7a285e068d0848f6ce5c73

Merge pull request #1472 from nsatragno/virtual_authenticator_extensions Virtual authenticators extension support

view details

push time in 16 days

PR merged w3c/webauthn

Virtual authenticators extension support subtype:FeatureProposal type:technical

Add support for authenticator extensions on WebDriver virtual authenticators.

This comes in the form of:

  • A capability for each extension signalling support.
  • An option to toggle which extensions are supported by a given virtual authenticator.

Fixes #1471

<!-- This comment and the below content is programatically generated. You may add a comma-separated list of anchors you'd like a direct link to below (e.g. #idl-serializers, #idl-sequence):

Don't remove this comment or modify anything below this line.
If you don't want a preview generated for this pull request,
just replace the whole of this comment's content by "no preview"
and remove what's below.

-->


<a href="https://pr-preview.s3.amazonaws.com/nsatragno/webauthn/pull/1472.html" title="Last updated on Sep 2, 2020, 3:52 PM UTC (ea9ad16)">Preview</a> | <a href="https://pr-preview.s3.amazonaws.com/w3c/webauthn/1472/ad8d1d0...nsatragno:ea9ad16.html" title="Last updated on Sep 2, 2020, 3:52 PM UTC (ea9ad16)">Diff</a>

+91 -1

2 comments

1 changed file

nsatragno

pr closed time in 16 days

issue closedw3c/webauthn

Virtual authenticator support for extensions

At the moment, the User Agent Automation section does not say anything about treatment of extensions by virtual authenticators. As user agents implement the extensions, we should strive to support them through the virtual authenticators so that relying parties can write automated tests and we can ensure interoperability with web platform tests.

My proposal is to add

  • for every defined extension, a capability with the name webauthn:$extension_identifier signalling virtual authenticator support for the extension, and
  • an extensions array to the Authenticator Configuration object, indicating which extensions must be supported by the specific virtual authenticator. Extensions not present in the array should not be supported (this is to test that a given relying party or user agent does the right thing when the underlying authenticator does not support an extension).
  • when defining an extension, the text

    User agents implementing $extension SHOULD support the webauthn:$extension_identifier webdriver capability

closed time in 16 days

nsatragno

push eventgoogle/boringssl

Anna Sarai Rosenberg

commit sha 8f12996be3a7a8a53c1b674c0cef103628a7b779

Fix docs link for SSL_CTX_load_verify_locations Link is outdated; results in 404. Update link to match docs version in other links with redirected path to current link for that version. Change-Id: I4c9bb2fe48d1b2bbf699773259d5eebad9461ddd Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41385 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>

view details

David Benjamin

commit sha 7b31d69f19e85dafa97854bfe35adbfd0fb6d280

Document that getrandom support must be consistent. Syscall-filtering sandboxes may make getrandom fail without crashing. This will sometimes trigger the /dev/urandom fallback and sometimes not. Change-Id: Ic824e5bfe6fcb99105fd285184243c4620447327 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41404 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>

view details

David Benjamin

commit sha 9701e84eff26d0110d21f024debbab88d97e9c81

Remove RAND_set_urandom_fd. Also update the documentation for RAND_enable_fork_unsafe_buffering. The fd parameter is no longer used. Update-Note: RAND_set_urandom_fd no longer exists. This was only called by Chromium, which now uses CRYPTO_pre_sandbox_init. Change-Id: I1659c1cc84a6f1edc01f6105fc07e80856e457fc Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41424 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>

view details

Nick Harper

commit sha 851943277fcbc6597d0d9d06f897e20b88afc32b

Modify how QUIC 0-RTT go/no-go decision is made. The previous implementation was too strict in its byte-for-byte equality check including Transport Parameters, because the Transport Parameters contain a field that QUIC requires be different on each connection. This change still has BoringSSL do a byte-for-byte check, but now it is only done over the quic_early_data_context. An additional requirement is imposed that the quic_early_data_context must be set for early data capable tickets to be issued. Bug: 295 Change-Id: I5145c10752b41908b6807c3a3c967653b0c13f37 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41427 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>

view details

David Benjamin

commit sha 81a998a637cc05d17f2173112fadf4c7943a50e2

Bump minimum CMake version. CMake 3.2.1 was released in March 2015, which was over five years ago. Change-Id: I8b76e1de3dba8732a143f86a3956c83fbb4306a7 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41444 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>

view details

David Benjamin

commit sha 8819e0be623f3555d34ce69fee938c34f237fab4

Test AES mode wrappers. AES_ctr128_encrypt, in particular, has a decent number of external callers but is completely untested. I haven't included AES_cfb128_encrypt because its EVP_CIPHER counterpart is tested in decrept_test. But the EVP_CIPHER counterpart simply calls AES_cfb128_encrypt, so it's tested transitively. Change-Id: I0133dbd5b13c2b4045a89a04f29240008a279186 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41425 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

David Benjamin

commit sha 2309f645e509507a1cc8f9845771110fcf986fd9

Use ctr32 optimizations for AES_ctr128_encrypt. There are a decent number of uses of this function directly. I've attached this to bug 338. Arguably it makes it worse, though it does help with aligning on ctr32, if that works out. Bug: 338 Change-Id: I3dfc1305d359ec0c88d4f298fe1928bef7ec9877 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41426 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

Adam Langley

commit sha 53a17f55247101105ae35767d5c5a6c311843a8e

Add a |SSL_process_tls13_new_session_ticket|. This API processes a given NewSessionTicket message and returns a resumable |SSL_SESSION| object that contains the ticket. (Change by Cesar Ghali.) Change-Id: I7426933b043865ca54d3cf597f7ecd54d493bf35 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41464 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

Adam Langley

commit sha 88024df12147e56b6abd66b743ff441a0aaa09a8

Remove -enable-ed25519 compat hack. Change-Id: I2d5843b2dc957f8ae8e4d9a41cecd3268220cc1d Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41504 Commit-Queue: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

David Benjamin

commit sha 251b5169fd44345f455438312ec4e18ae07fd58c

Assert md_size > 0. md_size is the size of a hash, so it cannot be zero. Add an assert since it appears to have caused some confusion. The j >= md_size and j -= md_size logic implicitly assumes md_size > 0. (It's another way to stick a % md_size elsewhere which, likewise, assumes md_size > 0.) The bug report itself is a false positive, but locally documenting assumptions is good. Bug: chromium:1092697 Change-Id: I3be0992552a300c6786cf1dc5ecfa881173a42e6 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41544 Reviewed-by: Steven Valdez <svaldez@google.com> Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>

view details

Adam Langley

commit sha fbaf1c0546987fea3e07778f7eaf384726057bfb

acvptool: go fmt Change-Id: If90e35bf4ef75d12cdbddc118611127b74bbafe6 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41604 Reviewed-by: Adam Langley <agl@google.com>

view details

Adam Langley

commit sha 0313b59d5f950a05f2269811732bbbf204059da5

Let memory hooks override the size prefix. In order to efficiently track heap operations, the memory hooks may need to store other information in the prefix area than the size that BoringSSL uses by default. This change lets them manage the prefix how they wish. Change-Id: I5a4d98bed100aff2deaaabb3d23fab02f0be82aa Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41584 Reviewed-by: Adam Langley <alangley@gmail.com> Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: Adam Langley <alangley@gmail.com> Commit-Queue: David Benjamin <davidben@google.com>

view details

Adam Langley

commit sha 9c256d1d7f2730d260c84eea2d9e97becd6dcc96

acvptool: handle negative sizeConstraint. The NIST server has been updated and is now sending a sizeConstraint of -1 to indicate that the large-upload process isn't needed. However, the code was trying to put that in a uint64, which caused a parse error. Change-Id: I9ee16918df13c229b0e889fa1248eb2e0a6a5fb2 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41605 Reviewed-by: David Benjamin <davidben@google.com>

view details

Adam Langley

commit sha 7f90eda55ee39c6b8c0c84ea2923dd5dd826a778

Add “Z Computation” KAT. FIPS updates will make this useful / mandatory in the future. Change-Id: I9921e4f3fc8a8315dc85dc366f331b456572d49e Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41644 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

David Benjamin

commit sha 72b095d0d483e6b9df002427054a0b150ee76f49

Reword some comments. There were a handful of comments that use "blacklist" and "whitelist". They are easy to fix. Change-Id: I49a9592393b43fc85e92b4a00a585b504dede75a Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41645 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>

view details

David Benjamin

commit sha cd8f3d36fe294b4896f26bf3add6a6a954218bfd

Enforce the keyUsage extension in TLS 1.2 client certs. I've left this independent of SSL_set_enforce_rsa_key_usage because client certificates in TLS always use the digitalSignature bit, RSA or otherwise, so it's less likely that someone has messed it up, unlike TLS 1.2 RSA server certificates. Update-Note: Client certificates which do not support the digitalSignature key usage will be rejected. They should either include that bit or omit the keyUsage extension. Bug: 349 Change-Id: I97bbf0c8e394f219ff75b686e0c14019f6d8c9a8 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41664 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

David Benjamin

commit sha 884614c24f8c04ebde9c72ec7ce8f50498e3cdae

Use CMAKE_SIZEOF_VOID_P instead of CMAKE_CL_64 CMake's documentation says this is preferred. https://cmake.org/cmake/help/latest/variable/CMAKE_CL_64.html Reportedly, it also works better with MINGW, though we do not currently support MINGW with the CMake build. See https://boringssl-review.googlesource.com/c/boringssl/+/41704/ Change-Id: Ie5794306beeeff816b34ee98c7a0f8e0d4f99ec8 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41724 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>

view details

David Benjamin

commit sha 8afdbf04bd665a76c81319bc9715a77d9bc32722

Abstract fd operations better in tool. Windows and POSIX implement very similar fd operations, but differ slightly: - ssize_t in POSIX is usually int on Windows. - POSIX needs EINTR retry loops. - Windows wants _open rather than open, etc. - POSIX fds and sockets are the same thing, while Windows sockets are HANDLEs and leaves fd as a C runtime construct. Rather than ad-hoc macros and redefinitions of ssize_t (which reportedly upset MINGW), add some actual abstractions. While I'm here, add a scoped file descriptor type. That still leaves recv/send which are only used in one file, so defined a socket_result_t for them. Change-Id: I17fca2a50c77191f573852bfd27553996e3e9c3f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41725 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

Jesko Jochum

commit sha c17985424391fcbaaa57f733b7197c5dd3e510aa

Fixes warning when redefining PATH_MAX when building with MINGW. Fixes warning thrown when compiling digest.cc with MinGW64, by only defining PATH_MAX, if it has not yet been defined. Else building with MinGW64, throws the following warning: <PATH_TO_SOURCE_FOLDER>\boringssl\src\tool\digest.cc:39: warning: "PATH_MAX" redefined 39 | #define PATH_MAX MAX_PATH | In file included from C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/9.3.0/include-fixed/limits.h:194, from C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/9.3.0/include-fixed/syslimits.h:7, from C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/9.3.0/include-fixed/limits.h:34, from C:/msys64/mingw64/x86_64-w64-mingw32/include/pthread.h:67, from C:/msys64/mingw64/include/c++/9.3.0/x86_64-w64-mingw32/bits/gthr-default.h:35, from C:/msys64/mingw64/include/c++/9.3.0/x86_64-w64-mingw32/bits/gthr.h:148, from C:/msys64/mingw64/include/c++/9.3.0/ext/atomicity.h:35, from C:/msys64/mingw64/include/c++/9.3.0/memory:73, from <PATH_TO_SOURCE_FOLDER>/boringssl/src/include/openssl/base.h:473, from <PATH_TO_SOURCE_FOLDER>\boringssl\src\tool\digest.cc:15: C:/msys64/mingw64/x86_64-w64-mingw32/include/limits.h:20: note: this is the location of the previous definition 20 | #define PATH_MAX 260 | Change-Id: I29eb33ee8fad9e4e80d9348a0d5e4057dfac620c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41705 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>

view details

David Benjamin

commit sha 1b8194715eeb6b43f9534a310cedd3d44d62911c

Test resumability of same, different, and default ticket keys. If we were to accidentally leave the ticket keys zero-initialized, the only tests that notice are DefaultTicketKeyInitialization (initial key is not all zeros) and DefaultTicketKeyRotation (old key is not new key), by way of querying the keys themselves. Add some tests which additionally test the effects on resumption itself. Change-Id: I3bfd3f1e082e3a466105dbdffa18621b81c53d17 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41564 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

push time in 17 days

push eventgoogle/boringssl

Daniel McArdle

commit sha bc2480510960a77bea24edc64fcb089aca103940

Implement PSK variants of HPKE setup functions. Change-Id: Ic190ac1efbb079e42bb22b39083ccb96e0a61e57 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42664 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>

view details

BoringSSL Robot

commit sha 50ddc1c67ab1490842d659246cd6843aff040062

update master-with-bazel from master branch

view details

push time in 23 days

push eventgoogle/boringssl

Daniel McArdle

commit sha bc2480510960a77bea24edc64fcb089aca103940

Implement PSK variants of HPKE setup functions. Change-Id: Ic190ac1efbb079e42bb22b39083ccb96e0a61e57 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42664 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>

view details

push time in 23 days

push eventgoogle/boringssl

Adam Langley

commit sha bef6a2f5f51b9753b9ee49a236e3433f6e623067

acvp: support working with files. A direct connections to the ACVP servers may not always be available. In some cases, NVLAP labs will interact with the servers and send JSON back and forth as files. This change supports both dumping the capabilities JSON (which a lab will need in order to send to the server) and processing vectors from a file on disk. Change-Id: Iefa0c411b9a19808b5a7eb431169068d1c2ea966 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42704 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

push time in 23 days

push eventgoogle/boringssl

Adam Langley

commit sha bef6a2f5f51b9753b9ee49a236e3433f6e623067

acvp: support working with files. A direct connections to the ACVP servers may not always be available. In some cases, NVLAP labs will interact with the servers and send JSON back and forth as files. This change supports both dumping the capabilities JSON (which a lab will need in order to send to the server) and processing vectors from a file on disk. Change-Id: Iefa0c411b9a19808b5a7eb431169068d1c2ea966 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42704 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

BoringSSL Robot

commit sha dbc7700cbfb1867f48e3b902a8010a483af1b20e

update master-with-bazel from master branch

view details

push time in 23 days

Pull request review commentw3c/webauthn

Make largeBlobs explicit during create.

 Note: In order to interoperate, user agents storing large blobs on authenticator :: `largeBlob`  : Operation applicability-:: [=authentication extension|Authentication=]+:: [=registration extension|Registration=] and [=authentication extension|authentication=]  : Client extension input ::  <xmp class="idl">     partial dictionary AuthenticationExtensionsClientInputs {         AuthenticationExtensionsLargeBlobInputs largeBlob;     }; +    enum LargeBlobSupport {+      "required",+      "preferred",+    };+     dictionary AuthenticationExtensionsLargeBlobInputs {+        DOMString support;         boolean read;         ArrayBuffer write;     };     </xmp>      <div dfn-type="dict-member" dfn-for="AuthenticationExtensionsLargeBlobInputs">+        :   <dfn>support</dfn>+        ::  A DOMString that takes one of the values of {{LargeBlobSupport}}. (See [[#sct-domstring-backwards-compatibility]].) Only valid during [=registration extension|registration=].+         :   <dfn>read</dfn>-        ::  A boolean that indicates that the [=[RP]=] would like to fetch the previously-written blob associated with the asserted credential.+        ::  A boolean that indicates that the [=[RP]=] would like to fetch the previously-written blob associated with the asserted credential. Only valid during [=authentication extension|authentication=].          :   <dfn>write</dfn>-        ::  An opaque byte string that the [=[RP]=] wishes to store with the existing credential.+        ::  An opaque byte string that the [=[RP]=] wishes to store with the existing credential. Only valid during [=authentication extension|authentication=].     </div> +: Client extension processing ([=registration extension|registration=])+::+       1. If {{AuthenticationExtensionsLargeBlobInputs/read}} or {{AuthenticationExtensionsLargeBlobInputs/write}} is present:+           1. Return a {{DOMException}} whose name is “{{NotSupportedError}}”.+       1. If {{AuthenticationExtensionsLargeBlobInputs/support}} is present and has the value “required”:+           1. Set {{AuthenticationExtensionsLargeBlobOutputs/supported}} to [TRUE].+           1. When creating the credential, prior to evaluating the [=authenticator attachment modality=], [=iteration/continue=] (i.e. ignore the authenticator) if the authenticator is not capable of storing large blobs.

The process would continue to wait for an applicable authenticator. I.e. same as if rk=required and no existing authenticator supported resident keys.

agl

comment created time in 23 days

PullRequestReviewEvent

issue commentw3c/webauthn

New platform authenticators are making discoverable credentials regardless of residentKey=false passed to Create()

I think this issue might be closable now. While the landed PR doesn't solve the underlying problem, I suspect that we have done all that we can in WebAuthn.

ve7jtb

comment created time in a month

push eventgoogle/boringssl

David Benjamin

commit sha 298d8bea0356799ce77c871b22fd6780383365bf

Add subject key ID and authority key ID accessors. Although extensions are accessible via X509_get_ext_d2i, OpenSSL's X509 object carries caches of a number of extensions. OpenSSL added accessors for some of these in 1.1.0 (X509_get0_subject_key_id) and 1.1.1d (the others), so mirror this. Note that, although they look like simpler getters, the error-handling is tricky. (For now I'm just looking to mirror OpenSSL's accessors and finally make the structs opaque. Go's x509.Certificate structure also recognizes a collection of built-in certificate fields, but error-handling is in the parser. That could be one path out of this cached fields mess, at the cost of making the parse operation do more work.) Change-Id: I051512aa296bd103229ba6eb2b5639d79e9eb63f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42624 Reviewed-by: Adam Langley <agl@google.com>

view details

David Benjamin

commit sha 4ef5de02c7d0d9cf8c1ec72450ab825b633c7b76

Document a few more functions in x509.h. While I'm there, tidy up some variable names and stray parens. Change-Id: Ifec36a532b9e9799a633b6e3b250b74255620283 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42665 Reviewed-by: Adam Langley <agl@google.com>

view details

BoringSSL Robot

commit sha 6c15d33e2fd5d25a44083e4f3e79985730bf1956

update master-with-bazel from master branch

view details

push time in a month

push eventgoogle/boringssl

David Benjamin

commit sha 298d8bea0356799ce77c871b22fd6780383365bf

Add subject key ID and authority key ID accessors. Although extensions are accessible via X509_get_ext_d2i, OpenSSL's X509 object carries caches of a number of extensions. OpenSSL added accessors for some of these in 1.1.0 (X509_get0_subject_key_id) and 1.1.1d (the others), so mirror this. Note that, although they look like simpler getters, the error-handling is tricky. (For now I'm just looking to mirror OpenSSL's accessors and finally make the structs opaque. Go's x509.Certificate structure also recognizes a collection of built-in certificate fields, but error-handling is in the parser. That could be one path out of this cached fields mess, at the cost of making the parse operation do more work.) Change-Id: I051512aa296bd103229ba6eb2b5639d79e9eb63f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42624 Reviewed-by: Adam Langley <agl@google.com>

view details

David Benjamin

commit sha 4ef5de02c7d0d9cf8c1ec72450ab825b633c7b76

Document a few more functions in x509.h. While I'm there, tidy up some variable names and stray parens. Change-Id: Ifec36a532b9e9799a633b6e3b250b74255620283 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42665 Reviewed-by: Adam Langley <agl@google.com>

view details

push time in a month

Pull request review commentw3c/webauthn

Make largeBlobs explicit during create.

 Note: In order to interoperate, user agents storing large blobs on authenticator :: `largeBlob`  : Operation applicability-:: [=authentication extension|Authentication=]+:: [=registration extension|Registration=] and [=authentication extension|authentication=]  : Client extension input ::  <xmp class="idl">     partial dictionary AuthenticationExtensionsClientInputs {         AuthenticationExtensionsLargeBlobInputs largeBlob;     }; +    enum LargeBlobSupport {+      "required",+      "preferred",+    };+     dictionary AuthenticationExtensionsLargeBlobInputs {+        DOMString support;         boolean read;         ArrayBuffer write;     };     </xmp>      <div dfn-type="dict-member" dfn-for="AuthenticationExtensionsLargeBlobInputs">+        :   <dfn>support</dfn>+        ::  A DOMString that takes one of the values of {{LargeBlobSupport}}. (See [[#sct-domstring-backwards-compatibility]].) Only valid during [=registration extension|registration=].+         :   <dfn>read</dfn>-        ::  A boolean that indicates that the [=[RP]=] would like to fetch the previously-written blob associated with the asserted credential.+        ::  A boolean that indicates that the [=[RP]=] would like to fetch the previously-written blob associated with the asserted credential. Only valid during [=authentication extension|authentication=].          :   <dfn>write</dfn>-        ::  An opaque byte string that the [=[RP]=] wishes to store with the existing credential.+        ::  An opaque byte string that the [=[RP]=] wishes to store with the existing credential. Only valid during [=authentication extension|authentication=].     </div> +: Client extension processing ([=registration extension|registration=])+::+       1. If {{AuthenticationExtensionsLargeBlobInputs/read}} or {{AuthenticationExtensionsLargeBlobInputs/write}} is present:+           1. Return a {{DOMException}} whose name is “{{NotSupportedError}}”.+       1. If {{AuthenticationExtensionsLargeBlobInputs/support}} is present and has the value “required”:

Done. (Defaulting to “preferred”.)

agl

comment created time in a month

PullRequestReviewEvent

Pull request review commentw3c/webauthn

Make largeBlobs explicit during create.

 Note: In order to interoperate, user agents storing large blobs on authenticator :: `largeBlob`  : Operation applicability-:: [=authentication extension|Authentication=]+:: [=registration extension|Registration=] and [=authentication extension|authentication=]  : Client extension input ::  <xmp class="idl">     partial dictionary AuthenticationExtensionsClientInputs {         AuthenticationExtensionsLargeBlobInputs largeBlob;     }; +    enum LargeBlobSupport {+      "required",+      "preferred",+    };+     dictionary AuthenticationExtensionsLargeBlobInputs {+        DOMString support;         boolean read;         ArrayBuffer write;     };     </xmp>      <div dfn-type="dict-member" dfn-for="AuthenticationExtensionsLargeBlobInputs">+        :   <dfn>support</dfn>+        ::  A DOMString that takes one of the values of {{LargeBlobSupport}}. (See [[#sct-domstring-backwards-compatibility]].) Only valid during [=registration extension|registration=].+         :   <dfn>read</dfn>-        ::  A boolean that indicates that the [=[RP]=] would like to fetch the previously-written blob associated with the asserted credential.+        ::  A boolean that indicates that the [=[RP]=] would like to fetch the previously-written blob associated with the asserted credential. Only valid during [=authentication extension|authentication=].          :   <dfn>write</dfn>-        ::  An opaque byte string that the [=[RP]=] wishes to store with the existing credential.+        ::  An opaque byte string that the [=[RP]=] wishes to store with the existing credential. Only valid during [=authentication extension|authentication=].     </div> +: Client extension processing ([=registration extension|registration=])

Done.

agl

comment created time in a month

PullRequestReviewEvent

push eventagl/webauthn

Adam Langley

commit sha 0c29080c5bfdd17cab925e773b5d427a897610d5

Address Nina's comments

view details

push time in a month

push eventw3c/webauthn

Adam Langley

commit sha f5b68078855e9b68a492ecab74efc95f18ec711e

Update description of residentKey. This change emphasises |residentKey| over |requireResidentKey| and updates some wording to note that the naming is historic. It adds a note to highlight one implication of the fact that RPs cannot always know whether a created credential is discoverable or not. Lastly it adds a remark in the credProps extension about why the |rk| field may be often omitted by user agents. Fixes #1459, #1457.

view details

Adam Langley

commit sha e3af510efa99e61a2159062ac74fabd2c1b56d45

Note that user agents will try to populate rk.

view details

Adam Langley

commit sha 5690b57c0f34dfe691af03a22d69e2c626c1beea

Apply Jeff's suggestion. Co-authored-by: =JeffH <jdhodges@google.com>

view details

Adam Langley

commit sha b4148f23dfbaebc8d148ee92fc6b1f5831e7ccf8

Merge pull request #1467 from agl/rkdesc Update description of residentKey

view details

push time in a month

PR merged w3c/webauthn

Reviewers
Update description of residentKey type:editorial

This change emphasises |residentKey| over |requireResidentKey| and updates some wording to note that the naming is historic. It adds a note to highlight one implication of the fact that RPs cannot always know whether a created credential is discoverable or not. Lastly it adds a remark in the credProps extension about why the |rk| field may be often omitted by user agents.

Fixes #1459, #1457.

<!-- This comment and the below content is programatically generated. You may add a comma-separated list of anchors you'd like a direct link to below (e.g. #idl-serializers, #idl-sequence):

Don't remove this comment or modify anything below this line.
If you don't want a preview generated for this pull request,
just replace the whole of this comment's content by "no preview"
and remove what's below.

-->


<a href="https://pr-preview.s3.amazonaws.com/agl/webauthn/pull/1467.html" title="Last updated on Aug 24, 2020, 6:54 PM UTC (5690b57)">Preview</a> | <a href="https://pr-preview.s3.amazonaws.com/w3c/webauthn/1467/f018e59...agl:5690b57.html" title="Last updated on Aug 24, 2020, 6:54 PM UTC (5690b57)">Diff</a>

+14 -17

2 comments

1 changed file

agl

pr closed time in a month

issue closedw3c/webauthn

revise "resident key" language in authenticatorSelection section to emphasize the "(non-)discoverable" notion

Section 5.4.4. Authenticator Selection Criteria (dictionary AuthenticatorSelectionCriteria) was not updated when we deprecated the "resident key" language (oops) and really ought to be in order to clarify the "discoverable" distinction.

see also issue #1457.

closed time in a month

equalsJeffH

push eventagl/webauthn

Adam Langley

commit sha 5690b57c0f34dfe691af03a22d69e2c626c1beea

Apply Jeff's suggestion. Co-authored-by: =JeffH <jdhodges@google.com>

view details

push time in a month

push eventgoogle/boringssl

David Benjamin

commit sha 1c58648f14ed75f2a8cc3ae08897987d97f493ec

Remove sxnet and pkey_usage_period extensions. These aren't used within the verifier and no one ever extracts them. Update-Note: Parsers for these two extensions are removed. Parsing the types directly or passing NID_sxnet and NID_pkey_usage_period into X509V3_get_d2i, or *_get_ext_d2i will no longer work. Change-Id: I359e64466fd0c042eda45c41cbc0843ebb04df9f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42585 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

BoringSSL Robot

commit sha f85220b3eb4d7a5dd694c9864a7490fc23a06b17

update master-with-bazel from master branch

view details

push time in a month

push eventgoogle/boringssl

David Benjamin

commit sha 1c58648f14ed75f2a8cc3ae08897987d97f493ec

Remove sxnet and pkey_usage_period extensions. These aren't used within the verifier and no one ever extracts them. Update-Note: Parsers for these two extensions are removed. Parsing the types directly or passing NID_sxnet and NID_pkey_usage_period into X509V3_get_d2i, or *_get_ext_d2i will no longer work. Change-Id: I359e64466fd0c042eda45c41cbc0843ebb04df9f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42585 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

push time in a month

push eventgoogle/boringssl

David Benjamin

commit sha 125a38fad9fc08cb9ac36925988c667d04fda993

Const-correct various X509 functions. Actually making crypto/asn1 and crypto/x509 const-correct will be a tall order, between all the hidden caches, non-const ASN.1 macros, and ambiguity between mutable and immutable getters. But upstream const-corrected a number of things, so align with them. (In particular, it is not currently possible to usefully use a non-const X509_NAME.) I think I've gotten most of x509.h. I started going through x509v3.h, but all the conf bits take non-const char* pointers, which shows up in the public (but probably unused) X509V3_CONF_METHOD, so I've left it alone in this CL. For some reason, OpenSSL made X509_get_subject_name a const-to-non-const function but kept X509_get_serialNumber uniformly non-const while adding a uniformly const X509_get0_serialNumber. I've just mirrored this for compatibility's sake. Change-Id: Ia33a7576165cf2da5922807fc065f1f114b0f84c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42584 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

BoringSSL Robot

commit sha 6c5c4fbe396e442c93492108a1a483c94909d9c8

update master-with-bazel from master branch

view details

push time in a month

push eventgoogle/boringssl

David Benjamin

commit sha 125a38fad9fc08cb9ac36925988c667d04fda993

Const-correct various X509 functions. Actually making crypto/asn1 and crypto/x509 const-correct will be a tall order, between all the hidden caches, non-const ASN.1 macros, and ambiguity between mutable and immutable getters. But upstream const-corrected a number of things, so align with them. (In particular, it is not currently possible to usefully use a non-const X509_NAME.) I think I've gotten most of x509.h. I started going through x509v3.h, but all the conf bits take non-const char* pointers, which shows up in the public (but probably unused) X509V3_CONF_METHOD, so I've left it alone in this CL. For some reason, OpenSSL made X509_get_subject_name a const-to-non-const function but kept X509_get_serialNumber uniformly non-const while adding a uniformly const X509_get0_serialNumber. I've just mirrored this for compatibility's sake. Change-Id: Ia33a7576165cf2da5922807fc065f1f114b0f84c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42584 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

push time in a month

push eventgoogle/boringssl

David Benjamin

commit sha 95d8eaa660040cfe7075a6a0390038a10cb64ff7

Make X509_set_not{Before,After} functions rather than macros. Some bindings libraries are sensitive to the difference and break with https://boringssl-review.googlesource.com/c/boringssl/+/42524. Change-Id: If7c3758fba3f71575c36b663fa5e596391e4b362 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42604 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

BoringSSL Robot

commit sha 1d53ac422ccae993ff29b21351df806af47a8f65

update master-with-bazel from master branch

view details

push time in a month

push eventgoogle/boringssl

David Benjamin

commit sha 95d8eaa660040cfe7075a6a0390038a10cb64ff7

Make X509_set_not{Before,After} functions rather than macros. Some bindings libraries are sensitive to the difference and break with https://boringssl-review.googlesource.com/c/boringssl/+/42524. Change-Id: If7c3758fba3f71575c36b663fa5e596391e4b362 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42604 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

push time in a month

push eventgoogle/boringssl

David Benjamin

commit sha 48cb69f8bd5606933e1844460551a4bc140622c0

Add X509_get0_uids from OpenSSL 1.1.0. Change-Id: I89938c652abe6b0a04808070a6d1f131dc3484b7 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42564 Reviewed-by: Adam Langley <agl@google.com>

view details

push time in a month

push eventgoogle/boringssl

David Benjamin

commit sha 48cb69f8bd5606933e1844460551a4bc140622c0

Add X509_get0_uids from OpenSSL 1.1.0. Change-Id: I89938c652abe6b0a04808070a6d1f131dc3484b7 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42564 Reviewed-by: Adam Langley <agl@google.com>

view details

BoringSSL Robot

commit sha 8d5a33f6ec0d781a261ecfc7c18981a64452deae

update master-with-bazel from master branch

view details

push time in a month

issue openedgorilla/websocket

[bug] Documentation for selecting subprotocols incorrect

Upgrader.Upgrade says:

// The responseHeader is included in the response to the client's upgrade // request. Use the responseHeader to specify cookies (Set-Cookie) and the // application negotiated subprotocol (Sec-WebSocket-Protocol).

But that's wrong. The Sec-WebSocket-Protocol header is filtered out from responseHeader and has to come from settting Upgrader.Subprotocols.

created time in a month

push eventgoogle/boringssl

David Benjamin

commit sha 9372f38cd06d181e8c9badf34d0d733670f282cc

Bound RSA and DSA key sizes better. Most asymmetric operations scale superlinearly, which makes them potential DoS vectors. This (and other problems) are mitigated with fixed sizes, like RSA-2048, P-256, or curve25519. In older algorithms like RSA and DSA, these sizes are conventions rather than well-defined algorithms. "Everyone" uses RSA-2048, but code which imports an RSA key may see an arbitrary key size, possibly from an untrusted source. This is commonly a public key, so we bound RSA key sizes in check_modulus_and_exponent_sizes. However, some applications import external private keys, and may need tighter bounds. These typically parse the key then check the result. However, parsing itself can perform superlinear work (RSA_check_key or recovering the DSA public key). This CL does the following: - Rename check_modulus_and_exponent_sizes to rsa_check_public_key and additionally call it from RSA_check_key. - Fix a bug where RSA_check_key, on CRT-less keys, did not bound d, and bound p and q before multiplying (quadratic). - Our DSA verifier had stricter checks on q (160-, 224-, and 256-bit only) than our DSA signer (multiple of 8 bits). Aligner the signer to the verifier's checks. - Validate DSA group sizes on parse, as well as priv_key < q, to bound the running time. Ideally these invariants would be checked exactly once at construction, but our RSA and DSA implementations suffer from some OpenSSL's API mistakes (https://crbug.com/boringssl/316), which means it is hard to consistently enforce invariants. This CL focuses on the parser, but later I'd like to better rationalize the freeze_private_key logic. Performance of parsing RSA and DSA keys, gathered on my laptop. Did 15130 RSA-2048 parse operations in 5022458us (3012.5 ops/sec) Did 4888 RSA-4096 parse operations in 5060606us (965.9 ops/sec) Did 354 RSA-16384 parse operations in 5043565us (70.2 ops/sec) Did 88 RSA-32768 parse operations in 5038293us (17.5 ops/sec) [rejected by this CL] Did 35000 DSA-1024/256 parse operations in 5030447us (6957.6 ops/sec) Did 11316 DSA-2048/256 parse operations in 5094664us (2221.1 ops/sec) Did 5488 DSA-3072/256 parse operations in 5096032us (1076.9 ops/sec) Did 3172 DSA-4096/256 parse operations in 5041220us (629.2 ops/sec) Did 840 DSA-8192/256 parse operations in 5070616us (165.7 ops/sec) Did 285 DSA-10000/256 parse operations in 5004033us (57.0 ops/sec) Did 74 DSA-20000/256 parse operations in 5066299us (14.6 ops/sec) [rejected by this CL] Update-Note: Some invalid or overly large RSA and DSA keys may previously have been accepted that are now rejected at parse time. For public keys, this only moves the error from verification to parsing. In some private key cases, we would previously allow signing with those keys, but the resulting signatures would not be accepted by BoringSSL anyway. This CL makes us behave more consistently. Bug: oss-fuzz:24730 Change-Id: I4ad2003ee61138b693e65d3da4c6aa00bc165251 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42504 Reviewed-by: Adam Langley <agl@google.com>

view details

BoringSSL Robot

commit sha 0d34ecd1a67b57eca1901de653f158ce4972a777

update master-with-bazel from master branch

view details

push time in a month

push eventgoogle/boringssl

David Benjamin

commit sha 9372f38cd06d181e8c9badf34d0d733670f282cc

Bound RSA and DSA key sizes better. Most asymmetric operations scale superlinearly, which makes them potential DoS vectors. This (and other problems) are mitigated with fixed sizes, like RSA-2048, P-256, or curve25519. In older algorithms like RSA and DSA, these sizes are conventions rather than well-defined algorithms. "Everyone" uses RSA-2048, but code which imports an RSA key may see an arbitrary key size, possibly from an untrusted source. This is commonly a public key, so we bound RSA key sizes in check_modulus_and_exponent_sizes. However, some applications import external private keys, and may need tighter bounds. These typically parse the key then check the result. However, parsing itself can perform superlinear work (RSA_check_key or recovering the DSA public key). This CL does the following: - Rename check_modulus_and_exponent_sizes to rsa_check_public_key and additionally call it from RSA_check_key. - Fix a bug where RSA_check_key, on CRT-less keys, did not bound d, and bound p and q before multiplying (quadratic). - Our DSA verifier had stricter checks on q (160-, 224-, and 256-bit only) than our DSA signer (multiple of 8 bits). Aligner the signer to the verifier's checks. - Validate DSA group sizes on parse, as well as priv_key < q, to bound the running time. Ideally these invariants would be checked exactly once at construction, but our RSA and DSA implementations suffer from some OpenSSL's API mistakes (https://crbug.com/boringssl/316), which means it is hard to consistently enforce invariants. This CL focuses on the parser, but later I'd like to better rationalize the freeze_private_key logic. Performance of parsing RSA and DSA keys, gathered on my laptop. Did 15130 RSA-2048 parse operations in 5022458us (3012.5 ops/sec) Did 4888 RSA-4096 parse operations in 5060606us (965.9 ops/sec) Did 354 RSA-16384 parse operations in 5043565us (70.2 ops/sec) Did 88 RSA-32768 parse operations in 5038293us (17.5 ops/sec) [rejected by this CL] Did 35000 DSA-1024/256 parse operations in 5030447us (6957.6 ops/sec) Did 11316 DSA-2048/256 parse operations in 5094664us (2221.1 ops/sec) Did 5488 DSA-3072/256 parse operations in 5096032us (1076.9 ops/sec) Did 3172 DSA-4096/256 parse operations in 5041220us (629.2 ops/sec) Did 840 DSA-8192/256 parse operations in 5070616us (165.7 ops/sec) Did 285 DSA-10000/256 parse operations in 5004033us (57.0 ops/sec) Did 74 DSA-20000/256 parse operations in 5066299us (14.6 ops/sec) [rejected by this CL] Update-Note: Some invalid or overly large RSA and DSA keys may previously have been accepted that are now rejected at parse time. For public keys, this only moves the error from verification to parsing. In some private key cases, we would previously allow signing with those keys, but the resulting signatures would not be accepted by BoringSSL anyway. This CL makes us behave more consistently. Bug: oss-fuzz:24730 Change-Id: I4ad2003ee61138b693e65d3da4c6aa00bc165251 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42504 Reviewed-by: Adam Langley <agl@google.com>

view details

push time in a month

push eventgoogle/boringssl

David Benjamin

commit sha c947efabcbc38dcf93e8ad0e6a76206cf0ec8072

Add set1 versions of X509 timestamp setters. OpenSSL renamed the preferred spelling of X509_set_notBefore to X509_set1_notBefore, etc., in 568ce3a583a17c33feacbf5028ece9f7f0680478. Add the set1 names and update uses within the library. Change-Id: Ib211e356da9de963990ad2b330249383ccfef7e5 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42524 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

BoringSSL Robot

commit sha 2d53ce8955d8b6bc6fc47fbe3fc8f594be1a78bc

update master-with-bazel from master branch

view details

push time in a month

push eventgoogle/boringssl

David Benjamin

commit sha c947efabcbc38dcf93e8ad0e6a76206cf0ec8072

Add set1 versions of X509 timestamp setters. OpenSSL renamed the preferred spelling of X509_set_notBefore to X509_set1_notBefore, etc., in 568ce3a583a17c33feacbf5028ece9f7f0680478. Add the set1 names and update uses within the library. Change-Id: Ib211e356da9de963990ad2b330249383ccfef7e5 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42524 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

push time in a month

push eventgoogle/boringssl

David Benjamin

commit sha edd4c5f76796e7c03168f8e30740d9edfc6caa90

Consistently sort generated build files. Most of the output formats manually call sorted(), which I've retained since they often concatenate multiple file lists, but the JSON output dumps the object to JSON directly. Sort everything earlier so the JSON output is deterministic. Change-Id: I9940f4ef3eb85a3fd7337058f5d7ce0ce6e28b9d Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42544 Reviewed-by: Adam Langley <agl@google.com>

view details

BoringSSL Robot

commit sha 57cd304dd461276d24d9132530abdce36e55088e

update master-with-bazel from master branch

view details

push time in a month

push eventgoogle/boringssl

David Benjamin

commit sha edd4c5f76796e7c03168f8e30740d9edfc6caa90

Consistently sort generated build files. Most of the output formats manually call sorted(), which I've retained since they often concatenate multiple file lists, but the JSON output dumps the object to JSON directly. Sort everything earlier so the JSON output is deterministic. Change-Id: I9940f4ef3eb85a3fd7337058f5d7ce0ce6e28b9d Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42544 Reviewed-by: Adam Langley <agl@google.com>

view details

push time in a month

Pull request review commentw3c/webauthn

Update description of residentKey

 At this time, one [=credential property=] is defined: the [=resident key credent             (i.e., <dfn dfn-type="dfn">client-side discoverable credential property</dfn>),             is a Boolean value indicating whether the {{PublicKeyCredential}} returned as a result of a [=registration ceremony=]             is a [=client-side discoverable credential=].-            If {{rk}} is [TRUE], the credential is a [=discoverable credential=];+            If {{rk}} is [TRUE], the credential is a [=discoverable credential=].             if {{rk}} is [FALSE], the credential is a [=server-side credential=].             If {{rk}} is not present, it is not known whether the credential is a [=discoverable credential=] or a [=server-side credential=].++            Note: some [=authenticators=] create [=discoverable credentials=] even when not requested by the user agent. Because of this, user agents may be forced to omit the {{rk}} property because they lack the assurance to be able to set it to [FALSE]. [=[RPS]=] should assume that, if the `credProps` extension is supported, then user agents will endeavour to populate the {{rk}} property. Therefore a missing {{rk}} indicates that the user agent believes that the created credential is mostly likely a [=non-discoverable credential=].

s/mostly/most/

agl

comment created time in a month

PullRequestReviewEvent

push eventw3c/webauthn

Adam Langley

commit sha 5ceefed29f6c8fb4c947d58b99aa6bb2ee092d28

Note that rk=preferred means strongly preferred. Fixes #1463

view details

Adam Langley

commit sha 0eb0ee9d5869b3bd9520010e25b7a0b70690de23

Correct dictionary reference

view details

Adam Langley

commit sha ad8d1d0897bc88703fa6a6a6ad9deea92ed3c9ec

Merge pull request #1466 from agl/rkpref Note that rk=preferred means strongly preferred.

view details

push time in a month

PR merged w3c/webauthn

Reviewers
Note that rk=preferred means strongly preferred. type:editorial

Fixes #1463

<!-- This comment and the below content is programatically generated. You may add a comma-separated list of anchors you'd like a direct link to below (e.g. #idl-serializers, #idl-sequence):

Don't remove this comment or modify anything below this line.
If you don't want a preview generated for this pull request,
just replace the whole of this comment's content by "no preview"
and remove what's below.

-->


<a href="https://pr-preview.s3.amazonaws.com/agl/webauthn/pull/1466.html" title="Last updated on Aug 17, 2020, 9:01 PM UTC (0eb0ee9)">Preview</a> | <a href="https://pr-preview.s3.amazonaws.com/w3c/webauthn/1466/f018e59...agl:0eb0ee9.html" title="Last updated on Aug 17, 2020, 9:01 PM UTC (0eb0ee9)">Diff</a>

+2 -2

0 comment

1 changed file

agl

pr closed time in a month

issue closedw3c/webauthn

How "preferred" is a "preferred" resident key

Now that we have the residentKey tri-state {discouraged, preferred, required} implemented, we should define what "level of preferredness" preferred actually means so that users have a consistent experience across client platforms.

There are multiple options: i) We’ll always create a resident key, even if we have to guide the user in setting up a PIN first. ii) If internal-UV or a PIN is already configured, we’ll prompt for a PIN / do UV and, if successful, create a resident key.

I'd like to vote that we do (i) where possible, and on devices (such as phones where we can't guide the user through PIN setup today) we do (ii), but with the intent to move to (i) in the long run.

What do folks thinks about this? Can we make a PR to tighten this up in the spec?

closed time in a month

christiaanbrand

Pull request review commentw3c/webauthn

Update description of residentKey

 attributes.     ::  If this member is present, eligible authenticators are filtered to only authenticators attached with the         specified [[#enum-attachment]]. The value SHOULD be a member of {{AuthenticatorAttachment}} but [=client platforms=] MUST ignore unknown values, treating an unknown value as if the [=map/exist|member does not exist=]. -    :   <dfn>requireResidentKey</dfn>-    ::  Note: This member is retained for backwards compatibility with WebAuthn Level 1 but is deprecated in favour of {{residentKey}}.-        {{requireResidentKey}} is ignored if the caller supplies {{residentKey}} and the latter is understood by the [=client=].-        Otherwise, {{requireResidentKey}}'s value is used. Note that {{requireResidentKey}}'s value defaults to [FALSE].--        If used in absence of {{residentKey}}, it describes the [=[RP]=]'s requirements regarding [=client-side discoverable credentials=].-        If {{requireResidentKey}} is set to [TRUE], the authenticator MUST create a [=client-side discoverable public key credential source=]-        when creating a [=public key credential=].-     :   <dfn>residentKey</dfn>-    ::  Note: This member supersedes {{requireResidentKey}}. If both are present and the [=client=] understands {{residentKey}}, then-        {{residentKey}} is used and {{requireResidentKey}} is ignored.+    ::  Specifies the extent to which the [=[RP]=] desires to create a [=client-side discoverable credential=]. For historical reasons the naming retains the deprecated “resident” terminology. The value SHOULD be a member of {{ResidentKeyRequirement}} but [=client platforms=] MUST ignore unknown values, treating an unknown value as if the [=map/exist|member does not exist=]. If no value is given then the effective value is {{ResidentKeyRequirement/required}} if {{requireResidentKey}} is [TRUE] or {{ResidentKeyRequirement/discouraged}} if it is [FALSE] or absent. -        The value SHOULD be a member of {{ResidentKeyRequirement}} but [=client platforms=] MUST ignore unknown values, treating an unknown value as if the [=map/exist|member does not exist=]. See {{ResidentKeyRequirement}} for the description of {{residentKey}}'s values and semantics.+        See {{ResidentKeyRequirement}} for the description of {{residentKey}}'s values and semantics.++    :   <dfn>requireResidentKey</dfn>

This will allow RPs to continue to work with user-agents that only implement WebAuth level one. Preferred will never result in a resident credential, but required will.

agl

comment created time in a month

PullRequestReviewEvent

PR opened w3c/webauthn

Make largeBlobs explicit during create.

Once largeBlobKey (at CTAP2) became something that the authenticator could derive I had hoped that we could simplify the WebAuthn level extension and not have a creation extension. Instead, user agents could just always create a largeBlobKey in contexts where the extension could be used.

However 100% (i.e. both) people who have looked at this now though that was non-obvious and so it's probably Too Cute and should be More Explicit. Also, it's been suggested that it would be a waste of a resident credential if the RP needed to store a blob and only found out after at assertion time that it wouldn't work.

+30 -5

0 comment

1 changed file

pr created time in a month

create barnchagl/webauthn

branch : largeblobcreate

created branch time in a month

pull request commentw3c/webauthn

Update description of residentKey

Can this language be restored?

I believe all the points in that are now covered elsewhere and that it would only confuse matters. Is there aspect you think is missing?

agl

comment created time in a month

Pull request review commentw3c/webauthn

Update description of residentKey

 At this time, one [=credential property=] is defined: the [=resident key credent             If {{rk}} is [TRUE], the credential is a [=discoverable credential=];             if {{rk}} is [FALSE], the credential is a [=server-side credential=].             If {{rk}} is not present, it is not known whether the credential is a [=discoverable credential=] or a [=server-side credential=].++            Note: some [=authenticators=] create [=discoverable credentials=] even when not requested by the user agent. Because of this, user agents may be forced to omit the {{rk}} property because they lack the assurance to be able to set it to [FALSE].

That's a good point. I've updated this to note that user-agents should try to populate rk. Thus, if it's missing, the user-agent believes that the credential is non-discoverable — it's just can't be completely sure with CTAP 2.0.

agl

comment created time in a month

push eventagl/webauthn

Adam Langley

commit sha e3af510efa99e61a2159062ac74fabd2c1b56d45

Note that user agents will try to populate rk.

view details

push time in a month

push eventagl/webauthn

Adam Langley

commit sha 0eb0ee9d5869b3bd9520010e25b7a0b70690de23

Correct dictionary reference

view details

Adam Langley

commit sha f5b68078855e9b68a492ecab74efc95f18ec711e

Update description of residentKey. This change emphasises |residentKey| over |requireResidentKey| and updates some wording to note that the naming is historic. It adds a note to highlight one implication of the fact that RPs cannot always know whether a created credential is discoverable or not. Lastly it adds a remark in the credProps extension about why the |rk| field may be often omitted by user agents. Fixes #1459, #1457.

view details

Adam Langley

commit sha 5c2b04ffe1ff669427ad7864b455eac0320c3a94

Update description of residentKey. This change emphasises |residentKey| over |requireResidentKey| and updates some wording to note that the naming is historic. It adds a note to highlight one implication of the fact that RPs cannot always know whether a created credential is discoverable or not. Lastly it adds a remark in the credProps extension about why the |rk| field may be often omitted by user agents. Fixes #1459, #1457.

view details

push time in a month

push eventagl/webauthn

Adam Langley

commit sha 0eb0ee9d5869b3bd9520010e25b7a0b70690de23

Correct dictionary reference

view details

push time in a month

push eventgoogle/boringssl

Adam Langley

commit sha 56308910f38a7e558205eccda134bc6e2215fb7e

delocate: use 64-bit GOT offsets in the large memory model. I tried to save space and use 32-bit GOT offsets since a GOT > 2GiB is crazy. However, Clang's linker emits 64-bit relocations even for .long, thus the four bytes following each offset get stomped. It mostly works because the relocations are applied in order, thus the following relocation gets stomped but is then processed and fixed. But there's four bytes of stomp at the end which hits the module integrity hash, which is fatal. This could be fixed by adding four bytes of padding after the list of offsets, but that's piling a hack on a hack. So this change just switches to 64-bit offsets. Change-Id: I227eec67c481d93a414fbed19aa99471f9df0f0e Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42484 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

BoringSSL Robot

commit sha 412844d75b14b9090b58423fd5f5ed8c2fd80212

update master-with-bazel from master branch

view details

push time in a month

push eventgoogle/boringssl

Adam Langley

commit sha 56308910f38a7e558205eccda134bc6e2215fb7e

delocate: use 64-bit GOT offsets in the large memory model. I tried to save space and use 32-bit GOT offsets since a GOT > 2GiB is crazy. However, Clang's linker emits 64-bit relocations even for .long, thus the four bytes following each offset get stomped. It mostly works because the relocations are applied in order, thus the following relocation gets stomped but is then processed and fixed. But there's four bytes of stomp at the end which hits the module integrity hash, which is fatal. This could be fixed by adding four bytes of padding after the list of offsets, but that's piling a hack on a hack. So this change just switches to 64-bit offsets. Change-Id: I227eec67c481d93a414fbed19aa99471f9df0f0e Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42484 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

push time in a month

Pull request review commentw3c/webauthn

Note that rk=preferred means strongly preferred.

 This enumeration's values describe the [=[RP]=]'s requirements for [=client-side         [=client-side discoverable credential=].      :   <dfn>preferred</dfn>-    ::  This value indicates the [=[RP]=] prefers creating a [=client-side discoverable credential=], but will accept a-        [=server-side credential=].+    ::  This value indicates the [=[RP]=] strongly prefers creating a [=client-side discoverable credential=], but will accept a+        [=server-side credential=]. For example, user agents SHOULD guide the user through setting up [=user verification=] if needed to create a [=client-side discoverable credential=] in this case. This takes precedence over the setting of {{PublicKeyCredentialRequestOptions/userVerification}}.

Note to self: should be creation options, not request options.

agl

comment created time in a month

push eventgoogle/boringssl

Daniel McArdle

commit sha 430ccd616381e7f008648a4b42167a8d02fc5762

Update HPKE implementation and test vectors to draft-irtf-cfrg-hpke-05. Bug: 275 Change-Id: I8af401f84b235e6249fb13161d26dc489f3415bd Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42444 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

BoringSSL Robot

commit sha 461b00f40594d6f219efded8aedef9710dd51502

update master-with-bazel from master branch

view details

push time in a month

push eventgoogle/boringssl

Daniel McArdle

commit sha 430ccd616381e7f008648a4b42167a8d02fc5762

Update HPKE implementation and test vectors to draft-irtf-cfrg-hpke-05. Bug: 275 Change-Id: I8af401f84b235e6249fb13161d26dc489f3415bd Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42444 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

push time in a month

push eventgoogle/boringssl

Adam Langley

commit sha d3a5b87aed103460a12dc2ca29ce4ae94733b304

Handle NULL arguments in some i2d_* functions. Prior to 5d7c2f8b1d, these i2d functions would fail, rather than crash, if passed a NULL argument. While we don't generally have much truck with the idea that functions should be expected to handle NULL arguments where not documented, it seems that a fair amount of code is depending on this. Change-Id: I928b35533aa2a7beed57d7f58ba44681a8eb05c6 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42464 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

BoringSSL Robot

commit sha 4825e4a2f97f58de9497cc9e0a7e539964278a68

update master-with-bazel from master branch

view details

push time in a month

push eventgoogle/boringssl

Adam Langley

commit sha d3a5b87aed103460a12dc2ca29ce4ae94733b304

Handle NULL arguments in some i2d_* functions. Prior to 5d7c2f8b1d, these i2d functions would fail, rather than crash, if passed a NULL argument. While we don't generally have much truck with the idea that functions should be expected to handle NULL arguments where not documented, it seems that a fair amount of code is depending on this. Change-Id: I928b35533aa2a7beed57d7f58ba44681a8eb05c6 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42464 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

push time in a month

push eventgoogle/boringssl

Tamas Petz

commit sha a0b49d63fdc33e54eac93674c86891d15d181d87

aarch64: support BTI and pointer authentication in assembly This change adds optional support for - Armv8.3-A Pointer Authentication (PAuth) and - Armv8.5-A Branch Target Identification (BTI) features to the perl scripts. Both features can be enabled with additional compiler flags. Unless any of these are enabled explicitly there is no code change at all. The extensions are briefly described below. Please read the appropriate chapters of the Arm Architecture Reference Manual for the complete specification. Scope ----- This change only affects generated assembly code. Armv8.3-A Pointer Authentication -------------------------------- Pointer Authentication extension supports the authentication of the contents of registers before they are used for indirect branching or load. PAuth provides a probabilistic method to detect corruption of register values. PAuth signing instructions generate a Pointer Authentication Code (PAC) based on the value of a register, a seed and a key. The generated PAC is inserted into the original value in the register. A PAuth authentication instruction recomputes the PAC, and if it matches the PAC in the register, restores its original value. In case of a mismatch, an architecturally unmapped address is generated instead. With PAuth, mitigation against ROP (Return-oriented Programming) attacks can be implemented. This is achieved by signing the contents of the link-register (LR) before it is pushed to stack. Once LR is popped, it is authenticated. This way a stack corruption which overwrites the LR on the stack is detectable. The PAuth extension adds several new instructions, some of which are not recognized by older hardware. To support a single codebase for both pre Armv8.3-A targets and newer ones, only NOP-space instructions are added by this patch. These instructions are treated as NOPs on hardware which does not support Armv8.3-A. Furthermore, this patch only considers cases where LR is saved to the stack and then restored before branching to its content. There are cases in the code where LR is pushed to stack but it is not used later. We do not address these cases as they are not affected by PAuth. There are two keys available to sign an instruction address: A and B. PACIASP and PACIBSP only differ in the used keys: A and B, respectively. The keys are typically managed by the operating system. To enable generating code for PAuth compile with -mbranch-protection=<mode>: - standard or pac-ret: add PACIASP and AUTIASP, also enables BTI (read below) - pac-ret+b-key: add PACIBSP and AUTIBSP Armv8.5-A Branch Target Identification -------------------------------------- Branch Target Identification features some new instructions which protect the execution of instructions on guarded pages which are not intended branch targets. If Armv8.5-A is supported by the hardware, execution of an instruction changes the value of PSTATE.BTYPE field. If an indirect branch lands on a guarded page the target instruction must be one of the BTI <jc> flavors, or in case of a direct call or jump it can be any other instruction. If the target instruction is not compatible with the value of PSTATE.BTYPE a Branch Target Exception is generated. In short, indirect jumps are compatible with BTI <j> and <jc> while indirect calls are compatible with BTI <c> and <jc>. Please refer to the specification for the details. Armv8.3-A PACIASP and PACIBSP are implicit branch target identification instructions which are equivalent with BTI c or BTI jc depending on system register configuration. BTI is used to mitigate JOP (Jump-oriented Programming) attacks by limiting the set of instructions which can be jumped to. BTI requires active linker support to mark the pages with BTI-enabled code as guarded. For ELF64 files BTI compatibility is recorded in the .note.gnu.property section. For a shared object or static binary it is required that all linked units support BTI. This means that even a single assembly file without the required note section turns-off BTI for the whole binary or shared object. The new BTI instructions are treated as NOPs on hardware which does not support Armv8.5-A or on pages which are not guarded. To insert this new and optional instruction compile with -mbranch-protection=standard (also enables PAuth) or +bti. When targeting a guarded page from a non-guarded page, weaker compatibility restrictions apply to maintain compatibility between legacy and new code. For detailed rules please refer to the Arm ARM. Compiler support ---------------- Compiler support requires understanding '-mbranch-protection=<mode>' and emitting the appropriate feature macros (__ARM_FEATURE_BTI_DEFAULT and __ARM_FEATURE_PAC_DEFAULT). The current state is the following: ------------------------------------------------------- | Compiler | -mbranch-protection | Feature macros | +----------+---------------------+--------------------+ | clang | 9.0.0 | 11.0.0 | +----------+---------------------+--------------------+ | gcc | 9 | expected in 10.1+ | ------------------------------------------------------- Available Platforms ------------------ Arm Fast Model and QEMU support both extensions. https://developer.arm.com/tools-and-software/simulation-models/fast-models https://www.qemu.org/ Implementation Notes -------------------- This change adds BTI landing pads even to assembly functions which are likely to be directly called only. In these cases, landing pads might be superfluous depending on what code the linker generates. Code size and performance impact for these cases would be negligble. Interaction with C code ----------------------- Pointer Authentication is a per-frame protection while Branch Target Identification can be turned on and off only for all code pages of a whole shared object or static binary. Because of these properties if C/C++ code is compiled without any of the above features but assembly files support any of them unconditionally there is no incompatibility between the two. Useful Links ------------ To fully understand the details of both PAuth and BTI it is advised to read the related chapters of the Arm Architecture Reference Manual (Arm ARM): https://developer.arm.com/documentation/ddi0487/latest/ Additional materials: "Providing protection for complex software" https://developer.arm.com/architectures/learn-the-architecture/providing-protection-for-complex-software Arm Compiler Reference Guide Version 6.14: -mbranch-protection https://developer.arm.com/documentation/101754/0614/armclang-Reference/armclang-Command-line-Options/-mbranch-protection?lang=en Arm C Language Extensions (ACLE) https://developer.arm.com/docs/101028/latest Change-Id: I4335f92e2ccc8e209c7d68a0a79f1acdf3aeb791 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42084 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>

view details

BoringSSL Robot

commit sha 8d984843753e0179c6da24f00db52b0bb633345d

update master-with-bazel from master branch

view details

push time in a month

more